055.3 Lektion 1

Kernziel der meisten Open-Source-Projekte ist Software, so dass für solche Vorhaben zumindest Programmierer, Softwaredesigner oder -architekten, Tester, Release-Manager und andere Experten für die Code-Entwicklung notwendig sind. Auch Dokumentation ist in der Regel ein Teil solcher Projekte, so dass die Community auch Autoren, Redakteure und Korrekturleser benötigt.

Andere Projekte produzieren vielleicht keinen Code, sondern andere “Ergebnisse” beispielsweise ein Buch-, Kunst- oder Musikprojekt oder einen politischen Bericht. Wikipedia ist ein bekanntes Beispiel für die Zusammenarbeit an einem Open-Source-Projekt, das sich auf Textdokumente und Medien konzentriert. Auch diese Projekte benötigen Experten für die Produktion, Gestaltung und Bereitstellung der Ergebnisse.

Communities profitieren von vielen weiteren Fähigkeiten, wie beispielsweise Marketing, Verwaltung, Rechtsberatung, künstlerisches Talent für Logos oder Diagramme in der Dokumentation, aber auch Kenntnisse bei der Pflege der Projektwebseite und anderer Kommunikationsmittel. Open-Source-Projekte können auch persönliche Treffen und sogar Konferenzen organisieren; in diesem Fall brauchen sie Organisatoren, die diese Veranstaltungen mit Leben füllen.

Die folgenden Abschnitte vermitteln einen Eindruck von den Fähigkeiten, die eine Community sucht. Diese allgemeinen Aufgaben lassen sich weiter unterteilen und spezifizieren. Ein einfaches Beispiel ist die Aufgabe eines Autors, der Texte anderer Autoren bearbeitet.

Ein aktives Projekt braucht unter den Programmierern immer einige “Veteranen” (oder Senior Programmierer), die den Code und die Programmierstandards gut kennen und mit den Newbies (den Neulingen im Projekt) zusammenarbeiten, die neue Ideen einbringen und einfache Aufgaben, wie etwa Fehlerkorrekturen, erledigen. Im besten Fall entwickeln sich einige der Neulinge irgendwann selbst zu Veteranen.

Die Qualität des Codes erfordert sorgfältige Kontrolle darüber, was in das zentrale Repository gelangt, das mit den Benutzern geteilt wird. Daher erhalten einige Veteranen den Status eines Committers (“Beiträger”). Sie sind dafür verantwortlich, die Beiträge auf Qualität, Nützlichkeit und Konformität mit den Coding Standards zu prüfen. Sie haben das Privileg, den vorgeschlagenen Code in das vertrauenswürdige Repository aufzunehmen. Andere Mitwirkende reichen den Code bei den Committern zur Überprüfung ein.

Viele Committer und andere Veteranen sind auch Mentoren für neue Mitwirkende, um ihnen die Standards und Praktiken zu vermitteln, die sie brauchen, damit ihr Code akzeptiert wird.

Manche Committer wissen das Geschenk nicht zu schätzen, das ein Mitwirkender mit seinem Beitrag macht. Wenn der Beitrag nicht den Qualitäts- oder Kodierungsstandards entspricht, kann der Committer ihn einfach ablehnen. Aber eine Ablehnung kann den potenziellen Mitwirkenden entmutigen und ihm eine wertvolle Möglichkeit nehmen, mit den Standards vertraut zu werden. Gute Committer sind darum auch Mentoren. Sie geben Hinweise, wie der Code den Standards gerecht wird, und arbeiten mit neuen Mitwirkenden zusammen. Ist der Beitrag wirklich unbrauchbar, sollte dem Mitwirkenden zumindest gedankt und gezeigt werden, wie er gegebenenfalls an anderer Stelle zum Projekt beitragen kann. Es ist wichtig, Leuten zu helfen, ihre Fähigkeiten zu entdecken und zu verbessern.

