Interviewers: Scott Swigart and Sean Campbell

Interviewee: Joe Brockmeier.

In this interview we talk with Joe. In specific, we talk about:

• Where openSUSE fits into the desktop Linux landscape
• Relationships between openSUSE and SUSE Linux Enterprise Server and upstream projects
• The effect of commercial agreements on open source projects
• The future roadmap for openSUSE

• Bringing together technical and non-technical users in open source projects
• Coordinating testing and bug fixes among distros and upstream projects
• Design coherence among distributed developers

Sean Campbell: Joe, to get us started, could you give us a little bit of your background?

Joe Brockmeier: OK. About 1999, I started writing about Linux as a freelancer. That eventually morphed into a career writing about Linux and open source as a technology journalist, more or less full time, much of that time as a freelancer. Around 2005, I joined Linux.com as editorial director, and then last year, I was with “Linux Magazine” as editor in chief. My educational background is in journalism, and that’s when I discovered Linux–when I was in university.

But last fall, Novell came and asked if I’d be interested in applying for the community manager job, which at that time was called the chief Linux evangelist. Having followed the open source community for so long, I was really interested in being directly involved with the project, as opposed to just observing and writing about what open source communities were doing, so I joined Novell in February as the community manager and have been pretty much going non-stop since.

Back in August 2005, openSUSE got its start when SUSE announced that they were going to start a community distribution. Prior to that, SUSE Linux had been developed in house by SUSE before they were purchased by Novell, and while it was a very strong distro, there really wasn’t much community input into it. Novell decided to build strong community participation.

The project is going on about three years old now, and we are making pretty good progress in terms of getting the infrastructure in place for external contributions and having transparent development.

We just announced last week the 1.0 release of the openSUSE Build Service, which adds the ability for external contributors to make direct contributions to the distribution, as opposed to going through the gatekeepers, so to speak. And we released openSUSE 11.0 in mid-June, with a lot of improvements, particularly in the installer and the package management, and of course all the normal improvements that go along with a version upgrade, such as new versions of KDE and GNOME and things of that nature.

Sean: Tell us a bit about where you feel openSUSE sits in the landscape of desktop distributions. What do you think it’s exceedingly good at, and maybe some of the places where you see challenges or opportunities?

Joe: Generally, my metric for success on the desktop is how well it fits what people need. I don’t really spend a lot of time comparing it to other Linux distros, because I really think we all have the same mission, which is to get people using Linux. So I don’t view them as competition, so much as inspiration, if anything.

The audience we’re trying to address includes home office users and others who want a good, solid desktop operating system that’s as easy to use as possible.

I think openSUSE is exceedingly good at package management, being easy to use, offering a top-notch desktop experience in GNOME or KDE, and providing a wide range of the best free and open source software available.

Our challenge is reaching new users and encouraging more users to become contributors.

The opportunity, right now, is that a lot of people are put off by Vista and are looking around at their options. I want those folks to find openSUSE, and another challenge we have is to find ways to make the jump from the audience that’s Linux-aware to the vast number of potential users who haven’t heard of Linux or know very little about Linux.

Sean: Every distribution seems to have an area that they don’t go after, or that they maybe feel they don’t have as great a degree of fidelity in. Is there some area where you think that’s true for openSUSE, where it’s not particularly geared for?

Joe: I was at Sun CommunityOne, and we had a Linux distro panel that included me, Jono Bacon from Ubuntu, Karsten from Fedora, and Glynn Foster from Sun. We were talking about this.

I think the only major difference is that we have a slightly different philosophies. Fedora really wants to approach the desktop with only free software, and they don’t want to ship anything that is proprietary at all. On the other hand, if you look at the retail box and the DVD that we ship, we actually include a little bit of proprietary software like Adobe Flash that we think people who are coming from Windows are going to want.

As much as I don’t like the fact that you have to have a proprietary program to view a lot of web pages, I think that that’s reality. If my girlfriend’s kids use a computer, they’re going to go to web sites that require Flash, and they’re probably not going to be sold on the argument that since it’s not free software, they should just not go to those sites.

I think it’s more important to successfully get people to use a 98 percent free software desktop than it is to ship a 100 percent free software desktop that no one wants to use.

Sean: So maybe we have to be OK with the idea of shipping a proprietary 3D driver, because everybody has EVO integrated right now. We can either tell them to go spend seven days configuring it when they’re not really competent to, or we can just roll over for two percent of what’s going to be in the distro.

