Selbstorganisierte Fülle (2): Voraussetzungen für erfolgreiche Peer-Produktion

Faustregeln für die Zusammenarbeit

Wir haben im ersten Teil gesehen, warum Leute bei Peer-Projekten mitmachen oder neue Projekte gründen, aber das erklärt noch nicht, warum und unter welchen Umständen solche Projekte langfristig erfolgreich sind. Peer-Projekte unterscheiden sich schließlich sehr von dem, was man sonst so gewöhnt ist. In Firmen gibt es Bosse, Vorgesetzte, die ihren Untergebenen sagen, was zu tun ist; als Selbständige/r geht man Verträge ein, die eine/n verpflichten, dies oder jenes zu tun; auch in Schulen, beim Militär und in anderen offiziellen Institutionen gibt es immer Leute, die den Ton angeben, und andere, die folgen müssen.

Bei Peer-Projekten gibt es solche Strukturen nicht. Es gibt keine Bosse oder Vertragspartner, die den anderen mit Entlassung oder anderen finanziellen Konsequenzen drohen könnten; es gibt auch keine Lehrer/innen oder Offiziere, die eine/n bestrafen können, wenn man ihnen nicht gehorcht. Warum und unter welchen Umständen funktioniert also die Zusammenarbeit, wenn sie nicht durch Geld oder Zwang motiviert wird?

Für die erfolgreiche Zusammenarbeit gibt es einige Faustregeln. Erinnern wir uns zunächst, dass am Anfang jeder Peer-Produktion ein gemeinsames Ziel steht. Eric Raymond, einer der ersten, der nicht nur selbst Freie Software entwickelt, sondern auch darüber geschrieben hat, hat dazu gesagt: „Jede gute Software setzt an einer Stelle an, wo’s ihre Entwickler/in juckt“ (Raymond 2000, eigene Übersetzung). Man hat ein bestimmtes Bedürfnis, das man sich erfüllen möchte. Man hat ein Problem oder eine Vision, etwas das einen juckt, und sucht sich dann andere, die ungefähr dasselbe Problem haben, die ein ähnliches Ziel verfolgen. Man tut sich mit den anderen zusammen, um gemeinsam zu produzieren, was man haben oder erreichen möchte, denn gemeinsam kommt man besser und schneller zum Ziel.

Peer-Produktion basiert also auf dem Bedürfnisprinzip: die konkreten Bedürfnisse, Wünsche und Ziele der Beteiligten bestimmen was passiert, es geht nicht um allgemeine abstrakte Ziele wie das Geldverdienen oder um die bloße Umsetzung eines Planes, den andere gemacht haben.

Bei Peer-Produktion ist es leicht, die anderen zu verprellen, und wenn man die anderen verprellt, scheitert das Projekt. Wenn die Person, die ein Projekt gründet oder koordiniert (typischerweise „Maintainer/in“ genannt), es nicht schafft, mit den anderen richtig umzugehen, wird das Projekt mangels Beteiligung scheitern. Deshalb ist es wichtig, dass man fair ist zu den anderen. Man kann die anderen nicht als bloße Zuarbeiter/innen behandeln, wie man es vielleicht in einer Firma tun würde („das sind meine Angestellten, die sollen tun, was mir vorschwebt“). Vielmehr sind die anderen meine „Peers“, sie sind mir ebenbürtig, und sie werden nur kommen und bleiben, wenn ich das anerkenne.

Sie sind nicht dabei, weil sie müssen, sondern weil sie ähnliche Ziele haben wie ich. Wenn ich versuchen würde, die anderen herumzukommandieren, dann werden sie gehen. Ich habe keine Macht über sie, sie sind freiwillig da und entscheiden aus freien Stücken, ob sie blieben oder nicht. Man behandelt die anderen also nicht deswegen als ebenbürtig, weil man ein guter Mensch ist, sondern man hat gar keine andere Alternative – wenn man es anders macht, wird das Projekt scheitern.

