Aufgrund ihrer zufälligen Bildung und Existenz ist es schwierig, eine Freie Software-Gemeinde/ein Open Source-Projekt zu gründen und zu managen. Es passiert nicht zufällig, dass Zehntausende Projekte aufgegeben werden - es ist wie in der Chaos-Theorie: Kleine Anpassungen an die anfänglichen Bedingungen können über den Erfolg oder das Scheitern einer Freien Software-Gemeinde entscheiden. Dieser Artikel versucht, einige Anforderungen und kritische Phasen aufzuzeigen, denen sich jedes Unternehmen oder jede Person bei der Bildung einer neuen Gemeinde bewusst sein sollte.

Innovation wird von neuen Ideen angetrieben. In der Informationstechnologie werden Ideen oft durch das Entwickeln neuer Software verwirklicht. In diesen Tagen erwägen immer mehr Unternehmen oder Personen, ihre Ideen als Freie Software umzusetzen - was wahrscheinlich der Grund ist, warum Sie gerade diesen Artikel lesen. Bevor Sie jedoch Ihr eigenes Projekt starten, muss eine sorgfältige Planung durchgeführt werden. Als erstes sollten Sie überlegen, ob es eigentlich notwendig ist, ein eigenes Projekt zu beginnen, oder ob Sie besser zu einem bereits bestehenden beitragen. IBM hat sich beispielsweise zeitig entschieden, einen Open Source-Webserver zu entwickeln, aber anstatt einfach nur eine neue Software zu entwerfen und zu veröffentlichen, entschieden sie, dass es besser wäre, einen Blick auf Apache zu werfen, und halfen schließlich bei dessen Entwicklung aktiv mit.

In einem aktuelleren Beispiel hat sich Apple entschieden, seinen neuen Webbrowser Safari auf Basis von KHTML und KEcmaScript (Javascript-Support) zu entwickeln. Kurz nach Weihnachten 2002 hat Apple eine erhebliche Menge Patches mit sehr detaillierten Erklärungen zum KHTML-Code beigesteuert, die bis jetzt noch eingepflegt werden. Sowohl der Beitrag von IBM als auch der von Apple wurden sehr gut aufgenommen und die Änderungen gewannen sofort viel positive Kritik von den ursprünglichen Entwicklern. Die Beisteuerung zu bestehenden Projekten hat viele Vorteile, besonders für Unternehmen und Personen, die noch nicht viel Berührung mit Freier Software hatten, da es eine reichliche Menge Gemeindeerfahrung erfordert, bevor man selbst eine Gemeinde organisieren und führen kann.

Okay, gehen wir jetzt mal davon aus, dass Sie entschlossen sind, ein eigenes Projekt zu starten. Die Gründe dafür können sehr verschieden sein. Oft entwickeln Unternehmen neue Software, weil sie versuchen, eine neue Idee oder eine bestehende Idee in einer neuen Weise zu implementieren. Ihr Ziel besteht darin, Akzeptanz für ihre Software auf breiter Ebene zu erreichen und der Marktführer in ihrem Bereich zu werden. Ein gutes Beispiel ist Netscape, die Mozilla entwickelt haben, um der Defacto-Webbrowser einer neuen Generation zu werden. Einzelpersonen dagegen starten meist neue Projekte in Freier Software, um ein Äquivalent für eine bestehende, herstellergeschützte Lösung zu entwickeln. Sie bauen aber oft nur ein Produkt mit den Funkionen, die sie benötigen, zusammen; Beispiele sind Gaim und MPlayer.