Wenn ein Unternehmen ein Open-Source-Projekt startet, benennt es manchmal Committer aus den eigenen Reihen, um sicherzustellen, dass es Richtung und Qualität des Projekts kontrollieren kann. Aber oft erlauben Unternehmen auch Externen, Fähigkeiten und Engagement zu zeigen und Committer zu werden.

Projektleiter (Project Leads) treffen kritische Entscheidungen, beispielsweise welche neuen Funktionen unterstützt werden sollen. Projektleiter müssen oft auch Entscheidungen treffen, die nicht mit der Programmierung zu tun haben: zur Bewerbung des Projekts, zur Beilegung größerer Meinungsverschiedenheiten und zur Beschaffung von Finanzmitteln. Projektleiter und Committer arbeiten eng mit den Release Managern zusammen, um zu entscheiden, wann eine Codebasis stabil ist und mit den Benutzern geteilt werden kann.

Manche Projekte haben einen einzigen Projektleiter, der oft als “benevolent dictator” (“wohlmeinender Diktator”) bezeichnet wird. Dabei handelt es sich in der Regel um eine Person, die das Projekt ins Leben gerufen hat (Linus Torvalds ist ein bekanntes Beispiel für Linux) und die über Autorität oder sogar Charisma verfügt. Die meisten Projekte ziehen es jedoch vor, ein kleines Komitee von Projektleitern einzurichten; sogar das Linux-Projekt ist zu einem Komiteeansatz übergegangen.

Projekte können auch einzelne Mitwirkende bitten, Support in den Projektforen zu leisten. Aber gesunde Projekte sollten viele sachkundige Benutzer haben, die sich gegenseitig unterstützen.

Wir schließen diesen Abschnitt mit einer sehr wichtigen Rolle ab — der des Community Managers. Er sorgt für offene und konstruktive Kommunikation und stellt sicher, dass die Community ihr Ziel im Auge behält. Der Community Manager weiß, wie man Mitwirkende gewinnt und motiviert, Streitigkeiten löst, Mitglieder der Community vor Anfeindungen schützt und das Wohl der Gemeinschaft fördert.

In vielerlei Hinsicht stehen Open-Source-Projekte vor den gleichen Aufgaben wie andere Projekte, die etwa in einem Unternehmen durchgeführt werden; so muss beispielsweise neuer Code getestet werden. Aber es gibt auch Unterschiede zu proprietären Projekten, bei denen nur eine begrenzte Anzahl von Personen den Code ändern darf und der Quellcode nicht öffentlich zugänglich ist.

Unternehmen beauftragen in der Regel geschulte Mitarbeiter der Qualitätssicherung (Quality Assurance, QA) mit dem Testen des Codes. Viele Open-Source-Projekte bitten hingegen ihre Benutzer, jede Version zu testen. (Bei proprietären Projekten werden neben der QA auch die Benutzer in die Tests einbezogen.).

Ein weiteres Beispiel für die Unterschiede: Ein proprietäres Projekt weist normalerweise bezahlten Entwicklern bestimmte Aufgaben zu und gibt vor, wie viel Zeit sie pro Woche für die Aufgaben aufwenden sollen. Einige Open-Source-Projekte profitieren von Mitwirkenden, die von ihren Arbeitgebern bezahlt werden oder manchmal sogar vom Projekt selbst angestellt sind, und denen Aufgaben auf die gleiche Weise zugewiesen werden wie proprietären Entwicklern. Aber in den meisten Projekten kommen viele Beiträge von Freiwilligen, die die Aufgaben erledigen, wie es ihre Zeit erlaubt. Da sich das Projekt nicht darauf verlassen kann, dass alle Freiwilligen ihre Aufgaben pünktlich abschließen, kann es bei Open Source Releases zu Verzögerungen kommen, bis die Entwickler der Meinung sind, die Funktionen sind abgeschlossen; oder die Veröffentlichung erfolgt zu festen Zeiten mit den Funktionen, die zu diesem Zeitpunkt fertig sind.

