[ox-de] keimform.de: Selbstorganisierte Fülle (2): Voraussetzungen für erfolgreiche Peer-Produktion
- From: Christian Siefkes <christian siefkes.net>
- Date: Tue, 08 Jun 2010 14:18:08 +0200
URL: http://www.keimform.de/2010/selbstorganisierte-fuelle-2/
Faustregeln für die Zusammenarbeit
----------------------------------
Wir haben im ersten Teil
<http://www.keimform.de/2010/selbstorganisierte-fuelle-1/> 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 <http://de.wikipedia.org/wiki/Eric_S._Raymond>,
einer der ersten, der nicht nur selbst Freie Software
<http://de.wikipedia.org/wiki/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
<http://de.wikipedia.org/wiki/Gemeinschaftsgarten> heißt es, dass der
Garten frei zugänglich ist; bei Freien Funknetzen
<http://de.wikipedia.org/wiki/Freies_Funknetz>, 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
<http://de.wikipedia.org/wiki/Wiki> (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 <http://de.wikipedia.org/wiki/Wikipedia> gibt es außerdem
Listen gewünschter Artikel
<http://en.wikipedia.org/wiki/Wikipedia:Most_wanted_articles>, 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
<http://de.wikipedia.org/wiki/Linux>-Projekt, das ja eins der größten
Freien Softwareprojekte ist, gibt es ungefähr hundert solcher
Bereichsmaintainer/innen. Linus Torvalds
<http://de.wikipedia.org/wiki/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 <http://de.wikipedia.org/wiki/Debian>-Projekt, das rund um den
Linux-Systemkern ein komplettes Freies Betriebssystem mit vielen
Anwendungen zusammenstellt. Und beim Perl
<http://de.wikipedia.org/wiki/Perl_(Programmiersprache)>-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
<http://de.wikipedia.org/wiki/David_D._Clark>, einen der Hauptakteure in
der Internet Engineering Task Force
<http://de.wikipedia.org/wiki/Internet_Engineering_Task_Force>, die die
wichtigsten technischen Standards fürs Internet entwickelt. Clark sagte
<http://en.wikiquote.org/wiki/David_D._Clark#Sourced>:
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 <http://de.wikipedia.org/wiki/Abgeordneter>
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
<http://questioncopyright.org/minute_memes/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
<http://de.wikipedia.org/wiki/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 <http://de.wikipedia.org/wiki/Quelltext>
braucht, also zu der Version der Software, die Menschen erstellt haben
und verändern können. Deswegen wird Freie Software auch Open Source
<http://de.wikipedia.org/wiki/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
<http://de.wikipedia.org/wiki/Berkeley_Software_Distribution#Die_Projekte_NetBSD.2C_FreeBSD_und_OpenBSD>
und Apache <http://de.wikipedia.org/wiki/Apache_Software_Foundation>).
Anderen, wie dem GNU-Projekt <http://de.wikipedia.org/wiki/GNU-Projekt>,
ist es wichtig, dass nicht nur ihre eigenen Versionen, sondern *alle*
Versionen der Software frei bleiben. Dafür gibt es das Copyleft
<http://de.wikipedia.org/wiki/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
<http://catb.org/esr/writings/homesteading/cathedral-bazaar/>. Deutsche
Übersetzung: Die Kathedrale und der Basar
<http://gnuwin.epfl.ch/articles/de/Kathedrale/>.
[Wird fortgesetzt.]
--
|------- Dr. Christian Siefkes ------- christian siefkes.net -------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Peer Production Everywhere: http://peerconomy.org/wiki/
|---------------------------------- OpenPGP Key ID: 0x346452D8 --
If there is one conclusion to be drawn from the life of Leonardo, it is
that procrastination reveals the things at which we are most gifted -- the
things we truly want to do. Procrastination is a calling away from
something that we do against our desires toward something that we do for
pleasure, in that joyful state of self-forgetful inspiration that we call
genius.
-- W.A. Pannapacker, How to Procrastinate Like Leonardo da Vinci