Leaping into the Future

At SUSECON, Richard Brown and I discussed a variety of topics, including the adoption or rejection of the two versions of openSUSE: Leap and Tumbleweed. We also discussed openSUSE's relationship with the desktop environment and arrival of openSUSE to Raspberry Pi 3.

ADMIN magazine: It's been a year now since openSUSE made a leap by moving its base to SUSE Linux Enterprise SP1 with the release of openSUSE Leap 42.1. How has the feedback been?

Richard Brown: The release of Leap went according to plan in many respects. We got it out on time; we got it on schedule; the quality was right where we wanted it to be. The engagement from the community was great and on point. We wanted the adoption by users, and downloads were exactly where we'd hoped them to be. Especially with going for a more conservative audience, there was always a little bit of concern of "are we going to have a little bit of a drop-off of our user base?" But the adoption rates were exactly where we expected [them] to be; it is more conservative. It wasn't like an astronomical growth that we've seen with Tumbleweed, but it was healthy.

ADMIN: What effect did it have on SLES?

RB: Everything was as expected, with some interesting things along the journey that I wasn't expecting. Obviously SUSE was to use this as a way of establishing more communication with the community and engagement there. That all worked out fine. One thing that's come across that we weren't expecting was actually more engagement from SUSE's customers and partners with SUSE and openSUSE through Leap. There were cases where companies like IBM were contributing directly to openSUSE, because they know that's going to be reflected in the SLE side of things and that makes their lives easy.

ADMIN: It's a complicated chemistry between SLES and openSUSE. OpenSUSE Leap is upstream of SLES but is itself based on SLES, whereas Tumbleweed is upstream of Leap. You gave an example of IBM contributing to openSUSE so that it goes into SLES, so if a company wants to get some code in SLES, where do they go? It's complicated.

RB: Yeah, that's not a simple question to answer. Because Leap is simultaneously downstream and upstream of SLES. For the parts that are shared with SLES, Leap is downstream of SLES. The submission path would be typically via SLES in essence, but for the parts that are not shared with SLES – all the community stuff – most of the time, that comes from Tumbleweed.

ADMIN: So if someone wants to contribute some code where does it go? If I am not wrong, SLE development, just like RHEL is not public.

RB: SUSE engineering are still doing their development their way. In the totally open sense side of things, the easiest, the quickest, the fastest route for starting this is contributing to Tumbleweed. Having your code in Tumbleweed first is the healthiest option, even if in order to get it into Tumbleweed you have to make some changes. If you want your package in Leap, it has to come through Tumbleweed.

ADMIN: OK, so openSUSE is kind of becoming a channel through which one can contribute to SLE, but here I see openSUSE as a beneficiary as it's getting more contributions. But how is it benefitting SLE?

RB: That's another benefit that we've seen that I wasn't expecting to get from openSUSE Leap quite so soon. I was hoping for it, but I wasn't expecting it this fast. For SLE 12 SP2, this year, SUSE has been able to move SLE a lot farther, a lot faster. When it came to planning for SLE SP2, they found that openSUSE has already been there, we've done that, we know which packages aren't dangerous; they are not going to break anything. That allows SLES engineers to upgrade the internals, like [the] kernel, Gnome, systemd, in SLES SP2. It's a big service pack for SUSE. Leap being there with the way we do it in 42.1 has really, really helped that.

ADMIN: How has the response been to Tumbleweed?

RB: Tumbleweed is now a healthy chunk of that growth – I would say approximately 10% to 15% of our user base. We'd have to go back and look. It's a healthy, measurable mark in there. In terms of growth rates, you're talking about 10 times more than Tumbleweed used to be in a year.

ADMIN: You have seen Leap, you have seen Tumbleweed, what do you see as the future of a Linux distribution? Point releases or rolling releases?

RB: My feeling, looking forward to where I expect everyone to be in five years, is [that] rolling releases are the future of those distributions. I look at how the rolling release process works; I look at how upstreams work; I look at some of the pain points that have spawned ideas like Snappy and Flatpak. Upstreams wanted to get their stuff in the hands of users faster, and rolling release solved those issues, in my opinion, in a more efficient way, where the workload of getting that stuff into the hands of users is distributed more equitably between the upstreams and the downstreams. It's not like the container with applications where they lack such collaboration and add more burden to the upstream.

I really like rolling releases as that model. However, rolling releases haven't got that whole kind of mindshare yet. There's a lot of fear involved, a lot of nervousness in that. I don't think any rolling release has got it perfectly right yet either. Arch breaks too much and requires too much work. Gentoo just requires too much work. Tumbleweed, I think, is on a really exciting track, because we test all the stuff before it reaches you. It's not a case of stability; it's a case of are you prepared to move at that pace of change?

I think there's scope for rolling releases at a slower pace. That's kind of one thing I'm spending a lot of my time thinking about: How do you define that pace? You almost have to think of it like a hybrid approach of identifying what makes a point release right now appealing – what our users and customers are expecting from that. What pace of change are they comfortable with? I think once you have those answers, there is a real room for having a rolling release fit that gap. Something a little bit more conservative than Tumbleweed.

ADMIN: Many people fear change. There is this mindset of not going with the latest version of software and sticking with the older, well-tested version. How do you manage to maintain the balance between stability and newness?

RB: The mindset exists for very real reasons. People have these very real concerns. Those concerns are not invalid. If they were invalid, we wouldn't be doing Leap. I'm not blind, but I really believe the future is something more rolling.

