KWin über den Verlauf der Zeit

Eine der kontroversesten Entwicklungen in KDE in den letzten Jahren war sicherlich das KDE 4.0 Release. Obwohl es klar als Entwickler Release bezeichnet wurde: "KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5." (Aaron Seigo, Plasma Maintainer, am 04.01.2008 in talking bluntly), wurde es auch von Anwendern verwendet und nach dem Feedback was man damals gehört hat, waren sie damit nicht wirklich zufrieden. Vor allem Plasma in KDE 4.0 wurde (zu Recht) als unausgereift und nicht stabil bezeichnet. Selbst heute kann man auf heise oder pro-linux kaum einen Artikel zu KDE sehen ohne Hinweis auf das nicht ausgereifte Release von vor drei Jahren.

Immer wieder hieß es, dass KDE sich durch das Release selbst Schaden zugefügt hat und massiv Nutzer verloren hat. Solche Zahlen sind schwer zu erfassen, da es generell keine Statistiken zu den Anzahl Nutzern gibt. Von Entwickler Seite selbst wird das 4.0.0 Release als äußerst wichtig angesehen, alleine schon weil man in der Open Source Welt "Release Early, Release Often" folgt. Persönlich gehöre ich zu den Entwicklern (Hinweis: mein erster Patch für KWin war kurz vor 4.0.0 und wurde am 08.01.2008 eingespielt), die 4.0 unter dem Aspekt was KDE selbst erreichen wollte, als vollen Erfolg ansehen. Als sehr einfache Metrik um das zu bestätigen: in 2008 wurde fast jeden Tag ein neuer SVN Account erstellt.

Nun bleibt die Frage offen, ob KDE wirklich Nutzer verloren hat durch das Release und sich selbst geschadet hat. Wie gesagt ist es schwierig Daten dafür zu bekommen. Als Versuch möchte ich mal die Bug Statistik von KWin über die Geschichte von 1999 bis heute heranziehen. KWin ist hierbei interessant, da es in 3.5 bereits eine sehr ausgereifte und extrem stabile Anwendung war. in KDE 4 kamen die Desktop Effekte dazu, jedoch bis 4.2 standardmäßig deaktiviert und als experimentelles Feature markiert.

Die Statistik beinhaltet leider auch die "Wishlist" (aka Feature Requests), welche die Statistik leicht verfälschen, da sie meistens nicht bestätigt werden oder implementiert werden. Aktuell haben wir ungefähr 320 Feature Requests wovon 270 zu der roten Linie der Unconfirmed Bugs gehört. Eine Entwicklung über die Zeit steht mir hier leider nicht zur Verfügung.

Erklärung der Begriffe:

  • UNCONFIRMED: ein Bug, der noch nicht reproduziert werden konnte oder ein Feature Request
  • NEW: reproduzierbarer Bug
  • ASSIGNED: ein Entwickler hat sich den Bug zugewiesen – wird in KWin eigentlich nicht verwendet
  • REOPENED: ein Bug der als behoben markiert wurde und noch immer vorhanden ist.

Der Graph zeigt sehr deutlich einen massiven Einschnitt in der Entwicklung. Dieser Einschnitt liegt um die Jahreswende 2007/2008. Zwischen 2005 und 2008 haben sich die Zahlen der bestätigten Bugs kaum verändert. Der Abstand zwischen den UNCONFIRMED und NEW bleibt in diesem Zeitraum in etwa gleich. Was hat sich also in 2008 ereignet, dass sich die Zahlen so verändern? In diesen Zeitraum fällt das 4.0 Release. Seit diesem Zeitpunkt hat sich die Gesamtzahl der offenen Bugs mehr als verdoppelt und nehmen etwa einen linearen Verlauf an.

Zuerst einmal stellt sich hier die Frage: wie kann es sein, dass Bugs gemeldet werden, wenn das Release doch in einem Zustand ist, dass es nicht benutzbar ist und der neue Code in der Anwendung standardmäßig nicht aktiviert ist (und damals) auch auf der meisten Hardware nicht funktionierte?