Kommunikation ist sowohl für proprietäre als auch für Open-Source-Projekte von entscheidender Bedeutung, wird aber sehr unterschiedlich gehandhabt. Proprietäre Projekte versammeln oft ein Team in einem Büro und halten regelmäßige Stand-up-Meetings nach einer Entwicklungsmethodik wie Scrum ab. Da Open-Source-Projekte meist geografisch verteilt sind, sind solche Methoden selten. Stattdessen findet die Kommunikation online und asynchron statt.

Kurz gesagt, freie Software und Open-Source-Projekte erreichen oft die gleichen Ziele wie proprietäre Projekte, aber auf andere Weise.

Das Melden von Fehlern (Bugs) ist ein kritischer Teil der Softwareentwicklung mit eigenen Rollen. Die Fehlerdatenbank muss überwacht und Prioritäten müssen zugewiesen werden. Ist ein Fehler kritisch und gefährdet sogar die Sicherheit der Software, sollte er einem kompetenten Betreuer zur raschen Behebung zugewiesen werden.

Projektleiter und Community Manager sollten die Beteiligung am Projekt beobachten und feststellen, wo es Lücken gibt. Sind zu wenige Personen bereit, den Code zu testen? Fehlt es an Dokumentation? Verlassen zu viele erfahrene Projektmitglieder das Projekt, ohne ersetzt zu werden? Projektleiter und Community Manager sollten Personen rekrutieren, die die benötigten Rollen übernehmen.

Projektleiter und Community Manager bei großen Projekten erfassen oft auch Metriken, um beispielsweise festzustellen, ob wichtige Fehler zeitnah behoben werden.

Wie bereits erwähnt, werden Personen, die Code, Dokumentation oder anderes in das zentrale Projektarchiv einbringen, als Contributors, Mitwirkende oder Beitragende bezeichnet. Projektmitglieder, die Beiträge genehmigen und in das Projektarchiv aufnehmen, nennt man Committer. Einige Mitglieder übernehmen andere übliche Rollen bei der Softwareentwicklung.

Obwohl Contributor üblicherweise jemanden bezeichnet, der Code oder andere Teile des offiziellen Angebots eines Projekts entwickelt, trägt jeder, der ein Projekt unterstützt, in irgendeiner Weise zu dessen Erfolg bei und verdient daher Anerkennung. Zu diesen eher informellen Beiträgen gehören das Melden von Bugs, das Beantworten von Fragen im Forum, das Spenden oder Sammeln von Geldmitteln und das Bewerben des Projekts bei Außenstehenden.

Bei Open-Source-Projekten wie auch bei proprietären Projekten werden die Benutzer befragt, welche Funktionen, Leistungsverbesserungen oder anderen Änderungen sie am Projekt wünschen — und diese Benutzer leisten dadurch ebenfalls einen wichtigen Beitrag.

Viele Communities erhalten Beiträge nicht nur von Einzelpersonen, sondern auch von Unternehmen, die ihre Mitarbeiter dafür bezahlen, dass sie zu einem Projekt beitragen, das das Unternehmen für wichtig hält.

Es kann zu Spannungen kommen, wenn bezahlte Beitragende und Ehrenamtliche zusammenarbeiten. Ehrenamtliche können sich ausgenutzt fühlen oder befürchten, dass bezahlte Mitwirkende versuchen, die Richtung des Projekts zugunsten der Interessen ihrer Arbeitgeber zu beeinflussen. Community Manager und Projektleiter müssen sicherstellen, dass alle akzeptierten Beiträge dem gesamten Projekt und seinen Benutzern zugute kommen. Ehrenamtliche müssen motiviert werden, aus persönlichen Gründen beizutragen, sei es aus Loyalität gegenüber der Community oder um ihre eigenen Wünsche an das Projekt zu verfolgen.

Manche tragen regelmäßig zu einem Projekt bei und übernehmen langfristig Verantwortung — die sogenannten Core Member. Aktive Communities haben auch gelegentliche Beitragende, die Fehler melden oder Support in Foren leisten, von denen aber nicht erwartet wird, dass sie Verantwortung im Projekt übernehmen.