Do you feel that’s kind of what’s going to have to happen in the interim, and then eventually the hardware manufacturers and the other folks will ship Linux drivers, and then maybe that’s not an issue as much anymore?

Joe: Yeah. I think it’s a major chicken and the egg thing. You have to demonstrate that you have a certain percentage of the user base before you can expect companies to spend engineering time or be willing to do things differently than they have in the past.

I don’t really buy the argument made by a lot of the manufacturers that they have to have proprietary code to be competitive. On the other hand, I do think it’s necessary for us to make the argument to them that there is some benefit to them when they ship a free software driver.

And the first thing that we have to accomplish there is to demonstrate that there are enough users that it will make an appreciable difference in the number of units that they would sell.

Scott Swigart: What’s the relationship between openSUSE and Novell’s enterprise distros for the server and desktop?

Joe: Basically, openSUSE is the foundation of SUSE Linux enterprise. We just released 11.0, and now we’re working on 11.1, which will be the foundation of the SUSE Linux Enterprise Server and Desktop products. The appropriate technologies that we develop in openSUSE are carried over into the enterprise product.

Scott: Would it be accurate, then, to say that newer technology might show up there, and then a decision is made in terms of what’s ready for the SLES and SLED distros?

Joe: We do sort of incubate technologies within openSUSE, although we also work on things that are of benefit to the openSUSE community that may not really have an impact for our enterprise customers.

We are also careful to make sure that whatever we ship in openSUSE is usable and stable enough that our users are going to be satisfied with it and happy with it.

Scott: What are the usual things that you do when you’re putting together a distro? Where does the work of the upstream project stop and your work start?

Joe: In some cases, there really isn’t a great deal of difference. For example, we have a team that works on GNOME and we try to do as much work as possible within GNOME, so that there’s not that loss between the upstream project and the distribution.

To illustrate one of the problems historically between a distribution and an upstream project, say you have Fedora and Ubuntu and openSUSE and all these other different distros working on something. You get lossiness when one project decides to innovate in one area or add a few patches or whatever, but those changes don’t necessarily make it upstream, or they do make it upstream but after the main project has also started working on the same feature or problem in tandem.

As much as possible, we try to work within the projects like GNOME for KDE that benefit us, rather than doing the patches in our own little area and then maybe submitting them back, or letting them come get them, or whatever.

Obviously, for the desktop, we add our own artwork and some polish in those areas. We also make some configuration decisions that may be aren’t handled by default GNOME or KDE, but in a large way, we really try to work with the upstream projects to avoid duplication of effort and that sort of thing.

Scott: How do you handle it when you identify upstream work that would be valuable to your customers when that work is produced after the last stable release?

Joe: For example, we knew the Mozilla folks would be shipping Firefox 3 some time after we shipped openSUSE 11. We had to make a decision about whether we should stick with Firefox 2, which would be pretty old midway through openSUSE 11.0, or whether we should go ahead and ship a pre-release version of Firefox 3.

Ultimately, we decided to go ahead and ship Firefox 3 beta 5, and when the feature freeze came into effect, we stuck with that version. Since then, we’ve gone ahead and shipped the final, via the package updates.

For community distribution, it’s easier to do that sort of thing, because we don’t have the five-year enterprise contracts to worry about, which gives us a little more flexibility.

Scott: What about the smaller projects, like Pulse Audio, an IM client, or Pigeon, when there’s maybe not an official release, but you want to back-port a really important patch to the version you’ve shipped?

Joe: Generally speaking, the policy would be that if there is a security fix or something, we would back-port it. We usually don’t do full-version updates or anything like that, with some exceptions for major apps like Firefox. As for new features, though, we have a rapid enough release cycle that it makes more sense to just put the new features into the next release.

Sean: Let me ask you a question in a different area. Generally speaking, in the open source community, there’s a somewhat mixed reaction to Novell having agreements with Microsoft. Do you feel that any controversy in that area has an effect on uptake of openSUSE?

Joe: When I took the job, that was one of the first things that I expected a lot of questions on, and in fact I did at one time, because everyone thinks that it’s the elephant in the room. But when I go to open source conferences and actually talking to users and whatnot, I generally haven’t found it to be as big of an issue as is generally suggested in the press. This is not to say that it’s not an issue at all, but it’s hardly the only issue, and after nearly two years, a lot of people have realized it’s not the catastrophe that some painted it as when it was announced.

