Interview – Dr. Gerald Pfeifer

OpenSUSE [1] was once one of the leading open source RPM-based distributions and one of the handful of distributions that operated under the auspices of a for-profit corporation. While SUSE had been marketing Linux for the enterprise since the '90s, the openSUSE project began in 2005, a couple of years after the company's acquisition by Novell. The last decade, however, has been very turbulent for SUSE, which has changed ownership several times.

At the Open Source Summit in Lyon, France, in 2019, I caught up with Dr. Gerald Pfeifer [2], who is the CTO at SUSE and chair of the openSUSE board. Despite the multiple changes of ownership and the resulting apprehensions from the community, Pfeifer assures that the openSUSE project continues unabated. Pfeifer has been actively involved in the open source community for several years, contributing to various open source projects, including GCC, Wine, and FreeBSD. In our conversation, he explains the current status of the openSUSE project and how its relationship with SUSE's Enterprise offering is a win-win for both the company and the project.

Linux Magazine : Let's start with your role at SUSE?

Gerald Pfeifer : I wear two hats. For example, at this event, I'm CTO at SUSE based in EMEA (Europe, the Middle East, and Africa). There's two of us: one based in North America, me based in EMEA. And since August, I also am the chairperson of the openSUSE Board.

LM : It's been a turbulent few years for SUSE with all the acquisitions. Where do things stand now? Who owns what, and what does it mean for openSUSE?

GP : SUSE now is wholly owned by EQT, a Swedish investment fund. That was announced in July of 2018. And then in spring 2019, mid-March, is when SUSE became really independent. The process of becoming independent kept us busy.

LM : How does this change of ownership affect openSUSE?

GP : I have talked with people in the openSUSE communities, and I've heard that some are a little concerned about the change of ownership. But practically, so far there hasn't been a change for the openSUSE project. Full stop. And there is no concrete plan of changing anything around openSUSE, driven from a SUSE perspective or from our owners. When I became chair of the board in August 2019, I started to look into the situation from both sides and had many conversations. One thing I found is that there is an opportunity for SUSE to communicate better with openSUSE our intentions, our commitments, and our ongoing commitments. For example, Melissa Di Donato, our CEO of SUSE, has sent a message to the openSUSE Asia Summit that happened in Bali first weekend in October re-emphasizing the importance of openSUSE for SUSE.

Equally what I found is many of us working for SUSE, including myself even before that change, have a foot in both openSUSE and SUSE. Even then, I and others at SUSE may not fully see all the good things that happen in the openSUSE communities. It actually could be a good thing if, in both directions, we were to share more – share more about the positives, share more about the positive intentions. This creates additional synergy effects.

One thing that I found is that at openSUSE we're not terribly good at marketing some of our successes and some of our accomplishments towards the world. And that's something I have started to encourage, and I do want to make this one of my contributions.

LM : One thing that you don't communicate very well is that both Leap and Tumbleweed have a relationship with SUSE Linux Enterprise (SLE). Could you please explain that relationship?

GP : OpenSUSE Tumbleweed [3] is a rich, rolling Linux distribution with lots of content, like probably a dozen desktop environments, that you can select as a user. Different components are updated, refreshed, and refined on an ongoing basis. Think of it as a big stream: At nearly any point in time, water is taken out, and fresh water is coming in from upstream. There is a new Linux kernel; there is a new glibc, a new compiler, [and] all the many pieces. We have a fabulous release engineering team that makes sure this all happens very smoothly. They bundle updates and put them into sub-projects that are tested independently – and this is where we have a really cool software called openQA [4] that does a lot of automated tests. If all those tests succeed, everything is integrated, and there is a new snapshot release. This sometimes happens weekly, sometimes twice a week, thrice a week, or so. It's a rolling release, where you essentially get updates of everything, whenever someone packages it, whenever the developers fix some of the implications. For example, you include a new compiler, and all of a sudden a number of packages don't build anymore, because the compiler became more standards compliant, and those packages were not. So you start fixing those packages, work with upstream so they fix, or we do a fix in openSUSE and share it with the upstream project.

LM : But what is the relationship with SLE?

GP : When we're thinking to do a major release of SUSE Linux Enterprise, we pick one point in the stream of openSUSE Tumbleweed and branch, and, say for instance, this is where SUSE Linux Enterprise Server 15 productization starts. Then all those components that you want in SLES 15 form their own code stream and our enterprise processes take place, which focus more on stabilization, documentation, testing, and iterating those steps without updating all the individual components.

