How Software is Built

Interviewers: Scott Swigart and Sean Campbell

Interviewee: Wade Olson

In this interview we talk with Wade Olson from the KDE project. In specific, we talk about:

• Background of KDE and comparison to GNOME
• Ensuring usability in an open source project
• Managing interoperability among components
• Impact of commercial acquisition of open source projects
• Cross-platform support in KDE
• Reaction to KDE 4 public release

Sean Campbell: Wade, give us a little bit of background on your role in KDE.

Wade Olson: I have been involved with KDE for several years now, both as a contributor and as a member of the e.V., which is the nonprofit organization that represents and takes care of our KDE members. And for three years, I’ve also been in the Marketing Working Group.

I think the origins of KDE are fairly common knowledge; it’s one of the desktop environments for Linux and other operating systems, and we have thousands of contributors worldwide. Its a full-blown desktop environment that handles not only window management, but also the entire application framework, to allow for an integrated experience for the end user.

• http://www.kde.org/announcements/announcement.php
• http://en.wikipedia.org/wiki/KDE#History

Sean: What do you see as the key differences are between KDE and GNOME? That seems to be the obvious comparison.

Wade: Obviously, there are a lot of similarities, and there has been a lot of work in building relationships between the two communities. The most obvious technical difference is that they are built upon two different toolkits–C versus C++, GTK+ versus the Qt toolkit. And then also philosophically speaking, GNOME has really put a lot of fantastic effort into the usability and GNOME interface guidelines to allow for a streamlined experience, and they really make sure that their interfaces are consistent. We focus more on the advantages of an interface that gives the user control, flexibility, and configurability.

That being said, when I talk about the similarities between the two desktops, don’t forget that there are various Linux architecture and desktop architecture groups that ensure that everything is done so that the different desktops and their applications are more integrated than ever before.

That might involve such things as the D-Bus system, on which we’ve both standardized, as well as smaller but important things like naming conventions and directory standards for icons so that the different theming engines can make sure to apply icons as expected for Tango or Oxygen or whatever icon themes you’re using.

• http://www.freedesktop.org/wiki/Software/dbus
• http://tango.freedesktop.org/Tango_Desktop_Project
• http://www.oxygen-icons.org/

Scott Swigart: The industry in general has a pretty laser-like focus on usability these days. How do you ensure and test for that? Just like you can’t have a developer check their own code, you definitely can’t let them police usability on their own code, so how do you handle that operationally?

Wade: It’s a fairly complex process. Unlike commercial software efforts, there’s not a strong business analyst layer where they actually go through use cases and make sure that the software adheres to some list of requirements or extra documentation.

Typically, you have members of a technical community who have to put on multiple hats or play multiple roles in the software design, requirements, and analysis phases. That’s how in the past, some Free Software projects have gotten into a little bit of a bind, in terms of usability adherence or making offerings that end up being as pretty or flexible or intuitive as commercial offerings.

To improve usability, we’ve been putting a lot of energy into making sure that all of our development staff understand the importance of usability as a key component for adoption and how to look at their code from a user’s perspective. Fortunately, we have talented usability experts in the KDE community that not only educate sub-communities on usability, they also do reviews and provide constructive feedback.

There have been plenty of instances where there may be competing software applications that are quite similar in what they can accomplish, but in the Free Software world, if one is more intuitive and usable than the other, then the uptake of that one is going to be larger.

The problem is always the person hours needed to do all the things you need to keep up on, like writing the documentation, building the web pages, writing the code, deploying it, and talk to distros that use it.

We’re expanding our user base to more and more people who are not technical and people who are used to commercial operating systems like Windows or Mac, where a lot of money gets spent on interface work and usability work.

Those users have expectations about how easy something should be to pick up, and frankly, it doesn’t matter if it’s free. If they install something or see a friend using it and it looks completely foreign or confusing to them, they’re going to stick with Windows and Mac, and we’re going to miss a chance to get someone to change over.

Sean: There seem to be a lot of retailers trying out selling Linux boxes now–how much are you guys driving towards the desktop Linux user?

