Unterschiedliche Rollen in Open-Source-Teams

Wenn ein Open-Source-Projekt wächst, kommen mehr Leute dazu und wollen mitmachen. Das ist super, aber irgendwann muss man sich überlegen, wie man das Ganze organisiert. Wer macht was? Wer hat das Sagen? Das ist gar nicht so einfach, denn die Strukturen können ganz unterschiedlich aussehen. Wir schauen uns mal an, welche Rollen es gibt und wie man das am besten regelt, damit das Projekt gut weiterläuft und alle wissen, wo sie dran sind. Es geht darum, wie man die Beteiligung fördert und gleichzeitig für klare Verhältnisse sorgt. Das ist wichtig für den Erfolg von rollen-open-source-teams.

Schlüsselpunkte zu rollen-open-source-teams

• In Open-Source-Projekten gibt es verschiedene Rollen wie Maintainer, Mitwirkende und Committer, die unterschiedliche Verantwortlichkeiten und Zugriffsrechte haben.
• Die Formalisierung von Führungsrollen hilft, Verantwortlichkeiten klar zu definieren und Mitwirkenden Orientierung zu geben, zum Beispiel durch Teamseiten oder Kernteams.
• Es gibt verschiedene Verwaltungsmodelle wie das BDFL-Modell, meritokratische Ansätze oder liberale Beitragsmodelle, die jeweils eigene Vor- und Nachteile haben.
• Die Dokumentation von Projektsteuerungsrichtlinien sollte frühzeitig erfolgen, um Erwartungen zu setzen und die Entwicklung des Projekts zu beeinflussen.
• Firmenbeiträge sind willkommen und werden nach technischen Kriterien bewertet, wobei bezahlte Entwickler keine Sonderbehandlung erhalten sollten.

Grundlegende Rollen in Open-Source-Teams

In jedem Open-Source-Projekt gibt es verschiedene Rollen, die dazu beitragen, dass alles reibungslos läuft. Diese Rollen sind nicht immer starr und können sich je nach Projektgröße und -kultur unterscheiden. Aber es gibt ein paar Kernrollen, die man fast überall findet.

Die Rolle des Maintainers

Ein Maintainer ist im Grunde die Person, die sich am meisten um die Richtung und Gesundheit des Projekts kümmert. Das bedeutet nicht immer, dass sie den ganzen Tag Code schreiben. Manchmal sind es Leute, die viel für die Öffentlichkeitsarbeit tun, die Dokumentation auf Vordermann bringen oder einfach dafür sorgen, dass das Projekt für neue Leute zugänglich ist. Sie fühlen sich verantwortlich und wollen das Projekt voranbringen. Sie sind oft die Ansprechpartner, wenn es um wichtige Entscheidungen geht.

Definition eines Mitwirkenden

Mitwirkende sind im Grunde alle, die dem Projekt auf irgendeine Weise einen Mehrwert bieten. Das kann jemand sein, der ein Problem meldet (ein Issue öffnet), einen Verbesserungsvorschlag macht (ein Pull Request erstellt), Code schreibt, der dann übernommen wird, oder sogar bei der Organisation von Veranstaltungen hilft. Die Definition kann breit gefasst sein, um möglichst viele Formen der Beteiligung anzuerkennen und zu fördern. Es ist wichtig, dass sich jeder, der etwas beiträgt, auch als Teil des Projekts fühlt. Die Gemeinschaft ist das Herzstück von Open-Source-Software.

Abgrenzung des Committers

Der Begriff Committer wird oft verwendet, um die Personen hervorzuheben, die tatsächlich die Berechtigung haben, Code direkt in das Haupt-Repository des Projekts einzufügen. Das ist eine spezifischere Rolle als die eines allgemeinen Mitwirkenden. Während viele Mitwirkende Ideen einbringen oder Code schreiben, der dann von anderen integriert wird, sind Committer diejenigen, die die Änderungen direkt vornehmen können. Diese Unterscheidung hilft dabei, die Verantwortung für den Code klar zu regeln und wer die finale Entscheidung über die Aufnahme von Änderungen trifft.