Obviously, everything we find in that context is again pushed into the upstream projects directly and openSUSE as applicable, so it's not a one-way street. This is where openSUSE Tumbleweed feeds into a SUSE Linux Enterprise major release.

OpenSUSE Leap [5], on the other hand, combines SUSE Linux Enterprise source code and additional components coming in from openSUSE Tumbleweed. A little simplified, but think of it as a two layer cake, where the base – the Linux kernel, everything around hardware, really the fundamentals of the system – comes from SUSE Linux Enterprise, and then some of the elements higher up in the stack, often things related to the graphical user interface or additional tools, come either from there as well or from the current state of openSUSE Tumbleweed. In other words, openSUSE Leap is downstream of both SUSE Linux Enterprise and Tumbleweed, combining these two.

LM : Why did you choose this approach?

GP : As I said, openSUSE Tumbleweed is actually surprisingly stable, very functional, given that it's a rolling release. I'm using it on my notebook. It's the only operating system currently on my notebook, and I'm quite satisfied.

One of the drawbacks of something like Tumbleweed is, and I see this with friends who are just users, that you regularly get bigger updates. This is sometimes because there's a new version of an application, the user interface changes a little, or just the sheer amount of data that you download. Sometimes it's 300MB; if I don't update for a week or two, then it's 500MB or more, sometimes beyond a gigabyte. So that's a lot. Which is fine for me to consume or techie users, but not necessarily for the persona (as we call them in product management: the persona "partner"). You're the techie, and your partner has a notebook, and all he or she wants is [to] read email, browse the web, [or] manage pictures. So, having something that is stable and has a richer set of applications – especially for desktop users, etc. – is what we wanted to do.

And so we said, let's take the stability of SUSE Linux Enterprise and add more of this richness of the openSUSE ecosystem. Because for SUSE Linux Enterprise, one design criterion we have as a default is "best of breed." We try to focus on one of each: one web server, one desktop environment, one this or that. We deviate when there's a strong user demand. For example, we are shipping KVM and Xen, because we have users of both. But on the desktop environment, we're really focused on Gnome, and KDE is not supported as part of SLE. With openSUSE, we wanted to have more richness, and the upper layer of the cake gets a lot from the openSUSE side. This approach combines stability and richness, and the result is Leap.

LM : SUSE has recently proposed bringing the code streams of SUSE Linux Enterprise and openSUSE Leap closer together [6]. How does this proposal affect the existing relationship between openSUSE and SLE? What does it mean for users of both openSUSE and SLE?

GP : The idea behind this proposal, which I relayed on behalf of SUSE, is to strengthen the relationship; on the one hand, by sharing not just source code, but the actual SUSE Linux Enterprise binary packages for use by openSUSE Leap, [and] on the other hand, by giving openSUSE developers more influence on the development of SUSE Linux Enterprise past the initial point when it branches from Tumbleweed.

As a practical first step, SUSE engineers are analyzing where Leap differs from SLE and adjusting the latter where possible, even if that implies extra effort now or during the life cycle. In parallel, we are also working to open up processes and tools on the enterprise side – think feature or bug tracking.

Why all this? We want to further strengthen the openSUSE project and the position of Leap as a platform for open source communities as well as industry partners. Intensifying collaboration and combining forces benefits users on both sides, and full compatibility between Leap and SUSE Linux Enterprise benefits developers who can target both at once and users who can easily migrate.

LM : SUSE has an interesting product lineup. There's SUSE Linux Enterprise Server for ARM/RaspberryPi, and you also used to sell a version of LibreOffice.

GP : When I was responsible for product management, we sunset LibreOffice as a product. And the reason is very simple. We sold LibreOffice as a Windows product, and it was the only Windows product in our portfolio. From a strategic perspective, but also from a go-to-market perspective, that just didn't work. It's something we inherited from the Novell days. That has been taken over by a partner called Collabora, and some of those team members stayed with SUSE in different areas, and some of the team actually went to Collabora and created the LibreOffice group at Collabora.

LM : Do you have some desktop offerings as well?

GP : We do. We have a SUSE Linux Enterprise Desktop and the Workstation Extension that on top of a full-fledged server product provides desktop functionality. One use case is technical workstations. For instance, you have some CAD software that is certified on the server OS, and you want to run it on your desktop.

