Distributions

Rebasing openSUSE

The success story is Tumbleweed, a fast-moving distribution built on the rolling-release model. Like other rolling distributions, Tumbleweed does without fixed releases; instead, it regularly incorporates updated software as it becomes ready. The number of Tumbleweed users has been growing at a steady rate, which is a good thing, but, as openSUSE board chair Richard Brown pointed out in a discussion in May, that growth has come at a cost:

As a result, the openSUSE 13.2 release "required a large amount of work from a small number of people to make it a success", and it's not clear that there will be that many more people to put together future openSUSE releases. The openSUSE distribution seems to be caught in an unappealing middle point: it does not move as quickly as Tumbleweed, but it still updates often enough to put off users looking for a higher level of stability. It is not entirely clear who the targeted users for openSUSE are.

Rebasing openSUSE

It might thus seem that the way to put openSUSE on a better growth path would be to get it out of Tumbleweed's shadow. Some core developers believe that the opportunity to do just that came at the end of April, when SUSE announced that all of the sources for SUSE Linux Enterprise (SLE) distribution would be placed into the open build system; this repository will also receive all SLE updates going forward. That announcement foreshadowed the plan for openSUSE:

Richard subsequently put forward this proposal at the openSUSE Conference in May [video]. There, he reiterated that openSUSE seems to be stuck in the middle, pulled one way by users wanting newer software and the other way by users wanting greater stability and longer support. Tumbleweed has pretty well satisfied the first camp, he said, so openSUSE should move to meet the needs of the second. That means, he said, offering a stable, well-maintained distribution with a lifecycle of at least three years and with a wide selection of packages.

The way to do that, he said, would be to rebase openSUSE on a "shared core" of SLE packages. Those packages would be maintained by the SLE developers, so openSUSE would get support and security updates for free. This core, he said, could comprise about 1,000 packages. The openSUSE project would then add newer packages based on its ability to maintain them, building toward that distribution's current size of about 6,000 packages. OpenSUSE would be able to replace "shared core" packages with its own at any time, but the project would then be on its own to maintain them, so such replacements should be done with care. The SLE 12 SP1 release is due around the end of the year; that would, Richard said, be a good time to put out a new, rebased openSUSE release.

Since then, openSUSE release manager Stephan Kulow has announced that he will indeed be working to base the next openSUSE release on the SLE core. Desktop software and other chosen packages would continue to come from the openSUSE Factory rather than SLE, offering openSUSE users a relatively new desktop experience on top of a stable core. Stephan is currently calling this release "openSUSE:42".

Discussion

As one might imagine, this decision is rather controversial in the openSUSE community and has led to a number of lengthy email threads. It is, after all, a huge change from previous openSUSE releases. We are, of course, talking about the change in version number from 13 to 42.

That said, there has been a remarkable lack of viable alternatives for the name. Stephan himself had come up with "openSUSE Boring" as an alternative, but such names have a tendency to run into irrational opposition from people in the marketing department. Robert Schweikert put forward "openSUSE Oak" as a suitably stable name to put up against "Tumbleweed," but there does not seem to be a lot of enthusiasm for that. Robert also noted that one other possible name, "openSLES," had a high probability of running into trouble from SUSE's legal department and was, thus, best avoided. The naming issue, it seems, is likely to be a topic of discussion for some time yet.

Meanwhile, there are users who have concerns about the nature of the changed distribution itself. Basing openSUSE on SLE means that many of the core components will regress to earlier versions in the release following 13.2. For example, openSUSE 13.2 runs a 3.16 kernel, while SLE 12 has 3.12. A reverse jump in the version numbers of core components just doesn't seem like the kind of change that is going to excite potential users. So, for example, Guido Berhoerster worried that this change, and the potential loss of support for new hardware in particular, would end up forcing some users and contributors away.

Stephan noted that concern, but indicated that the plan was going forward regardless:

To many users, the new openSUSE looks like an attempt to reproduce CentOS; some have even called it "SLEntOS". Richard (and others) are adamant, though, that this is not the intent. Between openSUSE's developers and its tooling, he says, it should be possible to do some interesting things with the new base:

The shape of something that only openSUSE can do remains necessarily vague at this point. It should come into better focus as developers work on creating a shippable distribution built on the new core.

Driving forces

Behind all of this, of course, there is a simple driving force: the openSUSE project does not really have the resources to properly maintain a lot of the low-level infrastructure that keeps a distribution going. Maintaining the kernel is, itself, a major job, especially if the distribution is (as openSUSE 13.2 is) not based on a mainline release with long-term maintenance. Taking advantage of the work done by the SLE developers should give openSUSE a rock-solid base to work from — a base that will be maintained for them. The time and energy that has been freed up can then, in theory at least, be applied to doing more interesting things at the higher levels of the application stack.

Meanwhile, SUSE also stands to benefit from this change. It allows SLE developers to work a little closer to the community and should, with luck, make it easier for work to move from openSUSE into SLE releases. So it is not surprising that SUSE is putting resources into making this change happen.

All of this depends, of course, on the new openSUSE's ability to attract users and contributors. The distribution is trying to push into a distinct, hybrid space that has not been seriously tried before (though the CentOS variants idea shows some similar themes). It does appear that openSUSE needs to make some changes toward being a stable distribution that properly complements Tumbleweed. The shift toward a stable core might just prove to be the change that openSUSE needs.

Comments (44 posted)

Distribution quotes of the week

Comments (4 posted)

Mageia 5 released

Comments (3 posted)

The Open Container Project

Comments (62 posted)

Fedora elections, interviews with the candidates

The candidates for FESCo are: Dennis Gilmore, David King, Josh Boyer, Haïkel Guémar, Stephen Gallagher, and Germano Massullo. The candidates for Env and Stacks are: Stuart Campbell, Nick Coghlan, Jan Kaluza, Jens Petersen, Václav Pavlín, and Honza Horak.

Comments (none posted)

Fedora 20 End Of Life

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 615 (June 22)
• 5 things in Fedora this week (June 19)
• Tumbleweed - Review of the Week (June 20)
• Ubuntu Weekly Newsletter, Issue 422 (June 21)

Comments (none posted)

Bacon: Rebasing Ubuntu on Android?

At his blog, former Ubuntu Community Manager Jono Bacon speculates on whether or not the Ubuntu Phone project should rebase its software stack on Android. Bacon prefaces the post with a note that it is "designed purely for some intellectual fun and discussion. I am not proposing we actually do this, nor advocating for this." The central argument is that new mobile platforms invariably expend hundreds of thousands of dollars attracting well-known app vendors to the new stack. Supporting Android apps would let Ubuntu focus efforts on the user interface, scopes, and other components. "I know there has been a reluctance to support Android apps on Ubuntu as it devalues the Ubuntu app ecosystem and people would just use Android apps, but I honestly think some kind of middle-ground is needed to get into the game, otherwise I worry we won’t even make it to the subs bench no matter how awesome our technology is." Note that, whatever one makes of the idea, Bacon is speaking only about the Ubuntu Phone stack; the post does touch on how such a rebase would interfere with Ubuntu's plans for a converged software stack.

Comments (21 posted)

The long ARM of Linux: Red Hat Enterprise Linux Server for ARM Development Preview (Red Hat Blog)

Comments (1 posted)

Shuttleworth: Introducing the Fan

Comments (58 posted)