Product SiteDocumentation Site

1.3. Das Innenleben des Debian-Projekts

Die reichlichen vom Debian-Projekt erzielten Endergebnisse entstehen zu gleichen Teilen aus der von erfahrenen Debian-Entwicklern geleisteten Arbeit an der Infrastruktur, aus individueller und gemeinsamer Entwicklungsarbeit an Debian-Paketen wie auch aus Rückmeldungen der Anwender.

1.3.1. Die Debian-Entwickler

Debian-Entwickler haben verschiedene Aufgaben und als offizielle Projektmitglieder haben sie großen Einfluss auf die Richtung, die das Projekt einschlägt. Ein Debian-Entwickler ist üblicherweise für mindestens ein Paket zuständig, kann sich aber je nach Wunsch und verfügbarer Zeit an mehreren Teams und Projekten beteiligen und so größere Verantwortung innerhalb des Projekts übernehmen.
Paketbetreuung ist eine recht straff organisierte Arbeit, sehr stark dokumentiert oder gar reglementiert. Sie muss mit wirklich allen in den Debian-Richtlinien festgelegten Standards übereinstimmen. Zum Glück gibt es zahlreiche Hilfsprogramme, die die Arbeit eines Betreuers erleichtern. So kann sich der Entwickler auf die Besonderheiten seines Pakets und auf komplexere Aufgaben wie die Fehlerbeseitigung konzentrieren.
Die Richtlinien, ein wesentliches Element des Debian-Projekts, legen die Normen fest, die sowohl die Qualität der Pakete sicherstellen als auch die Interoperabilität der Distribution vervollkommnen. Dank dieser Richtlinien bleibt Debian trotz seiner gewaltigen Größe konsistent. Sie sind nicht in Stein gehauen, sondern entwickeln sich aufgrund von Vorschlägen, die in der Mailingliste gemacht werden, ständig weiter. Änderungen, denen alle Betroffenen zustimmen, werden von einer kleinen Gruppe von Betreuern, die keine redaktionelle Zuständigkeit haben, entgegengenommen und in den Text eingearbeitet. (Sie nehmen nur die Veränderungen auf, auf die sich die Debian-Entwickler, die Mitglied der oben genannten Liste sind, geeinigt haben.) Sie können die aktuellen Veränderungsvorschläge im Fehlerverfolgungssystem nachlesen:
Die Richtlinien decken die technischen Aspekte des Paketierens sehr gut ab. Aus der Größe des Projekts ergeben sich jedoch auch organisatorische Probleme; mit diesen beschäftigt sich die Debian-Verfassung, die eine Struktur und ein Verfahren für die Entscheidungsfindung festlegt. Mit anderen Worten, ein formales System für das Projektmanagement.
Diese Verfassung definiert eine bestimmte Anzahl von Rollen und Positionen sowie für jede die Verantwortlichkeiten und Befugnisse. Es ist insbesondere beachtenswert, dass Debian-Entwickler stets eine abschließende Entscheidungsbefugnis durch einen allgemeinen Beschluss haben, bei dem eine qualifizierte Mehrheit von drei Vierteln (75%) der Stimmen erforderlich ist, um wesentliche Änderungen vorzunehmen (wie zum Beispiel solche mit Auswirkung auf die Grundlagendokumente). Indes wählen die Entwickler jedes Jahr einen „Leiter“, der sie in Sitzungen repräsentiert und der die interne Koordination zwischen den verschiedenen Teams sicherstellt. Diese Wahl ist immer eine Zeit erbitterter Diskussionen. Die Rolle dieses Debian-Projekt-Leiters (DPL ist in keinem Dokument ausdrücklich definiert: Kandidaten für diese Stelle schlagen gewöhnlich ihre eigene Definition dieser Position vor. In der Praxis bestehen die Rollen des Leiters unter anderem darin, gegenüber den Medien als Repräsentant aufzutreten, „interne“ Teams zu koordinieren und dem Projekt allgemeine Orientierungshilfen anzubieten, auf die sich die Entwickler beziehen können: Die Ansichten des DPL werden stillschweigend von der Mehrheit der Projektmitglieder anerkannt.
Im Besonderen haben die Leiter wirkliche Autorität; Ihre Stimme entscheidet bei Stimmengleichheit; sie können jede Entscheidung treffen, die nicht bereits unter die Zuständigkeit eines anderen fällt, und sie können ihre Verpflichtungen teilweise delegieren.
Seit seiner Gründung wurde das Projekt der Reihe nach von Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman und Jonathan Carter geleitet.
Die Verfassung sieht auch ein „technisches Komitee“ vor. Die wesentliche Rolle dieses Komitees besteht darin, in technischen Fragen zu entscheiden, wenn die beteiligten Entwickler untereinander kein Einvernehmen erzielt haben. Daneben spielt dieser Ausschuss eine beratende Rolle für jeden Entwickler, der eine Entscheidung, für die er verantwortlich ist, nicht trifft. Man sollte beachten, dass das Komitee sich erst dann einmischt, wenn es hierzu von einer der beteiligten Parteien aufgefordert wird.
Schließlich bestimmt die Verfassung die Position eines „Projekt-Schriftführers“, dessen Aufgabe darin besteht, die Abstimmungen im Zusammenhang mit den verschiedenen Wahlen und allgemeinen Beschlüssen zu organisieren.
Das Verfahren der "allgemeinen Beschlussfassung" (GR) ist in der Verfassung vollständig beschrieben, von der ersten Diskussionsperiode bis zur endgültigen Stimmenauszählung. Der interessanteste Aspekt dieses Prozesses ist, dass Entwickler, wenn es um die tatsächliche Abstimmung geht, die verschiedenen Wahlmöglichkeiten zwischen ihnen einstufen müssen und der Gewinner mit der Condorcet-Methode (genauer gesagt der Schulze-Methode) ausgewählt wird. Weitere Informationen finden Sie unter:
Auch wenn diese Verfassung einen demokratischen Anschein erweckt, sieht die tägliche Wirklichkeit ziemlich anders aus: Natürlich folgt Debian den Regeln der Freien Software, der „Tu-okratie“: Wer etwas tut, entscheidet auch. Viel Zeit kann darauf verschwendet werden, die jeweiligen Vorteile verschiedener Lösungswege für ein Problem zu diskutieren; am Ende wird die Lösung gewählt, die als erste funktioniert und zufriedenstellend ist... was sich aus der Zeit ergibt, die eine sachkundige Person darin investiert hat.
Dies ist der einzige Weg, sich Sporen zu verdienen: Etwas Nützliches zu tun und zu zeigen, dass man gut gearbeitet hat. Bei Debian agieren viele „Verwaltungsteams“ aufgrund einer Kootation (Wahl von Mitgliedern durch die übrigen Mitglieder) unter Bevorzugung von Freiwilligen, die bereits erfolgreich mitgewirkt und ihre Sachkenntnis bewiesen haben. Die Arbeitsweise dieser Teams ermöglicht es interessierten Entwicklen direkt mitzuwirken ohne erweiterte Rechte haben zu müssen. Deshalb wird Debian häufig als „Meritokratie“ bezeichnet.
Diese effektive Arbeitsweise gewährleistet die Qualität der Mitwirkenden in den zentralen Debian-Teams. Diese Methode ist keineswegs perfekt und gelegentlich finden sich auch Leute, die diese Arbeitsweise nicht akzeptieren. Die Auswahl von Entwicklern für die Teams mag ein wenig willkürlich oder sogar unfair erscheinen. Außerdem hat nicht jeder dieselbe Auffassung von der Leistung, die von diesen Teams erwartet wird. Für einige ist es nicht akzeptabel, acht Tage auf das Einfügen eines neuen Debian-Pakets warten zu müssen, während andere problemlos drei Wochen lang geduldig warten. Daher gibt es regelmäßig Beschwerden der Unzufriedenen über die „Arbeitsqualität“ mancher Teams.

1.3.2. Die aktive Rolle der Anwender

Man mag sich fragen, ob es wichtig ist, unter denen, die innerhalb des Debian-Projekts arbeiten, auch die Anwender zu erwähnen, doch die Antwort ist definitiv "Ja": sie spielen im Projekt eine lebenswichtige Rolle. Sie sind keineswegs „passiv“, sondern einige Anwender verwenden Entwicklungsversionen von Debian und schicken regelmäßig Fehlerberichte ein, in denen sie auf Probleme hinweisen. Andere gehen noch weiter und reichen Verbesserungsvorschläge ein, indem sie einen Fehlerbericht mit der Schweregradstufe „wishlist“ einschicken oder sogar Korrekturen des Quellcodes, „Patches“ genannt, einreichen (siehe Abschnitt 1.3.2.3, „Senden von Fehlerkorrekturen“).

1.3.2.1. Fehler melden

Das grundlegende Werkzeug in Debian für das Einreichen von Fehlern in die Debian-Fehlerdatenbank (Debian BTS = Bug Tracking System) wird von großen Teilen des Projekts genutzt. Der öffentliche Teil (die Webschnittstelle) ermöglicht es Anwendern, sich alle gemeldeten Fehler anzusehen und falls gewünscht, eine nach verschiedenen Kriterien sortierte Liste anzeigen zu lassen, wie zum Beispiel: betroffenes Paket, Schwere des Fehlers, Status, Anschrift des Meldenden, Anschrift des zuständigen Betreuers, Kennzeichnung, usw. Es ist auch möglich, die vollständige Liste aller bisherigen Diskussionen jedes einzelnen Fehlers durchzusehen.
Unter der Oberfläche ist das Debian BTS E-Mail basierend: Alle Informationen, die es speichert, stammen aus Meldungen, die von verschiedenen beteiligten Personen eingesandt worden sind. Jede an geschickte E-Mail wird so der Verlaufsgeschichte des Fehlers Nr. 12345 zugeordnet. Bevollmächtigte Personen können einen Fehler „schließen“, indem sie eine Nachricht mit einer Begründung dieser Entscheidung an schicken (ein Fehler wird geschlossen, wenn das angezeigte Problem gelöst oder nicht mehr von Bedeutung ist). Ein neuer Fehler wird gemeldet, indem man eine E-Mail in einem bestimmten Format, das das betroffene Paket bezeichnet, an schickt. Die Adresse ermöglicht es, alle mit einem Fehler verbundenen „Meta-Informationen“ zu bearbeiten.
Das Debian BTS hat noch weitere funktionelle Merkmale, wie die Verwendung von Markierungen zur Kennzeichnung von Fehlern. Weitere Informationen finden Sie unter
Benutzer können auch die Befehlszeile verwenden, um Fehlerberichte mit dem reportbug-Werkzeug zu einem Debian-Paket einzusenden. Es hilft sicherzustellen, dass der betreffende Fehler nicht schon früher eingereicht worden ist und so Redundanz im System zu vermeiden. Es erinnert den Benutzer an die Definitionen der Schweregrade, um so eine möglichst genaue Meldung abzugeben (der Entwickler kann, falls nötig, diese Parameter später immer noch fein einstellen). Es hilft, einen vollständigen Fehlerbericht zu schreiben, ohne dass der Benutzer die genaue Syntax kennen muss, indem es ihn schreibt und der Benutzer ihn überarbeiten kann. Dieser Bericht wird dann über einen E-Mail-Server verschickt (standardmäßig über einen entfernten von Debian betriebenen, aber reportbug kann auch einen lokalen Server verwenden).
Dieses Hilfsprogramm zielt vor allem auf die Entwicklungsversionen, in denen Fehler vorrangig beseitigt werden. Tatsächlich sind Änderungen in stabilen Debian-Versionen nicht gern gesehen und sehr selten, zu den wenigen Ausnahme gehören Sicherheitsaktualisierungen oder andere wichtige Updates (falls zum Beispiel ein Paket überhaupt nicht funktioniert). Die Korrektur eines kleineren Fehlers in einem Debian-Paket muss daher bis zur nächsten stabilen Version warten.

1.3.2.2. Übersetzung und Dokumentation

Des Weiteren möchten viele zufriedene Anwender der von Debian angebotenen Leistungen selbst einen Beitrag zum Projekt leisten. Da nicht jeder ausreichend große Sachkenntnisse in der Programmierung hat, kann er auch bei der Übersetzung und Überprüfung der Dokumentation helfen. Es gibt sprachspezifische Mailinglisten zur Koordination dieser Arbeit, für Deutsch zum Beispiel: .

1.3.2.3. Senden von Fehlerkorrekturen

Fortgeschrittene Benutzer können möglicherweise eine Problemlösung für ein Programm bereitstellen, indem sie einen Patch senden.
Ein Patch ist eine Datei, die Änderungen beschreibt, die auf eine oder mehrere Referenzdateien angewendet werden sollen. Insbesondere enthält sie eine Liste von Codezeilen, die entfernt oder hinzugefügt werden sollen, wie auch (manchmal) Zeilen, die dem Referenztext entnommen sind, um so die Veränderungen im Kontext zu ersetzen (sie ermöglichen es, die Platzierung der Änderungen zu bestimmen, wenn sich die Zeilennummern geändert haben).
Das Hilfsprogramm, das verwendet wird, um die in einer derartigen Datei vorgenommenen Veränderungen anzuwenden, heißt einfach patch. Das Hilfsprogramm, das sie erstellt, heißt diff und wird wie folgt benutzt:
$ diff -u file.old file.new >file.patch
Die file.patch-Datei enthält die Anweisungen, um den Inhalt von file.alt in file.neu zu ändern. Wir können sie jemandem zuschicken, der sie dann dazu verwenden kann, file.neu folgendermaßen aus den anderen beiden neu zu erstellen:
$ patch -p0 file.alt <file.patch
Die Datei file.alt ist jetzt mit der Datei file.neu identisch.
In der Praxis wird die meiste Software derzeit in Git-Repositorys verwaltet und die Mitwirkenden verwenden daher eher git, um den Quellcode abzurufen und Änderungen vorzuschlagen. git diff generiert eine Datei im gleichen Format wie diff -u und git apply kann dasselbe tun wie patch.
Während die Ausgabe von git diff eine Datei ist, die für andere Entwickler freigegeben werden kann, gibt es in der Regel bessere Möglichkeiten, Änderungen einzureichen. Wenn die Entwickler es vorziehen, Patches per E-Mail zu erhalten, bevorzugen sie in der Regel Patches, die mit git format-patch generiert werden, damit sie mit git am direkt in das Repository integriert werden können. Dadurch werden Commits für Metainformationen beibehalten und es ermöglicht, mehrere Commits gleichzeitig freizugeben.
Dieser E-Mail-basierte Workflow ist immer noch beliebt, wird aber tendenziell durch die Verwendung von merge-Anfragen (oder pull-Anfragen) ersetzt, wenn die Software auf einer Plattform wie GitHub oder GitLab gehostet wird – und Debian verwendet GitLab auf seinem salsa.debian.org-Server. Auf diesen Systemen erstellen Sie, sobald Sie ein Konto erstellt haben, forken das Repository, indem Sie effektiv eine Kopie des Repositorys in Ihrem eigenen Konto erstellen und Sie können dann dieses Repository klonen und Ihre eigenen Änderungen darin übertragen. Von dort aus wird Ihnen die Weboberfläche empfehlen, eine Zusammenführungsanforderung zu senden, die Entwickler über Ihre Änderungen informiert, sodass sie Ihre Änderungen mit einem einzigen Klick überprüfen und akzeptieren können.

1.3.2.4. Andere Möglichkeiten, Beiträge zu leisten

Diese Infrastruktur zur Benutzerbeteiligung wurden durch das Verhalten der Anwender optimiert. Sie sind keineswegs eine Gruppe isolierter Personen, sondern Teil einer richtigen Gemeinschaft, in der zahlreiche Austauschprozesse stattfinden. Wir möchten vor allem auf die beeindruckende Aktivität in der Mailingliste für Anwenderdiskussionen hinweisen: (Kapitel 7, Probleme lösen und relevante Informationen finden beschreibt dies ausführlicher).
Die Anwender helfen sich (und anderen) nicht nur technischen Problemen, die sie selbst betreffen, sondern diskutieren auch darüber, wie sie am besten zum Debian-Projekt beitragen und es dadurch voranbringen können - Diskussionen, die häufig zu Verbesserungsvorschlägen führen.
Da Debian keine Gelder für Eigenwerbungskampagnen ausgibt, spielen seine Benutzer bei seiner Verbreitung eine wichtige Rolle, indem sie es durch Mundpropaganda bekannt machen.
Diese Methode funktioniert recht gut, da Debian-Anhänger auf allen Ebenen der Gemeinschaft der freien Software zu finden sind: von Installationspartys (Treffen, bei denen erfahrene Anwender Neulingen helfen, das System zu installieren), die von örtlichen LUGs (Linux User Groups) organisiert werden, bis zu Vereinsständen auf großen Technikkongressen zum Thema Linux, usw.
Freiwillige erstellen Plakate, Broschüren, Sticker und andere nützliche Werbematerialien für das Projekt, die sie jedem zur Verfügung stellen und die Debian auf seiner Website oder Wiki frei anbietet:

1.3.3. Teams, Mischungen und Teilprojekte

Debian war von Beginn an um das Konzept der Quellpakete herum organisiert, jedes mit seinem Betreuer oder seiner Gruppe von Betreuern. Zahlreiche Arbeitsteams haben sich im Laufe der Zeit gebildet, die die Verwaltung der Infrastruktur und das Management von Aufgaben, die keinem bestimmten Paket zugeordnet werden können (Qualitätssicherung, Debian-Richtlinien, Installationsprogramm usw.) sicherstellen, wobei die jüngsten Teams rings um Unterprojekte heranwachsen.

1.3.3.1. Bestehende Debian-Unterprojekte und Mischungen (Blends)

Jedem sein eigenes Debian! Ein Unterprojekt ist eine Gruppe von Freiwilligen, die daran interessiert sind, Debian an spezifische Bedürfnisse anzupassen. Neben der Auswahl einer Untergruppe von Programmen, die für einen bestimmten Bereich (Bildung, Medizin, Multimedia-Erstellung usw.) bestimmt sind, sind Unterprojekte auch daran beteiligt, bestehende Pakete zu verbessern, fehlende Software zu paketieren, den Installer anzupassen, spezifische Dokumentation zu erstellen und mehr. Während eine "Mischung" vielleicht nicht genau dasselbe ist, funktioniert sie ziemlich ähnlich und versucht auch, eine Lösung für Gruppen von Leuten zu bieten, die Debian für einen bestimmten Bereich verwenden wollen. Man könnte sagen, dass "Debian Pure Blends" der Nachfolger der Unterprojekte ist.
Here is a small selection of current released Debian Pure Blends:
  • Debian Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;
  • Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic and educational world;
  • Debian Med, von Andreas Tille, dem medizinischen Bereich gewidmet;
  • Debian Multimedia, which deals with audio and multimedia work;
  • Debian GIS, which takes care of Geographical Information Systems applications and users;
  • Debian Astro, sowohl für professionelle als auch für Hobby Astronomen;
  • Debian Science, working on providing researchers and scientists a better experience using Debian;
  • Freedombox ermöglicht das Entwickeln, Designen und Bewerben von privaten Servern, auf denen kostenlose Software für die private und persönliche Kommunikation gehosted werden kann.
  • Debian Games, bietet Spiele in Debian von Arcade und Abenteuer bis zu Simulation und Strategie;
  • DebiChem, das sich um Chemie dreht, bietet Chemie-Suiten und -Programme an.
The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. Administrative Teams

Die meisten Verwaltungsteams sind relativ verschlossen und ergänzen sich nur durch Ko-optation. Die beste Möglichkeit bei einem Team Mitglied zu werden, besteht darin, die aktuellen Mitglieder intelligent zu unterstützen und so zu zeigen, dass man ihre Ziele und Arbeitsmethoden verstanden hat.
Die FTP-Master sind für das offizielle Archiv der Debian-Pakete zuständig. Sie betreuen das Programm, das die von Entwicklern eingeschickten Pakete entgegennimmt und nach einigen Überprüfungen automatisch auf dem Referenzserver speichert (ftp-master.debian.org).
Sie müssen auch die Lizenzen aller neuen Pakete überprüfen, bevor sie sie in die Sammlung bestehender Pakete aufnehmen, um sicherzustellen, dass Debian sie verbreiten darf. Wenn ein Entwickler ein Paket entfernen möchte, richtet er sich an dieses Team über das Fehlerberichtssystem und das „Pseudo-Paket" ftp.debian.org.
Das Debian System Administrators(DSA)-Team () ist, wie zu erwarten, für die Systemadministration der vielen vom Projekt verwendeten Server verantwortlich. Es stellt den reibungslosen Betrieb aller Basisdienste sicher (DNS, Web, E-Mail, Konsole usw.), installiert von Debian-Entwicklern gewünschte Software und trifft alle sicherheitsrelevanten Vorsichtsmaßnahmen.
Die Listmaster verwalten die E-Mail-Server mit den Mailinglisten. Sie erstellen neue Listen, bearbeiten Abweisungen (Mitteilungen über gescheiterte Zustellungen) und betreuen die Spam-Filter (unerwünschte Massen-E-Mails).
Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case for the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar HILFSPROGRAMM GitLab, Git Repository Hosting und vieles mehr), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Entwicklungsteams, Querschnittsteams