I think there are some folks that are very active online trying to complain about this particular issue, and they’re welcome to that viewpoint. I would suggest that maybe if you are deeply committed to open source, perhaps your time would be better spent in doing something positive.

Sean: [laughs]

Joe: I often wonder, in fact, whether people making complaints like that would go on to something more productive if they got exactly what they wanted, or whether they would just wander off and find something else to complain about.

But, that’s a tangent.

Sean: To follow up on that, there are of course cases where people make big changes, like when Red Hat walked up to the conference stage and said, “Nope, it’s not Xen anymore folks; it will be KVM.” And Novell at large has spent a lot of time and money partnering up with Xen which then gets bought by Citrix, which is another for-profit parent, right?

I know you do support KVM and Red Hat supports Xen, but what are the thoughts broadly in the openSUSE community about Red Hat making the push toward KVM?

Did that changed your perception about what you want to do with support for virtualization moving forward or put increasing emphasis behind KVM? And how does that map to Novell’s goals in that area?

Joe: I don’t think that there’s a decision that’s been made. I’m not actually on the Enterprise side of the house, so I would have to defer that to somebody else for that, but in the community, I haven’t seen a strong reaction either way.

I think that within the kernel community, there’s an obvious preference toward technologies that are in the mainstream kernel. But beyond that, I haven’t seen a huge movement either way due to Red Hat’s announcement.

Joe: I’d like to go back and finish addressing the Novell/Microsoft thing, though. I think that probably there is a small percentage of people, now that the deal is nearing two years old, who still have an objection.

But most people have realized, I think, that the deal has not really been detrimental to open source or Linux, and they have moved on. And we have a lot of folks who really enjoy openSUSE and who continue to use it, and we continue to get new users every day.

Sean: Tell me a little bit about the roadmap for you guys in terms of what you think you’re adding in the future that targets more the home office worker or business productivity user. What do you think are the top things that you need to add to continue to grab more of that audience?

Joe: We’re still very early on in the 11.1 cycle, so right now it would be hard to say exactly what’s going to wind up included, although we do know that the next version, for example, will feature OpenOffice 3.0. We are very active in OpenOffice.

Most Linux distributions actually ship the Novell version of OpenOffice, with some of the patches that we include as opposed to the actual Sun version. A lot of things in OpenOffice 3.0 are going to address the needs of people who use their computers to do office productivity type stuff, and they’re going to address them pretty well.

Sean: Apart from specific things included in the next release, can you speak a bit to the broader vision? If you want to continue to work with that audience, what do you think they’re asking for in a Linux desktop distro?

Whether it shows up in the next release or two releases from now, or three, what are the things that you feel openSUSE needs to do to continue to pull in that audience?

Joe: From that perspective, I think that what people are asking for is continual improvements in ease of use and familiarity. If you set somebody in front of a computer for the first time, I think Linux is actually more or less as intuitive as any other operating system.

But we have to keep finding ways to address the people who are coming from Windows or Mac OS 10 and making the computer not identical, but still familiar and easy to use.

That’s one of the reasons we spent so much time in the last version reworking the installer to make it much easier for people to actually get Linux on their computer in the first place.

Sean: Let me add one quick follow up. Wubu is a very interesting thing for Ubuntu, and I almost look at what they’re doing as kind of like what could happen with Apple when they reach a critical mass of boot camp, plus switching to Intel, plus virtualization.

We talked to a person on a train trip who said, “Oh, yeah, somebody put this thing on the computer for me that lets me run Windows in a window on my Mac.”

And we realized that this person didn’t know or care that it was virtualization; it was just something that let them run both OSs. And all of a sudden, these things kind of come together.

I’m curious if you guys are thinking of similar approaches. I know they’re doing images on USB, and it seems like the Ubuntu guys are trying really hard to make that initial five minutes to get into Linux happen really, really fast. What are you thinking about in terms of installation and things like that?

Joe: I don’t know how many people actually run off of the USB key or even off of a live CD for any amount of time. And I think that we do offer the email, just as Ubuntu does, and we do offer live CDs with KDE and with GNOME, so you have the same options there.

