Principles

We recently did a post about the Nextcloud Mission and Principles we discussed at the previous Contributor Week. I guess it is mostly the easy-to-agree on stuff, so let me ruin the conversation a bit with the harder stuff. Warning: black and white don't exist beyond this point.

Open Source

In an internal conversation about some community pushback on something we did, I linked to islinuxaboutchoice.com - people often think that 'just' because a product is open source, it can't advertise to them, it has to be chock full of options, it has to be made by volunteers, it can't cost money and so on...

But if you want to build a successful product and change the world, you have to be different. You have to keep an eye on usability. You have to promote what you do - nobody sees the great work that isn't talked about. You have to try and build a business so you can pay people for their work and speed up development. Or at least make sure that people can build businesses around your project to push it forward.

I personally think this is a major difference between KDE and GNOME, with the former being far less friendly to 'business' and thus most entrepreneurial folks and the resources they bring go into GNOME. And I've had beers with people discussing SUSE's business and its relationship with openSUSE - just like Fedora folks must think about how they work with Red Hat, all the time. I think the openSUSE foundation is a good idea (I've pushed for it when I was community manager), but going forward I think the board should have a keen eye on how they can enable and support commercial efforts around openSUSE. In my humble opinion the KDE board has been far to little focused on that (I've ran for the board on this platform) and you also see the LibreOffice's Document Foundation having trouble in this area. To help the projects be successful, the boards on these organizations need to have people on them who understand business and its needs, just like they need to have community members who understand the needs of open source contributors.

But companies bring lots of complications to open source. When they compete (as in the LibreOffice ecosystem), when they advertise, when they push for changes in release cycles... Remember Mark Shuttleworth arguing KDE should adopt a 6-month release cycle? In hindsight, I think we should have!

Principles

So, going back to the list of Nextcloud's Mission and Principles, I say they are the easy stuff, because they are. They show we want to do the right thing, they show what our core motivation was behind starting this company: building a project that helps people regain control over their privacy. But, in day to day, I see myself focus almost exclusively on the needs of business. And you know what, businesses don't need privacy... That isn't why we do this.

Oh, I'm very proud we put in significant effort in home users when we can - our Simple Signup program has cost us a lot of effort and won't ever make us a dime. The Nextcloud Box was, similarly, purely associated with our goals, not a commercial project. Though you can argue both had marketing benefits - in the end, a bigger Nextcloud ecosystem helps us find customers.

I guess that's what keeps me motivated - customers help us improve Nextcloud, more Nextcloud users help us find more customers and so both benefit.

Pragmatism and the real hard questions

Personally, I'd add an item about 'pragmatism' to the list, though you can say it is inferred from our rather large ambitions. We want to make a difference, a real difference. That means you have to keep focused on the goal, put in the work and be pragmatic.

An example is the conversation about github. Would we prefer a more decentralized solution? Absolutely. Are we going to compromise our goals by moving away from the largest open source collaboration network to a platform which will result in less contributions? No.... As long as github isn't making our work actively harder, does not act unethically and its network provides the biggest benefits to our community by helping us reach our goals, we will stay...

More questions and the rabbit hole

Would you buy a list of email addresses to send them information about Nextcloud? No, because it harms those users' privacy and probably isn't even really legal. Would you work with a large network to reach its members, even if you don't like that network and its practices? Yes - that is why we're on Facebook and Twitter, even though we're not fans of either.

Let's make it even harder. How about the choice of who you sell to. Should we not sell to Company X even if that deal would allow us to hire 10 great developers on making Nextcloud better for the whole world and further our goals? Would you work with a company that builds rockets and bombs to earn money for Nextcloud development? We've decided 'nope' a few times already, we don't want that money. But what about their suppliers? And suppliers of suppliers? A company that makes screws might occasionally sell to Boeing which also makes money from army fighters... Hard choices, right?

And do you work with countries that are less than entirely awesome? Some would argue that would include Russia and China, others would say the USA should be on a black list, too... What about Brazil under its current president? The UK? You can't stop anyone from using an open source product anyway, of course... It gets political quick, we've decided to stick to EU export regulations but it's a tough set of questions. Mother Teresa took money from dictators. Should she have? No?

It might seem easy to say, in a very principled way, no to all the above questions, but then your project won't be successful. And your project wants to make the world better, does it not?

Conclusion?

We discuss these things internally and try to be both principled and pragmatic. That is difficult and I would absolutely appreciate thoughts, feedback, maybe links to how other organizations make these choices. Please, post them here, or in the comments section of the original blog. I can totally imagine you'd rather not comment here as this blog is hosted by blogger.com - yes, a Google company. For pragmatic reasons... I haven't had time to set up something else!

There's lots of grey areas in this, it isn't always easy, and sometimes you do something that makes a few people upset. As the Dutch say - **Waar gehakt wordt vallen spaanders**.



PS and if you, despite all the hard questions, still would want to work at a company that tries to make the world better, we're hiring! Personally, I need somebody in marketing to help me organize events like the Nextcloud Conference, design flyers and slide decks for sales and so on... Want to work with me? Shoot me an email!

What's Holding ownCloud Back?

In the recent article about the ownCloud event program, I pointed out that while ownCloud has 2.5 million users, it is a drop in the ocean looking at the number of Internet users (a little over 4 billion today). The announcement of the "Let's Encrypt" initiative from the Electronic Frontier Foundation, Mozilla and others prompted me to write this: it is one step in the direction of removing the limitations holding back wider ownCloud adoption. What does the future hold?

Easy ownCloud

