Anwender - das dicke Problem bei Open Source

Trotz aller Unkenrufe - der Erfolg der Open-Source-Bewegung ist nicht mehr aufzuhalten. Weite Teile des Internets und auch immer mehr unternehmenskritische Software laufen unter Open Source Software, vor allem auf Linux und den verschiedenen Anwendungen der Apache.org. Nur in einem Anwendungs-Bereich will und will es einfach nicht "rund laufen". Bei der Software für den Schreibtisch, ganz normaler Textverarbeitung, Grafiksoftware, Tabellenkalkulation, Buchhaltung etc. Klar, gibt es auch Open Source Lösungen. Aber - bei aller Zuneigung zum Konzept - diese einen Erfolg (am Markt, bei den Usern) zu nennen, wäre doch etwas übertrieben. Es gibt Ausnahmen, wie zum Beispiel Open Office, aber diese Ausnahmen sind oft zunächst als Closed Source gestartet und später aus unterschiedlichen Gründen ins Open Source Lager übergelaufen.

Was macht es Open Source bei Software für normale Endanwender so schwer?

Das selbe, was Open Source in Entwicklerkreisen so erfolgreiche macht: Entwickler und Anwender sind sich sehr nahe, oft sogar die selbe Gruppe!

Ich bin vor kurzem bei Doc Searls (Open Source Advokat par excellence ist) wieder einmal auf diese Frage gestossen. Genauer gesagt war es die Entgegnung Doc Searls gets one wrong von Will Parker.

As John Gruber pointed out far more ably than I ever will, the Linux community is cursed with a fundamental inability to think deeply about user interface design beyond the command line. ...

Doc, I know you were taken up by the moment, but you're missing a very important point. Reaching some development goals requires more than deep thought and razor-sharp programming skills. Sometimes, you need to find out what the end-user needs before you lay down a single line of code.

Das ist böse formuliert aber leider zutreffend. Und es ist ein systeminherentes Problem der Organisation der meisten Open-Source-Projekte. Siehe auch mein altes Posting Open Source ist doch Klasse zu Raymonds Grundlagenpapieren der Open Source Gemeinde.

Diese Haltung [von Open Source Pionier e. Raymond] offenbart [...] eines der größten Probleme, vor denen die Open-Source-Kultur aktuell steht. In den selbst organisierten Entwickler-Teams domieren … eben die Entwickler, ihre Ansichten und Bedürfnisse. Die Anwender, wo sie denn mit den Entwicklern nicht identisch sind, spielen keine große (zumindest keine instititutionalisierte) Rolle. Deswegen sind in den großen, in klassischer Open-Source-Manier durchgeführten Projekten, schon viele gute Tools entstanden aber noch wenig coole Endbenutzersoftware; [...]

Was die Open-Source-Bewegung braucht – und einige ihrer Protagonisten auch schon erkannt haben, sind praktikable Modelle dafür, die „reinen“ (blöden) User in die Entwicklungsprozesse sinnvoll einzubinden.

Heute würde ich sogar noch etwas konkreter werden und sagen: Was die Open-Source-Bewegung braucht, ist Begeisterung für Vorgehensmodelle, wie User Centered Design (siehe Was soll überhaupt User Centered Design?) oder ähnliche Ansätze. Solange Open Source die reinen Enduser nicht als mächtige Stakeholder mit in die Projekte holt, wird es schwierig sein, Software für diese User zu entwickeln, die guten Closed Source-Produkten das Wasser reichen kann!

Comments

[Thomas Schulze]

Jein. Stimme Dir nur teilweise zu, denn solange der User nicht dabei ist haben die Kollegen Entwickler durchaus die Chance, *gute* bestehende Konzepte abzukupfern (nicht böse gemeint). Dann gibt's zwar oftmals ne Diskussion (Windows-look-alike) aber die Designs von KDE oder GNOME sind da durchaus "beeinflusst". Siehe Evolution (Outlook Kopie), Abiword (mit deutlichen MS Anleihen) und und und.

Du hast freilich recht wenn's um "originäre" Open-Source Software geht. Da wären die User, gerne innerhalb eines solchen Prozesses, klasse. Wenn sie denn eingebunden werden.

[Markus Breuer]

