Being grumpy is almost part of the job description for developers.
Recently though several KDE developers came right out and asked, “Does KDE even need (certain) users?” While, Troy Unrau, a KDE developer and perhaps best known as the author of stories for KDE News, opened this can of worm by saying “This is a rant,” it was soon taken in earnest. Unrau’s opinion was quickly seconded by another KDE developer, Jason Harris, who said, “KDE, like many other open-source projects, doesn’t really need users at all, whether they are poisonous or not.” Instead, both Unrau and Harris wanted to see KDE get more developers.
In the end though, KDE has ended up with at least one less developer. Unrau has quit KDE. He puts the blame, in part, on simply having too much to do and too little time to do it and on both internal and external criticism of KDE’s recent development direction.
The dispute which caused Unrau to leave dates back to conflicts within the KDE community. The spark for this dispute over ‘poisonous users’ appears to have sprung from a KDE developer thread that suggested on June 7 that a KDE fork was in order. This quickly ignited into a flame war between supporters of Plasma, the KDE 4 default interface, and KDE 3.5x supporters.
By then, however, the discussion had already boiled over into a heated argument of users vs. developers both on such KDE lists as the KDE developer list and on far more public forums such as Joe Brockmeier’s OStatic blog and Mark Asay’s CNET blog. The final result has been Unrau’s departure, at least for now, from KDE development circles and other KDE developers, such as lead Plasma developer Aaron Seigo, spending their time on KDE coding instead of further in-fighting on mailing lists and online discussion groups.
Looking ahead, as the passions slowly cool, KDE’s leadership is working on a “Code of Conduct” to keep conversations from turning into flame wars. While there were no details on what might be in such a Code, Kévin Ottens, a KDE developer, suggests on his blog that such a code be written, and enforced, to prevent the “constant bashing” of individual developers and development decisions.