Für jedes Projekt ist es wichtig, weitere Leute zu finden, die mitmachen, denn je weniger Beitragende es gibt, desto langsamer wird das Projekt vorangehen, und desto größer ist das Risiko, dass es irgendwann ganz einschläft. Deswegen muss man großzügig sein und teilen, was man teilen kann, denn je mehr Leute die Dinge nutzen, die man herstellt – also je großzügiger man teilt – desto mehr potenzielle Beitragende hat man. Erfahrungsgemäß wird nämlich ein gewisser Anteil der Nutzer/innen früher oder später zu Beitragenden, die sich aktiv an der Erreichung des gemeinsamen Ziels (beispielsweise der Weiterentwicklung der Software) beteiligen.

„Teilt was ihr könnt“ bedeutet bei digitaler Peer-Produktion, dass man die Software bzw. die Inhalte, die man entwickelt, als Gemeingüter freigibt, so dass alle sie nutzen können. Bei Gemeinschaftsgärten heißt es, dass der Garten frei zugänglich ist; bei Freien Funknetzen, dass das Funknetz ohne große Hürden von allen genutzt werden kann, die in Reichweite sind.

Der Übergang von Nutzer/innen zu aktiv Beitragenden ist fließend. Ein Großteil der Leute nutzt das Werk nur; manche tragen gelegentlich etwas bei, wenn ihnen z.B. etwas auffällt, was ihnen fehlt oder was nicht so ist, wie es sein sollte; nur ein kleiner Teil der Beteiligten engagiert sich regelmäßig und intensiv. Alle entscheiden selbst, ob und wie intensiv sie sich beteiligen, deshalb ist es wichtig, offen zu sein und niedrige Einstiegshürden zu haben. Damit ein Projekt floriert, muss man anderen sowohl die Nutzung der Projektergebnisse (denn wer nicht nutzt, wird vermutlich nie Beitragende/r werden) als auch die aktive Beteiligung leicht machen.

Niemand ist gezwungen, mitzuarbeiten, und niemand ist gezwungen, etwas Bestimmtes zu tun. Wie kommt es dann, dass Peer-Projekte trotzdem so oft erreichen, was Leute sich von ihnen versprechen? Wie wird das, was im Projekt passiert, mit den Bedürfnissen der Beteiligen – mit ihren Interessen und Wünschen in Hinblick auf das, was passieren soll – in Übereinstimmung gebracht?

Die Art, wie diese Vermittlung zwischen Bedürfnissen und Beteiligung zustande kommt, wird oft als Stigmergie bezeichnet. „Stigmergie“ kommt von dem griechischen Wort „stigma“, zu Deutsch „Zeichen“ oder „Hinweis“. Die Beteiligten hinterlassen also Hinweise darauf, was sie gerne hätten. Solche Hinweise sind in der Wikipedia und anderen Wikis (Wikis sind Webseiten, die alle editieren können) z.B. „rote Links“, die auf eine Seite zeigen, die es noch nicht gibt. Rote Links sind Hinweise für alle, die sich einbringen wollen, dass sich Leute einen Artikel wünschen, der noch geschrieben werden muss. In der Wikipedia gibt es außerdem Listen gewünschter Artikel, wo fehlende Artikel gesammelt werden, die an verschiedenen Stellen verlinkt sind – je öfter ein fehlender Artikel verlinkt wird, desto weiter oben in der Liste der gewünschten Artikel ist er zu finden, also desto deutlicher wird die Spur.

Bei Freier Software gibt es Ähnliches, beispielsweise Bugreports (Fehlerberichte), wo Leute melden: „hier funktioniert etwas nicht“. Je mehr Leute von einem Fehler betroffen sind, desto intensiver werden die Diskussionen um den Bugreport und desto sichtbarer wird der Bug. Eine andere Art von Hinweisen sind Feature Requests, wo Leute sagen: das ist ein fehlendes Feature, also eine bestimmte Funktionalität, die wir gerne sehen würden – es wäre schön, wenn das jemand schreibt. Außerdem gibt es To-Do-Listen, in die alles eingetragen wird, was noch geschehen soll. Das kann man als Notizen an die eigene Zukunft sehen, wo die Beteiligten sagen: „wenn wir dazu kommen, machen wir das“; aber häufig sind es eher Hinweise der Art: „wer weiß, ob und wann wir dazu kommen, uns darum zu kümmern – aber wenn sich jemand findet, die es umsetzt, werden wir es integrieren“.