I have not seen something like Wubu on the openSUSE roadmap so far, although that’s something that very easily could be added by a community member. And so if it’s something that people feel strongly about, I hope we will have work in that area.

Scott: Some open source projects like the Linux kernel or Apache are designed to be used by a very technical audience. But if you get further out into things like OpenOffice, and as you get further out into the distro itself, you’re potentially targeting non-technical people.

On some projects, the sentiment is that, “If you want a feature, code it up. Show up on the mailing list, submit your patch, and we’ll talk it over.”

But as you get more out into consumer-facing stuff, the people who have need for features, and the features they need, are very different from the needs of the people who are actually working on the project.

How do you guys balance that out? How do you, first of all, know what your users are going to really want and find beneficial? And since those people don’t necessarily have the ability to actually work on those features, how do they actually get implemented?

Joe: As you may know, a couple of years ago we did a desktop usability project, and one of the ways we implement the higher-level features is by handing them off to the desktop teams.

We are in the process, for example, of opening up our feature and tracking stuff, so that a user can come in and interact with the development community and have some input into features that are being worked on, without having to put their developer hat on and actually implement it themselves. In a way, it’s similar to the way that features are implemented in commercial projects.

I think it’s a little bit of a fallacy that open source projects are less receptive to their users than proprietary ones. For anyone who’s fairly interested in seeing a feature implemented, we actually have mechanisms where users can interact directly with our developers and lobby for a feature, whereas if you want a new feature implemented in Adobe InDesign, good luck getting direct contact with an engineer who works on the project.

Scott: It also seems also like there’s a lot of benefit in the pairing that’s happened in open source between commercial entities and the community. The community is really good at enabling technical people who are coders to scratch their own itch, which you can’t do with proprietary software.

And at the same time, the corporate entities are doing some of the stuff that people in the community wouldn’t find fun or interesting. They’re also doing things like usability studies that you’re just not going to have a community go and organize.

The open source community can add a lot of ideas, spark, and innovation, but the commercial entities are able to whiteboard out a feature, take input from users, do usability studies, work on documentation, do some of that heavy lifting that isn’t necessarily as good a fit with the community.

Joe: I would agree mostly with that, although I would say that the kernel development that occurred up until companies got involved with it surely constitutes heavy lifting as well. Still, I do think that it works best when you have both represented more or less equally, when you have a company that can hire people, for example, to tend to a Bugzilla and do bug fixes and product support, and you can have people in the community who are doing more innovative work.

You’ll find very few people who come along saying, “You know, I really know all I really want to do is squash bugs.” You don’t find a lot of people who only want to do product testing or things of that nature.

So, I think it works best when you have a company like Novell working with the community like the openSUSE community, or you have companies like Novell and Sun working with OpenOffice, and still making it possible to have the community help guide the project.

I think that companies alone don’t necessarily do as good a job at anticipating what users want and need as communities do when they have some input directly.

Scott: Right–it seems that there’s a balance, and if it’s done right you get the best of both worlds. It’s not people off in an ivory tower saying, “Here–we built what we think you’ll want,” because you’ve got so much community input. But at the same time, it can be more directly addressed when good documentation needs to get written or the bugs are piling up and need to get fixed.

Joe: Another good example is what the Mozilla Foundation has managed to achieve with Firefox, which has spawned most of the innovation that has come out in web browsers. They have married the two sides by having a corporate entity that actually funds all of the development and hires people to do specific things, and they also have a tremendous amount of external and community developers.

Scott: The bigger projects like the kernel or Apache have a lot of structure in place, but some of the smaller projects have less of that. Do the Linux distros act as a sort of clearing house for some of the smaller projects? Do they give another point for people to interact if they’re having a problem with something like a compatibility issue or bug?

In other words, do people sometimes go to the distro they’re using to resolve issues with upstream projects?

Joe: I think that happens to some degree. For example, if I’m new to Linux and I’m using openSUSE, my focal point for any complaints with a program is typically going to be the distribution, not the upstream project. So we can serve to distill those problems and figure out where the problem really lies. We also do give feedback.

And a lot of the time you also find people who work on those upstream projects work within the distros too. For instance, we have Vincent Untz on our GNOME team, and he’s also a GNOME Foundation board member and participant in GNOME aside from his work with Novell.

Scott: Like you said with GNOME, you guys are actually doing a lot of development on GNOME, because you don’t want openSUSE to have a fork that’s significantly different. There isn’t as much value in that as just working with the upstream project to move it forward.