Im Gegensatz zu den Verwaltungsteams sind die Entwicklungsteams, selbst gegenüber externen Mitwirkenden, recht offen. Auch wenn Debian sich nicht dazu berufen fühlt, Software zu erstellen, so benötigt das Projekt doch einige spezielle Programme, um seine Ziele zu erreichen. Natürlich wenden diese unter einer freien Softwarelizenz entwickelten Hilfsprogramme Methoden an, die sich andernorts in der Welt der freien Software bewährt haben.
Debian hat wenig eigene Software entwickelt, aber bestimmte Programme spielen heute eine zentrale Rolle, und ihr Name hat sich über den Bereich des Projekts hinaus verbreitet. Gute Beispiele sind dpkg, das Debian-Paketverwaltungsprogramm (es ist eine Abkürzung für Debian PacKaGe, ausgesprochen dee-package), und apt, ein Hilfsprogramm zur automatischen Installation von Debian-Paketen, und seine Abhängigkeiten, die die Konsistenz des Systems nach einer Aktualisierung sicherstellen (sein Name ist eine Abkürzung für Advanced Package Tool). Ihre Teams sind jedoch viel kleiner, da sehr gute Programmierkenntnisse für das vollständige Verständnis der Funktionsweise solcher Programmen erforderlich sind.
Das wichtigste Team ist wohl jenes für das Debian-Installationsprogramm debian-installer, das seit seinem Beginn im Jahr 2001 ein Werk bedeutenden Ausmaßes fertiggestellt hat. Zahlreiche Mitwirkende waren erforderlich, da es schwierig ist, ein einzelnes Programm zu schreiben, das in der Lage ist, Debian auf einem Dutzend verschiedener Architekturen zu installieren. Jedes hat seine eigenen Startabläufe und seinen eigenen Bootloader. All diese Arbeit wird in der Mailingliste unter der Leitung von Cyril Brulebois koordiniert.
Das (sehr kleine) Team des Programms debian-cd hat ein noch bescheideneres Ziel. Viele „kleine“ Mitwirkende sind für ihre Architektur verantwortlich, da der Hauptentwickler weder alle Feinheiten noch den genauen Weg zum Starten des Installationsprogramms von der CD-ROM kennen kann.
Viele Teams müssen mit anderen beim Paketieren zusammenarbeiten: versucht zum Beispiel, die Qualität auf allen Ebenen des Debian-Projekts sicherzustellen. Die Liste entwickelt Debian-Richtlinien aufgrund von Vorschlägen, die aus allen Richtungen eintreffen. Die Teams, die für jeweils eine Architektur zuständig sind (), kompilieren alle Pakete und passen sie dabei nach Bedarf an ihre jeweilige Architektur an.
Andere Teams betreuen die wichtigsten Pakete, um ihre Instandhaltung sicherzustellen, ohne eine allzu schwere Last auf die Schultern eines Einzelnen zu legen; dies ist bei der C-Bibliothek und der Fall, beim C-Compiler auf der Liste und bei Xorg auf (diese Gruppe, ist auch als die X Strike Force bekannt).