Wade: KDE focuses on the desktop environment and the desktop experience, so we are somewhat biased towards that experience. Now, obviously, Linux kernel hackers and BSD kernel hackers can certainly deal with virtualization, hypervisors, and whatever they want, and we have hooks into those layers through the hardware abstraction layer and so forth.

We are certainly interested in general in hooking to the various operating system layers and kernels and being as stable and flexible as we can be with the plugging in of devices, unplugging of devices, hardware recognition, et cetera. But, just by the nature of KDE, more likely than not we’re going to focus on the desktop experience and what we can do to make that the best experience possible.

This is also another layer–people typically don’t go straight to KDE when talking about desktop experience. So if you’re buying a pre-built system off the shelf, there’s a distro in between KDE and the hardware manufacturer. A couple of obvious cases are PC BSD, which is working with iXsystems to make hardware boxes that they sell throughout the U.S., as well as Xandros and the ASUS Eee PC, which is extremely popular throughout the U.S.

So we have hardware from ASUS and iXsystems that help KDE target specific markets. There are people from Xandros and PC BSD that obviously have industry connections that benefit us–we don’t necessarily sit down and think about what markets we want to target.

Scott: There are a lot of components from independent projects that come together, and in a sense, KDE is almost a distro within a distro. How much work does it take to get all of those independent pieces to work together smoothly, especially since it has to work on so many different OSs?

Wade: Everything is obviously driven off the Trolltech Qt Toolkit, and then on top of that there is an additional layer with the KDE Libraries, which is very specific to our desktop environment.

In terms of interoperability, there’s kind of a natural, organic process that subcommunities take when growing out and branching. When you think about the natural growth or evolution, not just KDE but with free software projects in general, something might start with just one or two people that are writing some code. That might grow into a couple more people, and then maybe they have the need for a web page, and then maybe they have the need to be in a larger source code repository. Later, they might start promoting, then start translating it, and so on and so forth.

Typically there’s a natural trajectory that applications take in their growth. Along the way, as individual KDE applications get more sophisticated. they naturally begin to use pre-existing code and connect with other KDE applications. Time spent on development is precious; it should be as productive as possible. It’s not coincidence that community members have created a software atmosphere to enable developers. It has taken a massive amount of effort to make it happen effortlessly, if that makes any sense.

Scott: It sounds, then, like KDE is built up of a lot of different components, but each one of those components is responsible for ensuring their portability to the different platforms, and those different components work together to interoperate with the other components that comprise the overall shell.

Wade: Right, exactly. The first key to interoperability is actually the e.V. organization that I mentioned before, which is a worldwide group that basically keeps track of everybody and makes sure that they all play nicely together. We also rely heavily on IRC and mailing lists, which is where a lot of the communication is done. And that communication is typically involved in adhering to coding guidelines, adhering to usability standards, and really allowing people to say, “Hey, I want to do this,” and that’s where the technical discussions come in–”What’s the best way to implement that?”

We also have working groups. As I mentioned, I’m part of the marketing working group, but we also have a usability working group and other organizations that help keep people in sync in different ways. With KDE 4–as you may have read in some of my blog entries and articles–a very large part of what we tried to accomplish was to set up a common language and infrastructure in what we called the Pillars of KDE. So if you look at a multimedia framework with Phonon, the look and feel across websites and our desktop environment via Oxygen, hardware interaction, PIM data storage with Akonadi, almost everything we did was to create a pillar for a common language in a common technology to allow people to quickly and easily build applications.

If you abstract away all that complexity, almost by nature you get people working on the same page, when you take away the difficulty of connecting to a CD ROM or an FTP server, for example. It’s important for code consistency, it’s important for code complexity, and it’s also important for making developers as productive as possible during their limited time, since, for many people, this isn’t their day job.

Sean: Let’s talk about the Trolltech/Qt acquisition, starting with the question of why you think Nokia bought it, and what do you think they’re going to do with it, and what effect does it have on you?

