Open Source und Usability

Entwickeln für die Community

Eines der häufigsten Argumente, warum OSS wenig benutzerfreundlich sei - in der Regel ohne konkreten Beleg - ist die traditionelle Ausrichtung an der Community, d. h. an anderen Hackern (Nielsen 2004). Ihr Urteil ist maßgebend für die Qualität einer Software, entsprechend wird sie mehr oder weniger für diese Gruppe als Endanwender geschrieben. Andere Projekte sind daraus entstanden, dass man eine Software entwickelte, die ziemlich genau das tut, was man selbst gerne haben möchte. Kann man dann verlangen, dass diese Software auch für „normale Anwender“ benutzerfreundlich sein muss? „Wer andere Bedürfnisse hat, kann ja eine andere Software einsetzen“ ist ein häufig gehörtes und durchaus plausibles Argument.

Diese Einstellung wird jedoch fragwürdig, wenn man Interesse daran hat, dass die eigene Software auch die Wahl für einen Behörden-Desktop oder Windows-Umsteiger ist. Solche Nutzer haben andere Ansprüche als die Entwickler. Deren Rationalität zielt nicht darauf herzustellen, was man möchte, sondern einzusetzen, was man braucht. Will man also Software für durchschnittliche Nutzer einfacher benutzbar machen, dann kann man sie nicht nur für sich selbst schreiben.

Damit tut sich eine sehr wichtige Konfliktlinie auf: Programmiert man für sich und andere OSS-Entwickler oder für „durchschnittliche“ Nutzer? Dass sich beides häufig ausschließt, zeigt sich z. B. bei der Funktionsvielfalt. Die meiste OSS hat einen reichen Schatz an Funktionalität, der natürlich für die speziellen Bedürfnisse der Entwickler durchaus passt. So gibt es im Mailprogramm KMail die Einstellung, dass ein Ordner eine Mailingliste beinhalten kann. Diese Funktion ist praktisch für die Verwaltung von Mailinglisten. Ein Entwickler fand dieses Feature sinnvoll, er programmierte es, und es wurde in die Software aufgenommen. Die Zahl derer außerhalb der Hacker-Community, die dieses Feature verwenden, dürfte dagegen sehr klein sein. Trotzdem steht es auf einer Ebene mit z. B. Ordner-Namen oder Icons. Für den Nutzer wird diese Funktionsvielfalt schwierig, weil er nicht sofort unterscheiden kann, was wichtig für ihn ist, und was nicht. Heißt das aber, dass man nur noch jene Funktionen anbietet, die für den „normalen“ Nutzer relevant sind? Auf welche Funktionen verzichtet man? Was sagen jene Entwickler, die diese Funktion programmiert haben? Was sagen jene Nutzer, die bisher die Software genau deswegen einsetzen, weil es diese Funktion gibt? Diese Konflikte traten z. B. auf, als ich Menü-Dialoge von KMail konzeptionell überarbeitete, um sie leichter benutzbar zu machen. Die „Orchideen“-Features herauszunehmen oder zumindest zu verstecken, würde die Übersichtlichkeit verbessern und die schnelle Erfassung der zentralen Funktionen erhöhen. Auf der anderen Seite stößt man Entwickler vor den Kopf. Ob sich ein Projekt dafür entscheidet, die eigenen Wünsche und die der Community zurückzustellen, um „massenkompatibler“ zu werden wird sicherlich in Zukunft an Bedeutung zunehmen. Vielleicht sind im Einzelfall Kompromisse möglich, mit denen es sich leben lässt. Doch ganz auflösen lässt sich dieser Konflikt nicht.