Einige Beitragende sind Experten auf ihrem Gebiet — unabhängig davon, ob ein Unternehmen sie für die Arbeit an dem Projekt bezahlt oder nicht --, während andere Amateure oder Enthusiasten sind. Aber man muss kein Profi sein, um eine wichtige Rolle zu übernehmen; auch als engagierter Enthusiast kann man sogar Mitglied des Kernteams oder Projektleiter werden.

Obwohl viele Open-Source-Projekte von engagierten Einzelpersonen oder kleinen Gruppen von Freiwilligen ins Leben gerufen werden, suchen sie in der Regel nach Unterstützung durch Organisationen, sobald die Projekte größer werden. Diese Unterstützung kann vielfältig sein: Im Allgemeinen leisten Organisationen diese Beiträge, weil ein Open-Source-Projekt ihre geschäftlichen Anforderungen kostengünstiger und zuverlässiger erfüllen kann als die Neuentwicklung gleicher Funktionen in proprietärem Code. Die Garantien, die eine freie oder Open-Source-Lizenz bietet, werden von vielen Organisationen geschätzt.

Manche Idealisten misstrauen Unternehmen oder großen Organisationen und würden es vorziehen, Open-Source-Projekte gänzlich von deren Einfluss fernzuhalten. Diese Einstellung ist jedoch immer weniger verbreitet. Die meisten Open-Source-Befürworter sind vielmehr der Meinung, dass Unternehmen und andere Organisationen Open-Source-Projekten eine wichtige Grundlage bieten können.

Viele Open-Source-Projekte starten in einem Unternehmen und können sogar auf proprietärem Code basieren, den das Unternehmen zu öffnen beschließt. Um Geld zu verdienen, kann das Unternehmen die Kontrolle über das Projekt behalten und es in offene und proprietäre Teile aufteilen; man spricht hier von einem Open-Core-Modell. Viele Projektgründer starten mit einem Open-Source-Projekt, gründen dann aber ein Unternehmen darum herum, das das Open-Core-Modell nutzen kann (oder auch nicht).

Andere Projekte versuchen sicherzustellen, dass kein einzelnes Unternehmen ihre Richtung kontrolliert. Um Unabhängigkeit zu wahren, ist es hilfreich, mehrere organisatorische Unterstützer zu gewinnen, so dass niemand stark genug ist, diktatorische Entscheidungen zu treffen.

Wie unterstützen Organisationen Open Source? Wie bereits erwähnt, stellen viele bezahlte Mitarbeiter für Projekte ein. Darüber hinaus können sie Personen einstellen, die als Freiwillige zu dem Projekt beigetragen und Fachwissen in dem Projekt entwickelt haben. Dieser Weg zur Beschäftigung ist eine wertvolle Möglichkeit für Studierende und andere freiwillige Mitarbeiter, ihre Karriere voranzutreiben.

Unternehmen, die Erweiterungen wünschen, die andere Benutzer nicht interessieren, sollten das Open-Source-Projekt nicht unter Druck setzen, diese zusätzlichen Funktionen hinzuzufügen; sie könnten vielmehr ihre Mitarbeiter dafür bezahlen, die Funktionen zu schreiben, ohne sie an das Projekt zurückzugeben.

Ein interessantes Beispiel für die möglichen Spannungen, die durch die Bedürfnisse von Unternehmen entstehen, ist das Android Betriebssystem, das auf Linux basiert und von Google für seine mobilen Geräte entwickelt wurde. Einige von Google vorgenommene Änderungen an Linux werden an die Linux Community zurückgegeben, während andere Änderungen nur in Android erscheinen. Die Linux-Entwickler lehnen manche Änderungen ab, die ihnen von Google vorgelegt werden, so wie alle Projekte entscheiden, welche Beiträge sie übernehmen.

Es gibt viele Gründe für ein Unternehmen oder eine Gruppe von Entwicklern, eine separate Version ihres Codes zu erstellen. Im Idealfall können sie ihre Bedürfnisse durch Hinzufügen einer optionalen Bibliothek oder einer Codesequenz erfüllen, die während der Kompilierung ausgeschlossen werden kann. Aber manchmal hat eine Gruppe auch Ziele, die mit der von den Projektleitern gewählten Richtung unvereinbar sind. Wenn dann eine separate Version erstellt wird, nennt man diese einen Fork.

Früher galten Forks als Folge schlechter Zusammenarbeit; heute sind sie deutlich akzeptierter. Normalerweise richten diejenigen, die einen Fork erstellen, ein neues Repository ein und starten ein neues Projekt. Manche arbeiten dann sowohl weiter an dem ursprünglichen Projekt als auch an dem Fork mit.

Viele Unternehmen steuern nicht nur Code bei, sondern auch finanzielle Mittel, beispielsweise für Marketing und Konferenzen. Sie können dem Vorstand beitreten und sachkundigen Rat zu Richtung und Strategie des Projekts geben.

Ein Beispiel für diese Art von “soft support” ist der Apache Webserver. Das Projekt machte schon früh einen großen Sprung nach vorn, als IBM sein Interesse bekundete. IBM-Anwälte zeigten dem Projekt, wie es sich rechtlich absicherte, und ein von IBM bezahltes Treffen half der Apache-Führung, eine stabile Organisation aufzubauen.

Um ihre Unabhängigkeit zu wahren, gründen viele Open-Source-Projekte eine gemeinnützige Stiftung oder schließen sich einer bestehenden Stiftung an. Bekannte Beispiele für Stiftungen, die Open-Source-Projekte leiten, sind die Linux Foundation, die Apache Foundation und die Eclipse Foundation.

Die Unterstützung einer Stiftung ist wertvoll, weil sie Logistik bereitstellt, mit der sich die meisten Softwareentwickler nicht befassen wollen: juristische Unterstützung wie Markenschutz, Haftungsfreistellung und Lizenzierung, Hilfe bei der Geldbeschaffung, Infrastruktur wie Fehlerdatenbanken und Websites und so weiter.

Wie bei Büchern, Musik und anderen kreativen Leistungen besteht auch bei Software ein komplexes Verhältnis zwischen den Entwicklern, den Organisationen, die ihre Beiträge verbreiten, und der Öffentlichkeit. Im Wesentlichen müssen die Mitwirkenden Schritte unternehmen, um dem Open-Source-Projekt das Recht zur Nutzung und Verbreitung ihres Codes einzuräumen.

Viele Open-Source-Organisationen fordern daher ihre Mitwirkenden auf, ein Contributor License Agreement (CLA) zu unterzeichnen. Manchmal überträgt der Mitwirkende den Code einfach auf das Projekt. Das Projekt ist dann Eigentümer des Codes und aller Rechte daran, so wie ein Unternehmen die Rechte an dem Code hat, für dessen Entwicklung es seine Mitarbeiter bezahlt hat.

Andere CLAs lassen einige Rechte in den Händen der einzelnen Mitwirkenden. Viele Contributor schätzen diese Flexibilität, weil sie denselben Code zu einem anderen Projekt beitragen oder ihr eigenes Unternehmen darauf aufbauen können.

Um die unterschiedlichen Beiträge verschiedener Personen in Einklang zu bringen, ist die dem Code zugewiesene Lizenz von entscheidender Bedeutung. Der Linux Kernel ist eines der Projekte, bei dem die Eigentumsrechte in den Händen der Mitwirkenden verbleiben, so dass mittlerweile viele Tausende von Personen Rechte am Linux Code besitzen. Aber alle Beiträger zum Core Code haben diesen unter die GNU General Public License (Version 2) gestellt, so dass Linux von allen frei verwendet, verändert und weitergegeben werden kann.