Leute die in ein Projekt neu einsteigen, die beispielsweise den anderen etwas zurückgeben wollen, die also etwas beitragen wollen, aber noch nicht genau wissen wie, orientieren sich häufig an diesen Hinweisen. Ebenso wer eine bestimmte Aktivität abgeschlossen hat und nach neuen Aufgaben sucht. Auf diese Weise werden Bedürfnisse und Beiträge tendenziell in Einklang gebracht, ohne dass es einen Boss gibt, der sagt: „so du tust jetzt das“.

Peer-Produktion basiert auf vielfältigen flexiblen Projektstrukturen, die sich gemäß den Bedürfnissen der Beteiligten entwickeln. Das muss so sein, denn wenn sich die Beteiligten in den Strukturen nicht gut aufgehoben fühlen, werden sie gehen oder gar nicht erst kommen. In der Praxis werden dabei ganz unterschiedliche Lösungen gefunden. Sehr viele kleine Projekte kommen fast ohne Strukturen aus – da gibt es eine Person, die das Projekt gegründet hat und oft weiterhin die Entwicklung koordiniert. Wenn Leute etwas beizutragen haben, wenden sie sich an diese Person, die sogenannte „Maintainer/in“. Bei großen Projekten wird es komplexer, da gibt es neben der Hauptmaintainer/in oft eine Reihe von Bereichsmaintainer/innen, die sich um bestimmte Teilbereiche oder Aufgaben kümmern. Beim Linux-Projekt, das ja eins der größten Freien Softwareprojekte ist, gibt es ungefähr hundert solcher Bereichsmaintainer/innen. Linus Torvalds steht nach wie vor im Zentrum des Ganzen, entscheidet aber nur in wenigen Fällen selbst – meist vertraut er den Entscheidungen der zuständigen Bereichsmaintainer/innen.

Anderswo steht nicht eine langfristig aktive Maintainer/in im Zentrum, sondern eine Person oder eine Gruppe von Personen, die regelmäßig neu gewählt wird. Einen gewählten Projektleiter gibt es beispielsweise beim Debian-Projekt, das rund um den Linux-Systemkern ein komplettes Freies Betriebssystem mit vielen Anwendungen zusammenstellt. Und beim Perl-Projekt, einer wichtigen freien Programmiersprache, gibt es ein regelmäßig neu gewähltes Steuerungskomitee. Ähnlich bei der Wikipedia, die mittlerweile eine sehr komplexe Struktur hat, während die meisten kleinen Wikis sehr unkompliziert sind und weitgehend ohne formelle Strukturen auskommen. Je größer das Projekt, desto komplexer werden erfahrungsgemäß die Strukturen, die sich gemäß den Bedürfnissen der Beteiligten entwickeln.

Kommen wir nochmal zu der Frage zurück: Wie erreicht man es, dass Leute dabei bleiben, obwohl man sie doch nicht zwingen kann und sie in vielen Fällen nicht durch Geld motiviert sind? Dafür hat sich das Prinzip des groben Konsens etabliert: auch wenn es eine Maintainer/in, eine Koordinator/in gibt, kann diese nicht einfach willkürlich entscheiden, sondern muss sich darum bemühen, sich zumindest mit dem Großteil der Beteiligten zu einigen. Grober Konsens heißt nicht zwangsläufig, dass alle von der Entscheidung begeistert sind, aber zumindest, dass niemand oder kaum jemand vehement widerspricht. Die große Mehrheit der Leute muss mit der Entscheidung einverstanden sein. Das Erzielen eines groben Konsens, der dabei auch technisch sinnvoll ist und praktisch funktioniert, ist in den meisten Projekten das Ziel.

Die Bezeichnung „grober Konsens“ wurde bekannt durch David Clark, einen der Hauptakteure in der Internet Engineering Task Force, die die wichtigsten technischen Standards fürs Internet entwickelt. Clark sagte:

Wir lehnen ab: Könige, Präsidenten und Abstimmungen.
Wir glauben an: groben Konsens und lauffähigen Code.

