LAX, SCALE, KDE, SUSE, GNOME and ownCloud

Lobby of the venue

Back home. Tired and jetlaggy, but satisfied: SCALE rocked!

SCALE loves ownCloud

The 13th South California Linux Expo was awesome! It is the biggest LinuxFest in the USA. While decidedly different in nature from Europe's biggest Linux event that that took place just three weeks prior (FOSDEM), we met similarly enthusiastic existing and future users. Conversations were also similar: about half the visitors already knew ownCloud, often using it or planning on deploying it; and the other half was more than a little delighted to hear about it, often exclaiming they had been looking for 'something like that' for a while. Negativity was extremely rare: I don't recall a single negative comment at SCALE (merely a few people who liked ownCloud but had no use for it personally), FOSDEM had one conversation starting unpleasantly but quickly turning around - even though one feature of ownCloud wasn't up to snuff, the user was happy with the experience as a whole.

Before the action started!

For most users, ownCloud was simply a wonderful product and they used it at home, deployed it for customers or managed it in their company. Some asked what features were coming or just arrived in ownCloud 8, or asked about the state of specific features and in more than one occasion they very enthusiastically told me how excited they were about ownCloud, how they loved it and how they were telling everybody to use it!

ownCloud to-go

Those who didn't know ownCloud were almost invariably surprised and excited. I can't count the times I heard "wow, why did I never hear about this before" and "dude, I've been looking for something like this for ever!". Often, people wondered how long ownCloud had been around (we just turned five), if it was open source (yes, with love), how many people contributed to it (719 and counting) and how many users it has (we guestimate over 2 million, with 500,000 in this single deployment alone). Oh, and, does it scale? The deployment linked above and a mention of users like CERN can put most concerns to rest. Yes, ownCloud scales from Raspberry Pi to Atom Smashing size.

What came up a few times as barriers to their future usage of ownCloud was pretty much what I discussed before. Running a server at home is not easy and I walked by the EFF booth to ask about progress on Let's Encrypt to ask about the progress of solving one aspect of that problem: more easily getting SSL certificates. I was told the project is on track for the 2nd half of this year.

Frank and Bryan Lunduke

It is wonderful to have such energizing, positive, enthusiastic users - and to have such an enthusiastic booth crew to talk to them as well. At the booth we had Frank, Matt, Ron, Camila and myself. Awesome it was and we had great fun! Below a timelapse video of Saturday morning. It was still rather quiet but it is nice to see us jump around!

Stuff and talk

Just like at FOSDEM, we brought ownCloud stickers, hand outs explaining ownCloud to users and developers as well as some posters for the booth and pins to give out. This was all very much appreciated - I estimate we gave out about 400 hand outs and 500 or so stickers as well as about 50-100 pins.

Sunday at 3PM, I gave a talk about Privacy and ownCloud, with Frank finishing off with a section about his talk at MIT where he discussed ownCloud's Federated Cloud sharing feature and where it is going. The talk was well received; I think the angle I took to privacy (inspired by my background in psychology) spoke to the audience and Frank's description of federation and how it's done in ownCloud was very interesting. owncloud.org and owncloud.com will feature blogs with some more information about this soon.

Friends

Big, big booth!

I also walked by the booths of 'old friends' - the openSUSE/GNOME/KDE crew in particular, it was awesome to meet them. Some I hadn't seen in years, others I met for the first time. They did an amazing job and richly deserve the reward they earned for most Stunningly Amazing Booth Crew (don't know the real name of the booth award but that's what it should be). If you think that 'just' GNOME an KDE being incorporated in the openSUSE booth isn't enough - Master Planner of the Booths Drew aims to bring in Enlightenment and XFCE as well next year. Supposedly a Trello board has been set up already. I bet it won't be long before it has grown to the point where the SCALE organization needs to give the 'openSUSE booth & friends' a separate hall at SCALE...

I have to note that it was thanks to our green friends that I could hang up the ownCloud flyers - they lend me some (green!) tape to do that.