As Frank pointed out in his blog on the future of PHP, ownCloud has ease of use as an explicit and very important goal. And while the technological choices made aren't always so exciting and bleeding edge, they do result in ownCloud being very easy to deploy on a very wide range of devices. Plenty of tutorials exist showing it running on everything from Rasberry Pi devices to big iron at organizations like CERN, where physicists looking for the origins of the universe are routing hundreds of terrabytes of data through their CernBOX build on ownCloud, sharing and collaborating on the data analysis.

Limitations

Unfortunately, there are limitations outside of what ownCloud can directly control.

In the database area, SQLite is default because it requires no manual setup whatsoever. But performance suffers when an installation has more than a trivial amount of data. When sharing with more than 15 users or indexing your mp3 connection, SQLite usage leads to frequent time-outs and other issues!

Another, more serious issue, is the architecture of the current internet. Most users are set up at home behind a firewall provided by their internet router. While this provides some additional security, it is mainly because the limited number of unique addresses available in the still widely-used 'IPv4' protocol. It simply is impossible to assign a unique address to each device connected to your internet at home. But this means your server will not be reachable when you're not home, unless you adjust some settings on your router. While we can configure some routers automatically, most we can't and as every router is different, an easy 'generic' how-to can't be provided either.

A third issue is that an ideal ownCloud platform would be small and cheap devices like the Raspberry Pi, but these are almost all based on 32bit CPU's. Due to technical limitations in the platform ownCloud builds on, this means you won't be able to have it handle files bigger than about 4 gigabyte! That is a big limitation if you'd like to store your virtual machine or Blue Ray collection on your ownCloud.

The fourth issue I see is security. While not the biggest problem of the three, setting up a server to be secure, including a decent SSL certificate, is not easy. I personally couldn't figure it out and while I'm new to server things, I am not a technology hater by any means. My parents wouldn't ever be able to figure it out and more importantly, they wouldn't want to!

Solutions

These four issues to wider ownCloud adoption aren't the only ones, but as far as I can tell, the biggest. So how do we deal with it?

There are several routes to an even easier ownCloud installation. Having a pre-setup operating system in the form of a container (Docker?) or a virtual machine can take care of much of the trouble around database setup and help a lot with the security issue. However, it can't run on light hardware like a Raspberry Pi and doesn't deal with the file size problem.

When it comes to the address limitations, the internet is slowly transitioning to IPv6 which will provide more unique addresses for each person than IPv4 offered in total (see here how Google explains IPv6). So, essentially, we just have to wait for this problem to be solved.

The hardware problem is also working on solving itself: the upcoming new swath of ARM CPU's (and Intel CPU's targeting the embedded market) are fully 64 capable so while current-gen Raspberry Pi devices (and other embedded devices like routers!) aren't perfect for ownCloud, a year from now many new devices will be perfectly capable of providing a great ownCloud experience.

The Electronic Frontier Foundation's "Let's Encrypt" initiative offers a (partial) solution for the security issue. Without it, a pre-configured ownCloud system will most likely be set up to use a self-signed certificate. While secure in principle, it always warns visitors of the self-signed state and thus isn't ideal. Let's Encrypt provides an automated and more importantly free (in terms of cost) solution for this.

And now

While I'd love for all these changes to be implemented yesterday, in reality we simply have to wait for the transitioning to IPv6 and 64bit CPU's. In the mean time, we can already start working on integrating Let's Encrypt into virtual machine and Docker images with a pre-configured MySQL (or MariaDB) and perhaps recommend people to run them on a 64bit capable system like a modern NAS or a NUC. The ownCloud-in-a-Box image on SUSE Studio is a great start!

Meanwhile, getting ownCloud ready to run on a wider range of devices and perform a wider range of 'cloudy' functions like running as backend of the Chromebook devices (see this page and ping me if you want to get involved) should be on the agenda as well. I personally look forward to more 'social' integration in ownCloud, like the ability to comment on images or other data and share these with the people you share files with. We're on it, tags sharing is integrated for ownCloud 8 and a generic metadata repo was created (empty still). Get involved if you can!

Obviously, telling people about ownCloud is still important - which is what the ownCloud event program is all about - and help is welcome. Go to owncloud.org/promote and share the love!

Where KDE is going...

In my blog about conf.kde.in, I promised I would blogify my talk about KDE's future but failed to publish it until now. I thought the content might be a good fit for on paper. It took a while, but the upcoming Linux Voice should feature an extended version of these blog posts about where KDE is going, with quotes from a variety of KDE folk providing some background.

Meanwhile, on the dot I have published an updated version of the first blog post about the technical side of things: KDE software. It is mostly aimed at people not intimately familiar with KDE but curious about what is coming. Users, for example...

If you find a bug, report it to me or the dot editors! And: spread the article around for users and interested people to read...

Building Converging UIs

I just blogged about my article on linux.com about the just-released KDE Frameworks 5 sneak preview.

Convergence in 2010: Plasma Netbook

Converging Form Factors

On the Frameworks, one can soon expect to see releases of KDE's Plasma Workspaces. A Technology Preview of Plasma 2 has already been released and this ambitious project has not lost any of its goals. Today, I noted that ZDNet's Steven J. Vaughan-Nichols wrote about what he expects from Ubuntu in 2014. There, he quotes Jono Bacon talking about formfactor convergence. And the intarwebs are full of people making jokes that Microsoft is copying Ubuntu with their single UI for multiple devices. But let's not forget where they got their ideas...

What is real ambition?