Mit „lauffähiger Code“ ist dabei gemeint, dass was da entschieden wird, immer auch technisch sinnvoll sein muss. Wenn man sich für etwas entscheidet, was man nicht oder nur schlecht umsetzen kann, dann kommt kein lauffähiger Code dabei heraus. Deshalb geht es bei Entscheidungen auch immer darum, dass die gefundene Lösung technisch praktikabel und sozial sinnvoll ist.

Die Ablehnung von „Präsidenten und Abstimmungen“ soll klarmachen, dass auch da, wo Leute gewählt werden (wie bei Debian und Perl), sie nicht zu gewählten Repräsentant/innen werden, die machen dürfen, was sie wollen, und dabei nur ihrem Gewissen verpflichtet sind. Stattdessen geht es immer darum, dass die Projektbeteiligten mit den Entscheidungen zufrieden sind. Wenn das nicht der Fall ist, wird das Projekt früher oder später Probleme bekommen, weil immer weniger Beitragende dazukommen oder weil immer mehr der Beitragenden gehen und ihr eigenes Ding machen.

Das bringt uns zum letzten Punkt: Das Forken, also das Aufteilen eines Projekts in zwei Teile, ist ein gängiges Konfliktlösungsmuster, das als letzter Ausweg bleibt, wenn sich die Beteiligten nicht einigen können – sei es über die Ziele des Projekts oder über die Art, wie die Ziele erreicht werden sollen und wie sich das Projekt organisiert. Wenn sich ein Teil der Leute in dem Projekt fehl am Platz fühlt, können sie gehen und ihr eigenes Projekt aufmachen. Das ist eine durchaus etablierte und vorgesehene Weise, wie man solche Konflikte auflösen kann, ohne sich in endlosen Streitereien aufzureiben.

Oft geht nach einem Fork eins der Projekte ein, weil die meisten Beteiligten sich lieber dem anderen Projekt zuwenden. Manchmal bleiben beide Projekte dauerhaft als separate Einheiten bestehen; in anderen Fällen wachsen die Projekte später wieder zusammen, wenn die Ursachen der Spaltung überwunden werden konnten. Also auch ein Fork, eine Aufteilung, ist nicht unbedingt das Ende vom Lied.

Drei Freiheiten für alle

Ein wichtiges Element der Peer-Produktion ist das Kopieren. Dazu gibt es ein wunderschönes Video von Nina Paley: Copying Is Not Theft.

Hier der übersetzte Text:

Kopieren ist kein Diebstahl.
Diebstahl nimmt eines weg,
Kopieren macht aus einem mehr.
Dazu ist Kopieren da.

Kopieren ist kein Diebstahl.
Wenn ich von dir kopiere, hast du nichts verloren.
Eins für mich und eins für dich –
Kopieren macht das möglich.

Wenn ich dein Fahrrad klaue,
musst du den Bus nehmen.
Wenn ich es aber kopiere,
haben wir beide eins!

Mehr von etwas machen,
das nennen wir „kopieren“.
Ideen mit allen teilen –
darum macht Kopieren Spaß!

Kopieren ist eine geniale Sache: wenn ich etwas kopiere, nutzt das mir, ohne anderen zu schaden (zumindest in einer vernünftigen Gesellschaft, wo man nicht darauf angewiesen ist, andere von etwas auszuschließen, um sich den Lebensunterhalt zu sichern). Kopieren alleine reicht aber noch nicht, denn kopiert werden kann ja nur, was schon da ist. Wenn immer nur das Vorhandene eins zu eins kopiert würde, würde nie etwas Neues entstehen. Ebenso wichtig ist es daher, dass man die Dinge auch anpassen kann und darf.

Deswegen müssen bei Freien Werken (ob das Freie Software oder Freie Inhalte sind oder, was später noch Thema sein wird, Freie Baupläne und Konstruktionsbeschreibungen) neben der Freiheit zu kopieren immer noch zwei weitere Freiheiten gewährt werden:

1. Man muss das Werk verwenden können, wie man es möchte. Das klingt nach etwas Selbstverständlichem, aber bei proprietärer Software gibt es oft jede Menge Klauseln, die genau regulieren, was man machen darf und was nicht. Das liest zwar keine/r und in der Praxis werden solche Klauseln ignoriert, aber nominell gibt es jede Menge Einschränkungen. Bei Freier Software ist das nicht erlaubt.
2. Man muss das Werk auch verändern und den eigenen Bedürfnissen und Vorstellungen anpassen können. Dafür es es notwendig, dass man erstmal herausfinden kann, wie es funktioniert. Für Software bedeutet das, dass man Zugang zum Quellcode braucht, also zu der Version der Software, die Menschen erstellt haben und verändern können. Deswegen wird Freie Software auch Open Source genannt. Der Quellcode (Sourcecode) muss offen zugänglich sein, damit andere nicht nur das theoretische Recht, sondern auch die praktische Möglichkeit zum Ändern haben.
   Nur dadurch, dass man so neben dem bloßen Kopieren des Vorhandenen auch immer wieder neue, abgewandelte und verbesserte Werke schaffen kann, entsteht die Fülle, der Reichtum der digitalen Welt. Wer ein bestimmtes Bedürfnis hat, ein bestimmtes Ziel verfolgt, muss sich weder mit dem begnügen, was schon da ist, noch muss er oder sie bei Null anfangen. Stattdessen kann man auf Vorhandenem aufbauen, es erweitern und verbessern.
3. Die dritte Freiheit ist schließlich die schon thematisierte Freiheit des Kopieren und Verbreitens – das Recht, das Werk weiterzugeben und mit anderen zu teilen, ohne dafür irgendjemand um Erlaubnis fragen zu müssen.

Damit ein Werk frei ist, müssen diese drei Freiheiten nicht nur einzeln gelten, sondern auch in Kombination. Es muss beispielsweise möglich sein, ein Werk zu verändern und dann die geänderte Fassung an andere weiterzugeben. Tatsächlich wird bei Freier Software meist von vier Freiheiten gesprochen, wobei die vierte Freiheit diese Kombination der beiden vorigen ist: das Recht, veränderte Versionen zu verbreiten.

Die drei Freiheiten sind dabei keine bloßen Versprechen, die man nach Lust und Laune später wieder einschränken oder zurücknehmen kann. Es sind vielmehr unwiderrufliche Rechte, die allen Menschen für alle Zeiten eingeräumt werden, wenn ein Werk einmal unter diesen drei Freiheiten veröffentlicht wurde.

Doch was ist mit veränderten Fassungen, mit abgeleiteten Werken? Wenn ich ein Werk ändere, entsteht ein neues Werk, über das ich als Urheber zunächst verfügen kann. Ich könnte also sagen: „dieses neue Werk wird nicht freigegeben, das müsst ihr bei mir kaufen“. Manche Autor/innen Freier Software haben kein Problem damit, wenn andere mit abgeleiteten Fassungen ihrer Werke so umgehen (z.B. BSD und Apache). Anderen, wie dem GNU-Projekt, ist es wichtig, dass nicht nur ihre eigenen Versionen, sondern alle Versionen der Software frei bleiben. Dafür gibt es das Copyleft-Prinzip, das festschreibt, dass alle abgeleiteten Werke unter derselben oder einer sehr ähnlichen Lizenz stehen müssen wie das Original. Somit gelten die drei Freiheiten auch für alle Nutzer/innen von veränderten Fassungen.

Das oben gezeigte Video steht z.B. unter einer solchen Copyleft- oder Share-Alike-Lizenz: ich darf es verändern und ich darf die geänderte Version auch veröffentlichen, aber nur unter der Bedingung, dass ich allen anderen die drei Freiheiten einräume. Ich muss (zumindest bei Freier Software) anderen die Möglichkeit zum Verändern geben, d.h. den Zugang zum Quellcode, und ich muss allen das Recht zum Nutzen, Verändern und Weiterverbreiten geben. Somit ist die Freiheit solcher unter Copyleft stehender Werke nicht nur für das Original, sondern auch für alle Weiterentwicklungen gesichert.

Literatur

• Raymond, Eric (2000). The Cathedral and the Bazaar. Deutsche Übersetzung: Die Kathedrale und der Basar.