Really Great Software entsteht nicht durch "Abkupfern", oder?

Aber auf die Art und Weise (solange gut gekupfert wird), kann wenigsten nichts völlig schief gehen.

Aber da Entwickler ja auch kreative Menschen sind (und ihre Sicht für universell halten), meinen die gelegentlich, dass, wenn sie selbst eine gute Idee haben und die ihnen (und den Kollegen) plausibel etscheint, es schon funktionieren wird -- und sie "verbessern" beim kupfern.

Ich wünsche mir ja innovative Software auch aus der Open Source Welt. Aber solange kein Grundverständnis dafür da ist, dass "ich der Entwickler" nicht der exemplarische User bin, wird das schwierig. Lesenswert zu dem Thema ist auch http://daringfireball.net/2004/04/spray_on_usability. Hier geht er direkt auf ein paar Anekdoten von Raymond zu dem Thema ein und das ist - als Sichtweise des Open Source Papstes - schon bemerkenswert. So wird das nicht fluppen.

[Thomas Schulze]

naja, auf auf in die diskussion:-))

raymond hat ja mal in seinem ersten essay über "scratch an itch" gesprochen als grund für die entwicklung vieler open-source-projekte. insofern ist der entwickler dann auch der benutzer - wenn auch kein typischer benutzer (was um himmels willen ist eigentlich ein typischer benutzer?).

im rest bin ich bei dir. entwickler sind fürchterlich kreative und oftmals selbstsichere wesen - und argumenten manchmal nicht aufgeschlossen. wie auch? schließlich hat so gut wie keiner mal gelernt, benutzeroberflächen zu gestalten. oder sich gestalten zu lassen. ich weiß nicht, wie es jetzt ist, aber zu meiner zeit (und kurz danach) war das in den vorlesungsplänen der informatiker eher nicht präsent.

denn: die allermeiste kommerzielle software wird ja genauso entwickelt. ist also so gesehen kein alleinstellungsmerkmal der open source. und unter der annahme, daß sich ein user zentrierter ansatz verbreiten würde, würde es dann ja wohl auch (endlich) gute kommerzielle software geben.

ganz selten gibts übrigens gegenbewegungen. sowohl kde als auch gnome als "gesamtprojekte" fahren zumindestens die klassischen usability labs - wenn auch auf die übliche "im nachhinein" art und weise. trotzdem besser als nix.

[Markus Breuer]

Auf, auf, ...
"scratch an itch" ist genau der Ansatz, der Klasse funktioniert, wenn Entwickler(gruppe) und Anwender(gruppe) nahezu identisch sind. Hier klappt Open Source super. Aber nicht, wenn Anwender - egal ob typisch oder nicht - nicht mit in der Entwicklergruppe sind. Charakteristisch für Open Source ist ja, dass es sogar schon sehr schwer bis unmöglich ist, Projekte zu initiieren, deren Zielgruppe nicht "Entwickler" sind. Da ist Closed Source/Commecial eindeutig vorn. Hier gibt es eine Motivation (Geld verdienen) etwas zu erstellen, das ich selbst vielleicht gar nicht nutzen werde. Mehr noch, obwohl ich es selbst nicht nutzen werde, möchte ich es für die Anwender möglichst gut machen.

Ob bei Open Source die Motivation "es Microsoft mal zu zeigen" ausreicht, ein besseres Word zu entwickeln, obwohl mir selbst eigentlich vi und LaTeX reichen (ok, jetzt werde ich gemein), gkaube ich nicht.

Ich überlege gerade, wo der Motivationshebel für ein freies Open-Source-Projekt wäre, mehr usercentered (mit Usern außerhalb des Entwicklerkreises) zu arbeiten. Wer lädt hier freiwillig einen DAU ein, der dem Team das Leben nur unnötig schwierig macht? Und warum? Schwierig! Vielleicht wirklich "besser sein", Ruhm und Ehre auch ausserhalb der Entwicklergemeinde (also mehr glückliche Nur-User). Ist gar nicht so einfach ...

BTW: typische Nutzer sind die Leute, denen ich das fertige Ding andrehen möchte. Wenn ich die auf eine oder mehrere "Persona"s zurückführen kann, habe ich typische Nutzer.