In the early days it seems like the methodology in a lot of open source projects was to post code to a mailing list that got examined by a lot of people, and it got rolled in or it didn’t get rolled in. There was sort of a “many eyes” approach.

More recently, people at Mozilla and others have developed tools to automate code inspection, although there’s also obviously a lot of manual inspection. I know Coverity has been involved in doing scans of code and making those available to different projects.

What are some of the things that are coming online that are further raising the quality of open source? How are you seeing that evolution happening across open source projects?

Joe: Slowly. Things like Coverity are being developed, although that’s not an open source tool. They simply like to use open source because it gives them a good way to show off. They can actually talk about the results as opposed to if they do work for commercial customers.

Scott: Right, exactly. But at the same time, some open source projects find the information they get to be extremely valuable, even if others may just find that they get a ton of false positives.

Joe: I would like to see the community come up with more tools of that nature, but I am not aware of any. You mentioned the Mozilla one, but I’m not aware of any major efforts in that direction.

Scott: Do companies like Novell take a little bit of that on? As projects move from openSUSE to SLES and SLED, is there a certain level of hardening that happens, or is it not really needed? Is it more the case that the code is of a sufficient quality to be enterprise ready as it is, and those things might be nice, but they’re not really essential because the code is good enough where it is?

Joe: There’s additional quality control and hardening at every step. There’s the initial project, with all the alphas and betas that they do, and then there’s the stage when a project like openSUSE decides to go ahead and adopt a particular version.

We do additional testing, and then we go through our alphas and betas and so forth. Then, there is the additional testing that goes into putting together the enterprise release. So, there is a little bit of hardening and improvement at every step.

Scott: It sounds as if it might be fairly typical as you do your testing to maybe find some bugs that didn’t get found in the alphas and betas, so you work with the upstream project. The quality goes up another notch there and then as SLES and SLED are put together, and as Red Hat, Sun, and a lot of other distros do their work, more things are found, pushed upstream, and fixed.

There’s this incremental hardening and improvement of the code, and by the time it gets to any vendor supporting the enterprise release, it has gone through a lot of layers, each of which made it better. Is that a fair characterization?

Joe: Yeah. And the additional layer, of course, is once it’s released to the enterprise version, then there’s additional testing. It would be nice to say that there are absolutely no bugs shipped once it gets to that level, but of course you do find things, and you do find areas where you can improve it. And then the process starts all over again.

Scott: I do have one other question. It seems like for a lot of things that are released by companies like Novell or Red Hat, the architecture must have been sketched out around a whiteboard, and they had to staff developers on it.

But then, the output of that is code that’s put out for community inspection. Are some of the features designed in a traditional way like that, in a typical conference room and white-boarding scenario? And then, are the architectural design documents, and specs, and so forth released as well?

Joe: There are occasionally similar things with open source projects without necessarily any corporate influence except to say the various participants are employed by the different companies.

For example, I’ve gone to things like FOSS camps and developer summits where you get a bunch of developers around a table working on a vendor-neutral program. They often do essentially follow the same (or some of the same) software development process that you would see if you were to go into a Novell office where they are working on something. Let’s not forget that a huge percentage of participants in FOSS projects work for companies that have an interest in FOSS, and they have day jobs that involve standard software development methodologies and those methodologies are brought into FOSS projects (and vice-versa, of course).

And so, it may be less prevalent, but I think that you do still see some of that, depending on how big a feature is, or whether you are talking about iterative change versus the difference between KDE 3.5 and 4.0. Then, I think developers still get asked by the other developers, “Hey, write something up and show it to us”, because you can’t code something like that from scratch and show it to people.

Scott: Well, it has to be comprehensible, right? There’s got to be a higher level of abstraction that people can look at, because it might be 30, 000 lines of code.

Well, I want to be sensitive to the time. Are there any closing thoughts you have or something you want to circle back to?

Joe: I guess I’ll take the opportunity to reiterate that we’ve put out (finally) the 1.0 version of our build service, which allows people to contribute more directly to openSUSE. So I’m looking forward to seeing more direct involvement in the direction of the distro and in contributions.

Sean: OK, that seems like a good place to wrap up. Thanks for taking the time to talk with us.

Joe: Thank you.

Bookmark this: