© Scott Rothstein, 123RF

FLOSS-Projekte sind weder Staaten noch Unternehmen, und doch müssen sie sich intern sinnvoll organisieren, um dauerhaft zu existieren. Good Governance, das richtige Regieren, ist gefragt. Wie haben die großen Projekte der Gegenwart das in den letzten 20 Jahren getan, was hat funktioniert – und was nicht?

Das Linux-Magazin hat in den letzten 20 Jahren viele FLOSS-Projekt begleitet und ihren Werdegang dokumentiert. Immer wieder ging es dabei auch um die interne Organisation der Projekte selbst. Denn obwohl Open Suse oder Debian – um nur zwei Beispiele zu nennen – weder Staaten noch Konzerne sind, brauchen sie eine sinnvolle Organisationsstruktur, die die Kooperation aller Beteiligten erst ermöglicht.

Die richtige Regierungsform will erst gefunden sein

“Governance” – das Wort steht für das Regieren, aber auch das intelligente Führen – mag in diesem Kontext sehr technokratisch klingen, trifft das Problem aber im Kern: Wie organisieren sich FLOSS-Projekte sinnvoll? Welche Hierarchie funktioniert in einem Netzwerk von Freiwilligen, ist eine Hierarchie überhaupt nötig oder funktionieren Laisser-faire-Ansätze genauso? Welche Rolle spielt im technischen Kontext das Thema Demokratie und wie lässt sie sich sinnvoll umsetzen?

Der folgende Artikel blickt zurück und stellt die Ansätze vor, die sich verschiedene Organisationen zu eigen gemacht haben. Was hat funktioniert, was nicht – und was ergibt sich daraus für junge Projekte, die vor den gleichen organisatorischen Herausforderungen stehen?

Linux – eine Diktatur mit Linus als Dictator for Life

Den Anfang macht fast zwangsläufig der Linux-Kernel selbst, auch weil gerade dieser im Grunde eine Anomalie innerhalb der Open-Source-Szene ist. Unabsichtlich ist es Linux-Erfinder Linus Torvalds gelungen, ein System auf Grundlage des BDFL-Prinzips zu gründen und erfolgreich zu betreiben. BDFL steht dabei für “Benevolent Dictator for Life” – gemeint ist ein zentraler Mäzen, eine Identifikationsfigur, die die Geschicke eines Projekts quasi im Alleingang betreut.

Das bedeutet aber keineswegs, dass jener Mäzen sich für seine Arbeit keine Helfer an Bord holen dürfe; schließlich sichtet Linus Torvalds schon seit langer Zeit nicht mehr jeden Codechange im Kernel selbst, bevor er ihn durchwinkt. Torvalds hat sich für diese Aufgabe ein ganzes Netzwerk an Subsystem-Maintainern organisiert, also Entwicklern, die sein uneingeschränktes Vertrauen genießen. In dieser Hinsicht trägt der Kernel Grundzüge einer Meritokratie, also einer Herrschaft derer, die sich in der Vergangenheit entsprechende Meriten erworben haben. Dennoch obliegt es Torvalds allein, richtungsweisende Entscheidungen für Linux zu treffen.

Hinzu kommt, dass der Finne in fast der ganzen FLOSS-Szene ohne jede Einschränkung als Autorität gilt. Das räumt ihm auch das Privileg ein, sich harsch und oft unangemessen gegen andere öffentlich zu äußern, ohne dafür getadelt zu werden. Torvalds Wutausbrüche auf der Linux-Kernel-Mailingliste sind legendär, auch auf Google Plus ist er sich für ordentliche Rants nicht zu schade.

Schlechte Umgangsformen

2012 empfahl er zum Beispiel den Entwicklern des Open-Suse-Projekts, sich selbst umzubringen, anstatt die Sicherheitsaspekte (etwa den Rootzugriff bei Netzwerkkonfigurationen) ihrer Distribution weiterhin so falsch zu handhaben [1]. Ausfälle dieser Art würden bei wohl jedem anderen Entwickler der FLOSS-Szene zum sofortigem Ausschluss aus allen Entwicklerkreisen führen. Nicht so bei Linus; ihm lässt man derartige Ausfälle durchgehen, auch das ist ein Grund für das Funktionieren des BFDL-Prinzips bei Linux.

Eine Anomalie ist der Linux-Kernel deshalb, weil das BDFL-Prinzip sich bei kaum einem anderen Projekt etablieren konnte. Ubuntu fällt hier noch am ehesten auf, denn ohne die Millionen von Mark Shuttleworth wäre Canonical undenkbar und mithin auch Ubuntu. Innerhalb des Projekts sind jedoch immer wieder kritische Stimmen zu hören von Menschen, denen die berüchtigten Shuttleworth’schen Hakenschläge missfallen, die vom Desktop über die Cloud gingen und derzeit die Smartphones in den Fokus rücken.

Mini-Universum Debian

Was machen nun also Projekte, die sich nicht auf einen BFDL berufen und stattdessen Strukturen aufbauen müssen, um die Entwicklung am Produkt sinnvoll zu steuern? Formidabel beantworten lässt sich diese Frage beinahe vollständig mit einem Blick auf das Debian-Projekt. Denn Debian ist in den vergangenen 20 Jahren stets an sich selbst gewachsen und hat es verstanden, Strukturen an das stetige Wachstum des Projekts anzupassen. Ein paar Daten zum Projektstart machen das deutlich.

War Debian 1993 nur ein kleines Projekt, gewann es sehr schnell die Sympathie weiterer Entwickler. Das lag auch daran, dass Debian – für heutige Verhältnisse unvorstellbar – damals das einzige Projekt war, das neue Entwickler willkommen hieß, ohne dabei eigene, kommerzielle Zwecke zu verfolgen. Debian-Gründer Ian Murdock hatte das System bewusst als offen und frei konzipiert, eine Eigenschaft, die die Förderung durch die FSF einbrachte.

Aber interessanterweise leitete der Deb-Ian das Projekt anfangs selbst im Stile eines BDFL, und als er 1996 Debian nicht länger als Projektleiter zur Verfügung stehen konnte, ernannte er einfach einen Nachfolger. Zwischen 1995 und 1998 verdoppelte sich die Zahl der aktiven Debian-Entwickler jährlich. Spätestens Ende 1997 sind die ersten Diskussionen auf den Projekt-Mailinglisten belegt, die eine stärkere Demokratisierung von Debian forderten.

Ein Projekt im Wandel

Unter Leitung von Ian Jackson entstanden zwei zentrale Dokumente des Projekts, die bis heute – wenn auch in veränderter Form – bei Debian gültig sind: die Verfassung des Debian-Projekts [2] sowie die Debian-Richtlinien für freie Software ([3], Abbildung 1). Nach den Regeln der noch nicht beschlossenen Verfassung stimmten damals 86 Entwickler ab, alle votierten zugunsten der Verfassung. Was zuvor ein Hobby-Projekt gewesen war, war damit erstmals institutionalisiert.

Abbildung 1: SPI ist die Not-for-Profit-Organisation, die Debian in den USA rechtlich vertritt.

Die Debian-Verfassung legte viele grundlegende Details fest, die das freie Projekt bis heute ausmachen. Der Debian Project Leader (DPL) ist beispielsweise von den Entwicklern per Schulze-Wahlverfahren direkt zu bestimmen. Auf dem Papier ist der DPL mit vielen Kompetenzen ausgestattet; beispielsweise obliegt es ihm allein, die so genannten Delegates zu ernennen, die ihm bei diversen Aufgaben behilflich sind. Anhand jener Delegates, die bereits in der Verfassung von 1998 vorhanden waren, lässt sich über die weiteren Jahre schön darstellen, wie Debian sich verändert hat.

Ursache für die sich stetig ändernde Projektstruktur war die wachsende Zahl von Projektmitgliedern, die sich als Fluch und Segen zugleich herausstellte. In den frühen Debian-Jahren war es nicht schwer, Mitglied von Debian zu werden und beispielsweise das Recht zu erhalten, Pakete in das offizielle Debian-Repository hochzuladen. Die Bekanntschaft mit einer Person, die bereits Mitglied war, stellte eine Eintrittskarte dar.

Der Erfolg macht manches komplizierter

Je größer Debian wurde, desto komplizierter war diese Vorgehensweise aber durchzuhalten. Also systematisierte Debian den New Maintainer Process, durch den sich fortan alle Mitgliedsaspiranten quälen mussten. Quälen vor allem deshalb, weil der Prozess streckenweise sehr langsam war: In Person von James Troup gab es nur einen Debian-Entwickler, der LDAP-Accounts für Mitglieder anlegen durfte. Der so genannte Debian Account Manager, kurz DAM, war indes ein DPL-Delegate. Es wäre den Projektleitern also durchaus möglich gewesen, neue DAMs zu ernennen.

Das NM-System blieb ein Nadelöhr, und im Jahre 2011 beschloss Debian per Generalabstimmung, neben dem “Developer”-Status auch den Status des “Debian Maintainers” einzuführen; dieser gesteht Entwicklern Upload-Rechte zu, ohne durch den NM-Prozess zu müssen – solange sich ein anderer Entwickler als Leumund findet.

Debian war doch immer offen für Neues

Viel hat Debian im Laufe der letzten 20 Jahre an den eigenen Statuten und der eigenen Arbeitsweise herumgeschraubt, nicht ohne Erfolg. War es in früheren Jahren stets ein einzelner Debian-Entwickler, der als Manager für neue Releases agierte, so ist diese Arbeit mittlerweile an ein ganzes Team aus Release-Managern und -Assistants ausgelagert.

Zwar waren über die Jahre die Debian Project Leader die Personen, die solche Änderungen letztlich vollzogen – beispielsweise indem sie neue Delegates ernannten. De facto ist Debian aber viel mehr eine Meritokratie als ein ausschließlich demokratisches Projekt. Wer über längere Zeit erfolgreich dem Projekt bei der Organisation seiner Geschicke hilft, darf sich Hoffnung auf höhere Weihen machen.

Der Debian-Entwickler Andreas Barth ist dafür ein gutes Beispiel. Im Jahre 2004 stieg er bei Debian ein, bald darauf begann er bereits, sich an der Arbeit rund um Debians Release-Management zu beteiligen. Mittlerweile ist er festes Mitglied des Release-Teams. Für Barth spielen dann auch gerade die Änderungen beim Management von Releases eine wichtige Rolle: “Das Thema Releases ist ja deutlich gereift. Vor einigen Jahren gab es große Unsicherheit, ob und wie es bei Debian überhaupt weitergeht – es stand die Aussage im Raum, Debian könne gar nicht mehr releasen, weil sich alles immer verzögert.”

Falsche Wahrnehmung

Beide Aussagen, so Barth, hätten sich als falsch herausgestellt, und zwar maßgeblich deshalb, weil das Release-Management aus den Händen einer Einzelperson (damals Anthony Towns) in die Verantwortung des Release-Teams überging. “Hinzu kamen im Laufe der Jahre viele Details, die das Releasen einfacher machen: Eine verbesserte Toolchain, der Transition-Tracker [für Updates von Bibliotheken, Anm.], viele Rewrites – all das machte das Release-Team deutlich effizienter.”

Debian schaffte es immer wieder, die eigenen Abläufe und Prozesse zu hinterfragen. Davon zeugen auch die berüchtigten Diskussionen auf verschiedenen Mailinglisten. So mancher Entwickler vergreift sich in hitzigen Diskussionen im Ton. Wenige Projekte streiten so verbissen wie Debian. Diskussionen ziehen sich häufig über viele Bildschirmseiten hin.

Um den immer heftiger verlaufenden Ausläufern bei Diskussionen einen Riegel vorzuschieben, beschloss Debian schließlich einen Verhaltenskodex für Mailinglisten – und zwar, wie sollte es anders sein, per Generalabstimmung [4].

Die unangenehmen Themen Geld und Recht

Ein Thema, mit dem sich FLOSS-Projekte in den vergangenen 20 Jahren immer wieder herumschlagen mussten, ist das Geld. Als ebenso anstrengend erweisen sich rechtliche Streitigkeiten. Beide Problemkomplexe suchen FLOSS-Projekte in schöner Regelmäßigkeit heim, aber in den vergangenen Jahren haben sich mehrere Ansätze herausgebildet, um ihrer Herr zu werden.

Als Schnittpunkte zwischen Softwareprojekten und der “echten Welt da draußen” kommt ihnen ja auch besondere Bedeutung zu: Wer etwa einem FLOSS-Projekt etwas spenden möchte, will das oft in Form von steuerbegünstigten Zuwendungen tun. Die meisten Staaten sehen für diese Art von Spende allerdings zwingend vor, dass die empfangende Partei selbst eine Eigenschaft als Rechtskörper aufweist.

Das Gleiche gilt, wenn ein Projekt vor Gericht gegen andere Projekte oder Unternehmen vorgehen will – eine Klage kann vor hiesigen Gerichten nur eine natürliche oder eine juristische Person einreichen, die meisten FLOSS-Projekte sind aber weder noch. Exemplarisch steht dafür Harald Weltes Privat-Engagement gegen GPL-Verletzungen, zum Beispiel in den Firmwares verschiedener Router (siehe Artikel “Recht und Freiheit” im Titelthema).

NPO und Stiftungen

Ein tragfähiges Konzept für große Projekte bieten solche Einzelkämpfer aber nicht. Zwei alternative Ansätze haben sich in den vergangenen Jahren als die tragfähigsten herausgestellt, wobei sich die Konzepte sehr ähnlich sind: Auf der einen Seite stehen Non-for-Profit-Organisationen nach US-Recht, auf der anderen Seite Stiftungen.

Das bekannteste Beispiel für eine Non-for-Profit-Organisation dürfte wohl Software in the Public Interest Inc. (SPI) sein, das Debian-Entwickler vor etlichen Jahren gegründet haben und seither auch betreuen. SPI kümmert sich für Projekte sowohl um (zweckgebundene) Spenden als auch darum, sie im Falle eines Falles rechtlich zu vertreten.

SPI fungiert dann als offizieller Vertreter, ist mit diesem aber keineswegs organisatorisch und rechtlich identisch. Genau das ist bei Stiftungen der Fall: Mozilla (Abbildung 2), Open Stack oder Open BSD sind nur einige Beispiele für Projekte, die in diversen Staaten Stiftungen eröffnet haben und über diese ihre offiziellen Belange regeln.

Abbildung 2: Die Mozilla Foundation betreut den Firefox, Netscape gab die Starthilfe vor rund zehn Jahren.

Natürlich wirkt sich die Organisation eines Projekts als Stiftung auch auf die internen Abläufe aus. Einen Königsweg gibt es jedoch nicht, wie das Beispiel der Mozilla Foundation, der Herstellerin des Browsers Firefox, zeigt. Bei ihr hat sich die Stiftungsstruktur auch unmittelbar auf den Alltag der Entwicklung in einem Projekt niedergeschlagen. Denn für die verschiedenen Mozilla-Komponenten gibt die Foundation die Marschroute vor. Seit beispielsweise 2013 die Stiftung beschloss, den Mailclient Thunderbird nicht weiter zu unterstützen, ist das Programm todgeweiht.

Open Stack: Es geht auch mit weniger Einfluss

Sowohl beim Linux-Kernel als auch bei Debian handelt es sich um von der Community getragene Projekte. Hier ist eine Entwicklergemeinschaft nicht nur beteiligt, die Entwicklung geht überhaupt erst von der Community aus.

Andere Projekte nutzen eine Stiftung ausschließlich als Vehikel für offizielle Anlässe, ohne dass diese sich einmischen darf. Open Stack ist dafür ein gutes Beispiel, denn hier beeinflusst die von diversen Konzernen getragene Foundation die Entwicklung kaum. Den Ausschlag geben vielmehr die Technical Project Leads, die für jede Release aus der Mitte der Community gewählt und eingesetzt werden; wahlberechtigt ist dabei jedes Mitglied des Projekts.

Mozilla, Red Hat, Open Suse: Gelenkte Communities

Eine andere Gründungsgeschichte hat die Mozilla Foundation: Fast zeitgleich mit Red Hat schuf sie 2003 ein Entwicklungs- und Governance-Modell, das sich bis heute als beständig und erfolgreich herausgestellt hat: gelenkte Communities. In beiden Beispielen, sowohl bei Red Hat als auch bei Mozilla, war nicht etwa edles Denken die treibende Kraft. Red Hat wollte 2003 ganz einfach die wachsende FLOSS-Community an der Entwicklung der eigenen Desktop-Distribution beteiligen und schuf das Fedora-Projekt, das seither die gleichnamige Linux-Distribution herstellt.

Im Falle von Mozilla hatte Netscape Communications 1998 einfach keine Lust mehr, den Navigator als eigenen Browser weiterzuentwickeln. Deshalb veröffentlichte man die Quellen des Browsers und gründete die Mozilla Foundation, die sich um die Entwicklung des Browsers im weiteren Verlauf kümmern sollte. Suse folgte mit Open Suse im Jahre 2004 und hatte ähnliche Interessen; nach der Übernahme durch Novell wollte sich der Konzern auf Enterprise-Linux festlegen und die Entwicklung der Basis an die Community auslagern (Abbildung 3).

Abbildung 3: Open Suse ist in den vergangenen Jahren durch einige Entwicklungen positiv aufgefallen, der Open Build Service ist sicher eine davon.

Drei Prototypen

Red Hat, Mozilla und Suse sind insofern Prototypen für das Prinzip der gelenkten Community. Red Hat und Suse unterstützen die jeweiligen Projekte offiziell in vielerlei Hinsicht, nämlich durch Geld, durch bezahlte Entwickler und durch die formale Absicherung, auch in rechtlicher Hinsicht.

Dennoch sahen und sehen sich Organisationen wie Suse und Red Hat mit einem Problem konfrontiert: Communities fallen nicht vom Himmel. Entwickler haben viele Gründe, sich an FLOSS-Projekten zu beteiligen. Sei es, dass sie das von ihnen mitentwickelte Produkt selbst kennen und nutzen (“Dog Fooding”) , sei es, dass sie sich zur Fortbildung mit einzelnen Programmen beschäftigen.

Oft stehen auch ideelle Motive im Vordergrund: Wer freie Software entwickelt, tut das meist aus Überzeugung für die Sache – und möchte im Gegenzug das Gefühl haben, von anderen anerkannt zu werden und zumindest grundlegende Mitbestimmungsrechte zu haben.

Ein nach dem Ubuntu-Prinzip verordnetes Projekt würde für Red Hat, Suse oder Mozilla kaum funktionieren, da viele Entwickler mit der Zeit das Interesse an der Mitarbeit verlieren würden. Weil das den großen Unternehmen klar war, brüteten sie relativ lange an einer Lösung und schufen schließlich in Form des Community-Managers eine völlig neue Jobbeschreibung.

Schall und Rauch

Bei Red Hat (für Fedora) wie auch bei Suse (für Open Suse) ist der Community-Manager seither eine feste Größe im Entwicklungsprozess. Denn er trägt maßgeblich die Verantwortung dafür, die Arbeit zwischen dem kommerziellen Linux-Hersteller und der Projekt-Community zu organisieren.

Hinzu kommt, dass sich Fedora und Open Suse sehr ähnliche Community-Strukturen verordnet haben, beide Projekte haben ein Board, also gewissermaßen einen Vorstand, dessen Mitglieder die Community zumindest zum Teil per Wahl bestimmt. Der Community-Manager hat in solchen Fällen auch die Aufgabe, mit den gewählten Entwicklergremien zusammenzuarbeiten.

Board, Community-Manager und Projektleiter

Es ist übrigens keineswegs so, dass der Community-Manager immer genau diesen Titel führen muss; Suse hat lange Jos Poortvliet beschäftigt, der jener Rolle seinen ganz eigenen Stempel aufgedrückt hat und das Berufsbild prägte. Bei Red Hat ist der Fedora Project Leader (FPL, Abbildung 4) de facto für die Agenda eines Community-Managers verantwortlich, auch wenn er diesen Titel nicht trägt. Er wird dennoch direkt von Red Hat bestimmt und steht auch auf der Gehaltsliste der Rothüte.

Abbildung 4: Matthew Miller ist der amtierende Fedora Project Leader und als solcher in der Rolle eines Community-Managers bei Red Hat.

Ganz gleich, ob gewählt oder bestimmt: Für Unternehmen, die mit FLOSS etwas werden wollen, hat sich die Position eines Community-Managers bewährt. Denn langfristig funktionieren solche Projekte nur, wenn sich eine Community um sie herum bildet, die eine konstante Zahl an Entwicklern aufweist. Damit das der Fall ist, müssen sich die Projektmitarbeiter allerdings wohlfühlen und den Eindruck haben, gebraucht zu werden. All das lässt sich offensichtlich von einem mit emotionaler Intelligenz und Sozialkompetenz ausgestatteten Community-Manager gewährleisten.

Neue Entwicklungen bei Open Suse

Der direkte Vergleich zwischen Open Suse und Fedora macht deutlich, dass die beiden Projekte durchaus unterschiedliche Werdegänge in den letzten Jahren hinter sich gebracht haben. Während Fedora wie beschrieben stark am Rockzipfel von Red Hat hängt, war bei Open Suse das Bestreben stets, unabhängiger vom Nürnberger Unternehmen Suse zu werden.

Der aktuelle Vorsitzende des Open-Suse-Community-Boards, Richard Brown, bestätigt das: “In den letzten Jahren haben wir uns viel Mühe gegeben, Verantwortlichkeiten von Suse weg und zu Open Suse hin zu verschieben. Die typische Aufteilung in Community oder Angestellte gefällt mir sowieso nicht, doch unabhängig davon ist es uns in immer größerem Ausmaß gelungen, als Projekt selbstständig zu werden.”