Eine naheliegende Erklärung zu den wachsenden Kurven wäre, dass vor 4.0 die Entwickler neu aufgemachte Bugs behoben haben und ab 4.0 der Bugtracker vermüllt. Diese These kann man mit einer weiteren Statistik widerlegen:

Zuerst die Erklärung der neuen Linien:

  • FIXED: ein behobener Bug
  • DUPLICATE: ein Bug der bereits gemeldet wurde und durch Triaging manuell als Duplikat markiert wurde
  • NEEDSINFO: ein Bug bei dem Rückfragen an den Nutzer gestellt wurden und keine Antwort kam
  • UPSTREAM: Bug in einer Komponente auf die KWin aufbaut – meistens Treiber

Bei den neuen Kurven ist wichtig zu bedenken, dass es zu erwarten ist, dass die Werte immer weiter anwachsen – im Gegensatz zu den offenen Bugs wo man erwartet, dass sie konstant sind oder zurückgehen. Am interessantesten ist die Kurve der FIXED Bugs. In dem Bereich zwischen 2005 und 2008 ist die Kurve fast konstant – genauso wie die Kurven der UNCONFIRMED und NEW Bugs. In 2008 verändert sich die Kurve ebenfalls und nimmt auch ein lineares Wachstum an. In den drei Jahren seit 4.0 haben die KWin Entwickler fast so viele Bugs behoben wie in den acht Jahren zuvor.

Die Kurve zeigt deutlich, dass zum Auslauf von KDE 3.5 keine neuen Bugs mehr gemeldet wurden und seit 4.0 die Anzahl sowohl gemeldeter als auch behobener Bugs deutlich ansteigt. Dies kann man auch an der DUPLICATE Kurve sehen. Diese wächst auch während KDE 3 linear an. D.h. es wurden immer wieder die gleichen Bugs gemeldet. Jedoch verändert auch diese Kurve Ende 2008 ihre Form (Kubuntu mit 4.1 und Effekten standardmäßig aktiviert). Die Kurve hat klar die stärkste Steigung von allen hier gezeigten und scheint gänzlich unbeeinflusst von den anderen Kurven zu sein. Dass wir viele Duplikate bekommen habe ich ja schon vorher gewusst.

Nun will ich noch eine weitere Statistik zeigen: die Entwicklung von KWin. Mit Hilfe von git log und einem kleinen Programm hab ich mir die Anzahl Commits und Anzahl Committer pro Jahr generieren lassen (Achtung: Y-Achse ist logarithmisch):

Der Graph bricht zum Schluss so stark ab, da wir in 2011 noch nicht viele Monate hatten ;-) Was dieser Graph nun zeigt, ist dass in der Zeit in der keine neuen Bugs gemeldet wurden die Enticklungsgeschwindigkeit stark angezogen hatte (KDE 4 Portierung/Entwicklung der Effekte) und auf dem hohen Level sich hat halten können. Das 4.0 Release hat die KWin Entwicklung weder in die eine noch in die andere Richtung beeinflusst. Insbesondere konnte KWin das reduzierte Engagement des Maintainers (immernoch etwa 27 % aller Commits) durch neue Entwickler kompensieren.

Fazit:

  1. Die Aussage, dass es das 4.0 Release brauchte um den Code getestet zu bekommen, ist im Falle von KWin klar bestätigt. Seit 4.0 steigt die Anzahl der gemeldeten und behobenen Bugs stark an.
  2. Zumindest KWin hat durch das 4.0 Release keine Nutzer verloren. Andernfalls hätte die Kurve nicht anziehen können
  3. Die Anzahl der Bugs ist gestiegen obwohl die neue Funktionalität nicht standardmäßig aktiviert war. Dies deutet auf ein Wachstum der Benutzerzahlen hin.
  4. Das spätere standardmäßige Aktivieren der neuen Funktionen hat keine Auswirkungen auf offene und behobene Bugs sondern nur auf Duplikate und Treiber Bugs
  5. Die massive Stabilisierung in KWin hat keine Auswirkung auf die Anzahl der gemeldeten Bugs. Die Rate ist nahezu konstant. Auch dies lässt sich nur mit Anwachsen der Benutzerzahlen erklären.
  6. KWin ist als Projekt sehr gesund.