Transactional updates is one way of solving the problem of not breaking things. SUSE is working on a new operating system called Micro OS that offers transactional updates, and if something breaks, it rolls back to the previous working version. If we can start doing that at Tumbleweed scale, where 8,000 or more packages do a transactional update into a snapshot, and the next time the system reboots it's running those updated snapshots, and if it goes wrong, they can rollback without us touching anything else in their system? Well that's rolling release without the risk.

ADMIN: Talking about updates and support, recently KDE released an LTS version that benefitted openSUSE a lot. I have seen DE [desktop environment]-specific distros that, due to lack of collaboration, can't even keep up with the very DE they are distributing. How did you manage that feat with KDE?

RB: By dealing with KDE upstream the same way we deal with each other in the distribution. A perfect case study of that would be KDE 5.8. The upstream release schedule meant that KDE 5.8 would have been too late for us to put in Leap 42.2. We had been having these discussions with KDE for a while. The KDE community came up with the idea of an LTS release that was to kind of address some of the things we'd been raising as a point of concern. We had those discussions, and we said: What if you moved your release schedule forward a bit and we move our release schedule back a bit? We both basically compromised. KDE shifted theirs a bit; we shifted ours a bit. That then gave us a nice, healthy set of weeks that we could actually integrate this stuff.

We've now got KDE 5.8 (LTS) in Leap 42.2. That's important, as KDE 5.9 is going to be a very ambitious release with the kind of changes they are planning for it – which would be a bit too ambitious for us to put in openSUSE 42.3, but we can now still ship 5.8, as it will be supported for a bit longer.

We're having those discussions right now. They're going really well. We're talking about maybe adding in another six or 12 months to KDE's 5.8 release. That's great for us. We're hoping that they'll work with that. It's how open sources mainly work. That's how we work.

ADMIN: Is KDE going to stay the default DE for openSUSE? Default in the sense that openSUSE offers a few DEs during install, but KDE comes pre-checked. I have heard reports about a change.

RB: From a cultural perspective inside the community, we don't actually treat ourselves like a default. We treat Gnome and KDE equally. In terms of which one is the default in the openSUSE distributions, this is under a constant state of review. There has been no decision made there. There won't be a decision made there without discussing it with our internal KDE teams and the upstream KDE team and the Gnome team. Ultimately, openSUSE's promise is making sure that we give the nicest, cleanest, most stable options to our users, especially in Leap.

In Tumbleweed we have had the discussion about maybe not having a default. We do have an agreement in principle from all of our distribution maintainers, including the KDE team, to not have a default in Tumbleweed. We haven't pulled the trigger on that yet because, you know, when we do that we want to make sure the timing's right. If we're going to change something in Leap, that's when we'll talk about changing it in Tumbleweed, but in principle, the no default for Tumbleweed is in the cards, and no default for Leap I think makes no sense. Aiming for a different user base there.

ADMIN: Why aren't there Live ISO images for Leap, whereas there are for Tumbleweed?

RB: We have Live CD images for Tumbleweed; we do not have Live CD images for Leap. We are looking for contributors to work on it. If somebody contributes them, and supports them, and is able to deal with bugs and keep them polished, we're more than happy to have them. There is no blocker for the live CD images; it's all about what contributors want. With the contributors we have right now, they're not interested in doing that. We haven't done it yet.

ADMIN: OpenSUSE is being touted as "makers," or, in other words, a developer distribution.

RB: The vision we have for openSUSE as an ideal platform for developers is not just throwing a few tools in for someone to play with. It's the whole ecosystem. It's the whole ability for a developer to sit on an openSUSE machine [and] be able to have the tools they need to get the job done that they want to get done. They also need tools to build their packages for our distributions and others. That's where our OBS (Open Build Service) comes into [the] picture that helps them in building for our and other platforms. They need to test these things on openSUSE and other systems, and that's where our openQA helps them. It's the whole ecosystem of having the tools, the technology to do it on your machine, to then deliver it with our tools [and] test it on Leap if you want to go the enterprise route. None of it is being centric with our distribution – it supports other major distributions like Fedora, Debian, Ubuntu.

We are not going to have everything a developer wants, so by being a nice, easy distribution for them to work with, they can then get the features they need into our distribution, get the features that they need into our tools – being easy and very open for developers to then shape openSUSE to be the developer platform they want it to be. That's what we do. That's where we're going. That's the vision.

ADMIN: One of the biggest highlights of SUSECON is SLES S2 support for Raspberry Pi 3 Model B, which also means openSUSE will be running on Raspberry Pi. Why would users care about openSUSE on the Pi 3?

RB: Yes, openSUSE will be officially supported on Raspberry Pi 3 Model B. We are already running Leap 42.2 and Tumbleweed on it. Users should care about it because openSUSE is the only 64-bit operating system for Raspberry Pi 3 Model B.

ADMIN: What are the things that are working and not working?

RB: Everything is working great. There might be some issues, due to patents and licensing, but they may be fixed. Unlike other distributions for Pi, we do everything upstream, so if there are some things that are not working [in] openSUSE, it [is] because upstream doesn't yet support it. OpenSUSE always contributes "upstream first." The changes we're making to the kernel to support the Pi 3 are being submitted to the upstream kernel, and we're working with them to get them in. Meanwhile, openSUSE offers Pi images that offer both the standard upstream kernel and a variant which includes some of the Pi Foundation patches which haven't managed to get upstream yet.