Der Einsatz einer einzigen Lizenz für den gesamten Code in einem Projekt ist der einfachste Weg, Verbreitung und Verwendung des Codes einfach zu gestalten. Aber manchmal erlaubt ein Projekt, dass verschiedene Teile des Codes unter verschiedenen Lizenzen stehen, normalerweise weil das Projekt existierenden Code nutzen möchte, der bereits unter einer anderen Lizenz veröffentlicht wurde. Lizenz-Experten sollten dann sicherstellen, dass die Lizenzen kompatibel sind.

Viele Online Communities stehen in dem Ruf, hemmungslos zu diskutieren (nach dem Motto “alles ist erlaubt”), bis hin zu Beschimpfungen und Streitereien. Heute gehen die meisten Open Source Communities dagegen vor, wenn sich Teilnehmer dazu hinreißen lassen. Vielmehr wollen moderne Communities konstruktive, höfliche und respektvolle Teilnehmer, die alle Geschlechter, ethnischen Gruppen, Persönlichkeitstypen usw. einbeziehen.

Die Erwartungen an Mitglieder werden in der Regel ausdrücklich in einem Code of Conduct (Verhaltenskodex) formuliert, der festschreibt, wie man mit anderen Personen im Projekt umgeht, sowohl online als auch persönlich. Um wirkungsvoll zu sein, muss dieser Verhaltenskodex vom Community Manager und den Projektleitern durchgesetzt werden.

Manchmal wird eine Person, die ein anderes Mitglied der Community verhöhnt oder beleidigt, dauerhaft oder vorübergehend ausgeschlossen. In anderen Fällen gibt der Community Manager oder ein Kollege öffentlich bekannt, dass das Verhalten gegen den Verhaltenskodex verstößt, und spricht möglicherweise außerhalb des Forums mit dem Täter. Oft hat dieser zuvor Frustration, mangelnde Aufmerksamkeit oder ein Burn-out erlebt, und die Mitglieder der Community können ihm helfen, besser zu kommunizieren.

Neben dem sozialen Verhalten legen Communities auch Qualitätsstandards fest. Die formellsten sind die Coding Guidelines (Kodierrichtlinien), die sicherstellen, dass der gesamte Code ähnlich aussieht. Die Richtlinien können Entwickler an best practices erinnern, wie beispielsweise die Verwendung von Klammern um Codeblöcke, oder Details festlegen, wie etwa die Benennung von Variablen und die Art der Einrückung.

Open Source Communities haben auch Regeln für die Freigabe von Code oder anderen Ergebnissen. Einige Projekte definieren feste Termine für die Freigabe; Ubuntu beispielsweise verspricht alle zwei Jahre eine neue Version mit Long Term Support (LTS) sowie Zwischenversionen in kürzeren Abständen. Andere Projekte führen eine Liste mit neuen Funktionen und Fehlerkorrekturen, die sie in der nächsten Version haben wollen, und geben die Version frei, wenn alles auf der Liste abgehakt ist. Aber anders als die meisten Unternehmen setzen Open Source Communities ihren Teilnehmern normalerweise keine Fristen, weil man von Freiwilligen nicht zu viel verlangen darf.

Neben den bereits erwähnten CLAs bitten einige Projekte die Mitwirkenden, ein Developer Certificate of Origin (DCO), also ein Entwicklerzertifikat, zu unterschreiben. Darin versichert der Mitwirkende, über den Code verfügen und ihn in das Projekt einbringen zu dürfen.

Warum ist das DCO wichtig? Stellen Sie sich folgendes Szenario vor: Ein Programmierer entnimmt Code aus einem proprietären Produkt seines Arbeitgebers und bringt ihn in ein Open-Source-Projekt ein; damit verletzt er die Lizenz seines Arbeitgebers und setzt das Open-Source-Projekt einem rechtlichen Risiko aus.

