OpenSUSE is a major community Linux distro and Richard Brown is Chairman of the OpenSUSE Board. OHM managed to catch up with him and ask him a few questions....
Q: Richard, please introduce yourself and your roles with the OpenSUSE project and SUSE?
This should be such an easy question but I’m going to manage to make it complicated.
I’m Richard Brown, and I’ve been contributing to openSUSE since it started in 2005, with various roles as a tester, ambassador, packager, and as a community elected Board Member.
Since 2014 I’m now openSUSE’s Chairman of the Board. The Board is the body inside the openSUSE Project responsible for ‘leading’ the Project.
As openSUSE tries to be as empowering as possible to its contributors, leaving as many decisions as possible to the people actually doing the work, this actually translates to the Board primarily being a central contact point, a group where people inside and outside the project can turn to for advice, direction, and a hand to find out who else to talk to and start working with.
We’re also the project’s conflict resolution body, and decision makers of last resort when there is no one else able or willing to make a decision inside the project. The Board consists of 6 members, 5 elected by the community, with the Chairman appointed by SUSE.
Previously, I used to work as a Systems Manager in academia in the UK. Since 2013 I’ve moved to Germany and I’m now working in the QA Department at SUSE.
So in addition to my openSUSE work, I work as a Technical Lead for openQA, the open source testing tool which was originally used for testing openSUSE and is now also adopted by SUSE for SLE (and Red Hat for Fedora).
Q: Back to basics - what is openSUSE and how did it get started?
openSUSE is an independent open source project started in 2005. Back then it was primarily a vessel for the opening up of the SUSE Linux (aka SUSE Linux Professional) boxed Linux distribution, while SUSE turned it’s corporate attention towards the SUSE Linux Enterprise products.
Since then we’ve evolved into a very vibrant and large open source community, which actually now produces 2 Linux distributions (Tumbleweed and Leap) as well as several major tools, such as the Open Build Service (OBS), openQA, YaST and KIWI.
Q: What’s the relationship with SUSE?
SUSE are the primary sponsor of the openSUSE Project. This sponsorship is provided in terms of finance, infrastructure, and some dedicated staff to help in very specific areas . for example Release Management, Marketing, and myself as Chairman.
SUSE seek to ensure openSUSE operates as an independent project, free and able to set it’s own direction, with the community deciding it’s own fate and what exciting new avenues to pursue - it sees it as the most effective way to guarantee a healthy future for openSUSE, but also a source of continual innovation which may (or may not) be beneficial to SUSE someday.
So when it comes to the nitty gritty of actually contributing to the Project, SUSE contributes to openSUSE as peers, with many SUSE employees collaborating on various parts of the openSUSE Project and our products alongside community members from around the world.
As much as possible, the whole of the R&D Department at SUSE is actively encouraged to contribute in this way, and in addition to doing so as part of their day jobs, SUSE run regular Hack Weeks where SUSE employees can work on whatever they want for one week, and this often leads to very intense bursts of exciting new ideas which often lead to very tangible benefits for openSUSE - such as our new website at www.opensuse.org which started as a SUSE Hackweek Project.
Q: How do you compare openSUSE with SLES?
That depends what you mean by ‘openSUSE’ - as we’re now a project with two separate Linux distributions. There is no longer a single ‘openSUSE’ to compare with SLES.
We have openSUSE Tumbleweed, which is our rolling release - a rolling release is a relatively new concept for a Linux distribution, the idea is to forgo releases, instead constantly releasing a consistent distribution, full of the packages which everyone wants to use, at the latest versions.
This is a really exciting offering, especially for developers, desktop users, and enthusiasts who want to experience the cutting edge of Linux, without the several month wait that normally comes with the ‘old fashioned’ way of distribution releases. It allows us to get new features, innovations, and bug fixes in the hands of users right away, and can much more closely follow and contribute back to all of the various upstream projects we’re working with, such as the Linux Kernel, GNOME, and KDE.
Tumbleweed, our rolling release is currently unique among the Linux distributions because we’ve been able to leverage the full power and capabilities of openSUSE’s tools like the Open Build Service and openQA.
We’re able to build the distribution with a huge amount of changes, going through a process similar to a full blown openSUSE or SLES release, several times a week - Sometimes we’re doing as many as 5 ‘snapshot releases’ a week, which means not only new packages available for download, but new ISOs and disk images published, just like a full blown distribution release.
And unlike other rolling releases, each and every ‘snapshot release’ of Tumbleweed is fully tested before we put it in the hands of any human user. openQA automatically installs and upgrades the new version of Tumbleweed over 100 times, in a whole variety of different scenarios and configurations, and we only release it to users when openQA’s automated results categorically confirm that this new version actually works.
It doesn’t really compare to SLES much, in the sense that it is almost a ‘complete opposite’ - SLES favours choosing specific versions of packages for each major release, and then from that point on SUSE expend great effort in carefully maintaining those packages, making changes in response to customer demand, but generally keeping everything as stable as possible.
However, this very fast moving code stream is very beneficial to the SLE ecosystem. SLE 12 included a lot of stuff pulled straight from Tumbleweed. Modules benefit greatly from the constantly evolving versions available in Tumbleweed, and ultimately the expectation is that SLE 13, the next stable release of SLE, will be branched from a Tumbleweed snapshot some years from now.
Alongside Tumbleweed, we have our regular release, which has recently undergone a major change and we’re now calling openSUSE Leap. Leap is a much more ‘traditional’ Linux distribution (with one major twist), with regular minor releases approximately every year, and a major release expected a few years from now.
Leap targets more conservative desktop users, maybe some developers on slower moving software stacks, and system administrators, the kind of people who want a powerful community Linux distribution, but favour something that ‘just works’ over something that ‘just works with the latest of everything’.
Q: I’ve heard talk of a Project 42 - please explain?
Project 42 was a codename (one among many: Core, Cornerstone, and probably some others) for a concept which has now grown into openSUSE Leap, our new Regular Release.
Unlike previous openSUSE Regular Releases, which were wholly built by the openSUSE Project on our own codestream (which was only synchronised with SUSE when they used it for SLE every few years), Leap is the world’s first ‘hybrid’ Linux distribution
SUSE have made available the source packages for SUSE Linux Enterprise 12, and will also be including the sources for maintenance updates, in our openSUSE Build Service.
This has enabled openSUSE to build a unique distribution that takes ‘the best of both worlds’. Leap has a ‘core’ which shares a great deal of code with SUSE Linux Enterprise, but on top of that core the openSUSE community have built a large, capable community distribution, including technologies like KDE and newer versions of GNOME which are not readily available on SUSE Linux Enterprise.
From a community perspective, it’s an opportunity to build a stable release with less effort, as openSUSE benefits from the maintenance work SUSE are doing for SUSE Linux Enterprise.
From SUSE’s perspective, it helps expand their options for SUSE Linux Enterprise.
Every package openSUSE adds to Leap, or every package openSUSE decides to upgrade from that SLE base, becomes a potential candidate for either future SLE Service Packs or Modules.
From both organisations perspectives, Leap is an opportunity to collaborate much more closely and more often with each other, learning from a much broader spectrum and finding ways to save each other work and last but not least, from a users perspective, Leap will be a distribution that should benefit from both the enterprise stability of the SLE source packages, and the broad package selection and capabilities from the openSUSE source packages.
The first release of Leap will be Leap 42.1, due out in November 2015.
Q: Is openSUSE enterprise ready?
That totally depends on what you mean by ‘enterprise’ ready.
If you want a Linux distribution with 10+ years of patches & support, with someone on the end of the phone to provide help, support, custom packages and such, then your best choice is clearly the paid-for SUSE Linux Enterprise from SUSE.
Leap offers approx 3+ years of patches, and there is no official support besides that which the openSUSE community provides via it’s volunteer forums, chat-rooms, and mailing lists.
However this should mean Leap can find a home in a whole bunch of ‘enterprise’ environments where SLE might not be considered. Test environments, small scale deployments, small-to-medium businesses, are all potential users of openSUSE Leap who may find themselves deploying Leap either exclusively or alongside SUSE’s enterprise offerings.
And openSUSE Tumbleweed is ready, if your needs are for something that runs the latest of everything, which is becoming a growing possibility for organisations who like to push the boundaries and live on the cutting edge of open source technologies.
Q: What’s the process for updating and improving the openSUSE release?
Again, it depends on which distribution.
Tumbleweed follows a process known as the Factory process. As upstream software projects produce new software or new versions of existing software, our openSUSE contributors create packages for that software. This is submitted to the openSUSE Factory, where the Open Build Service builds the packages.
For important packages we go through an additional process known as Staging where those submitted packages are vetted automatically by openQA, which is using OBS created What-If-DVDs which are basically special custom versions of Tumbleweed that include the proposed changes (answering the question “What if we added this?”).
This makes sure that many potential breakages are found before they get anywhere near the main Tumbleweed codebase, and contributors are given immediate feedback to go back and fix it before submitting the package again
Once the packages are in openSUSE Factory, the Build Service then creates candidate Tumbleweed ISOs and Disk Images. These are then all tested automatically in openQA, which can actually see the screen, analyse the UI elements and ensure that users will actually see the things they should see, while typing and clicking mouse buttons the same way users do. This tests installation, console applications, and graphical applications, in over 100 different scenarios on different hardware architectures.
When those tests sufficiently pass, we release a new Tumbleweed snapshot, which includes new ISOs for download for new years, and standard package updates for all our existing users.
One of the nicest things with this process is that it’s totally open to anyone. Anyone can login to the Open Build Service and start putting together packages which can then end up in Tumbleweed.
There are no bureaucratic processes about selecting new features or packages, just a few lightweight steps like talking to existing contributors to make sure everyone knows what is going on and so that everyone can help each other out.
This approach avoids a lot of the heartache and debates other distros go through. If we have two sets of contributors both wanting to pull openSUSE in different directions, the natural reaction with this process is to find either a compromise which both are happy with, or find a way of doing both - so conflict and strife is a pretty rare thing.
For openSUSE Leap, the process shares a lot of the lessons learned with Tumbleweed. We have of course both SLE and Tumbleweed as potential sources of packages for Leap.
Those are selected by contributors, submitted to Leap and staged, similar to how we do things with Tumbleweed. Then they’re tested by openQA before selected builds called Milestones, Betas, or Release Candidates get additional manual testing.
Once Leap is released in November, the process for maintenance updates will be much more like a ‘traditional’ openSUSE release, where bug fixes are carefully put together as a minimal change to a package, submitted using the open build service, and made available to users after a period of testing.
In the case of the packages using SLE sources, this will all be done by SUSE as part of their regular work on SLE.
Q: How can people get involved with the openSUSE project?
Find an area that interests you, and start contributing! www.opensuse.org has a lot of pointers to help people get started. We need packagers, people helping on our support forums and chat rooms, wiki writers and editors, people to go conferences, gatherings, friends, and advocate the use of openSUSE.
Whatever your skillset, there is a way you can help openSUSE. The best way is to read the information on our website and wiki, or just find a way of getting in touch with us that you like, be that IRC, mailing lists, forums, or social media, and just start getting involved.
And remember, have a lot of fun 🙂
Richard, thank you for taking the time to explain all this. Now you can get back to work!
This article was forst published in OH Magazine, Issue 31, 4/2015, p13-16