I would argue that neither Apple, Microsoft, GNOME, nor Ubuntu/Canonical are even half as ambitious as the KDE Community in the area of convergence. They are all merely catching up to the state of KDE technology in 2010. In that year, the KDE community released Plasma Netbook, a plasma-based shell optimized for another form factor: the netbook. With far more advanced convergence than anybody today has yet shown: Plasma Netbook and Plasma Desktop share well over 90% of their code, as opposed to not even sharing toolkit or display shell (Ubuntu) and having a completely separate desktop (Apple). On Plasma, widgets can dynamically adjust to the constraints of their environment, be it on a panel, free-form on the desktop, full-screen, in a window or in a tiled environment. And yes, the different form-factor optimized shells be switched on-the-fly. No separate login or account, no loss of functionality, no separate applications for each shell, nothing like that. It just works. See this blog from 2011 to get an idea how the tablet plans were doing.

Plasma on desktop/netbook/phone in 2011.

I understand what Microsoft is doing - trying to build a single user interface for vastly different devices. And I guess we've all seen how it does not work - Apple is smarter, in that regard. Underlying technology can of course be re-used but you simply can not make a UI which works equally well on a 75 DPI 24" screen with mouse & keyboard, on a 455 dpi touch phone, on a 300 DPI touch tablet and a 64" television with Kinect or something like that...

Instead, the Plasma team has build a technology which separates presentation from logic, allowing you to build UI's which adapt dynamically to the needs of the form factor.

Below is a video of Plasma's awareness of the container size in action, like it has functioned since it was released in 2008.


Now I don't deny that in terms of resources, MS and Apple are so far ahead they can make pigs fly. Our more advanced architecture and ideas can't really compete with what they do and as long as we have 0.5% market share on the desktop, Free Software will probably not get the resources it needs to polish things to the same degree. That's a bit frustrating but it doesn't mean we frequently do things far beyond what the big boys do: anybody who has seen the introduction of the upcoming release of Mac OS X and knew about KDE Connect knows we're way ahead of them when it comes to phone-desktop integration ;-)

Moving Forward

All this technology will be brought to a new level with the release of Plasma 5, where your workspace will be able to smoothly morph into a different form factor without even a hickup. So, when it comes to the convergence of formfactors, KDE is lightyears ahead of what the competition is even aiming for. And outside of that, we're doing awesome stuff, for sure.

Did I say something about the power of innovating in the open? That's what I'm talking about.

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!

On Innovation, Free Software, NIH, Geary, Trojita and KDE PIM

I argue that if Free Software wants to get anywhere, it needs a culture of 'collaboration first'. In most areas, we have that. In some, we don't - and that is hurting. The desktop is probably a prime example of that.

Rob Boudreau wrote an opinion piece about Personal Information Management (PIM) and the future. He concludes that 2013 has different requirements from PIM than 1995, and:

"KDE PIM seems to be the only FOSS project working on technology that will eventually go beyond just the PIM itself"

I think reality agrees with him. Mobile devices are cleverly integrating chat, email, social media and phone in one. Contacts have details on all of these and show the latest tweet or Facebook message of that person as status. Why doesn't the desktop do this? Well, it does, but only by putting your data on corporate servers, accessible though web browsers: Facebook, Google, Microsoft, ...

The Linux Desktop has a mission here: help keep user data out of the greedy hands of Google, Facebook and Microsofts! That can only be done by building on the shoulders of giants, not by re-inventing the wheel out of sheer arrogance. Let me explain what I mean.

Collaboration

10 years ago I often presented to people new to Free Software and how we work. I would explain the benefits of Open Source so:

"Imagine you thought of the best New Idea for word processing. From now on, documents will almost write themselves. But you first have to embark on the huge journey to write a full word processor. Three years later, your amazing application does not get anywhere as it can't open MS Word files."

"Imagine instead you added your amazing feature to an existing word processor. The discussion with the experienced word processor developers even resulted in a better result!"

Being able to stand on the shoulders of giants is an important benefit from collaboration in Free Software. We do have competing projects but note that most successful forks and rewrites were started due to a lack of collaboration! A recent example is LibreOffice. Often people from the 'original' project join or even start the fork or rewrite. Wayland is build by the Xorg team and the MySQL fork MariaDB is led by the founder of MySQL!

The Linux kernel is another great example. Google, for example, is putting in enormous resources in getting their technologies back into the kernel. After a period of forking for the benefit of speed and efficiency, they figured out that in the long run, it actually is more efficient to not fork and put in the extra effort in collaboration.

Collaboration-by-default is not a given. Aaron Seigo said about KDE:

"The open nature of the community has purged the “not invented here” syndrome from our ranks"

Yes, the KDE community has a strong tradition of re-using efforts and building on the shoulders of giants. And questioning those who don't! But such a culture took years to build as there is plenty reason to NOT collaborate.

Reasons for not collaborating

Failing forks or duplicating projects are often based on personal conflicts or a dislike for certain toolkits, languages or technical choices. And there is much starting from scratch because developers just focus on their own problem or want to learn something new.. While I would argue that you probably learn more working with experienced, competent people, and you might get more done, too, it is not hard to understand these reasons.

Then, there is psychology. Most people think they are smarter than average and programmers are no different (sometimes expressed as "what others do is easy")... Given the bell-curve followed by the distribution of intelligence, this clearly is one of the many fallacies our brain saddles us with. Even companies are affected. Google, working to get their features into the upstream kernel, discovered that not all the intelligent people in the world work for them and there is lots of room for improvements in what their team came up with.

More than one mail client

I argue that this last reason leads to more duplication of effort than healthy in the area of mail clients. Recently, Yorba pushed to get funding for Geary, another 'new approach to mail'. And there is Trojita, also providing a great IMAP client. Both projects were started in the last couple of years and seem to be re-inventing the wheel -- twice. As you probably saw many prominent developers giving a hard time to a company insisting upon writing another display server, I hope you understand how misguided I think this is. Yorba said they decided to write a new email client to keep things simple and fast and due to the complexity of other mail clients... I described the rationale and wrongness of this "let's write a new mail client" approach in a comment on LWN a while ago. In short, I'm betting that the reasons behind it boil down to the previously mentioned combination of over-estimating oneself and underestimating the problem. In the case of email probably a lack of ambition and forward-thinking as well. Just email doesn't cut it in 2013, certainly not 5 years from now.