Bevor wir direkt in die einzelnen Schritte und Herausforderungen für das Starten einer neuen Gemeinde eintauchen, sollte ich eine kurze Erklärung abgeben. Obwohl diese Art von Gemeinden auch für freie Musik und Bücher (z.B. Dokumentation) gilt, werde ich mich speziell auf die Gründung eines Software-Projektes konzentrieren. Außerdem ist das hier Beschriebene nicht der einzige Weg, der zu einem erfolgreichen Software-Projekt führt, sondern spiegelt meine Erfahrungen darüber, was funktioniert und was nicht, wieder. Im nächsten Abschnitt des Artikels richtet sich das Augenmerk auf die Schritte, die ein Unternehmen oder eine Person nehmen sollte, um ein Projekt zu starten. Im abschließenden Teil werde ich dann einige der allgemein bekannten Missverständnisse, die in Unternehmen vorliegen, ansprechen und aufzeigen, wie diese am besten vermieden werden.

Rezept für den Start
Der Beginn eines Projektes ist der Schlüssel zum Erfolg. Eine umfangreichere Planung am Anfang kann den entscheidenden Unterschied bedeuten, genauso wie die anfänglichen Bedingungen einer Differentialgleichung sehr unterschiedliche Langzeitergebnisse produzieren können (denken Sie an die Chaos-Theorie). Einige mögen glauben, dass es das Richtige ist, mit dem Schreiben von Code zu beginnen und diesen dann herauszugeben, sodass andere einen Blick darauf werfen können - ich möchte Sie davor warnen. Nehmen wir mal an, dass Sie einfach mit dem Coden eines Prototypen beginnen und dieser sehr gut aufgenommen wird. Viele Leute werden also einen Blick darauf werfen und sich an dem Projekt beteiligen wollen. Aber sobald sie bei der Entwicklung helfen wollen, stoßen sie an eine Grenze, da es überhaupt nicht klar ist, wie es von hier aus weitergehen soll. Normalerweise beginnt dann eine große Debatte und Leute können das Projekt verlassen und niemals zurückkehren oder die Entwicklung der Code-Basis spaltet sich. Sie werden mir zustimmen, dass wir diese Situation nicht wollen. Deshalb ist es viel besser, sich nur mit wenigen Leuten zusammenzusetzen und ein paar Anfangsideen auszuarbeiten.

Der erste Schritt besteht in der Definition der Ziele und gewünschten Funktionen Ihrer Software. In Abhängigkeit vom Typ des Projektes (Bibliothek, Command Line Tool oder GUI-Anwendung) kann diese Diskussion sehr unterschiedliche Formen annehmen. Für Endnutzeranwendungen ist es gewöhnlich sehr hilfreich, einige anfängliche Fallstudien zu entwickeln und herauszufinden, was die identifizierten Nutzer wirklich brauchen. Für Bibliotheken auf der anderen Seite ist es angemessener, ein Set von gewünschten Funktionen festzulegen und Verweise auf alle Standards, die in der Bibliothek implementiert werden, zu erstellen, sodass alle hinzukommenden Entwickler einen Ansatzpunkt haben. Zu Ihrem eigenen Wohl sollten Sie einen provisorischen Release-Plan mit einer Liste der Funktionen, die Sie für jedes Release fertig stellen möchten, erstellen. Berücksichtigen Sie in dieser Stufe den Gemeindeeffekt nicht, d.h. nehmen Sie an, dass nur das anfängliche Team an der Software arbeitet. Jede Hilfe der Gemeinde wird als Bonus betrachtet.

Die nächste Aufgabe ist es, sich über das Timing der Veröffentlichung Gedanken zu machen - Ihre erste große Entscheidung unter dem Gesichtspunkt der Gemeinde. Ein erster Ansatz besteht darin, frühzeitig zu veröffentlichen, was bedeutet, dass Sie eine Bekanntmachung machen, sobald Sie die ersten Designdokumente oder den ersten Prototypen fertiggestellt haben. Dies hat den Vorteil, dass Sie die Idee frühzeitig vielen Leuten preisgeben und somit die Möglichkeit, dass sich Entwickler der Gemeinde anschließen, erhöhen. Außerdem können erfahrenere Leute Ihr Design beurteilen, bevor Sie viel Zeit verschwenden, weil Sie die falsche Richtung einschlagen oder weil Sie den richtigen Weg mit der Probe- oder Fehlermethode herausfinden wollen. Ich habe normalerweise diesen Ansatz für meine Produkte gewählt und hatte gemischte Ergebnisse; manchmal hat es funktioniert und ich erhielt frühzeitig viel Unterstützung und andere Male hat es buchstäblich das Projekt aufgrund von Desinteresse zerstört (was wahrscheinlich besser war). Der andere Ansatz besteht darin, Ihre Software nach der Entwicklung einer ziemlich stabilen Version mit einem respektablen Funktions-Set auf den Markt zu bringen. Der Vorteil ist, dass die Leute, die sich diese Software ansehen, positive Erfahrungen machen und nicht von einem halbfertigen Funktions-Set geplagt werden. Meine Erfahrungen haben gezeigt, dass oftmals zu fehlerhafte oder unvollständige Software frühe Anwender abschreckt, die nie wieder zurückkommen, um die Software neu zu bewerten. Es gibt viele Produkte in der Zope-Gemeinde, die sehr spät freigegeben wurden, und großen Erfolg hatten, da die Software sofort out-of-the-box verwendbar war. Ein gutes Beispiel ist das CMS Silva, zu dem seit dem ersten Release viele Beiträge gemacht wurden, die fehlende Funktionen implementieren. Obwohl beide Ansätze ihre Licht- und Schattenseiten haben, werde ich in diesem Artikel nur den ersten Ansatz darlegen, da dieser mehr Disziplin, Organisation und Führung vom Projektinitiator erfordert.

Nachdem wir jetzt eine Vorstellung haben, was wir machen wollen und wie wir die Entwicklung angehen, ist es nun sehr wichtig, die notwendigen Entwicklungstools vorzubereiten. Das bedeutendste Tool sind Mailing-Listen, die in jeder Gemeinde das Hauptkommunikationsmittel darstellen. Beachten Sie, dass Sie Kommunikationswege einrichten, die nicht davon abhängen, dass Leute zur gleichen Zeit an der Software arbeiten (Sie möchten ja Entwickler aus der ganzen Welt anziehen) und die einfach erweiterbar sind. Also ist ein traditionelles Meeting nicht die beste Alternative für die Kommunikation. Die nächste Software, die Sie einrichten sollten, ist ein Versionskontrollsystem wie CVS oder SVN. Es ist sehr wichtig, dass Sie ein Versionskontrollsystem auswählen, das leicht und frei zugänglich ist, sodass Entwickler es einfach herunterladen und installieren können. Wenn sie ein herstellergeschütztes oder nicht weit bekanntes Versionskontrollsystem wählen, dann erhöhen Sie bedeutend die Einstiegsschwelle für neue Entwickler und es könnte letzten Endes das Scheitern Ihres Projektes verursachen. Zur Zeit ist CVS das am besten bekannte Versionskontrollsystem und alle Linux-Distributionen werden damit geliefert. Es wird außerdem von Sourceforge und den meisten der großen Freien Software-Gemeinden verwendet, sodass es sehr wahrscheinlich ist, dass Entwickler bereits mit dieser Software umgehen können. Ein Newcomer in der Szene ist SVN, das einige der CVS-Probleme behebt, aber noch ziemlich unbekannt ist. Wir haben SVN bereits für die Zope 3-Entwicklung in Betracht gezogen und werden hoffentlich bald mit dessen Nutzung beginnen. Zwei weitere wichtige Kommunikationstools sind IRC (oder andere Chat-Programme) und eine Webseite, vorzugsweise so etwas wie ein Wiki, die von jedem leicht geändert werden kann. Eine detailliertere Analyse der Beziehungen zwischen diesen Kommunikationsmitteln ist in meinen Artikel Sozialdemokratische Anarchien (Linux Enterprise 10/2003) zu finden.

Im vierten Schritt geht es um die Dokumentation und Diskussion des Software-Designs. Denken Sie daran, dass Dokumentation unglaublich wichtig ist - den meisten Freien Software-Projekten fehlt es an guter Dokumentation - da sie ein Teil Ihrer Kommunkation mit anderen Entwicklern ist. Kommunikation ist der Schlüssel zu Ihrem Erfolg und dem Erfolg Ihres Projektes. Sie sind für die Führung und Steuerung der Gemeinde in die Richtung, die Sie sich vorstellen, verantwortlich. Ein starker Führer zu sein ist sehr wichtig, denn zu viele Köche verderben den Brei. Dies bedeutet jedoch nicht, dass Sie auf keinen anderen hören sollen und keinem anderen erlauben sollen, Entscheidungen zu treffen.

Während Sie diese organisatorischen Aufgaben erledigen, sollten Sie auch eine Art Entwicklungsprozess und Checkin-Regeln definieren. Es ist eine gute Idee, sich mit Konzepten wie Rational Unified Process (RUP), eXtreme Programming (XP), Catalysis, Agile Development und anderen vertraut zu machen. In der Zope 3-Gemeinde verwenden wir eine Mischung aus RUP und XP. Von RUP nehmen wir Fallstudien und ein bisschen vom UML-Modeling (hauptsächlich Sequenz-Diagramme) und von XP übernehmen wir die Konzepte von Sprints, Unit-Tests und erbarmungslosem Refactoring, welche wir *geddons nennen (der Stern wird mit einem kurzen Titel des zu verändernden Codes ersetzt).

Der Entwicklungsprozess wird dann von Ihren Checkin-Regeln wiedergespiegelt. Das KDE-Projekt beispielsweise verwendet keinen testgesteuerten Entwicklungsprozess und befasst sich mit Bugs und Problemen erst, wenn sie auftreten. Das bedeutet, dass der HEAD des CVS von sehr stabil auf nicht nutzbar umschwenken kann (wie es der Fall in der Woche nach der Kastle-Konferenz war). Zope 3 auf der anderen Seite sieht den HEAD jederzeit als stabil an und alle Tests müssen bestehen, sodass jemand, der an einem Stück Code arbeitet, niemals von einer kaputten Funktion in einem anderen Teil des Baumes überrascht wird. Branches (Verzweigung vom HEAD) werden von Leuten dann verwendet, wenn zusammen an Aufgaben gearbeitet wird, die höchstwahrscheinlich einige Tests nicht gleich bestehen werden. Ein gutes Beispiel dafür ist das Beheben von Bugs. Eine Person, die einen Fehler findet, ist oft nicht in der Lage, diesen selbst zu korrigieren. Aber er/sie kann den Bug normalerweise nachbilden und einen Test schreiben, der den Fehler demonstriert. Eine andere Person mit dem entsprechenden Wissen kann dann den Bug beheben, sodass der Test bestanden wird. All dies wird gewöhnlich in einem Branch vorgenommen, sodass die Tests des HEADs nicht zeitweilig kaputt sind. Durch die Anwendung dieses Models hat Zope 3 selbst während der Pre-Alpha-Entwicklungsphasen eine unglaubliche Stabilität erreicht. Instabilität wird gewöhnlich nur von unzureichenden und fehlenden Tests verursacht!

Nachdem nun die ganze administrative Arbeit erledigt ist, können wir endlich mit dem Coden beginnen. Sie können entweder anfangen, an der Software selbst zu arbeiten oder einen Wegwerf-Prototypen schreiben, wie es XP vorschlägt. Prototypen haben den großen Vorteil, dass sie ein schneller und schmutziger Hack sein können, der einige der anfänglichen Ideen und Funktionen demonstriert. Ich bin der Meinung, dass dies sehr wichtig ist, da es mögliche Mitwirkende neugierig auf das Projekt macht. Außerdem ist es manchmal einfach nicht möglich, es das erste mal richtig hinzukriegen. Ich habe zum Beispiel ein Projekt begonnen, bei dem ich den Prototyp-Ansatz verwendet habe, und hatte eine großartige Resonanz und Leute begannen, zum Projekt beizutragen. Dann dachte ich: Okay, jetzt habe ich den richtigen Schwung, also lasst es uns auf die richtige Art und Weise machen. Unglücklicherweise haben die Leute den neuen Ansatz nicht verstanden und deshalb das Projekt verlassen, sodass es schließlich gestorben ist. In diesem Fall wäre es viel besser gewesen, weiterhin zum Prototypen hinzuzufügen und kleinere Dinge je nach Notwendigkeit neu zu schreiben.

Ein abschließender, wichtiger Anfangsfaktor ist die öffentliche Bekanntmachung des Projektes. Je mehr Lärm Sie machen, umso besser. Das ist die Zeit, in der Sie Ihre Public Relations-Fähigkeiten glänzen lassen können. Stellen Sie sich nur vor, wie viel Aufsehen und wie viele Downloads Ihr Projekt bekommen würde, wenn es als ein Newseintrag auf Slashdot gelistet wäre. Ok, ok, das scheint ein wenig unrealistisch. Aber wenn Sie Ihr Publikum effektiv ansprechen und mögliche Entwickler über Ihr Projekt informieren, wird dies die Chance, dass Sie Gemeindehilfe für Ihr Projekt bekommen, drastisch erhöhen.

Weitere Rahmenbedingungen
Normalerweise vernachlässigen Freie Software-Projekte und Gemeinden bestimmte Aufgaben wie Dokumentation und Internationalisierung/Lokalisierung (I18n/L10n). Dies liegt an der Tatsache, dass diese Aufgaben oft nicht von einem Software-Entwickler vollendet werden können, sondern verschiedene Fertigkeiten und daher verschiedene Freiwillige erfordern. Internationalisierung ist wahrscheinlich das offenkundigste Beispiel. Während ein Entwickler mit den zur Internationalisierung verfügbaren Tools und Bibliotheken vertraut werden und diese nutzen kann, wird er/sie definitiv nicht zur Lokalisierung (d.h. zur eigentlichen Übersetzung) der Software in alle gewünschten Sprachen in der Lage sein. Ein zweites Beispiel ist GUI und Grafikarbeit, welche besonders für Endnutzeranwendungen wichtig sind. Entwickler sind oft nicht gut darin, über die Bedürfnisse des Durchschnittsnutzers zu entscheiden, da sie selbst Power-Nutzer sind und die allgemeinen Muster auf sie nicht zutreffen.

Was bedeutet das für Ihr Freies Software-Projekt? Sie müssen Wege finden, um Nicht-Entwickler, wie Informationsarchitekten, Grafikdesigner, Autoren und Übersetzer so früh wie möglich in Ihre Gemeinde zu locken. Alle diese Leute sind rar und Sie sollten sie als einen Ihrer wertvollsten Werte in der Gemeinde ansehen. Denken Sie daran, dass ein Endnutzer, dem beim ersten Austesten der Software das UI nicht gefällt, höchstwahrscheinlich nicht so bald zurückkehren wird!

Ein anderes großes Problem ist die Dokumentation, die normalerweise bis zum Abschluss der ersten Entwicklung herausgezögert wird. Sie sollten diese Situation vermeiden. Es gibt mehrere Wege, beim Coden zu dokumentieren und von Anfang an eine aktuelle API-Dokumentation zu erstellen. In den frühen Zeit von Zope 2 war die fehlende Dokumentation der Hauptgrund für negative Kritik, da es für hinzukommende Gemeindemitglieder schwer war, einen Überblick über die verfügbaren Funktionen zu erhalten und überhaupt zu verstehen, wo man anfangen sollte. Ich erinnere mich noch an meine erste Stunde mit Zope; ich installierte es und startete das Web-Interface und dann fragte ich mich Und was jetzt?.

In Zope 3 haben wir versucht, diese steile Lernkurve für den Entwickler zu vermeiden. Zum Beispiel begannen wir, Schnittstellen (Interfaces) sehr stark zu nutzen, um klare APIs zu definieren. Wir nutzen auch unsere Schnittstellenerklärungen, um die hauptsächliche API-Dokumentation zu erledigen. Wenn Sie zu einer Schnittstellendatei gehen, können Sie die Dokumentation für jede Klasse, Methode oder jedes Attribut lesen. Es ist nicht immer einfach, diese Art der API-Dokumentation sofort zu schreiben, aber es ermöglicht uns, Unit-Tests basierend auf Dokumentation und nicht auf Code zu erstellen und Entwickler können leichter in unbekannte Teile des Frameworks einsteigen. Wir haben außerdem Tools, die lesbare Dokumentation für das Web-Interface und einfache Textdateien automatisch erzeugen. Eine andere Methode der Dokumentation ist eine tiefgreifendeAntragsmethodik. Vor der Durchführung einer wesentlichen Änderung oder vor der Implementierung einer neuen Funktion wird ein Antrag gestellt, den Entwickler genau überprüfen. Dieser Antrag und die damit verbundenen Kommentare eignen sich normalerweise sehr gut als anfängliche Dokumentation für die geänderte oder neue Funktionalität.

Wir haben auch damit begonnen, Newsletter für die allgemeine Gemeinde zu veröffentlichen, welche Zusammenfassungen von Entwicklern über Sachen, die seit dem letzten Newsletter gemacht wurden, beinhalten. Es hat sich herausgestellt, dass der Newsletter jetzt das Hauptkommunikationsmittel von Zope 3 für Gemeindemitglieder ist, die nicht am Zope 3-Entwicklungsprozess teilnehmen, was uns Feedback von Außenstehenden liefert. Ein letztes Stück Dokumentation, das wir sogar vor dem ersten Meilenstein-Release begonnen haben, ist ein detailliertes Tutorial (in Präsentationsformat) und ein Kochbuch für Entwickler. Das Tutorial ist ideal für Sprints, bei denen der Sprintmentor den Teilnehmern das Tutorial als Einführung präsentiert (oft sind Sprinter mit dem Framework nicht vertraut - es ist ihre erste Zope 3-Erfahrung). Das Rezeptformat des Kochbuchs erweist sich als eine sehr gute Wahl für eine sich noch entwickelnde Software, da jedes Rezept in sich abgeschlossen ist, was die Verwaltung einfach macht. Leute verwenden bestehende Kapitel des Buches aus verschiedenen Gründen, zum Beispiel um Zope 3 kennen zu lernen oder sich selbst mit einem Teil des Frameworks vertraut zu machen, den sie bisher noch nicht angeschaut hatten. Schon vor der ersten Beta (die noch nicht freigegeben ist), haben wir viele Kommentare von Lesern über das Buch erhalten, was dessen Qualität mit jeder Überarbeitung erhöht.

Auch ein gut gepflegtes Wiki unterstützt den Dokumentationsprozess und alles, das als Kommunikation betrachtet werden kann. Dies alles erfordert ein gutes Maß an Disziplin auf Seiten der Entwickler, aber es macht sich auf jeden Fall bezahlt. Es ist besser, langsamer zu entwickeln und dafür Dokumentation zu haben, anstatt eine Software schnell zu produzieren, die für den Nutzer nicht zugänglich ist.

Besondere Herausforderungen für Software-Händler
Unternehmen, die an herstellergeschützte Software gewöhnt sind, haben normalerweise gute betriebsinterne Kommunikationskanäle und Entwicklungsprozesse. Die meisten dieser Prozesse (Software-betriebene Qualitätskontrolle) funktionieren im allgemeinen jedoch nicht für Freie Software-Gemeinden. Dies liegt an der Tatsache, dass Freie Software-Entwickler keinen Zugang zu den benötigten Spezialtools haben. Sie sollten sich versichern, dass Sie Freie Software-Entwicklungstools verwenden, wenn Sie ein Freies Software-Projekt erschaffen. Außerdem ist ein Gemeindeentwickler nicht an Ihrem Geschäftsmodell interessiert und wird höchstwahrscheinlich Ihre Visionen und Ihre Aufregung in dieser Hinsicht nicht teilen. Entwickler sind in einer Gemeinde, weil die Software cool ist und sie an einem großen Projekt arbeiten wollen. Daher ist es von höchster Wichtigkeit, dass Sie Ihnen eine Vision geben, die von Ihren Unternehmenszielen losgelöst ist.

Ein weiterer wichtiger Punkt ist die Position, die Sie als erster Sponsor des Projektes einnehmen werden. Das schlimmste, das Sie machen können, ist, eine Diktatorrolle einzunehmen. Dies wird den Beteiligten die Lust an dem Projekt nehmen und niemals eine stabile Gemeinde schaffen. Betrachten Sie stattdessen den Fakt, dass Sie das initiierende Unternehmen sind, als ehrenwertes Privileg. Aber mit diesem Privileg kommt auch Verantwortung. Seien Sie ein guter Gastgeber! Je gastfreundlicher Sie sind, umso schneller wird die Gemeinde wachsen. Ein Aspekt, der direkt mit Ihrer Rolle verknüpft ist, ist die Gemeindehierarchie oder -struktur. Es gibt mehrere erfolgreiche Arten von Gemeindestrukturen, die umgesetzt wurden.

Die einfachste Form ist, einfach keine Struktur zu haben. Jeder Teilnehmer hat alle Rechte und gleiches Sagen. Dies ist gerade richtig für kleine Gemeinden mit bis zu ca. 20 Mitgliedern, aber für größere Projekte versagt diese Methode offensichtlich. Größere Gemeinden, die kein Unternehmen im Rücken haben, bilden normalerweise eine Hauptentwicklungsgruppe, die besondere Rechte hat und alle wirklich wichtigen Entscheidungen trifft (besonders die politischen). Die Art und Weise, wie man ein Hauptentwickler wird, variiert von eingeladen werden (einen Sponsor haben, wie es in der KDE-Gemeinde Brauch ist) bis hin zum vollständigen Selbst-Aufstieg, wobei man einfach so viel Zeit und Kraft in das Projekt investiert, dass man als ein Hauptentwickler akzeptiert wird. Einige Gemeinden haben auch einen Benevolent Dictator for Life (Wohltätigen Diktator fürs Leben), der einseitige Entscheidungsmacht und Vetorechte besitzt. Für Python ist diese Person Guido van Rossum und für Zope 3 ist es Jim Fulton, der scherzhaft Pope of Zope (Papst von Zope) genannt wird. Wenn diese Leute außergewöhnliche Entwickler sind, dann sind sie für die Gemeinde ein Segen, wie es in Python und Zope der Fall ist, aber das Konzept eines Diktators kann auch fehlschlagen und eine Gemeinde zerstören. Schließlich kann es für Freie Software-Gemeinden, die von Unternehmen geführt werden, eine gute Idee sein, ein gewähltes Führungskomitee einzusetzen. In diesem Fall sind Sie in der Lage, bestimmte Beschränkungen und Gesetzmäßigkeiten anzuwenden, die Sie von einem regulären Entwickler nicht verlangen möchten, was für einige sicherheitsbezogene Programme von Bedeutung sein könnte. Ein Führungskomitee ist auch dann eine gute Wahl, wenn eine Partnerschaft von mehreren Unternehmen, die eine Freie Software-Gemeinde leiten, vorliegt.

Zusammenfassend sollte sich ein Unternehmen nicht berechtigt fühlen, Gemeindemitglieder herumzukommandieren, sondern sich selbst als ein einzelnes Gemeindemitglied ansehen, das in der ehrenhaften Position des Projektinitiators ist. Wenn Sie weitere Fragen über das Starten einer Gemeinde haben, können Sie mich gerne per eMail unter stephan.richter@tufts.edu kontaktieren.