There’s an interesting dynamic happening in the past year or so, where companies decide they love a certain open source project, so they buy it and plan to build on top of it. A lot of nervousness tends to develop around those acquisitions, about things like how much there is still going to be a community process behind it and how comfortable developers are going to be continuing to contribute.

There are successes all around, like Red Hat’s been great with CentOS. The jury is still out about MySQL with Sun, since it’s still a brand new thing, but Qt must have cut right to the bone with you guys–what’s your feeling about it?

Wade: Let me preface by stating that I’m neither a Trolltech nor Nokia employee, so opinion has the same weight as any other observer. If you look at issues that people have had philosophically and historically with KDE, from a Free Software standpoint, it was with the affiliation with Trolltech and Qt and the licensing. So because of that, for the past several years, Trolltech has truly gone out of their way to try to eliminate all of those obstacles and barriers and frustrations that some of the people that are on the very free side of the open source spectrum have had with this affiliation.

They’ve created various poison pill contracts and things that have really said that no matter what happens, Qt is going to be there for KDE to use. And there’s no reason to expect that there was anything nefarious going on. This was with best intentions, and they have certainly spent time and money with lawyers to make sure that everything was locked up from a licensing standpoint. We take them at their word, and we are obviously appreciative of that work.

I don’t think there’s a lot of necessary concern or fear from the fact that it might go away, because certainly there are various abilities to fork and continue to use this freely. It’s not as if it just goes away, and KDE is left standing out in the cold.

With Trolltech lately, we’ve been hitting this great stride. You may or may not realize that they do sponsor several KDE developers, as well as get-togethers and meetings that we have. Some of the code they write now with WebKit is beneficial to us from a browser perspective. They have integrated WebKit into their code repository, based off of KHTML and work by Apple in the WebKit community. And very recently, they’ve been doing all of the Phonon multimedia work in our SVN repository, completely openly.

So, really, I think the only concern that I’ve seen in the KDE community is the fact that things have been going so well that we just are praying that it continues with Nokia and that things don’t slow up. Might they fund as much? I have no idea. Might the developers be forced to work on other things? I have no idea. I just know that things have been going so swimmingly, that’s the only apprehension.

I do know that people are talking with Nokia, and Nokia is doing all the right things thus far, as I understand, as far as scheduling meetings and talking about intentions. I don’t think they want to screw up a good thing, and trust me, with that toolkit, there is certainly a hugely beneficial relationship between KDE and Trolltech. Who better to test your toolkit and provide feedback than hundreds of talented programmers stressing its capabilities and millions of users?

Sean: How does a closed source company not screw up the acquisition of an open source one, in your mind?

Wade: I think the key is to really go back and actually look at the various motivations of why someone would commit their own personal time and vested interest to work on something like this. We’ve already talked about why some open source projects work and why some fail. It’s all about people having an emotional connection and attachments that make it more worthwhile to them than doing something else, whether it’s working down at a soup kitchen, working for a nonprofit, or sanding their hardwood floors, for that matter.

Some people spend their free time doing it, and some people get paid to do it. But either way, it’s the emotional connection, and it’s the passion, and it’s the community that builds around it, and the friendships. Trust me, KDE’s code is exciting, but it’s not that exciting. People love to work on it because they love to get together and talk about it, and they have the same passions and interests. That’s where companies really need to look. They cannot screw up that ecosystem.

Even a company that really gets open source–like Red Hat, when they buy JBoss–has to think about the community. And the fear is, what if all of the people go away? Because now it’s a corporate entity that people might not be interested in, instead of their little, home grown, comfortable part of the world.

Scott: Old-school open source projects like Linux and Apache don’t really have a chief sponsor that’s driving the development. But some of the more modern open source projects–like Alfresco, Zed, and PHP–have a company wrapped around them that’s really driving a lot of the innovation, and we’re starting to see a wave of those companies being acquired by these much larger companies.

The thing that I wonder is, if these large companies do screw it up, they have essentially paid a whole bunch of money for nothing, because one thing open source lets you do is fork the code. It isn’t far enough into the future yet to see how this all plays out, but one could imagine that if Sun really mismanages MySQL, somebody else could form a company around it. The same thing with Qt or Zen or any of these other things.