Formalisierung von Führungsrollen

Strukturierung von Verantwortlichkeiten

Wenn ein Open-Source-Projekt wächst, wird es wichtig, wer was macht. Das ist nicht nur gut für die Organisation, sondern hilft auch den Leuten, die mitmachen wollen. Man kann sich das wie ein kleines Team vorstellen, das ein Haus baut. Am Anfang machen alle alles, aber irgendwann braucht man jemanden, der sich nur um die Elektrik kümmert, und jemand anderen, der das Dach macht. Genauso ist es in Open-Source-Projekten. Klare Rollen helfen dabei, dass sich jeder weiß, an wen er sich wenden kann, wenn er Fragen hat oder Hilfe braucht.

• README-Datei: Für kleine Projekte reicht es oft, die Namen der Hauptverantwortlichen einfach in die README-Datei zu schreiben. Das ist schnell gemacht und jeder kann es sehen.
• Teamseiten: Wenn das Projekt eine eigene Website hat, ist es eine gute Idee, dort eine eigene Seite für das Team einzurichten. Dort kann man dann die Namen und vielleicht sogar kurze Beschreibungen der Leute auflisten, die bestimmte Aufgaben übernehmen. Das macht es noch übersichtlicher.
• Kernteams und Gremien: Bei größeren Projekten mit vielen Mitwirkenden kann man sogar spezielle Teams bilden. Zum Beispiel ein Team, das sich nur um Sicherheit kümmert, oder eines, das sich um die vielen offenen Anfragen kümmert. Das Tolle ist, dass sich die Leute oft selbst für die Bereiche melden, die sie am meisten interessieren. Das sorgt dafür, dass die Arbeit gut verteilt wird und jeder Spaß an seiner Aufgabe hat.

Die Formalisierung von Führungsrollen ist kein Selbstzweck. Sie dient dazu, die Zusammenarbeit zu erleichtern, die Verantwortlichkeiten klar zu definieren und die langfristige Gesundheit des Projekts zu sichern. Es geht darum, Strukturen zu schaffen, die es neuen und bestehenden Mitwirkenden ermöglichen, sich effektiv einzubringen und das Projekt gemeinsam voranzubringen.

Verwaltungsstrukturen für Open-Source-Projekte

Wenn ein Open-Source-Projekt wächst, braucht es eine Struktur, die entscheidet, wie Dinge laufen. Das ist nicht immer einfach, und es gibt verschiedene Wege, wie das gemacht werden kann. Manche Projekte haben eine Person, die das letzte Wort hat, andere setzen auf die Weisheit der Gruppe. Es ist wichtig, dass diese Strukturen klar sind, damit jeder weiß, wer was entscheidet.

Das BDFL-Modell

Das BDFL-Modell, kurz für "Benevolent Dictator for Life", ist eine Struktur, bei der eine Person, oft der ursprüngliche Schöpfer des Projekts, die endgültige Entscheidungsgewalt hat. Das kann sehr effizient sein, besonders in der Anfangsphase eines Projekts, wenn schnelle Entscheidungen getroffen werden müssen. Python ist ein bekanntes Beispiel dafür. Bei kleineren Projekten mit nur wenigen Beteiligten ist das oft die natürlichste Form der Verwaltung. Aber auch größere Projekte, die von Unternehmen unterstützt werden, können unter diesem Modell laufen, wenn eine bestimmte Person die Hauptverantwortung trägt.

Meritokratische Ansätze

Bei einem meritokratischen Ansatz werden Entscheidungsbefugnisse an diejenigen vergeben, die sich durch ihre Beiträge bewiesen haben. Das bedeutet, wer viel und gute Arbeit leistet, bekommt mehr Mitspracherecht. Die Apache Foundation nutzt dieses Modell, und dort sind alle Beiträge als individuelle Leistungen zu sehen, nicht als Beiträge im Namen eines Unternehmens. Entscheidungen werden oft durch Konsensfindung getroffen, was bedeutet, dass die Meinungen aller gehört werden, bevor eine Entscheidung fällt. Es ist ein System, das auf Leistung basiert, aber manchmal auch kritisch gesehen wird, weil es soziale Dynamiken beeinflussen kann.

