Changes brewing for openSUSE?

For some time now, openSUSE has been searching for its identity. It is not alone in that, as Fedora and others have also wrestled with many of the same questions. Some of the recent discussions were largely inspired by SUSE VP of Engineering Ralf Flaxa's keynote [YouTube] at the recently concluded openSUSE conference—though many of the ideas have been floating around for years. Since then, discussion is ongoing regarding the future and plans for the distribution and its offshoots: Factory, Tumbleweed, and Evergreen.

One of the problems for openSUSE right now is that the work that goes into Tumbleweed, a rolling release, is not necessarily aligned with what is going on in Factory, which is where the development for the next version happens (much like Fedora's Rawhide). Packages may be updated in Tumbleweed (or available from the openSUSE Build Service), but not be the same as what is being developed for Factory, and thus for the next openSUSE. Getting those efforts in better alignment would be one step in the right direction.

There is also the belief that openSUSE is not well-targeted and tries to be too many things to too many different kinds of users. For example, the current eight-month release cycle is too frequent for some, but too slow for others. Similarly, the 18-month support cycle for each release is either too short or far longer than many users are interested in. As openSUSE community manager Jos Poortvliet put it on his blog: "openSUSE is well known for doing everything a bit - making everybody a little happy, but nobody REALLY happy."

Flaxa offered more help for openSUSE from the SUSE Linux Enterprise (SLE) team, but also noted that he was not there to mandate anything. OpenSUSE has been working on transparent community governance for some time, and SUSE wants to see that continue, he said. The conclusion of his keynote was based around suggestions from SUSE, not mandates, or even requests. Many of the suggestions parallel the problems that Poortvliet and others have been bringing up (e.g. quality, life cycle, release integration, etc.).

Flaxa said that SUSE is pleased with openSUSE and plans to continue its investment in it. But, he said, there is a gap between the users served by openSUSE and those served by SLE. One suggestion he had was to try to bridge that gap, such that there was a smoother path, not just for users moving to SLE, but also for SLE users to be able to use openSUSE more effectively. SUSE is also interested in seeing a more community-oriented openSUSE as its governance broadens.

The roots of some of these issues go back at least three years to the openSUSE strategy discussions of 2010. While a strategy was determined in 2011, it didn't really change things that much. In many ways, openSUSE is running in third place behind Ubuntu and Fedora. Users who want user-friendliness tend to turn to Ubuntu, while those looking for the cutting edge (or nearly so) look to Fedora.

But even if a particular focus can be settled on in terms of the kinds of users the distribution will target, there are some technical barriers to overcome. Some of those barriers and possible solutions were discussed back in June 2012 once it became clear that the 12.2 release would have to be delayed.

More recently, openSUSE board member Robert Schweikert opened a discussion on "Fiddling with our development model" on the opensuse-factory mailing list. He clearly noted that the ideas were his, "NOT board intervention", however. Schweikert sees problems with the current "push model" where a new component like GCC can enter Factory and break lots of other packages. There are only a few people from the release team working to resolve those kinds of problems, so Factory (or the staging portion of Factory) can be broken for a long time.

That problem led Schweikert to propose breaking the distribution up into "components", each of which has a clearly defined set of dependencies. Multiple versions of a component might be supported at any given time, and the other components' teams would decide when to switch to a new version of a component it is dependent on. That way a change to a dependency wouldn't immediately be able to break any packages dependent on it as there would be no forced upgrade (at least until distribution release time neared).

There were a number of posters disagreeing with Schweikert's approach, but his post did spark a discussion that the distribution needs to have, at least according to Poortvliet. An alternative that has evidently been suggested by Stephan "Coolo" Kulow is to separate the packages in Factory into "rings". Poortvliet mentions the idea in his blog post above, as well as in an earlier one.

Basically, the core of the OS, the kernel and minimum needed to boot would be ring 0, while build tools and utilities would be in ring 1, ring 2 would have desktops and their development frameworks, and, finally, user applications would live in ring 3. The rings could be supported for different lengths of time, and could be updated separately. So one could keep the core and desktop stable, but update the applications frequently, for example.

So far, the rings idea hasn't really been discussed on the mailing list, but based on the comments on Poortvliet's posts, it may be more popular than Schweikert's idea. In the final analysis, though, the question is much bigger than just a technical one. Poortvliet put it this way:

That, in some ways, takes the distribution full circle, back to the 2010/2011 strategy discussions and vote. It is not an easy problem to solve. There are lots of people involved, each with their own personal idea of what the distribution is "for". As we have seen, other distributions have struggled with the same thing. Even Ubuntu, which seems to have the clearest grasp on who its audience is, went through a long discussion of switching to rolling release model recently. In all of those cases, the distributions in question have been struggling to better serve their users—openSUSE is following that same path.