Sebastian Kuegler of KDE recently agreed to give an interview, the first in what I hope will be a series. His responses are well thought out and detailed. I hope you enjoy it as much as I do.
1. For the readers unfamiliar with you, tell us about yourself and the work you do for KDE.
I’m a 31 year-old German, living in the Netherlands with my girl-friend and my two chinchillas. My KDE history involves coding on Guidance, a set of system administration tools written in Python using PyKDE and PyQt. My current coding activities for KDE focus on Plasma, KDE4’s new desktop shell.
During aKademy 2005, I’ve started with the help of some others the KDE Marketing Working Group. With this group we have improved KDE’s PR work consistently over the past years. In 2006, I was elected into the Board of Directors of the KDE e.V., the foundation that is backing the KDE Community legally, financially and administratively.
2. How was the Release Event? What stood out the most to you?
The most amazing thing during the late Release Event was that KDE, while traditionally a bit Europe-centric, has an impressive presence in America as well. The event in Mountain View almost felt a bit like our yearly get-together Akademy. From a community-building and -strengthening aspect, it was a huge success. I also got to meet some people I’ve never met before. This kind of event is vital to nourishing a community and was a great success.
On the other hand, the event was a great opportunity to show what KDE offers right where the industry is. We got quite some people from companies interested in KDE, and we showed well what KDE has to offer, and how to make use of it.
The event itself was well-balanced between community and industry. Something which I particularly liked is that we kept it open, we gave everybody, including the press a look into the “KDE kitchen”. We don’t have anything to hide, this is how we work.
3. You have mentioned being thrilled at how KDE has improved its processes. Would you mind elaborating?
Sure. While the most apparent presence of KDE is often screenshots and surely new software for those who want to try the new version, during the last two years we were also able to improve the organizational side of things. Project governance is an important aspect for Free Software projects, and KDE has managed to make itself more sustainable and stable from this point of view.
2.5 years ago, the members of the KDE e.V. decided to formalize certain aspects of the KDE Community. This was achieved by creating a set of so-called Working Groups, small committees that deal with a field of interest within KDE. The initial set of Working Groups was the Technical Working Group (more on that later), the Human Computer Interaction Working Group, dealing with usability, accessibility and artwork and the Marketing Working Group.
The Technical Working Group didn’t work out very well. The members, that had been elected by the KDE e.V. members, all core developers of KDE didn’t have
enough time left to formally deal with issues related to release management and decision-making in technical matters. The only real result of the Technical Working Group was the decision to use CMake as a build system for KDE (back then, there were 3 buildsystems in use). CMake turned out to be an excellent choice for KDE, of course, but the TWG itself didn’t last that long. After some discussions about the form and members of the TWG, we have decided to put back this problem into the hands of the wider community, calling for people to take responsibility and form a release team.
Some people stood up to take this responsibility, a mailing list was set up and the release team started its work. Most important aspect was to get on the release train towards KDE 4.0. It turns out that this Release Team works really well. It’s very open, everyone can subscribe to its mailinglist and follow discussions, and its members are respected so the decisions that are being made are followed by the rest of the community.
The HCI Working Group has been working continuously to integrate usability and accessibility engineering into the KDE development process. Recently, there is for example hardly any developer meeting without a usability expert present. This way, we make sure that usability and accessibility are not applied as an aferthought, but are one of the bases of the technical design process. To make applications more consistent, and developing easier for the hackers, the HCI group is also working on human interface guidelines, which explain how certain aspects of our user interfaces should be designed. The Oxygen team, which is responsible for artwork in KDE is also flourishing. We can see that KDE has gotten a new, contemporary and modern look through the last 3 years.
The Marketing Working Group has taken care of good relationships with the press, has fostered the idea of “Guerilla Marketing”, promotional activities carried out by the wider community, and has also provided guidance for those that want to get involved with promoting KDE. One of the most important achievements of the Marketing Working Group is being accepted by the developers, and creating a strong brand which is based on fairness, honesty and other elements of the Free Culture spirit. More tangible improvements are materials telling about KDE (remember Troy Unrau’s “The Road to KDE 4″ series of articles?) and generally improved communication channels with the press.
This all shows one thing well, KDE as a Free Software community is turning into a community of Free Culture people. “Just coding” is not enough to spread Free Software, making Free Software a success is something that requires a multi disciplinary team working together well. That is what we see happening in KDE.
4. How can everyday users help with “Guerilla Marketing”? Is there an easy way to step in and help?
Yes, there are many easy ways to help. The most obvious is helping people installing KDE, answering questions on forums, IRC and other media. Lately, we’re getting also an increased amount of requests for speakers. Often local LUGs are interested in talks by KDE knowledgeable people. It might sound a bit scary, representing KDE in your local LUG, but it’s really what KDE is about. Everybody comes from a local community, that is where our grassroots are. People often don’t think that they are entitled to represent KDE, but that’s just not the case at all. In fact, the marketing and promo team have a hard time finding enough speakers for all events. Slides are usually available, so it doesn’t need all that much preparation.
There are of course many more areas where you can support KDE. Writing articles for magazines is a way to even earn some money, helping with maintenance of websites, submitting KDE-related news to your local newssites, maybe even writing for them, translating news (or of course applications), helping out at events and fairs, there’s lots to be done, much of which doesn’t involve writing a single line of code, but it’s just asimportant.
5. I was excited to see the new release schedule for KDE. How did this come about?
Well, we obviously need a release schedule, otherwise our developers don’t get an idea of when their code should be release-ready, and of course not knowing when to release doesn’t have a great effect on motivation. That’s the immediate reason why we worked on a release schedule quickly after 4.0.0 was released, but our release plans are really two-fold. The next 6 months with a monthly bugfix update and 4.1 in July are only part one. Part two is that we agreed to release a feature release every 6 months.
This is where public perception and our own didn’t really match lately. Looking into the past, KDE had a pretty steady release rhythm where we released a new feature version (3.x) at least every 8 months. Unfortunately, this was found to unpredictable by some external parties, especially distributors, so we thought how we could accommodate them better. At the same time, we need to have a close look at our development cycle. How long will people need to stabilise the codebase? How long does it take to implement new features? What part of our development time between releases do we want to spend feature-frozen? All those are important questions. First and foremost, we want to develop software, if we don’t, we don’t need to release at all. So our development process is what should dictate release schedules.
If we have a look at how the KDE 3.x cycle worked, we can get a clue of what’s to be expected for 4.x. With 3.0 we had put the pieces necessary that are necessary to build great applications in place. It turned out that we could release more than once a year, and with every release provide exciting changes and nice new and updated applications.
Now with 4.0 delivering even better frameworks, we can build on those. Having a stable basis in place makes it possible for us to cut down the time between
releases — because changes don’t need to be done under the hood. Oversimplified, we don’t need to change much but can build exciting new stuff on top of our frameworks. The issue how long a feature takes to be implemented becomes less important. Our community has reached a size where there will always be the bigger thing that just won’t make it into the release. We should learn to live with that.
On the other hand, we seem to have lost a bit of our traction with larger Linux distributions. We hope we can address parts of that with being more predictable. I don’t think that merely a release cycle is to be blamed for that, but really, we are putting the pieces together to make living with KDE easier for our commercial partners. We have emphasised focus in UI aspects such as usability and artwork, but we’re also more actively working together with distributions and try to engage them more in our development process. The release schedule, as an example, has been created after consideration of some distributions.
6. Are there any misconceptions about KDE 4 you see regularly and would like to address?
The most striking misconception I saw in the review is that people don’t really get what KDE is. I saw quite some bad press that didn’t go any further than “The panel lost some features”, but without really having a look at what changed. The Panel, belonging to Plasma is a completely new component. As that, it’s not exactly surprising that it has not yet reached feature parity. It’s quite a pity though to see that some journalists don’t look any further than that. We have some terrific new applications, our frameworks are greatly improved (which will make for many more new and improved applications in the near future). KDE 4.0.0 is really what it’s called. A dot-oh-oh release. Some people said that we should have waited half a year and released 4.0 as 4.1, but those don’t seem to understand how the Free Software development process works.
Having 4.0.0 out gives it more exposure to users, but also shows some other components down the stack that they really need to catch up. We’re raising the bar of what’s being done with desktop operating systems, this is not free of pain. Plasma for example exposes some bugs in video drivers and other toolkits such as GTK — simply because we’re the first to make extensive use of ARGB visuals (or, for the less technical inclined, transparency effects). Hadn’t we released 4.0.0, nobody would’ve tested their drivers with it. Result, if you then release 6 months later: the bugs are still there, simply because no one has run into them (well, except for us developers, but we are only so many). See, we’re not an island, we cannot create all great stuff only by ourselves. We’re highly dependent on projects like X.org, the Linux kernel and of course a lot of Freedesktop components. And some of those just don’t accept bug reports that come from a beta release of KDE. It’s a chicken-egg situation, if you want.
So sure, 4.0.0 is not as polished as anyone (especially ourselves) would have wanted it to be. It certainly is a usable desktop, if not up to all the goodness of 3.5.8 (which is what people seem to be used to, which shows that we do deliver quality work). We knew from the beginning that the development cycle leading up to a stable KDE 4 release would be painful. The fact that the definition of stable varies widely within our userbase and the expectations of everyone doesn’t make it any easier.
And then, most of the issues people have been complaining about are already fixed (and will be released in early February with KDE 4.0.1). Others will certainly be addressed with KDE 4.1, coming this summer. And of course, we always have our good old proven 3.5 branch, which is the perfect fit for those that cannot or do not want to live on the bleeding edge. KDE 3.5 is still fully supported, we’ll be releasing an update with quite some improvements especially in the KDE-PIM components in February. KDE-PIM in KDE 4 is scheduled to be released along with 4.1, making this release much more attractive to the users that are a bit more hesitant than our average developer.
7. What in the upcoming 4.1 release excites you the most?
I think the part that most people — just like me — are really looking forward to is an improved Plasma desktop shell. It really is the most visible part of the desktop. The good news here is that Plasma, a relatively young subcommunity within KDE is really alive and kicking. We’ve already been able to fix most of the problems that were still there in 4.0.0, and if we continue to keep the current pace of development, it looks like we have exceeded feature parity in those part with the 3.5 series already by summer.
Then of course, I’m looking forward to KDE-PIM in 4.1. It will make use of the Akonadi storage framework and as such be more stable and usable as the 3.5 series. Then, just recently, Dragon Player has been merged into our 4.1 tree. Dragon Player is a very simple but powerful video player, which of course makes use of Phonon, our new multimedia framework. For non-Linux/UNIX users, 4.1 will also bring the first stable applications to Mac OSX and Windows, which is another very big thing in my eyes.
Other features include more scripting support, newly ported applications (Amarok for example seems to be aiming for a summer release as well), performance improvements all over the place, new plugins for the KWin window manager with its nifty compositing features, and many more.
This really suggests what I expect from the KDE 4 series, new, innovative and really exciting features and improvements at a steady pace. With the KDE 4
series, we’ll simply outperform our proprietary competitors in terms of speed of innovation and user orientation.
8. What are your feelings about Gnome? People love to play up a war between KDE and Gnome and fight it out in comment sections. How is your relationship with Gnome? Do you find anything interesting about the Gnome desktop?
It’s sometimes a bit tiring that people try to put everything into the KDE vs. GNOME perspective. We’ve been working together with people from GNOME for a
long time and reached a lot together. A quick glance at freedesktop.org shows that there is plenty we have in common, and that we are doing quite a good job sharing efforts where it makes sense. I feel that the sentiments are often caused by people that simply have nothing better to do, or are out for sensationalism. The friendly competition between KDE and GNOME has probably helped both projects to become what they are now: Serious competitors of proprietary desktop systems.
On the other hand, GNOME often is not all that interesting to us to work with since one essentially can replace the other. Our issues up an down in the stack usually don’t hit GNOME directly, and GNOME offers an alternative to KDE, which also means that we don’t have to suit everyone’s need.
Frankly, I don’t like the whole concept of the “Linux Desktop”. Linux is really just a kernel, and in this case very much a buzzword. Having to mention Linux (which is just a technical implementation detail of a desktop system) suggests that something is wrong. Should it matter to the user if he runs Linux or BSD on his machine? Not at all. It only matters because things just don’t work so well (mostly caused by to driver problems, often a matter of ignorance on some vendor’s side).
The result is that people talk about Linux, then get confused between KDE and GNOME. The first question they ask “Why do I have to choose?” which expresses
that they are having a hard time dealing with the complexity that is offered immediately. The really important concept is plurality, and that is where we
can all win. Once people understand that the choice for KDE and GNOME is very much like the choice between, say Mac OS and Windows (nobody ever says: “Well, the world would be much better off if the effort wouldn’t be spread between Apple and Microsoft!”), so I keep asking myself why people often come up with this when talking about the Free Desktops. What we want is raising consciousness that you don’t have to swallow everything that a certain vendor wants you to, that there is choice, and that consumers can actively influence the market and put pressure onto those that don’t respect the consumer’s needs.
The term “Linux” serves more or less as a buzzword, but I think calling KDE “The Linux Desktop” is harmful. First, it ignores the concepts of plurality and choice, which are very much core values in the Free Software community. Second it ignores the efforts being undertaken to push KDE onto other Free Platforms such as FreeBSD, OpenBSD and OpenSolaris — those are not second class citizens for us.
To fix this problem, we need to increase awareness of the Freedom concept and not so much “teach people what Linux is”. The concept of Freedom is also much
more appealing to the masses than the concept of an operating system kernel, it just requires us to start thinking outside the box. Creating strong brands of user-visible components makes a lot of sense here.
John Palmieri, a top GNOME developer who attended KDE’s annual conference two years ago said: “Competition and collaboration are not mutually exclusive”. I
agree with this statement.
9. Thank you so much for your time, Sebastian. It certainly has been illuminating. Any final thoughts?
Thanks a lot for offering the opportunity to share my thoughts.
Thank you Sebastian, for an interesting and thoughtful review. It is appreciated. Be sure to check out Sebastian’s blog, vizZzion.org, for news on planned features of KDE 4.1, a horrific story of a crocodile attack and much more.