Ich bitte davon Abstand zu nehmen mich in den Kommentaren daruaf hinzuweisen, dass 4.0 doch ganz fürchterlich war. Das 4.0 Release war vor meiner Zeit als Entwickler und ich bin daher in keinster Weise für das Release verantwortlich.

=-=-=-=-=
Powered by Blogilo

4 thoughts on “KWin über den Verlauf der Zeit

  1. vielen dank für die infos, allerdings empfinde ich das als eine “sinnlose” sache in solchen zahlen manches reinzuinterpretieren.

    zu den einzelnen aussagen:
    1. ich sehe das nicht so, ein 3.9 release oder sowas hätte vermutlich nicht zu deutlich weniger bug-meldungen geführt, das schlechte image aber erheblich verbessert, weil es nämlich nutzbar gewesen wäre. ich bin damals sofort mit auf kde4 umgestiegen, hab aber auch einen desktop ohne panel gehabt, damit der desktop überhaupt ein wenig zu gebrauchen war.

    2. mag sein, wie du ja auch selbst sagst, gibt es darüber keine genaue statistik. wichtig ist dabei ja auch, wieviel % man an die “gegner” verloren hat. linuxi st die letzten jahre auch viel gewachsen und ich kann mir vorstellen, dass gnome an den “wachstumszahlen” mehr gehabt hat als kde.

    6. ich hoffe es. vorallem hoffe ich aber auf mehr distributionen, die ein schönes kde einbinden können. das schönste kde war -meines achtens- immer noch das kdemod 3.5 in archlinux. die aktuellen implementationen sind zwar meist ok, aber überzeugen mich leider weniger. aber das wird schon noch…

  2. Die Leute brauchen was zu meckern, sieht man ja schon an Gnome 3, ist das selbe wie bei KDE4.

    Vll. werden dann wieder ein paar User von Gnome auf KDE wechseln, wer weiss. (Oder sie werden nurnoch tty verwenden xD)

  3. Ist das nicht der Vorteil von Gnome und KDE, nein von Linux, nein sogar von der gesamten OpenSource Software? Was kann OpenSource, was keine kommerzielle Software jemals können wird?

    Ausprobieren, ob die Nutzer ein neues Konzept annehmen oder nicht. Jede kommerzielle Software hat den Nachteil, das der Hersteller mit jeder Änderung Nutzer vergrault und damit Umsatzeinbrüche hat. WIR können tun was wir wollen, es bleiben Linux Nutzer, das macht Innovationen viel einfacher. Kein Marktforscher, der uns auf die Finger schaut…

  4. Als ich zu Zeiten von KDE 4.0 zu Linux konvertierte, stellte sich mir die Frage welcher Desktop denn der für mich bessere sei. Wegen KDE’s schlechten Leumund bin ich dann bis heute bei Gnome hängen geblieben obgleich die optische Anmutung bei KDE ungleich sympathischer ist.

    Als User der hohen Wert auf Stabilität und Reife legt, wird es für mich mit Gnome 3.0 dann vielleicht einen Grund geben auf das inzwischen voll ausgereifte KDE zu wechseln.
    Und genau das ist der Reiz von OS: ich habe eine Wahl!

    Und bei aller berechtigten Kritik die jetzt auf die Gnome-Macher einschlagen wird, heißt es auch Dankeschön zu sagen.
    Nur durch Wagnisse können diese Projekte weitergebracht werden.

Comments are closed.