Das DCO soll sicherstellen, dass der Mitwirkende den Code tatsächlich geschrieben oder ihn legal erhalten hat. Das Open-Source-Projekt hängt von der Ehrlichkeit des Mitwirkenden ab, der das Zertifikat ausstellt.

Sozialwissenschaftler behaupten, dass Projekte und Unternehmen von großer Vielfalt bei Geschlecht, Ethnie, wirtschaftlichem Hintergrund, Nationalität und Fähigkeiten ihrer Mitglieder bzw. Mitarbeiter profitieren. Organisationen haben allerdings die Tendenz, sich mit anderen Menschen zu verbinden, die ihrer eigenen aktuellen Mitgliederstruktur ähnlich sind, so dass eine Community, die Vielfalt und Gleichberechtigung schätzt, ihre Mitglieder bewusst darin schulen muss, offener für Menschen zu sein, die nicht so sind wie sie selbst. Die Bewegung zur Umsetzung dieses Ideals wird Diversity, Equity, Inclusion (DEI) (Vielfalt, Gleichheit, Inklusion) genannt.

Der Code of Conduct ist der Ausgangspunkt für DEI. Er sollte ausdrücklich Menschen unterschiedlichen Geschlechts, unterschiedlicher Ethnien usw. willkommen heißen. Jeder Verstoß gegen den Verhaltenskodex muss umgehend und unmissverständlich missbilligt werden. Manche Minderheiten haben ihr ganzes Leben lang unter Ausgrenzung und negativen Kommentaren gelitten, und eine einzige schlechte Interaktion in einem Forum könnte dazu führen, dass sie keinen Grund mehr sehen, sich zu engagieren. Eine rasche Reaktion auf Aggressionen kann ihnen die Gewissheit geben, dass die Gemeinschaft hinter ihnen steht.

DEI geht aber noch viel weiter: Die Community sollte sich an Gruppen wenden, die sie stärker vertreten sehen will. Die Entwicklung einer App für die Stellensuche beispielsweise sollte sicherstellen, dass sie sowohl Stellen für Menschen mit niedrigem Einkommen als auch für Menschen aus der Ober- und Mittelschicht anzeigt. Die App sollte auch in einem Umfeld mit eher niedrigem Einkommen beworben werden und dort Mitglieder zum Beispiel zum Testen finden.

Eine Community könnte davon profitieren, Organisationen zu finden, die Menschen aus marginalisierten Bevölkerungsgruppen ausbilden, und dort neue Mitglieder rekrutieren. Viele solcher Organisationen sind lokal tätig und auf nationaler oder internationaler Ebene nicht bekannt.

Es ist wichtig, die Bedürfnisse von Randgruppen zu verstehen. Ist die Projektwebsite für Sehbehinderte zugänglich? Liegt Dokumentation in Sprachen vor, mit denen die Zielgruppen vertraut sind? Sollte es spezielle Foren in anderen Sprachen geben?

Die meiste Kommunikation in Open Source Communities findet asynchron und online statt. Bei Meetings oder Chat-Sitzungen sollten die Standorte/Zeitzonen der Teilnehmer berücksichtigt werden. Wenn Menschen aus vielen Ländern und Regionen auf Englisch kommunizieren, sollten Vokabular und Grammatik einfach gehalten werden.

Sind Angehörige einer Minderheit in einem Team, sollte deren Meinung gehört werden. Ein bekanntes Symptom für Ausgrenzung ist das Ignorieren der Aussagen von Minderheiten oder die Geringschätzung ihrer Bedeutung.

Andererseits sollten Mitglieder von Minderheiten nicht mit der Notwendigkeit belastet werden, die Bedürfnisse ihrer Gemeinschaften zu erklären — jeder sollte mit dieser Aufgabe betraut werden. Mitglieder von Minderheiten könnten wertvolle Aufklärungsarbeit leisten, ohne dabei unter Druck gesetzt zu werden. Jeder sollte die Möglichkeit haben, sich so zu beteiligen, wie er möchte, ohne eine Alibi-Minderheit repräsentieren zu müssen.