Während noch vor einigen Jahren ein großer Teil der geleisteten Arbeit für Open Suse von Suse-Mitarbeitern kam, stemmt nun die Community den großen Teil der Arbeit, erklärt er: “Außerdem konnten wir über viele großartige Projekte an Eigenständigkeit und Verantwortung dazu gewinnen: Den Open Build Service (Abbildung 3), Open QA, die neue Factory. Vieles davon basiert zwar auf Ideen, die Suse bereits hatte, doch gereift sind die meisten Werkzeuge erst im Rahmen der Open-Suse-Arbeit.”

Die Gegenwart: Turbo-Communities

Alle bis dato vorgestellten Community-Projekte zeichnen sich dadurch aus, dass sie entweder direkt aus der Community heraus entstanden sind oder sich durch ihre Kontinuität zu einem festen Bestandteil der Szene gemacht haben. Die ganz frisch gebildeten Hype-Communities unterscheiden sich von diesen Projekten deutlich.

Typische Beispiele für diesen Typ sind Open Stack oder Owncloud: Beide Projekte hatten nicht die Zeit, um organisch zu wachsen. Weil beide im Dunstkreis der Cloud existieren – dem Hype-Thema seit Jahren – müssen sie sich sehr flexibel und sehr anpassungsfähig zeigen. Das führt zwangsläufig dazu, dass sich auch die Community schneller entwickelt und insgesamt unverbindlicher ist.

Manch eingesessener FLOSS-Entwickler rümpft über Projekte wie Owncloud und Open Stack außerdem die Nase, weil die entstehenden Communities maßgeblich durch schnöden Mammon gelenkt sind, den große Unternehmen im Hintergrund bei den Projekten einwerfen. Ohne Support durch Intel, HP & Co. wäre Open Stack zum Beispiel sicher nicht dort, wo es heute steht, ebenso Owncloud ohne seine Millionen an Venture-Kapital. Und viele Entwickler dieser Szene machen ja gerade deshalb mit, weil sie für diese Aufgabe von ihren Arbeitgebern gut bezahlt werden.

Zwar bemüht sich gerade Open Stack darum, seine Community nach dem Vorbild anderer Projekte sinnvoll zu organisieren. Diverse Entwicklungen rund um die Open Stack Foundation zeigen aber, dass das Motto in Zukunft immer deutlicher “Pay-to-Play” lauten dürfte. Das Board der Open Stack Foundation besteht bereits jetzt aus einigen Mitgliedern, die sich eingekauft haben.

Fazit

Projekte wie Debian und der Linux-Kernel haben in den vergangenen 20 Jahren eindrucksvoll unter Beweis gestellt, wie sich Communities starten und dauerhaft sinnvoll organisieren lassen. Selbst wer nur ein kleines Projekt beginnt, kann sich auf einige Erfahrungswerte der großen Projekte verlassen.

Ähnliches gilt für jene Projekte, die zwar als Corporate-Spin-off angefangen haben, mittlerweile aber trotzdem etabliert sind: Die FLOSS-Community wäre ohne Fedora und Open Suse nur schwer vorstellbar. Dabei macht es interessanterweise gar keinen so großen Unterschied, wie die Projekte rechtlich aufgestellt sind: Das Prinzip der Stiftung, wie es bei Mozilla am Werk ist, fungiert grundsätzlich genauso wie das Spiel über Bande mit SPI, das unter anderem Debian und Gnome erfolgreich betreiben.

Doch zeigen insbesondere die letzten Jahre auch, dass sich gegenwärtig ein heftiger Wandel vollzieht, was FLOSS-Communities betrifft. Insbesondere neue Projekte dienen regelmäßig nicht mehr als Freizeitbeschäftigung für Enthusiasten, sondern werden von Unternehmen ins Leben gerufen – und sind mit entsprechenden Erwartungen an den Erfolg des Projekts verknüpft.

Ob Modelle wie die von Open Stack oder auch Owncloud langfristig funktionieren, muss sich erst noch herausstellen. So wie sich ebenfalls erst zeigen muss, ob aus jenen Communities Lehren für andere Projekte zu ziehen sind. Langweilig wird das sicher nicht, auch nicht in den nächsten 20 Jahren.