Month: September 2011

Over a decade ago an event happened which is still influencing our life in free software. Instead of one, two projects emerged to bring a fully free desktop to Linux based systems. Back then we failed to see the advantages of having multiple available desktop environments and we basically created a schism between the KDE and the GNOME world.

The Schism is still in place!

Without noticing it the emerge of multiple desktop environments (and with that I mean not only GNOME and KDE) created something positive: nowadays we have several superb environments the user can choose from. We have what nobody else can provide: choice of the desktop shell and software for the personal needs. The free software world does not provide a one size fits it all solution, but the user can choose between multiple products. This is a great advantage.

In the end it does not matter whether a user is using GNOME Shell, Unity, KDE Plasma, XFCE or any other environment. As well it does not matter whether he uses KMail, Evolution or Thunderbird. What matters is that the user has been liberated from the lock-in systems of our competitors. Our goals are all the same: we want free software to succeed.

If a user switches from GNOME Shell to KDE Plasma, it is not a lost user to GNOME. It is a user won for free software and not lost to the proprietary competition. If a user switches from KDE Plasma to Unity, it’s not a lost user to KDE, but a user won for free software. We have to realize that we are not in competition with each other, we are in competition with the proprietary lock-in systems. United we have something to compete with our real competitors.

I think most developers have already realized that we are not in competition but have to work together. We can see this through events like Desktop Summit. But if I look around, I see that there is still a war between GNOME and KDE – at least among the users. KDE users are happy that GNOME Shell is not yet ready and similar idiocy. This is something we have to fight. If for example somewhere a user is complaining about KDE Plasma it is totally fine to suggest them to give GNOME Shell a try. We have the choice, we have different environments to support different workflows. We do not provide software which is suited to all users. I am sure we have the software component to make each user happy, we all have to help the users to find the right software for their needs.

When Linus turned first from KDE Plasma to GNOME and later from GNOME Shell to XFCE he was exactly demonstrating the advantages of choice. Neither KDE Plasma nor GNOME Shell can suit the needs of a power Kernel superlord but free software in general does offer the possibility to have a desktop shell available for everyone. These two events have not shown a failure of GNOME or KDE as the media seemed to suggest, but the opposite: it highlighted the great advantage of choice in the free software ecosystem.

My hope is that our users would stop to fight each other. While our users fight, they demotivate the developers, they undermine efforts to improve the collaboration. There is no need to fight for KDE. If a KDE user writes bad about GNOME, he is not harming GNOME, he is harming both KDE and GNOME. KDE and GNOME belong together, we are in no competition, we need each other. Only together we have a chance of bringing the merits of free software to all possible users. I also hope that the media would stop to compare the systems: they don’t need to be compared. GNOME Shell has a different workflow than KDE Plasma. What would be the need for GNOME Shell to simulate the behavior of KDE Plasma or vice versa? Comparing the systems is wrong from the start.

I hope that also the two organizations around KDE and GNOME can help to make a united vision come true. Why is there no mention of GNOME on the KDE web site? Why is there no mention of KDE on the GNOME web site? Why are release notes of GNOME not published on the KDE news site, isn’t it a news worthy event if our collaborators have a release? Why is it so strange that a picture of a GNOME developer is in a release note of KDE that it has to be mentioned in a keynote at Desktop Summit? Such collaborations should be normal and nothing which needs to be mentioned.

And we can also do something to make the acceptance for our users better. New users will end up with either GNOME Shell, Unity or KDE Plasma. There is a good chance that they don’t like the system they got by chance. In that case they are lost again to the proprietary competitor. Why don’t we offer a “discover more” mode in our systems? Make it easy to install and try GNOME Shell from inside Plasma and vice versa. We have so many awesome software and nevertheless we are still in our GTK-only and Qt-only world. Why do we not include GTK applications in the default offerings in KDE Plasma? If there is a better alternative, do we really need to ship a maybe unmaintained and half broken Qt application, just because it’s Qt?

We all – users, developers and media – can do much better than we already do to finally end the schism of free software. It’s not KDE vs. GNOME, it is KDE and GNOME. We are one free ecosystem. If we want we could say KDE Plasma is just another desktop shell for GNOME OS, just like GNOME Shell and Unity are shells for GNOME OS. We have to finally be united to bring the merits of free software to all users. Let’s all pull together to make free software more awesome. Let’s stop the so often childish and ridiculous comparisons between GNOME and KDE software. They are alternative options and not competing products.

A free software project such as the many projects under the KDE umbrella do not need users, they only need more developers. A user which is not able to develop is useless. Because of that it is totally acceptable that you demand that user’s should start learning programming to fix the bugs they report.

Of course such an opinion is as ridiculous as users demanding that bugs get fixed or insulting the developers who spend hours and hours of their spare time to produce an awesome product.

What I want to indicate is that the relationship between users and developers in a free software project is very special. And we need both: we need the developers and we need the users. What’s the fun of developing if nobody is going to use your software? How do you get new software if there are no developers?

A recent incident on a mailinglist and similar incidents before motivated me to finally write this blog post which I had in mind for quite some time. I hope this can help users in the interaction with developers. Now I have to add that I am not an expert in that area and most of the things I put down here are based on my personal opinion and experience.

The Value of Free Software

Free Software is something incredible: hundreds of developers write software in their spare time and not only do they give it away for free, no they also give you the right to do whatever you want with the source code. Furthermore you are allowed to give feedback directly to the developers: through bug reports, through mailing lists, through blog posts and many more possibilities. Each user can interact directly with the developers. There is no expensive support hotline in between. Keep that in mind whenever you have the urge to communicate with developers. It is one of our greatest values and it would be a pity to lose it.