LM : Coming to the meat of it, the enterprise back end: You are betting big on containers, especially Kubernetes. The two products that you seem to be excited about are Container as a Service (CaaS) and the SUSE Cloud Application Platform.

GP : Yeah, I'm really excited about them. If I meet someone who has not had a history with SUSE, the way I usually start describing what we do focuses on application delivery. Why have people even started to use Linux? Two reasons: One is to run some part of the infrastructure – be it a web server, be it a print server – so something which a Linux distribution can do, can provide itself. Or, and that's really what happened more and more after the early days of Linux, it is to provide the platform for stuff to run on. And originally, what that meant is, you had an operating system, and you ran one application on that.

But what we see application teams develop – think what Google does! – all the Software-as-a-Service really has a strong focus on containers. So ideally, as an application team, all you want to focus on is you write your software, you test it, [and] you deploy it. And you do not have to focus on provisioning something – networking, storage, and all those things, or even virtual machines [VMs]. You just say: "Here's the software, deploy!" We have based SUSE Cloud Application Platform [7] on that; that is where Cloud Foundry [8] has a history and a lot of experience meeting user requirements. It's focusing on developing, testing, deploying, and not worrying about the infrastructure. That's why if you look at the SUSE architecture, at the top of the architecture, you have application delivery that's instantiated with SUSE Cloud Application Platform.

LM : Where does CaaS fit in?

GP : Where do you deploy stuff? And when I say stuff, increasingly often that stuff is actually containers. Some people package classic software into one huge container. For that, but also to be the foundation for something like Cloud Application Platform, a rich container platform like Kubernetes-based SUSE CaaS Platform is useful.

What if you could quickly and easily, without a lot of manual steps, deploy a cluster running a container infrastructure, have a nice dashboard where you see what's going on in the cluster, how your utilization is, where you're reaching some thresholds like storage or other things, where you can update the cluster, extend the cluster, and everything? For people on the infrastructure side, that's actually really important. In the past, you had one application on one machine, [and] then you had 10-12 of VMs running. And now on the same machine, you are running maybe 100 containers or more. So there is just a lot more of individual things to manage. And if you try to do that manually, that's a problem.

I've not met a CIO so far who told me they are getting more people. The equivalent of what we're doing for the developer with Cloud Application Platform – write your code, deploy, using automation, using tooling to really scale up and scale out – is what SUSE CaaS Platform does in the Kubernetes context. It gives more control. So I can easily envision, and that's what we're actually seeing, that those big lift and shift containers, where you take your old application and just put it in one container, you may deploy it directly on the Kubernetes cluster [and] interface it directly with CaaS or Kubernetes. And then where you have your Platform-as-a-Service, that's where you use something like SUSE Cloud Application Platform.

LM : Security seems to be one of the big issues in terms of deploying containers and managing them. Do you have any special groups that are focused on security?

GP : No SUSE product is ever going to leave the company without a security review.

LM : What does that entail?

GP : Our security team reviews the architecture of the product – for example, are things being encrypted when they go over the line? – and reviewing components that we ship for known security issues. Some of our security people actually are really good at breaking into systems. They are trying to break into our own products.

Security is rarely binary, because essentially everything is penetrable if you apply enough force. Sometimes the amount of force is not available to people, but if you are really determined, then maybe the weak link is not the security of the software; the weak link is the sys admin, and you put them under pressure. That's why I'm saying there is no point in using hundred-thousand-bit encryption apart from the fact that it will be terribly slow. You know, sometimes a wall is high enough, and building it higher doesn't actually help anything.

LM : Besides security, what are the other challenges of deploying open source software in the enterprise that you usually encounter when talking to people?

GP : I don't think I can answer that question for open source versus non-open source. For most people, open source is interesting; it's appealing. "If I have a choice, I want to avoid vendor lock-in" or "I like the principle." But if push comes to shove and you are the decision maker, you need the solution that is more secure, you need the solution that is faster, more performant, that uses less energy or space, and that has a lower cost of ownership.

By virtue of how we in the bigger community sense develop open source upstream and how we in the smaller SUSE sense productize it, we have demonstrated that in those areas where we decide to play, we actually will win. I mean, where is Unix, right? Which container solutions beyond Kubernetes can you think of? And I predict we'll see the same around Software Defined Storage where Ceph [9] is in a strong position to become the Linux of storage.