The KDE booth had a bunch of terribly cool stickers (I only now realize I forgot to get one for myself!) as well as the "frameworks 5" flyers. I could only bring, like, 5 t-shirts and a dozen old 'join-the-game' flyers so I'm glad Bert Yerke and his wife, who formed the awesome local KDE team, had created the other materials. We already discussed 2016, as they have plenty of ideas on how to improve the booth!

Awesome stickers...

If you, dear reader, want to help out at the KDE or ownCloud booth next year - let me know, either in the comments or by mail. I can promise you: it is awesomely fun and by far not as scary as you might think! Bert and Matt and everybody who has ever been at a KDE, openSUSE, ownCloud or other FOSS booth can attest to that: it is a great way of getting involved and making a big difference!

Bonus points for who finds a suitable meaning for the one item in the title which isn't yet an acrynym ;-)

Leaving SUSE

Dear Geekos,

I'll be leaving SUSE by the end of this month.

What that means

That does not mean I am running away from all things green, I still have no less than 5 talks to give at the openSUSE conference and I will certainly continue to put in some spare time for the marketing of oSC14 and news.opensuse.org! But it won't be a full time contribution anymore.

Now I know there have been some heavy discussions lately about where we as openSUSE community are going and despite the rather rough start, I think we are on the right track now. The openSUSE Team is hacking on OBS, openQA and other tools and that will help improve both the quality of openSUSE as a distro. I also think the new board is great and will make a difference on the community side.

You all rock!

My time at SUSE has been amazing. You, the openSUSE community, are awesome, smart, sweet and fun. openSUSE as a distro is kick-ass, OBS rocks and so on. I'm proud to be a part of the Geeko crowd and be allowed to make my modest contribution. And it was great meet you at events and conferences around the world!

You might wonder where I'm going - well, I have to keep that under wraps until the end of this month. But I'm not leaving Free and Open Source behind and I'll still run openSUSE!

See you later, Geekonator...


PS: In the spirit of my cat presentations, let me finish this post with a pair of cute eyes from our dog Popcorn...

Summit, Con, Release...

The last weeks before my holiday have been quite crazy for me. SUSECon, openSUSE Summit and of course the openSUSE 13.1 release. Meanwhile, the openSUSE Board Elections have started... I decided to really try and stay away from things for two weeks. I'm not particularly good at that and I did a few thingies but I managed not too shoddy. Saw a museum, did pick up running again, watched some movies...

Now, back to SUSECon, the Summit and the release!

SUSECon,oS Summit

First things first, SUSECon and the openSUSE Summit were awesome. It is always wonderful how much energy these events give - so many enthusiastic people, ideas, plans...



On the press side during SUSECon, I kept myself busy with talking to 7 of the journalists, doing and arranging interviews or finding answers to their questions about openSUSE. And with Robert Schweikert I presented a session (twice) about the collaboration between SUSE and openSUSE. ITWire reported on this talk. We ran a booth at SUSECon as well and it was, as always, great to talk to people there.

On Wednesday was a Pirate Party, Thursday a visit to the Epcot park. I'm not a huge fan of such parks but it was entertaining enough to get food there... And I had great company!



At the Summit I presented two sessions, one about handling a booth and one about building local communities. In both cases, there was a lot of awesome feedback from the room and at the Orlando airport and further during the trip back I worked the suggestions in the presentations for further sharing. Thanks! I also really appreciated the private conversations about these topics which took place later on.



But the most important thing, for me, was meeting old friends again. Andi, Drew, the openSUSE Forms guys, the Greek delegation and many more. And bumping into new people like Navid and Christopher, two guys who run a media production company and want to help out openSUSE with web things. That's where the inspiring conversations happen. There were discussions about how to proceed with the Summit, how to handle community building in the Americas but also the great town hall meeting where I presented the 'Karmafication' idea for our infrastructure. This is something I might blog about later.

After the openSUSE Summit was over, Alex, Stella, Ludwig and myself went for a beach trip, video below. It was fun - although we drove an order of magnitude longer than that we actually spend on the beach ;-)

The release

Then the release, on the day I landed back from the US of A (and yes, they lost my luggage, luckily it is back). I think it went great, and seeing the response from the press I think others agree.

Now, we're debating changes to our development process on the mailing lists. Let's see how that goes!

oSC13, Strategy and Stable

At the openSUSE conference there were discussions about the future of openSUSE. Last Wednesday I summarized some of the ideas around Factory. Today I blog about the openSUSE releases.

Note: This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Stable - big picture

On the Stable release future, things are much more in the air. In his keynote, Ralf hinted that SUSE has some ideas about how the future of openSUSE should look:

• Open Governance - SUSE wants openSUSE to be successful and independently strong. Ralf noted that SUSE does not expect or aim to make money on openSUSE directly; other parties however are very much welcome to build a business around openSUSE.
• Filling the gap - SUSE and openSUSE have a great win-win relationship. But SUSE notices a gap between openSUSE and SLE in the market: SLE is oriented to large enterprises and the current openSUSE has a too wide market to feed, from newbies to hard core developers to professionals.

This is, from the SUSE side, the big picture; SUSE wants to provide room in the openSUSE ecosystem for initiatives, both from volunteers and from the commercial side. And SUSE would like openSUSE to move up a little, offer solutions for people serious about computing in a professional capacity. But what does this mean exactly?

Concrete changes

Let's start again with what came out with the keynote. Ralf essentially summarized some of SUSE and openSUSE's history and talked about our current situation. openSUSE Stable, our final release coming out every 8 months, is a compromise between stability and being-up-to-date. But this compromise was made in a time when far less people used the many repositories on OBS offering more up-to-date software; and before Tumbleweed and Evergreen saw the light of day. It is 2013 now and Ralf hinted at a possible re-evaluation of the choices that were made back then: perhaps, we should limit our scope, improve quality and increase the life cycle of openSUSE?

Improve quality

Let's talk about quality first. This is difficult, harder than it seems. Factory has some automated testing and openQA got better thanks to some recent work, but nothing can replace human testing and there is not enough of it. There is room for improving our processes here, but there is also the fact that some people in our community care more about Stable and others more about moving forward with Factory. We need to find a way to service the needs of both. Having Factory more stable, hence more usable on a day-to-day base, would be a great first step here.

Limit the scope

If you want to do something well, you should focus on it. It's the Unix philosophy many of us share: do one thing, and do it well. openSUSE is well known for doing everything a bit - making everybody a little happy, but nobody REALLY happy. Part of why this model is still working reasonably well is thanks to OBS - which has grown in this role. Many, many users these days use the openSUSE release as simply a base for their favorite OBS repositories. If we want to improve quality and lengthen the life cycle, we can use this model.

For example, parts of openSUSE which can be and are maintained longer get in the stable releases; other parts with a shorter life cycle (Firefox for example) stay on OBS. This means that being part of Stable depends on commitment from both upstream and the openSUSE maintainers of the packages; as well as testing capacity and our quality standards.

Lengthen life cycle

A portion of the openSUSE users would like to have a longer release cycle - the interest in Evergreen and questions on our mailing lists and forums make that clear. SUSE has dedicated a set amount of resources for maintaining openSUSE releases; checking security and entering bug fixes. The maintenance process is now opened up and some teams in openSUSE are contributing to the maintenance, lowering the load on the SUSE maintenance team. A smaller scope (resulting in a smaller release) would do the same, as Ralf mentioned in his keynote. This will have to be a part of the solution we're looking for to increase our maintenance window.

In practice

To put it in perspective, three examples of how we could do this. Keep in mind that sticking to the openSUSE-has-all-and-comes-every-8-months model is of course also an option...

Rings, rings, and rolling!

Presume we will have rings in Factory (see blog from Wednesday)? Let's put them in the distro. There's the core with ring 0 and ring 1 ("everything up to X"). It is released every 2 years and maintained for 3. Then, there is ring 2, with the basic desktops and their devel frameworks. They are maintained 2 years after release (every year). Then, ring 3, the applications and development tools. They are updated from OBS, essentially rolling.
It would of course be possible to keep ring 3 also stable - for, say, 1 year. Update it when a new release comes out - you can keep the core and desktop from the previous version but have the new apps.

Split it up in components

As Robert proposed on the factory ML this week it would be possible to split openSUSE Factory not per-se in rings, but in smaller components, dictated by their dependencies. Some would be one package, others would be multiple. Each component is developed by a team in a factory-like model. Rob states: "Each component advances based on it's own release cycle and the component team decides which release of it's dependent components to build against. Some tooling will be needed to help sort out the combinatorial problem."

And "when a release approaches,the release team picks a version of the core component that will be the base for the next openSUSE release. This version is used to populate factory and may be the only component that is in factory for a little while." This scheme should make the job of the release team easier but would still allow us to release the same openSUSE. Perhaps faster, perhaps slower - or perhaps in pieces, giving users an unprecedented level of flexibility!

Core, selection + OBS

How about we take the core of openSUSE (ring 0 and 1 from Coolo?), add a few components which have a long-term commitment from their teams; and let OBS take care of the rest! So, we'd have, say, the Core, our default desktop with a base set of applications for it, LibreOffice and Firefox. That is the release. The rest you grab off of OBS. The core is maintained for a longer time (this very much depends on community input!) and much more tested than what we ship today.

To limit the impact of the change and for the convenience of our users, the installer would still be able to offer the same choices as it always has; but besides adding the packages, it also enables the repository they are found in!

Initially, the release would be a lot smaller than it is today - but in time, as people step up for long(er) term maintenance, it will grow again. The idea is similar to what was proposed on the factory ML this week, but might lead to less clashes between components as there are less of them (much is in the core, presumably).

The real discussion

The issue with all the above scenarios is that while we can technically do them (some are harder than others, of course) the choice doesn't just depend on what we can do but also on what we should do. That makes the discussion a lot more interesting. We have to fix some things in our process, adjust to reality, that is clear. But do we want to shift direction, too? What is our real goal?

Our previous strategy discussion hinted at the fact that most of our users are professionals, people used to computers. We decided not to focus on newbies and making things simple to the expense of flexibility of our distribution. Should we go further on that path, make harder choices to focus on people using computers for a living?

Conclusion

What I tried to illustrate with the 3 examples is that we can go in various directions. It will be up to some of our core developers as well as the dev teams to comment on what makes most sense, what is the least amount of work for the biggest benefit (to users). But there's also the question of who those users are!

oSC13, Strategy and Factory

The openSUSE conference had some chats about strategy. Ralf talked about suggestions from SUSE in his keynote and there were more suggestions discussed in person between various people. I'd like to summarize some of the things I heard. In this blog I will talk about the directions of Factory, what Ralf mentioned as SUSE's ideas from his keynote; later this week I will blog about the openSUSE releases.

This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Factory

Let's start with talking about Factory.

Who is it for

We need to think about who factory is for, how these people are supposed to be using it etcetera. Right now, we have a shared understanding - but it probably isn't always as shared as it seems and it can be good to write things down and talk about them (see my keynote at oSC). Some of these thoughts will come to the mailing lists, I am sure, over the coming months.

Where should it go

On the technical side, there are some things I've heard about and seen several times and which will most likely see some form of implementation:

• more automated testing - the openSUSE team did a openQA sprint but many agree that there is more room for improvement.
• getting more people involved - As Ralf said, SUSE will commit to more SLE engineers on openSUSE; and the community & the openSUSE team should work more on both growing our dev pool and training people. In a GSOC discussion about this at oSC, this point was made as well: it would be good to use GSOC also for bringing existing contributors to a higher level.
• Bringing Tumbleweed, Devel projects and Factory in alignment - As Ralf noted in his keynote, not all work on Devel projects and Tumbleweed benefits Factory and openSUSE ultimately - it would be great to unite forces and bring them all in one process!
• segmenting Factory in rings - which Coolo has been talking about for a while now. It would create a Ring 0 with the bootstrap- and compiler infrastructure, ring 1 with the base system and other rings on top of that. He has been experimenting with this, hinting at some results in this mail. I leave it up to a later post (perhaps by/with Coolo) to be more concrete about this whole thing once the core Factory team has talked to more people and expanded upon it...

That last point is by far the least concrete - it is an idea which is discussed and toyed with. How much and what exactly will happen - only the Geeko knows ;-)

Some discussion has started on the mailing list, by the way, with the idea of segmenting Factory in even more 'components' than just the rings. I had a chat with Coolo before this proposal came out and I suggested the same thing. He noted that it would lead to a huge mess of dependency issues, including many circular ones (he gave libpoppler as example). This is already brought into the discussion there, let's see where this goes!

SUSE 20 years old!

I've been with SUSE now for almost 2 years now and it's been quite a ride. SUSE itself, however, has been having fun long before I joined. Heck, even before Free Software was on my radar (that's somewhere around 2000), SUSE was already going strong! November it'll be 20 years. Cool to see that in that time, Linux went from 'nothing' to "two-thirds of the global Fortune 100 uses SUSE Linux Enterprise"!!!

At SUSECon there'll be a celebration, the geeko's will re-do that at the openSUSE Summit afterwards. But SUSE has already been gearing up for the celebrations, putting up this infographic for example, see also on the right. Quite cool ;-)

There's another one showing 'where SUSE leads', the 11 good reasons why SUSE is the savvy Linux choice. It is used on the careers page with the header "where SUSE leads, YOU lead". Nice touch :D

Join us?

Talking about careers, I know the SUSE Studio team is looking for an UI designer. If you've played with SUSE Studio you know you've got some big shoes to fill. But it is an amazingly cool project with an amazingly cool team and an amazingly cool project lead - that would be Cornelius Schumacher, or Mister President for you!

The Boosters are also looking for new blood and so are many other teams in SUSE. Just have a look on this page for the job openings, about 40 at the moment.

At LinuxTag in Berlin, about three weeks from now, there'll be two SUSE HR people, who can answer any questions you might have. So, if you wanna work on awesome stuff for the Greenest company in the F/LOSS world, come and talk to us ;-)

See you at LinuxTag!

fork on github?

Got lots of comments on my blog "on the value of collaboration". Some positive, some less so - but that's all fine. Today I wanted to point to one thing I had in there as a link: snapper.

Fork me on Github

Remember my blog about the Qt based firefox-like webbrowser Qupzilla and Fork me on Github? The new snapper website has a nice "fork us on github" button which does indeed link directly to the github repo of snapper!

Snapper

So snapper is a frontend for creating and handling the snapshots the new btrfs Linux filesystem can make. This was initially written by SUSE engineers for SLE and also made available for openSUSE - that's SLE's upstream after all. And the team thought it makes sense to make it available for other Linux distributions as well, as there's lots more interesting work to do in FOSS than re-writing tools from one distro to the other.

Thus right now Snapper is available for the following Linux'es: Ubuntu, Fedora, Red Hat, Debian, Mandriva and of course openSUSE.

The GUI is written as a YaST plugin to make it available for commandline users as well as both on GNOME and KDE. We have ported LibYui to other distro's but I don't know if that's already enough to have the plugin create a gui on say Gentoo or Ubuntu. Help and collaboration in that area is very much welcome - LibYui is on sourceforge.

Get it

So if you want snapper, get it at this link! You don't have to thank us but if you have ideas for improvements and some hacking time, please think about forking github repo and of course, once things are up and running, creating a merge request!

Thank you for collaborating ;-)