Developers are not evil

No developer is going to destroy his software. No developer is going to introduce bugs on purpose. No developer is ignoring bug fixing. Whatever you think, developers are not evil. They are more interested in a successful product than you as a user. It’s what they invest time for, it’s what they like doing. If a developer is not fixing a bug or not even reacting to it, it’s not because he does not care, it is more likely that he did not see it, that he does not encounter it, that he just does not have time or something else. It’s never about ignoring the user. Also developers do not remove features to harm their users. They have to think about more than just a collection of features. Sometimes it is required to remove a rotten log in order to get something better. It might be worse for you, but in general it’s better for all. Developers don’t change for the sake of change – we are lazy.

You are not a Developer

Remember that you are not a developer. You should not try to discuss about technical details with developers: you cannot win. No matter how good your opinion is, no matter how smart you are, the developer is most likely an expert in his area and has a better view on issues. If he tells you something is not possible, it most likely is. If he tells you he cannot fix a bug, that’s the case. If he has to remove a feature, he has to. Please accept it, don’t argue, you will make a fool out of yourself.

Developers might be busy

Even developers might be busy: they have a day job, they might have to learn, they might have to write a thesis. Accept that they cannot answer to your bug reports instantly. It may take some days, maybe even months till there is a response. It’s not optimal, but that’s the way it is. Please also respect the private life of the developers: don’t query them in IRC without asking, don’t send them private mails asking for bug fixes. At least for me it’s a certain way to ensure that the bug won’t be fixed any time soon. Just think if everybody would send their bug reports via private mail, it doesn’t scale.

Bugs belong into the Bugtracker

It’s obvious, right? A bugtracker is the only available tool to ensure that the bugs can be tracked. A comment on a dot article won’t fix your bug, a mail to a mailinglist will be ignored. Use the bugtracker. Even if it seems to be a dumping place, it’s the best we have.

Don’t state the obvious

A unresolved bug in the bugtracker is not fixed. You don’t have to repeat in each minor release that it is still not fixed. If it were fixed, it would be closed or you could close it. Repeating the obvious just causes even more mail in my already overcrowded mail account and it does not increase the chances that I fix the bug for the next release.

Not all bugs are equal

Just because you have a bug which really annoys you, don’t assume that anyone else has the bug. It’s possible and likely that no developer is using the same workflow as you do. So the very obvious bug might be completely hidden to the developers. Also developers run a different version than you do: they run the latest development version. They might be not aware of a bug in an old version. So don’t assume that everyone sees your bugs.

Everybody has his pet bugs

Yes, you are not the only one having bugs. At the time of this writing the KDE bugtracker lists 23374 open bug reports with a rate of more than 400 new bugs per week (more gets closed). So every user has his personal very important bug which has to be fixed. Also there are many more open bugs than the developers could fix. Yes it’s software, yes that is normal. So don’t rally for the bug to get fixed. I as a developer decide which bug I’m going to fix and if I see that you think your pet bug is more important than the pet bug of someone else, I go for someone else pet bug.

Don’t insult

It should be obvious but it isn’t. Don’t insult the developers. It won’t help your case. Do you really think I’m going to fix your problem (which I do not experience) if you are insulting me? It is contra-productive and harmful. Remember that we spend our spare time. If I get insulted in my hobby, I might pick a different hobby. Your problem is never that important that it is worth the risk that developers are leaving the community.

We are not going down the GNOME road

It’s the argument I hate most when it comes to adding new features or removing existing ones when needed. Nobody is going down the GNOME road and it’s a very insulting statement towards the awesome GNOME developers for whom I have great respect. Such arguments are not going to help you: you want a feature and you try to convince me with such an argument? If you need a feature convince with real arguments under consideration that the developer has to take care of more than just collecting features.

Features are Expensive

Each added Feature means more code to maintain, more code paths which could break, more time to spend, less users which actually use a given code path and by that worse testing. There are valid features, there are not valid features. If the developer decides against your idea, please accept it, he has to take care of more than adding a bunch of functionality. Also please think about how likely it is that you find a new great idea which has not yet considered in the past? Please also use brainstorm.forum.kde.org to suggest new features. Everything else is most likely to just be ignored.

Developer Mailinglists are for Developers

It’s great that users can follow the development process directly by reading the internal mailinglists. But please remember that this is the think tank where the developers need to speak freely. There they exchange their ideas, there they might post controversial ideas on purpose. Don’t jump in and tell your opinion on how stupid the developer is. The mail was not intended for users but to get valuable feedback from other developers. Respect that, don’t destroy the discussion by pulling it in the wrong direction.

Don’t mention the war

Yes KDE 4.0 was a bad release, not ready for productive usage and aimed at developers. There is no reason to bring up KDE 4.0 in a discussion about a present bug or missing feature. It is our past and we cannot change it, especially not the developers who joined after 4.0. If you keep mentioning the state of 4.0 people will ignore you, even think that you are a troll. So just forget about it.

You don’t need to learn C++ to help

Everybody can help, so please give something back. It’s the best way to convince developers to fix your bugs by becoming part of the community. There’s documentation which needs to be written, there are translations which need to be done, there is a marketing team which needs help, there is user support which is lacking supporters, there are designers who need more clones, there is the bug tracker which really needs to be cleaned up. Especially if you hate that your bugs don’t get fixed, help the developer team by taking away the burden of going through all the useless and duplicate bug reports.

I hope these items help to keep KDE the friendly place which it is and helps to keep the relationship between users and developers healthy.