Liberale Beitragsmodelle

Ein liberales Beitragsmodell konzentriert sich auf die aktuelle Leistung und den Beitrag, den jemand leistet, anstatt auf eine lange Historie. Hier zählen die Ideen und die Arbeit, die gerade jetzt wichtig sind. Wichtige Entscheidungen werden durch Diskussion und Konsens getroffen, wobei versucht wird, möglichst viele Stimmen aus der Community einzubeziehen. Projekte wie Node.js und Rust nutzen solche Modelle. Das Ziel ist, eine breite Beteiligung zu fördern und sicherzustellen, dass viele Perspektiven gehört werden, was zu robusteren Entscheidungen führen kann.

Die Wahl der richtigen Verwaltungsstruktur ist kein einmaliges Ereignis, sondern ein Prozess, der sich mit dem Projekt entwickelt. Es ist gut, frühzeitig über die Grundprinzipien nachzudenken, aber die genaue Ausgestaltung ergibt sich oft erst aus der gelebten Praxis der Community.

Zeitpunkt der Dokumentation von Projektsteuerung

Wann genau sollte man die Regeln für die Projektsteuerung festlegen? Nun, es gibt keinen perfekten Zeitpunkt, aber es ist oft einfacher, wenn man schon ein bisschen gesehen hat, wie die Community so tickt. Das Tolle und gleichzeitig Schwierige an Open-Source-Projekten ist ja, dass die Gemeinschaft die Richtung mitbestimmt! Wenn Sie frühzeitig dokumentieren, was Sie wissen, helfen Sie auch dabei, wie sich Ihr Projekt entwickelt. Das bedeutet, dass Sie schon zu Beginn klare Erwartungen formulieren können, wie die Mitwirkung ablaufen soll.

Wenn Ihr Unternehmen ein Open-Source-Projekt startet, ist es sinnvoll, vorher intern zu sprechen. Was erwartet Ihr Unternehmen von der Pflege und den Entscheidungen rund um das Projekt? Vielleicht möchten Sie auch öffentlich klarstellen, ob und wie Ihr Unternehmen involviert ist. Das hilft, Missverständnisse zu vermeiden und schafft Transparenz für alle Beteiligten. Eine gute erste Anlaufstelle für solche Überlegungen ist die Definition eines klaren Projektziels.

Frühe Erwartungsdefinition

Schon ganz am Anfang eines Projekts ist es ratsam, die Erwartungen an die Mitwirkung festzuhalten. Das kann beinhalten, wie Pull Requests eingereicht werden sollen, welche Art von Beiträgen erwünscht ist oder wie die Kommunikation im Projekt ablaufen soll. Klare Richtlinien von Beginn an können helfen, die Entwicklung der Community positiv zu beeinflussen und von Anfang an eine gute Arbeitsatmosphäre zu schaffen.

Interne Unternehmensdiskussionen

Wenn ein Unternehmen hinter einem Open-Source-Projekt steht, sind interne Absprachen unerlässlich. Wie soll das Projekt unterstützt werden? Wer trifft die Entscheidungen? Diese internen Prozesse sollten nicht im Verborgenen stattfinden, sondern idealerweise auch nach außen kommuniziert werden, um Vertrauen zu schaffen und die Rolle des Unternehmens transparent zu machen.

Öffentliche Erklärungen zur Unternehmensbeteiligung

Es ist oft hilfreich, wenn Unternehmen offenlegen, wie sie sich an einem Open-Source-Projekt beteiligen. Dies kann die Form von bezahlten Entwicklern, die Bereitstellung von Infrastruktur oder die aktive Teilnahme an Diskussionen annehmen. Eine solche Offenheit stärkt die Beziehung zur Community und kann das Vertrauen in das Projekt erhöhen.

Umgang mit Firmenbeiträgen

Wenn ein Unternehmen in ein Open-Source-Projekt einsteigt, kann das viele Vorteile bringen, aber es gibt auch ein paar Dinge zu beachten. Firmen nutzen Open-Source-Code oft als Baustein für ihre eigenen Produkte oder Dienstleistungen. Das ist völlig normal und zeigt eigentlich nur, dass das Projekt gut ankommt.

Manchmal werden Leute, die sich mit dem Projekt gut auskennen, dafür bezahlt, an bestimmten Funktionen zu arbeiten. Das ist auch kein Problem, solange die Bezahlung nicht dazu führt, dass diese Leute bevorzugt behandelt werden. Jeder Beitrag sollte nach seinen technischen Qualitäten bewertet werden, egal ob jemand dafür bezahlt wird oder nicht. Es ist aber auch wichtig, dass die Leute, die kommerzielle Interessen haben, sich damit wohlfühlen, ihre Anwendungsfälle zu nennen oder sich für bestimmte Verbesserungen einzusetzen.

Das Wichtigste ist, dass kommerzielle Nutzung und Open Source gut zusammenpassen. Wenn eine Firma die Software in einem eigenen Produkt nutzt, das selbst nicht Open Source ist, ist das Gesamtprodukt proprietär. Aber die Open-Source-Komponente bleibt davon unberührt und kann weiterhin für alle Zwecke genutzt werden.

Entwickler, die für ihre Arbeit bezahlt werden, können natürlich mehr beitragen, aber das sollte die Diskussionen im Projekt nicht beeinflussen. Konzentriert euch auf die Beiträge selbst, nicht darauf, wer dahintersteckt oder warum jemand dafür bezahlt wird.

Kommerzielle Nutzung von Open-Source-Code

Die kommerzielle Nutzung von Open-Source-Code ist ein Zeichen für die Reife und Beliebtheit eines Projekts. Unternehmen integrieren diese Software oft in ihre eigenen kommerziellen Produkte und Dienstleistungen. Dies ist eine natürliche Entwicklung, die zeigt, dass der Code einen echten Mehrwert bietet. Solange die Lizenzbedingungen eingehalten werden, ist dies ein positiver Aspekt für das Projekt.

Bezahlte Entwickler im Projekt

Wenn Entwickler für ihre Arbeit an einem Open-Source-Projekt bezahlt werden, ist das ebenfalls eine normale Situation. Diese Entwickler können durch ihre bezahlte Zeit mehr Beiträge leisten. Entscheidend ist jedoch, dass ihre Beiträge genauso wie die von unbezahlten Mitwirkenden nach rein technischen Kriterien bewertet werden. Die Motivation hinter einem Beitrag – ob bezahlt oder ehrenamtlich – sollte die Qualität der Arbeit nicht beeinflussen. Es ist wichtig, dass sich alle Beteiligten wohlfühlen, ihre geschäftlichen Interessen oder spezifischen Anforderungen zu äußern, solange dies im Rahmen der Projektziele geschieht.

Bewertung von Beiträgen nach technischen Kriterien

Die technische Qualität eines Beitrags sollte immer im Vordergrund stehen, unabhängig davon, wer ihn einreicht oder ob dafür bezahlt wurde. Ein gut durchdachter, sauber geschriebener und gut getesteter Code ist wertvoll, egal ob er von einem langjährigen Community-Mitglied oder einem neuen Mitarbeiter eines Unternehmens stammt. Dieser Fokus auf technische Exzellenz hilft, die Integrität und Weiterentwicklung des Projekts sicherzustellen und schafft ein faires Umfeld für alle Mitwirkenden.

Zugriffssteuerung und Berechtigungen

Rollen auf Repository-Ebene

Wenn wir über die Zugriffssteuerung in Open-Source-Projekten sprechen, ist es wichtig zu verstehen, wie Berechtigungen auf der Ebene einzelner Repositories gehandhabt werden. Hier geht es darum, wer Code lesen, schreiben oder sogar Änderungen zusammenführen darf. Man kann sich das wie verschiedene Zugangsstufen zu einem Haus vorstellen: Manche dürfen nur rein, andere können auch Möbel umstellen.

• Leser (Read): Diese Leute können den Code sehen, Issues öffnen und Kommentare schreiben. Sie sind oft die Nutzer des Projekts.
• Schreiber (Write): Zusätzlich zum Lesen dürfen sie auch Änderungen vorschlagen, also Pull Requests erstellen.
• Maintainer (Maintain): Sie haben die Macht, Pull Requests zu überprüfen und zusammenzuführen. Sie sind quasi die Hausmeister, die entscheiden, was ins Haus kommt.
• Administrator (Admin): Das ist die höchste Stufe. Sie können alles tun, inklusive Einstellungen ändern, Mitglieder verwalten und das Repository löschen. Das sind die Hausbesitzer.

Die genauen Berechtigungen können je nach Plattform variieren, aber das Grundprinzip bleibt gleich: Es gibt eine Staffelung des Zugriffs, um die Sicherheit und den Fluss der Projektarbeit zu gewährleisten.

Rollen auf Teamebene

Manchmal reicht die Repository-Ebene nicht aus, besonders in größeren Projekten. Hier kommen Teams ins Spiel. Ein Team kann eine eigene Sammlung von Berechtigungen haben, die dann auf verschiedene Repositories angewendet werden. Das ist praktisch, wenn man zum Beispiel ein bestimmtes Team hat, das sich nur um die Dokumentation kümmert, und ein anderes, das für die Kernfunktionalität zuständig ist.

Ein Team kann eigene Mitglieder haben und diesen dann spezifische Rollen innerhalb des Teams zugewiesen bekommen. Ein Team-Maintainer hat dann zum Beispiel mehr Rechte innerhalb dieses Teams als ein einfaches Team-Mitglied. Das hilft, die Verantwortlichkeiten klar zu definieren und die Zusammenarbeit zu strukturieren, ohne dass jeder alles auf jeder Ebene machen muss.

Rollen auf Organisationsebene

Auf der höchsten Ebene haben wir die Organisation. Hier werden die übergeordneten Regeln und Berechtigungen festgelegt, die für alle Repositories und Mitglieder gelten. Das ist wie die Satzung eines Vereins.

• Organisationsbesitzer: Haben die volle Kontrolle über die Organisation, können Mitglieder hinzufügen oder entfernen und die allgemeine Struktur verwalten.
• Organisationsmitglieder: Die Standardrolle für alle, die Teil der Organisation sind. Sie haben grundlegende Rechte, wie das Erstellen von Repositories, je nach Konfiguration.
• Organisationsmoderatoren: Können Mitglieder sperren oder zulassen und Interaktionen einschränken, was bei der Verwaltung der Community hilft.
• Abrechnungsmanager: Verwalten die finanziellen Aspekte der Organisation.
• Sicherheitsmanager: Konzentrieren sich auf die Sicherheitseinstellungen und -richtlinien.

Diese Rollen auf Organisationsebene sind wichtig, um die Struktur und die Verwaltung des gesamten Open-Source-Projekts zu regeln. Sie legen fest, wer die Fäden zieht und wer welche übergeordneten Aufgaben übernimmt.

Erreichen von Projektrollen

Dokumentation von Beitrittsprozessen

Damit neue Leute den Einstieg finden, ist es wichtig, klar zu dokumentieren, wie man Teil des Projekts wird. Das kann bedeuten, dass man einen Abschnitt in der README.md oder einer separaten CONTRIBUTING.md-Datei hinzufügt. Hier sollten die Erwartungen an Mitwirkende und die Schritte zur Einreichung von Beiträgen beschrieben werden. Eine klare Dokumentation senkt die Hürde für neue Beteiligte erheblich.

Nutzung von Tools zur Beitragsverfolgung

Moderne Plattformen wie GitHub bieten hervorragende Werkzeuge, um Beiträge zu verfolgen. Issues und Pull Requests sind nicht nur für die Code-Entwicklung wichtig, sondern auch, um zu sehen, wer sich wie engagiert. Man kann sehen, wer welche Probleme löst oder welche Features vorschlägt. Das hilft dabei, Leute zu identifizieren, die bereit sind, mehr Verantwortung zu übernehmen. Es ist ein guter Weg, um Engagement sichtbar zu machen.

Verschiebung zu GitHub-Organisationen

Viele Projekte migrieren ihre Verwaltung und Rollenstruktur zu GitHub-Organisationen. Das ermöglicht eine feinere Steuerung von Berechtigungen auf verschiedenen Ebenen – Repository, Team oder sogar der gesamten Organisation. So kann man zum Beispiel bestimmte Personen zu Maintainern für ein bestimmtes Repository machen, ohne ihnen gleich die volle Kontrolle über das gesamte Projekt zu geben. Das ist besonders nützlich, wenn ein Projekt wächst und die Verantwortlichkeiten klarer aufgeteilt werden müssen. Die Strukturierung von Rollen auf Organisationsebene hilft, die Übersicht zu behalten und die Sicherheit zu erhöhen. OSSDL zum Beispiel nutzt solche Strukturen, um ihre Projekte transparent zu halten und die Zusammenarbeit zu fördern OSSDL believes software should be accessible, transparent, and freely improvable.

Vergabe von Commit-Rechten

Offene Vergabe von Commit-Zugang

Manche Leute denken, dass man jedem, der einen Beitrag geleistet hat, sofort Commit-Zugang gewähren sollte. Das kann dazu führen, dass sich mehr Leute für dein Projekt interessieren. Es ist eine sehr offene Herangehensweise, die das Wachstum fördern kann. Aber man muss auch die Risiken bedenken, gerade bei größeren Projekten.

Berechtigung nach nachgewiesenem Engagement

Eine andere Methode ist, Commit-Rechte nur an Personen zu vergeben, die ihr Engagement für das Projekt schon gezeigt haben. Das bedeutet, sie haben vielleicht schon mehrere Pull Requests eingereicht, die angenommen wurden, oder sie helfen aktiv bei der Beantwortung von Issues. Es ist ein Weg, die Qualität und Beständigkeit der Beiträge sicherzustellen. Es gibt hier nicht den einen richtigen Weg, und was für dein Projekt am besten ist, hängt von vielen Faktoren ab. Wichtig ist, dass der Prozess klar und nachvollziehbar ist, damit sich niemand ausgeschlossen fühlt. Die OSSDL zum Beispiel setzt auf eine breite Beteiligung und transparente Prozesse, um innovative Open-Source-Tools zu entwickeln OSSDL believes software should be accessible, transparent, and freely improvable.

Verwaltung über geschützte Branches

Wenn dein Projekt auf Plattformen wie GitHub gehostet wird, kannst du geschützte Branches nutzen. Damit legst du fest, wer unter welchen Bedingungen auf bestimmte Branches schreiben darf. Das ist eine praktische Methode, um die Stabilität des Hauptcodes zu sichern, während man gleichzeitig neuen Mitwirkenden die Möglichkeit gibt, sich einzubringen. Man kann zum Beispiel festlegen, dass nur bestimmte Personen oder Teams auf den main-Branch committen dürfen, während andere Branches für breitere Tests offen sind. Das hilft, den Überblick zu behalten und unerwünschte Änderungen zu vermeiden.

Zusammenfassung: Die Vielfalt macht’s

Am Ende des Tages ist es wichtig zu verstehen, dass Open-Source-Projekte von Menschen leben, die sich einbringen. Egal ob jemand den Code schreibt, die Dokumentation pflegt, Veranstaltungen organisiert oder einfach nur im Forum hilft – jede Rolle ist wichtig. Die Art und Weise, wie wir diese Rollen definieren und anerkennen, kann einen großen Unterschied machen. Indem wir klare Strukturen schaffen, aber auch Raum für Flexibilität lassen, fördern wir eine gesunde und wachsende Gemeinschaft. Denken Sie daran, dass die besten Projekte oft diejenigen sind, bei denen sich jeder willkommen fühlt und weiß, wie er am besten mithelfen kann. Es geht darum, die richtigen Leute für die richtigen Aufgaben zu finden und ihnen zu zeigen, dass ihre Arbeit geschätzt wird.

Häufig gestellte Fragen

Was sind die wichtigsten Rollen in Open-Source-Projekten?

Stell dir vor, ein Projekt ist wie eine Schulklasse. Der „Maintainer“ ist wie der Klassenlehrer, der dafür sorgt, dass alles gut läuft und die Richtung vorgibt. „Mitwirkende“ sind alle Schüler, die etwas zum Projekt beitragen, sei es durch Ideen, Hilfe bei Aufgaben oder das Verbessern von Dingen. Ein „Committer“ ist wie ein Schüler, der die Erlaubnis hat, direkt Änderungen am Schulprojekt vorzunehmen, also quasi derjenige, der die „finalen“ Ideen umsetzt.

Wie kann man die Rollen im Projekt offiziell machen?

Um die Zusammenarbeit einfacher zu machen, kann man feste Rollen einführen. Das ist so, als würdest du in der Klasse sagen: ‚Du bist für die Plakate zuständig, und du hilfst beim Vorlesen.‘ Das hilft allen zu wissen, wer was macht und wen man fragen kann. Man kann das einfach in einer Projektdatei aufschreiben oder auf einer extra Team-Seite im Internet. Bei großen Projekten gibt es manchmal sogar kleine Teams, die sich um bestimmte Bereiche kümmern, wie Sicherheit oder die Organisation von Treffen.

Welche Arten von Führungsmodellen gibt es für Projekte?

Es gibt verschiedene Arten, wie ein Projekt geführt werden kann. Manchmal hat eine Person das letzte Wort (wie ein „wohlwollender Diktator auf Lebenszeit“), das ist oft bei kleineren Projekten so. Manchmal entscheiden die Leute, die am meisten zum Projekt beitragen, gemeinsam (das nennt man Meritokratie). Und manchmal zählt vor allem, wer gerade am meisten hilft und gute Ideen hat, auch wenn er oder sie noch nicht lange dabei ist. Jede Methode hat ihre eigenen Vorteile.

Wann sollte man die Regeln für die Projektleitung aufschreiben?

Man muss nicht sofort am Anfang alles festlegen. Oft merkt man erst, wenn das Projekt wächst und mehr Leute mitmachen, wie man die Regeln am besten gestaltet. Aber es ist gut, schon früh zu überlegen, wie die Zusammenarbeit funktionieren soll. Wenn eine Firma ein Projekt startet, sollte sie intern besprechen, wer welche Entscheidungen trifft und das dann auch den anderen mitteilen.

Was passiert, wenn Firmen Geld mit dem Projekt verdienen wollen?

Wenn Firmen mitmachen und Geld verdienen wollen, ist das kein Problem! Open Source und Kommerz gehen gut zusammen. Wichtig ist nur, dass alle Beiträge gleich behandelt werden, egal ob jemand dafür bezahlt wird oder nicht. Die Qualität der Arbeit zählt. Firmen, die das Projekt nutzen, können auch Entwickler dafür bezahlen, dass sie am Projekt arbeiten. Das ist gut, weil es das Projekt voranbringt. Aber bezahlte Entwickler sollten nicht mehr Mitspracherecht haben als andere.

Wie kann man die Zugänge und Rechte für verschiedene Rollen regeln?

Man kann Leuten verschiedene Rechte geben, je nachdem, was sie im Projekt tun sollen. Stell dir vor, du hast ein Heft, in das jeder reinschreiben darf, aber nur bestimmte Leute dürfen die Seiten umblättern oder neue Seiten hinzufügen. Auf der Ebene des „Repositories“ (das ist wie die digitale Mappe des Projekts) kann man einstellen, wer was ändern darf. Auch auf der Ebene des ganzen „Teams“ oder der „Organisation“ (das ist wie die ganze Schulklasse oder der Verein) kann man unterschiedliche Zugänge und Rollen vergeben.