Wade: Obviously, because of licensing considerations, different projects have different options when things like this happen. I have not pored through the licensing on Qt in particular, and I can’t tell you what will or will not happen, or how poison pills are engaged, or what the ability is to fork it.

In general, though, not only are companies paying for historical results, but they’re paying for future results as well. They are certainly are not just paying for the MySQL historical codebase and saying, “OK, thanks, we’ll take it over now,” but they still want those people to contribute, and they still want it built upon.

Scott: Right–they’re paying for the mindshare. To me, what they acquire when they acquire these companies is not the code, but the expertise around the code.

Wade: A somewhat similar situation could be considered with any open source community that relies on Java, for example, like the Eclipse community or JUnit, or any one of many Sourceforge projects. Sun could have taken them any which way. They could have closed down Java, or locked it down, or stopped working on it, or open sourced it. That was up to some speculation as well.

You have to hook your horse up to a cart, and that has obviously played some role in the GNOME community saying “We want GTK. We want our own toolkit, and we want it to be free.” There are benefits and detriments of closed source versus open source. Qt is what it is, and it’s incredibly powerful, but it’s not entirely free because of that.

Scott: Remind me what different platforms KDE runs on outside of Linux.

Wade: It runs on BSD and Linux and any *nix platform, and there’s actually a lot of renewed interest in having it run on Solaris. Obviously when we talk about Plasma, the desktop itself, that’s only going to run on Unix like systems that we already do. On the application level, as long as you have the KDE libraries and the Qt framework–which is cross platform–then it is game on. Going forward, we’ll see KDE applications run and run well on Windows and Mac platforms.

It’s just a matter of figuring out all the nuances–what exactly makes something cross platform in theory as well as practice: installation directories, multimedia engines, rendering models–the stuff that makes Windows and Mac different.

Scott: I guess the reason I ask is that to projects like OpenOffice for example, cross-platform is very important, whereas it seems like KDE could get away with being mainly a Linux thing.

On the other hand, OSs like Solaris and OpenSolaris might be important because they create a little bit of competition with Linux, which is probably healthy for both Solaris and Linux. In your view, how important is it for KDE to be cross platform?

Wade: There actually has been a fair amount of debate on that approaching the 4.0 release. Obviously, when people work on things that they want to work on, there’s really no stopping anyone. It’s not as if you can just assign someone to work on a task. It’s not a development job where you can say, “I’m sorry, I don’t want you working on that anymore. I’m assigning you to project 123.”

If you don’t want to waste resources having someone work on KDE and Solaris, you can’t just say “Go back to working on BSD. We need to fix that up.” It’s really all based on people’s interest level, and that’s the secret to great code–when someone has passion for an area.

It comes down to the “can do” versus “should do” question–we can do a lot, but should we do it? From a marketing standpoint, my stance is that if someone’s going to work on it, just please do it well. If you think about how people get exposed to KDE and open source and Free Software, you always want the first impression to be a good one.

KDE is obviously at home on Unix and Unix-like operating systems, and then there was the expanded ability that people could view it through VNC or RDP servers to actually connect to a remote client and see what KDE and open source and Free Software is like.

Then it was expanded further with the Live CDs like Knoppix that spin up. Then it was expanded again with VMware Server and other virtualized servers, where you could literally be on Windows and just get a VMware image and boot it up and see what it’s like. The final frontier, then, is the application layer where we’re actually installing and deploying applications on other platforms.

Again, from a marketing standpoint, I just say please make it a good first impression. I am not interested in leaving a Windows or a Mac user with the impression that it’s half baked or not as good as it should be.

There was debate about whether would it drive people to use KDE or Free Software in general. We talked about whether OpenOffice and Firefox have necessarily gotten more users onto platforms like Linux or BSD or Solaris. A lot of Windows users probably say, “Hey, that’s great. I’m going to continue using Windows with these free applications.” Is that a good thing or a bad thing?

