Die Woche: Entwickler von Anwenders Gnaden?
Immer wieder reagieren Anwender verärgert, wenn gemeldete Verbesserungsvorschläge oder vermeintliche Fehler von der freien Entwicklergemeinde nicht aufgegriffen oder noch während einer laufenden Diskussion abgelehnt werden. Warum tun die Programmierer nicht einfach das, was die Anwender wünschen?
Programmierfehler sind immer ärgerlich, vermeiden lassen sie sich jedoch nicht, schließlich sind Entwickler auch nur Menschen. Dank ausgeklügelter Bugtracking-Systeme hat man heute ein Mittel zur Hand, um gemeldete Fehler an die für den jeweiligen Programmteil zuständigen Entwickler weiterzuleiten -- die dann im Idealfall schnellstmöglich eine Lösung des Problems finden.
Während Anwender bei kommerzieller Software noch damit drohen können, die nächste Version nicht mehr zu kaufen, wenn ein bestimmter Fehler nicht umgehend beseitigt wird, haben sie bei freier Software praktisch kein Druckmittel in der Hand. Sie sind davon abhängig, dass ein meist unbezahlter Freizeit-Programmierer genügend Verantwortungsgefühl hat und den Fehler ausbügelt. Bei schwerwiegenden Fehlern, die zum Absturz führen oder Sicherheitsprobleme bereiten, legen sich die meisten freien Entwickler ins Zeug und sorgen umgehend für Abhilfe.
Doch nicht alle gemeldeten Probleme sind Programmierfehler, manchmal geht es nur um etwas missglückte Dialoge, dass eine Funktion umständlich zu bedienen ist oder dass die entscheidende Killer-Funktion noch nicht implementiert wurde – und noch während die Anwender im Bugtracker darüber diskutieren, wie die optimale Lösung aussehen könnte, bügelt der zuständige Entwickler das Ticket als "Won't fix" oder "Invalid" ab und beendet somit die Diskussion.
Dadurch fühlt sich mancher Anwender auf den Schlips getreten – spielen die Wünsche derer, die die Software tagtäglich einsetzen, etwa keine Rolle? Wer glaubt dieser Entwickler eigentlich, zu sein?
Um den Grund für die Ablehnung zu verstehen, müssen sich die Anwender in die Sichtweise eines Entwicklers hineinversetzen. Die meisten Open-Source-Entwickler stellen ihre Arbeitskraft zur Verfügung, weil sie Spaß am Programmieren haben, gerne neue Herausforderungen annehmen und sich mit dem Projekt als Ganzem verbunden fühlen. Eine breite Anwenderbasis bedeutet zwar ein gewisses Renommee, ansonsten hat der Entwickler jedoch nichts davon, dass man sein Programm benutzt. Insofern ist der Anwender durchaus auf das Wohlwollen des Entwicklers angewiesen – er kann ihn zu nichts zwingen.
Durch die heute üblichen Bugtracking-Systeme ist der zuständige Entwickler auf der anderen Seite jedoch auch unter Zugzwang: So lange er das Ticket nicht als behoben oder abgelehnt kennzeichnet, bleibt es geöffnet und somit als potenzieller Fehler im System bestehen. Ein "Won't fix" bedeutet insofern nicht unbedingt "Will never be fixed", sondern nur, dass der Vorschlag nicht in nächster Zukunft umgesetzt wird.
Das betrifft vor allem Verbesserungsvorschläge, in denen die Meinungen der Anwender weit auseinander gehen, welches nun die optimale Lösung wäre. Was glauben die Anwender denn, wer sie sind? Wie können sie es sich herausnehmen, den Entwicklern die optimale Lösung vorschreiben zu wollen, wenn sie nicht mal in der Lage sind, einfache Fehler selbst zu beheben?
Um nicht ständig die einzelnen Postings vom Bugtracking-System vorgelegt zu bekommen, ist die Versuchung groß, den Vorschlag einfach abzulehnen, weil er zu kontrovers diskutiert wird. Für den Anwender sieht es oft so aus, als ob die Entwickler die Diskussion über den Verbesserungsvorschlag unterbinden wollten – und führte in der Vergangenheit schon zu mancher Anfeindung.
Der neue Status "Opinion" könnte dafür sorgen, dass sich Anwender und Entwickler künftig weniger anfeinden: Denn anstatt einen Vorschlag, über den noch lebhaft diskutiert wird, endgültig abzulehnen, können die Entwickler auf der Plattform Launchpad nun den Status "Opinion" setzen. Damit tut der Entwickler kund, dass er zwar (vorerst) nicht an einer Problemlösung arbeitet, aber durchaus daran interessiert ist, dass das Thema ausdiskutiert wird. Das Bugtracking-System schließt das Ticket, sodass der Entwickler frei ist für andere Aufgaben, ohne die Anwender vor den Kopf zu stoßen und ihnen vermeintlich den Mund zu verbieten.
Als Anwender sollte man aber auch weiterhin realistisch bleiben: Sollte die Diskussion zu einem Konsens führen, hat man nach wie vor keinen Anspruch darauf, dass die Lösung auch genau so umgesetzt wird. Denn letztlich sind freie Entwickler in erster Linie frei, zu entwickeln, was sie möchten – und nicht Auftragsprogrammierer der Anwender. (mid) (mid)