Bringing conversation-view to email is an awesome idea - and can probably be done through a Google Summer of Code project within an existing client. Writing an entirely new email experience needs a bit more effort of course, but writing the entire underlying infrastructure too - that is just a sodding waste of time, pardon my French. Good to see Trojita at least has joined the KDE community and is working with KDE PIM! How about you, Geary?

More than one conference

I've always been a big proponent of the Desktop Summits and I do indeed think that it shows both arrogance and a lack of big-picture thinking that these don't happen anymore. I'm glad that the KDE board, including Agustin (who organized the first Desktop Summit) managed to kick off a "freedesktop summit" at the SUSE offices. I'm also glad that some people who DO see the benefit of collaboration participated there - even if their communities don't (yet) understand that it is worth the investment.

What we need

We need a culture where we are critical of people who don't try to work together or are unwilling to put in effort to collaborate. Free Software depends on collaboration and not working together is just counterproductive. So I'd like to ask all readers to support collaboration: talk about collaboration, share the tales of success. And if somebody decides to write an app from scratch, or is writing an application doing the same thing another does - question them, ask why they go it alone, why not collaborate. It is totally OK to be critical of forks and anti-collaborative behavior. You don't have to beat anyone up, but at least making them think about it is a good thing. And if you're a developer: integrate technologies, build re-usable libraries. And remember that the shoulders YOU are standing on can be made stronger for future generations of Libre developers! Just dumping disconnected code is NOT a contribution to Free Software, contrary to what some folks seem to think.

I'd also like to ask people to support KDE PIM: if we want to have a shot at keeping our data out of greedy corporate hands and if we want to ever get onto the corporate desktop, Akonadi is the only architecture that really has a shot. Instead of writing new wheels, let's improve this one together! Yes, KDE PIM needs UI work. Then why not do that? Writing a new mail client makes total sense - if you build it on a proper infrastructure. The KDE PIM team is greatly looking forward to help people who want to write new mail, RSS, Facebook or contact management applications. Skills required are mostly related to motivation and the willingness to ask questions and get help - otherwise, javascript coding skills will probably get you pretty far as it makes all the sense in the world to write these new UI's in QML.

Concluding

I'm happy to concede that things are not black and white. I'm sure nobody can fully judge neither Geary nor Trojita or all aspects of the Desktop Summit. Mea culpa for any wrongness. But please take the lesson to heart: there is great value in collaboration. And getting these benefits means putting in 'extra' efforts, yes, it can cost you something in the short run - that is the whole point of long-term vs short-term thinking. So, next time somebody argues that 'we can go faster if we do it alone', tell them that most smart people do NOT work for you and problems are always simple when they're not (yet) yours. Or just remind them that once upon a time, people thought volunteers could never write a encyclopedia. It is the 21st century and collaboration is what sets apart winners from losers.

Take care!

On Open Innovation and Open Governance

Heya,

As I wrote in my blog yesterday, on Thursday the 15th I'll be leading a discussion session about open governance in the Open Innovation track at the 'Summit of new thinking' in Berlin.

Edit: The video of my talk is up...

#SON12: Jos Poortvliet - Open Governance done right: creating rules without ruling from newthinking on Vimeo.

Open Innovation

I'm actually looking forward to that: the 'open innovation' thing was what once got me professionally interested in Free Software communities (while studying Organizational Psychology) and I still consider it an exciting topic. I did my thesis on open innovation but 10 years ago there was barely any research done in the area of open source governance and when I asked questions to my professors, blank stares where the result. These days, things are different (see for example this interview): the Academic world has seen what open source organizational methods can do and there is quite a bit to read about it.

Open Governance

The idea behind Open Innovation is to involve the entire organization with innovation and improving things. Both big and small - we're not just talking about creating 'The Next Big Thing' but also improving current products, structures, processes and more. Think about it as bottom-up innovation.

That only works if you have the right governance: the right structure and rules. Innovation is the first thing you stifle if you make mistakes in how you set up an organization. And you can't just create a 'department of innovation', stuff a bunch of folks in a room and tell them to innovate. It just doesn't work that way. Innovation comes from interaction: people talking to people. Sales together with Engineering, that kind of stuff. Creating an organization which is conductive to innovation is not easy.

Open Source communities of course excel at this: their organically grown structures and informal rules let people 'do what they want' and freedom is the foundation of innovative cultures. But these ways of working have their limitations - you can't be informal forever, not if you grow big. At some point, some guidance has to be there to prevent things from clogging up the wheels of innovation. Things like personal conflicts, fights about creative directions, strategic disagreements. And this is, again, where governance comes in. My session is sub-titled "creating rules without ruling", as in my opinion, it is more about writing down existing but implicit rules than creating new ones.

Qt Open Governance

Interesting in this regard is the Open Governance the Qt project is working on: building such structures 'from scratch' is not easy. You have to find out where you agree, yes, but while writing things down, implicit things become explicit and that goes for (potential) conflicts then too. But being able to do this in a fresh community, before ideas get entrenched! Having a chance to set direction in a 'soft' way. Terribly exciting!

Meet me, talk to me!

If you want to share thoughts with me on this topic, meet me at QtDevDays or at the Summit of New Thinking - or other events in the future (how about FOSDEM?).

In a while, Crocodile!

Edit:
A few video's has been created for the conference. Esp the first one is funny ;-)

Check 'em out:
What is Open Innovation? (Chinese Whispers Game)
Open Innovation Track Day 1
Open Innovation Track Day 2
Rule No.1 for innovation: Have fun!

Pre and post conference blues...

Heya all,

Since the Akademy conference in Estonia beginning of August I've been rather quiet as I have been struggling with health issues. After loosing some blood and undergoing a few *scopy's the people with stethoscopes don't seem too worried so neither am I but it has been unpleasant at times. Not too many tests left - an MRI and another 'scopy' in December, I hope they can give me a diagnosis by then.

It has been frustrating to have had to cancel trips to the openSUSE Summit, COSCUP, Brazil and more. And at the openSUSE Conference (my first trip in 3 months) I had to skip the evening fun - instead opting for quiet food-in-the-hotel and early bed. Believe me: not nice.

new team: 'the openSUSE team'

Luckily, I'm getting back on my feet and at a recent visit to Nürnberg I even went out a night with my new team mates. Yup, a new team - if you're following the openSUSE mailing lists, you probably have heard that already. In my two years of 'community manager' of openSUSE, I've worked with people around the company and community - but I was not really part of a formal team. Independence is nice but it also can make you take on a few things too many - I know I did. So, when it was decided to try and re-arrange things with regards to the openSUSE Boosters team, I decided it was a good idea to join the team and help it find directions. Together we can do more, and all that.

It means the scope of the former boosters team (now just 'openSUSE team') has widened: I will of course continue to care about the things I used to care about. Things like the atmosphere in the community, governance, strategy - and of course marketing, the ambassador program and presenting a friendly face to the wider Free Software world. But I'll be doing that together with the rest of the team now, not alone!

Things are quite different now, so let's see how it'll go.

Conference last month

So, the openSUSE conference was my first event since a while. It was quite awesome, with a lot of faces I hadn't seen in a while and a lot of excitement. We organized a bunch of interviews with people, which will be released over the coming months. On the openSUSE days, a few important things were discussed, results of which have been posted to mailing lists. I'm working on a summary of that but it'll take a bit longer. One thing I already managed to change: Richard gave some feedback on the 'we believe' poster and we decided it needed a fourth item. Which I added, see the image on the right.

You can get the source for the poster in our github repo.

Conferences coming

There'll be more events, of course. On short notice, I'll be at the QtDevDays in Berlin - it's practically next door and a great way to meet people. I've heard we can expect 500+ people there from all over the (huge) Qt ecosystem. It'll be interesting to talk to people outside of the usual Linux crowd: Qt has managed to grow well beyond the Linux Desktop into an industry standard for a wide variety of use cases.

Open Innovation and Open Governance

On Thursday the 15th I'll be leading a discussion session about open governance in the Open Innovation track at the 'Summit of new thinking', also in Berlin.

I'll write a tad more about that in a blog tomorrow.

For now, I have a conference to dress up for, so see you later, alligator ;-)

keynote by Agustin Benito Bethencourt at Akademy

Agustin wanted to talk about success. Times are a tad uncertain now - in the economy, in software and in the KDE ecosystem. It's good to be aware of how well we've been doing over the last 15 years and how well we are positioned for the next decades!

Success story 1

Active patience

We now have an open development process around Qt. Once upon a time, nobody believed that to be even remotely possible - it was not even free software. But we knew how the Qt people wanted the things we wanted and we had the patience to wait and quietly keep pushing. And now - the unexpected happened. This will have a pervasive effect on our infrastructure. We (and others!) can now more easily take Qt in other directions, do new things!

The lesson is, in the words of a Chinese proverb: Be not afraid of growing slowly, be afraid only of standing still.

Success story 2

Magister

KDE is first class in getting new, young people involved and educating them. Our contributors are from a variety of cultures, students or established developers - we all work and learn together. And being involved in KDE you learn a lot. Once you start working in companies you will notice how much you've learned in KDE. And that should make you confident that those who will take over in the future, also part of this community, will be ready for it.

Success story 3

Efficiency

As a 'loose' bunch of volunteers, we're doing incredible work. Most companies in 'our business' do a far worse job at developing products with often far more resources.

Success story 4

Leadership

We're becoming better and better at becoming business incubators. More and more entrepreneurs step up in KDE and start new, cool, innovative businesses. We're proud to be part of a community where innovations can go somewhere!

Success story 5

Vision

We're capable of developing and executing on a vision. Take KDE 4! We've embarked on that vision seven (!!) years ago and today - while it is not perfect yet - we've gotten very close. Most of the plans we decided on are implemented and have come into reality. All that without investments of millions and millions by large companies. We did the impossible!

There are people out there who have their own ideas and projects and who want to be part of KDE, develop under our umbrella, our vision and who join us. This tells us we're on a path to a bright future: we're not just open to people, but there are projects outside who recognize our clear vision and the fact that we deliver.

Success story 6

Experience Innovating
People see how hard it is to stay in the tech business for a long time. You see that with many companies. Yet, we're 15 years old, yet we are still doing new, innovative things. What we do is completely different from what we did, but we still do it with the same spirit and energy than when we started. And Agustin is confident that in 10 years we'll still be approaching entirely new challenges with that same energy!

KDE's future depends basically on US.

These 6 examples (and we haven't even talked about design, the project and code, design or many other things) tell you something about KDE: we have a bright future!

We've gotten to a point in which most limitations we're facing come from inside, things we need to and can change. Not from outside but under our control! There is little out there that can stop us from being successful for another 15 years!

(Agustin holding a Plasma Active tablet) Innovation does happen right here!

Future of openSUSE - Update on the Discussion

Beta 2 is out and meanwhile, the discussion on the future of openSUSE development continues. I've attempted to summarize the current status, both to help my own overview of the discussion and to try and help clarify it for others. It has become quite a mail-client-challenging monster thread and Robert S has already asked people to open separate threads for the specifics we're discussing...

Tumbleweed

A first point of consensus was that there should be more emphasis on Tumbleweed. Greg brought up a few pain points he would need to see fixed and asked for help in general. Some conclusions and plans:

• change processes to lower amount of rebuilding of packages in OBS (Greg, Coolo, OBS team)
• add hardware for faster building (OBS team)
• optimize OBS for faster building with things like better/smarter/faster bootstrapping (pre-setup VM's with GCC ?), new filesystem, smarter dependency checking and possibly integrate the rebuild_logic="coolo" thing in OBS itself (OBS team)
• Greg needs to tell us what else we can do to help him make Tumbleweed better

Release Cycle

Consensus seems to be that a longer release cycle is a good idea but nothing concrete has been proposed. Coolo will probably simply make a 12.3 proposal for say November 2013. Some numbers where brought up that show that we can indeed use a longer stabilization period for our releases. 'Release when ready' is also still on the table.

If a longer release cycle is introduced, Tumbleweed becomes more important, but so do the other OBS projects. Users will depend on OBS far more to get new packages. What effect this has and how to tackle that has not been discussed yet. On a personal note, I think the new software.opensuse.org will need some improvements in case we go this route. It would have to put more emphasize on the devel projects as 'official' sources of software. Right now, there are roadblocks put in place for users who want 'stuff from OBS' and it's made clear that things from there are untested and possibly unstable.

Changing the Development Process

Consensus seems to be that the current setup with devel projects feeding into Factory and having groups of maintainers (the aggregate of the individual package maintainers) doesn't work that great. In short, we need to stabilize Factory further. Things that might change:

• Build Failures could create BNC Entries... assigned to the bug owner of the package. (OBS team?)
• Be stricter about maintainership - have 2-3 maintainers who really are responsible. There is some unclarity between the roles of bugowner and maintainer. OBS currently adds the role of maintainer to everyone in a project, which is deemed a bit overzealous - a package can that way end up with 20 maintainers but only 1-2 of these might dare to touch it. Not clear where to go with this yet.
• Do more checks on packages like rebuilding dependencies to see if they fail. Heavily depends on available build capacity (currently very limited). While it requires more work to get something in Factory, as Karl Eichwalder said: "your fun must not prevent the others from having fun."
• process of getting packages in factory might need changes. For less core packages, we could possibly skip devel projects, provided there is review done on the packages. We might also expand devel projects for the remaining packages to do more testing.
• staging projects
  
  
  we could either have one or multiple staging projects.
  • With one, all eyes would be on the same, but it would have the same breakage issues as Factory. Advantage is that we can have an automatic revert policy where packages can't get in Factory until all breakage in Staging is fixed. It would require OBS to automatically detect build errors due to changes in a given package. We're unsure if that is possible.
  • Another way would be to try and get Staging stable, once everything is green - move to Factory. Get new packages, stabilize again, move to factory. Etcetera. Having multiple staging's in parallel might help to lower the 'latency' of getting packages in Factory but it would cost build resources.
  This discussion is also still ongoing.

It was brought up that it'd be possible to create a 'core' of base openSUSE packages (roughly up to X.org) which would be 'atomically updated' for the rest of the packages on top, decreasing breakage and allowing easier testing. This could even be part of a release scheme with a 'core openSUSE' and peripheral packages in Tumbleweed and OBS. It would require some work on the software.openSUSE.org search UI and software management in general, however.

Social issues and responsibilities

Several people brought up the social side of things. As Coolo already mentioned in his initial email, we'd need more people fixing problems 'all over'. These will need mentoring - something openSUSE currently doesn't do in a structured manner, except in the context of Google Summer of Code.

Aside from mentoring, there should be more clarity about responsibilities. If a new version of a library breaks things, who should fix this? The person who maintains the library or the applications which are broken by it? These questions are unanswered as well and possibly a one-size-fits-all answer doesn't exist.

Last but not least, development is helped by a positive, constructive atmosphere on the list. The openSUSE Board has been spending some efforts in improving the situation on our lists and with some success. But more would be needed and how to do this is still unclear.

Conclusion?

It is most certainly not clear where exactly we will end up. Of course, we're only 6 days since the announcement by Coolo that he thinks things have to change. Much of the discussions does point to interesting solutions, but we have to come to definite conclusions before anything can be done. And then, we need people to commit to executing some of the changes!

The openSUSE Conference (Prague, October)will be a good place where we can finalize these conclusions and start implementing things. If you're in the Americas, the openSUSE Summit in Orlando in September might be more convenient for you... In both cases, if you have an interest in the future of openSUSE you should make sure to be there!

strategy!

A few weeks ago the results of the voting for the openSUSE Strategy came in. 90% agreement, nice!

And another number - I've talked about the openSUSE strategy in no less than 8 posts already. Sjeeminee. Re-reading, I noticed this one where I mentioned that Fedora was also 'doing strategy'. I see that the Fedora Board has created a Vision statement.

Obviously Fedora is quite different from openSUSE (see their Leadership system) and they worked quite differently compared to what we did. Other communities are also having 'strategic discussions'. Looks like we set a trend ;-)

It was quite a learning experience. Doing this in such a large community, with so many ways to let people provide input - wow. I think we did very well. Thanks in part to tools like co-ment and of course the input of many people. I think it's impressive that we did it so open and bottom-up!

In any case, I'm happy with the outcome and I'd like to echo the statement in the article: we're still looking for feedback and further refinement and the strategy mailinglist will stay open! And you're always welcome to provide input in-person at the openSUSE conference.

oS strategy

The voting for the oS strategy ended on the 30th but the board decided to extend it a bit. Which makes sense, quite a few members were not aware of the voting. Seems like many of them don't read the planet very often ;-)

So, we will extend it with two weeks & send out a mail to all members notifying them of the voting...

Obviously, you don't have to wait for that mail - if you read this you can also
go here, log in and vote!

From the email:

What do I vote for?

We realize the vast majority of you simply prefer to focus on writing code and building packages. 'strategy' might not be the most interesting thing in the world. However, it does influence at the very least how we communicate about ourselves and how we are seen. Think about texts on our websites, what our ambassadors say about us at conferences. This is an important goal of the strategy - not only decide upon the direction we want (after all, the current document simply describes the status quo) but also define our communication!

Obviously there are many more reasons why we did the strategy discussion - after all, many people asked for it, not just marketing. But communication is an important part of it... And:

We need to know if the end result of the discussions about strategy reflect how you see openSUSE. Even if you disagree, it is important for us to know that - we accept any outcome!

In short, please vote, even if you want to neither answer yes or no - there is a third option ("Abstain, I can't decide").

Note that the document isn't meant to be final and should be revised in the future. That's also why we're still very much open to feedback!

Strategy voting has started!

Awesomeness!!!

Yup - we've got a strategy proposal under vote. Sorry it took so long. Everyone, both from the board and the strategy team, has been busy with the openSUSE 11.4 release and the upcoming openSUSE conference. But the board has asked Thomas Thym to get it out 2 weeks ago and he asked me to create a openSUSE Members poll (he's not a member yet). And I did. So if you're an openSUSE member, go to connect.opensuse.org and cast your vote!

Meaning

I've blogged before about what this strategy is and isn't about but I'd like to re-iterate it one more time.

No, it's not about finding a perfect description of all of us. We're way too diverse for that to ever work. It also isn't about carefully describing a grand, detailed plan for what we will do. We don't tell our contributors what they can and can't work on. And it's not about writing a sexy and engaging text. The marketing team will do the marketing texts, this is too much based on compromise for that to be possible.

It is about having a reasonably accurate description of who we are, what we want and where we stand.

Yes, it does say some things about where we might not want to go or where we focus. That is because the majority of us focuses on certain things and doesn't care about other things. IF someone wants to take those things on, change that focus, fine. But they have to be prepared to do a LOT of work and get little support. In a sense, this 'strategy' can tell people they should join openSUSE because we are the perfect community to do what they want. Or not...

Now surely we can and will revise it in the future, but in small steps. We'll update it if people start doing cool new stuff, for example. We already had to add Tumbleweed and Evergreen! And if enough people want to work on mobile devices, ARM or other stuff - well, we just do it and then change our 'strategy'.

So, now go to connect.opensuse.org and cast your vote!

green picture in the article

On the green "I want you" picture on news.opensuse.org: I got it off the web and used Krita to make it green. I know, Krita is meant as an artist tool, a painting app. Wrong tool for the job. I just didn't think about using the Gimp... Actually, on my laptop I usually use Showfoto for these things which is far superior to both for basic photo manipulation. Forgot to use that too. Yes, right tool for the job isn't always high on my agenda, hehe.

The image in the previous Milestone 1 article WAS made with the right tool: Krita again. Just 5 minutes with the right brushes and layers and it's awesome... Obviously, this is NOT a serious proposal for openSUSE 12.1 artwork.

Almost time!

Hi all!

After a slightly-too-big dinner last night your strategy team spend all day working on the strategy docs. We've spend most of that time trying to shorten it without loosing the essential information in there - trying to make it more readable. I think we did reasonable well - the results are on co-ment again.



Meanwhile it's almost time for the conference to start - yay :D

Love, Jos

Last piece of strategy before the conference

Hi all!

The strategy discussion in openSUSE is a difficult one. I wrote in the latest announcement this:

So if you've held back, have not had a look at this yet - now or never! Provide your input on the draft on co-ment and help shape our description of what being a Geeko means to us all. Yes, this will hopefully describe ourselves - where we stand, but also add a bit of pepper and salt and show our ambitions. Our strategy document has to be inclusive - but not too long. It has to show some ambition - but must also be realistic.

This is not easy. We're a hugely diversified community with all sorts of users and contributors. We do NOT aim to change that - we're openSUSE after all. But we also have to make choices and have a profile potential users and contributors can recognize themselves in. Take 'beginners'. What does that mean? Are we talking about people who haven't used computers before? openSUSE should be fine for them - if they are looking to learn, play with it a bit. Someone who only needs a computer to check mail will probably need help, however, to get it up and running. They are not interested in reading on a forum about how to install multimedia codecs. So we target the person who will help him or her installing it and setting it up! Which again doesn't exclude a community team working on a super-simple openSUSE with everything a beginner needs - our infrastructure supports them. But we have to pick our battles, and openSUSE is traditionally a distribution which is powerful and flexible - we don't want to sacrifice functionality in our default offering. We want a graphics professional to be able to have all the powertools at his or her fingertips; we want a sysadmin to have an easy-to-administer system; we want a teacher to have a wide choice of interesting learning tools; we want a pro-audio user to easily install a low-latency kernel. openSUSE should not be harder than it has to be - but you may notice the power under your fingertips.

Anyway. Lots of talk, the resulting new paragraph in the description of our target users is dramatically shorter than the old one:

openSUSE users are looking for an easy and comfortable computing experience which does not limit their freedom of choice, offering sane defaults and easy configuration.

I think I like it, but the 'old' one (with updates) is also up on co-ment - let me know which one you like more. I even have a bunch of iterations in a piratepad here, feel free to look at the evolution. Altough this is only from today, yesterday I worked until 1 with Thomas Thym (thanks!). Today I had help from Klaas Freitag, Will stephenson and Henne Vogelsang for helping with this single sentence... I could not have done it alone! To paraphrase Thomas from last night: a team is more than the sum of the individuals.

Love, Jos

strategy, helping SUSE...

Hi all!

I just published/send/submitted the last part of the openSUSE strategy stuff. Coming from KDE, this was a very interesting endeavor. It's not done yet, of course - I expect a huge amount of comments on this one (find it here) as it includes some notes on our 'competition' (coopetition?), what the results will be and how we'd like to be in a few years.

I know the KDE community is also looking at future directions - KDE 4 series is stabilizing, so where to go next? GNOME meanwhile is getting GNOME 3 out - but at the same time also had strategic discussions at the last GUADEMY. And of course Fedora has followed openSUSE in discussing directions. Guess it's contagious...

Not surprisingly, not everyone is happy with 'strategic discussions' within Free Software communities. In an earlier blog I spoke about the why of a strategy, so I won't go there again. I do feel, however, that tides seem to have turned. Either those sick of strategy have gone away, or those who think it's good to think about the future have convinced them. Or changed their ways of course, hehe...

Anyway. For a sec, let me move to the topic of helping... Not just openSUSE, but Free Software in general. I'm not sure how effective this is going to be, but I like the idea even though it's remarkably similar to linux counter :D

Ok, one more thing, because I can't help myself: the openSUSE marketing team is working on some flyers - KDE promo peeps might recognize something there, hehe. Find them here (for potential users) and here (for potential developers). Feel free to edit and improve ;-)

Oh and of course, because we're less than 2 weeks away now - go register!



Love, Jos

Target Aquired... Aim... xxxxx!

Hi all!

Today the first part of a new description of openSUSE was released. Go, read through it, comment on it if you like!

We are using something relatively new for the commenting called co-ment. I encountered a similar tech when reading up on what was going on with the GPLv3 while it was being written - and thought it was brilliant... So we're using it now to get comments on the text we write in a more structured manner. Feel free to join the discussion!

Cheers,
Jos

directions - openSUSE and Fedora

Interestingly enough, in parallel to our discussion about where we're going, Fedora is also discussing strategy. One particularly good blog post by Máirín Duffy about target users of Fedora offers some interesting insights.

Situation

On Fedora, there are basically four repositories:

• Stable - end user product


• Testing - stabilisation tree


• Rawhide - development tree (our factory)


• Kopers - personal repositories (bit like our Build Service home projects)

As you might know, Fedora Stable does currently receive quite some package updates over it's lifecycle - catering to users who want the latest software. The downside of this is that it sacrifices stability - you can't have your cake and eat it too. And for some users - even that isn't enough. They want the latest Banshee when it is released right away - not wait for it to mature in Testing. So they have to enable Rawhide repositories - often bringing in far more unstable software than just Banshee or whatever they're after. And that software is build against a whole different stack - Rawhide has moved beyond stable of course, adding things like a newer glib or other base libraries and building against a newer GCC. All this creates a significant risk for instability.

Solution?

Máirín describes 4 target users of Fedora:

• Caroline Casual-User


• Pamela Packager


• Connie Community


• Nancy Ninja

She proposes to give each of these users what they want by essentially splitting the update policy for packages based on what 'level' the are. She recognizes Core Platform, Core Desktop and Applications. Core Platform should only receive crucial fixes and security updates, Core Desktop should get a bit more liberal updates and Applications should always be up to date. This way, users won't get bitten by instability, yet those who want more up-to-date software don't have to resort to Rawhide either.

Does this solve the problem? It does if you assume these more up-to-date packages for the Applications don't ever break things for Caroline. And if you assume that there is no reason why Nancy Ninja newer version of something in the Core Platform or the Core Desktop for the app she's writing.

openSUSE

openSUSE is far more conservative when it comes to upgrading packages in the stable release. Making it a much more stable platform. So, that means you're always a bit behind and you can't have the latest and greatest? No! openSUSE users CAN have their cake and eat it too. Thanks to the Build Service, newer versions of enduser applications and libraries can be entirely build against the stable distribution, lowering the number of packages you need to pull in and thus increasing stability.

Máirín and the other Fedora peeps don't use OBS - luckily, it's a Free service. Sponsored by Novell, AMD, IP Exchange and B1 Systems. Many packages on the openSUSE buildservice are build for various stable Fedora releases as well as for Red Hat releases, Ubuntu, Mandriva and of course SUSE Linux Enterprise. And the Build Service is also used by third parties like MeeGo to build their packages in house.

So I would invite Fedora users like Caroline to grab just the one package she needs from OBS!

For developers - and users

So the buildservice is awesome for developers who want to make their software available to users - no matter what distribution they use. The Build Service builds each package on a clean virtual machine install of the target distribution, guaranteeing compatibility. Check the documentation here. And a nice tutorial here. Note that it currently mostly focusses on the commandline solution OSC - but you can actually build and packages entirely from your webbrowser and get them to your users with almost no hassle using the gtk-apps.org and kde-apps.org OBS integration. Be like Lucky Backup and offer packages for ALL mayor distro's instead of only Ubuntu OR Fedora Or ...!

And for openSUSE and it's users, OBS enables us to cater a much wider audience than we ever could without. We can make newer software easily available for users who want it thanks to the one-click-install; yet users who want stability can have it. Surely there is still work to do - a proper app-store would be nice, although the search on software.opensuse.org IS pretty good...

Of course there is more awesomeness to openSUSE - like SUSE Studio (cool video here) and more. I just wanted to highlight one thing ;-)