So, if you’re porting for KDE adoption and recognition from an application perspective, you’ve got millions more people that you could reach. However, if you’re looking for people to make the move philosophically to Free Software and to have that desktop environment, maybe you’re actually hindering your cause. That’s where the debate comes in, and that was an interesting period of time.

People basically said do what you want to do, and please do it well. If nothing else, what we’re looking for is to increase visibility and awareness of KDE and the world class software that we’re making. In addition, we want to let developers know that a lot of people that write free software for Windows and Mac, and that there are other options that they have as well that they might take an interest in, and we might grow our developer base.

Scott: That’s always been one of the things that’s interesting to me about open software. Closed source sometimes has to guess what people are going to want. They have to be very speculative about the features and plan the next release and try to make sure they have “killer features” that are going to make people upgrade and that kind of stuff.

Open source often takes the approach that if a feature or capability is really important, it’s important enough that somebody will show up to do the work.” And if nobody does, it shows that maybe it’s not that important.

Wade: Right. You figure out the source of the priority and the urgency. Was it Sun Microsystems saying, “I want this to work well”? Was it a couple of influential users? Was it something strategically that needed to be done? It’s very interesting what is worked on and not worked on in free software, and that’s obviously not specific to KDE.

Scott: Great. A lot of times, when we get to this point in these conversations, we’ll hand the microphone to the interviewee and say, “What did we not ask about that you think is interesting?”

Wade: This interview is happening just after our big 4.0 release, which we worked on in parallel to the 3.5 series for years. That’s a big deal, and it really is like the architecting and building a house analogy, where we have worked on the foundation to make this series one that is just going to be modern and performant and stable, like any other commercial offering, or better, over the next several years.

And certainly, there has been much press and discussion about whether we released too late, too soon, what the expectations were, did we over-hype it, etc. A lot of people were saying, “It should’ve had another release cycle,” or “It should have had more QA,” or “Why didn’t you just wait for the next thing?” Everybody chimes in with their pet project and why it should have just waited just a little bit longer, until their particular area of interest had been satisfied. So that’s certainly one thing that was tough.

Obviously, there was a massive amount of forethought and discussion and reasoning, because the 4.0 release was very significant, and any time you’re planning on something to be the foundation of your entire community for the next 5, 6, 17 years, you don’t do so lightly.

We’re very excited about it, and I think people are going to see that the upcoming releases are going to show very accelerated development. During the crunch time leading up to the 4.0 release, when you looked at the speed of commits to our code base, as well as the number of people working on it, just as with any software project right before the release, you saw a swelling of activity.

What’s been amazing is that it hasn’t slowed sown, now that the release is out. People did not take a breather and say, “Oh my God, I made it across the finish line. We got Version 4 out.” It’s actually only grown. Week after week, we have more and more application developers going in and saying, “I’m going to use that framework and port my application over to the KDE 4 code base. I’m going to use these new libraries and toolkits and Pillars of KDE that you’ve given me.”

With upcoming releases, I think that’s going to prove out how quickly this code base matures and how quickly things become stable.

Scott: There’s no better measure of success than people adopting it and moving toward it. In any community, but especially in open source, you’re always kind of herding cats, and there are always going to be strong opinions and outspoken people. You can never be everything to everybody, but if you’re getting good adoption, that’s the best validation that you could ask for.

Wade: I think, historically, things are going to point to this being the correct decision, to release at this time, because the foundation, the architecture, the pillars were sufficiently mature, from an API freezing standpoint. We’ve really seen an uptick in the QA loop, the feedback, and the amount of people that are going in and reporting bugs. A lot of applications are going in and using this technology now.

Obviously, if we would have delayed to work further on some things, we would have postponed the involvement of other groups, such as translators and documentation writers and QA and things like that.

The important thing is that at our release event, we announced that we have a very standardized release schedule going forward, so that distros can plan on those releases happening, where we have smaller sub point releases every month. And we’ve adhered to that thus far, where, in February, and now in March, we’ve had 4.0.1 and 4.0.2, and that the major point releases are going to be every six months, and so we plan on 4.1 coming out late this July.

Scott: Well, thanks for talking today. This has been a great conversation.

Wade: Thank you.