© Zacarias Pereira da Mata, 123RF

Während die Geschichte vieler kommerzieller Distributionen von jubelnden Aufs und heftigen Abs geprägt ist, darf das Community-Projekt Debian heuer auf 25 vergleichsweise kontinuierliche Jahre zurückblicken, in denen es seinen offenbar erfolgreichen Prinzipien treu geblieben ist.

Linux gehört heute so selbstverständlich ins Rechenzentrum wie Server oder Switches. Aber im Geburtsjahr von Debian, 1993, war das noch anders: Linus Torvalds hatte mit der Arbeit an Linux ja erst kurz zuvor, 1991, angefangen. Eine Distribution war damals auch kaum mehr als eine übersichtliche Sammlung von Werkzeugen, die nötig waren, um den Betriebssystem-Kernel irgendwie sinnvoll zu verwenden. Das traf auch auf Softlanding Linux System zu. SLS hatte allerdings so seine Ecken und Kanten und stand nicht unbedingt im Verdacht, das stabilste System zu sein.

Ein 20-jähriger amerikanischer Entwickler namens Ian Murdock wollte das ändern und startete kurzerhand seine eigene Distribution. Aus dem Vornamen seiner Frau Debra und seinem eigenen Vornamen komponierte er “Debian” – nicht ahnend, welche Erfolgsgeschichte hier ihren Anfang nahm. Heute ist Debian so etabliert wie Linux selbst und nicht zuletzt auch die Grundlage für andere große Linux-Distributionen.

Freilich gehen 25 Jahre nicht spurlos an einem solchen Projekt vorüber: In dieser Zeit hat es innerhalb der Community immer wieder große Umbrüche, neue Ideen und erbitterte Fehden zwischen den Verfechtern verschiedener Ansätze gegeben. Das 25-Jahre-Jubiläum des Projekts bietet eine gute Gelegenheit, Erinnerungen aufzufrischen: Was waren die Meilensteine der Projektgeschichte? Was hat das Projekt fernab davon geprägt? Wohin geht die Reise? Der Autor dieses Artikels ist seit 2003 selbst Debian-Entwickler und sein Artikel entsprechend ein ganz persönlicher Rück- wie Ausblick.

Die verdammten Releases

2001, als der eigene Debian-Werdegang des Autors seinen Anfang nahm, dominierte ein Thema die gesamte Debian-Community: Die Frage nach einer sinnvollen Planung und Umsetzung neuer Releases.

Die Uhren tickten damals noch anders: Die mittlerweile klassische Aufteilung der Hersteller in eine Community- und eine Enterprise-Distribution war so noch nicht gegeben. Red Hat und Suse, die damals den amerikanischen und europäischen Markt mit Linux-Systemen in schicken Pappkartons versorgten, legten bei der Veröffentlichung neuer Distributionsversionen ein beachtliches Tempo vor.

Bei Debian war das anders: Die Debian-Version 2.2 war Mitte 2001 schon anderthalb Jahre alt, und mit dem baldigen Erscheinen der Version 3.0 alias Woody war laut Release-Manager Anthony Towns noch lange nicht zu rechnen.

Aus jener Zeit stammt die Verballhornung “Debian Stale”: Traditionell geht die Arbeit an der Distribution bekanntlich in drei Zweigen vonstatten. Die Stable-Variante bekommt nur noch Security-Updates und Patches für besonders schwerwiegende Probleme – dafür handverlesen. Der Unstable-Zweig ist der Entwicklungszweig, in den Entwickler neue Versionen ihrer Pakete hochladen und in dem die Entwicklung stattfindet. Das Mittelding ist Testing: Melden Nutzer oder Entwickler für Pakete im Unstable-Zweig keine schwerwiegenden Fehler, migrieren diese nach festgelegten Wartezeiten automatisch nach Testing.

Um zu einer Debian-Release zu kommen, arbeiten die Entwickler am Ende eines Release-Zyklus die Release-critical-Bugs des Testing-Zweigs ab, bis alle gelöst sind – fertig sind der Lack und die Release. Weil gerade dies aber einige Zeit in Anspruch nahm, war Debian Stable im direkten Vergleich mit den anderen Distributionen seinerzeit tatsächlich “stale”, abgestanden.

Debians Unstable-Zweig ist übrigens der einzige, der dauerhaft nach einer Figur aus den Toy-Story-Filmen benannt ist, nämlich nach Sid, dem bösen Kind, das stets das Spielzeug zerstört. Die Debian-Releases dagegen tragen wechselnde Namen von Figuren aus dieser Reihe.

Nicht schneller, aber besser

Wer sich die damaligen Diskussionen in Erinnerung ruft, kann sich kaum vorstellen, dass sich am Zeitraum zwischen zwei Debian-Releases seit 2001 bis heute wenig verändert hat – im Schnitt bringt Debian alle zwei Jahre eine neue Stable-Version heraus. Einziger Ausreißer war bisher Sarge, das drei Jahre Entwicklung benötigte, im Gegenzug aber auch mit den radikalsten Veränderungen der Distributionsgeschichte aufwartete.

Auf vielen Änderungen der damaligen Zeit fußt Debian GNU/Linux bis heute. Das prominenteste Beispiel ist der Debian Installer, der 2005 den altbackenen Installer ersetzte (Abbildung 1).

Abbildung 1: Wer Debian Potato noch händisch installiert hat, erinnert sich an die unbeliebten Boot-Floppys, die zwischenzeitlich dem Debian Installer gewichen sind.

Dass der Release-Zyklus innerhalb des Projekts trotzdem kein Aufregerthema mehr ist, liegt an mehreren Faktoren. Einerseits betreut mittlerweile nicht mehr ein einzelner Release-Manager die Arbeiten rund um neue Versionen, sondern ein ganzes Team, das deutlich aktiver mit der Community kommunizieren kann und das auch tut.

Andererseits hat sich die Distributionswelt seit damals radikal verändert: Im Enterprise-Kontext geben nun die Long-Term-Support-Distributionen (LTS) den Takt an, die auf fünf Jahre Support setzen. Auch bei denen hat man es nach mehreren Jahren zwar mit einem Software-Museum zu tun, doch scheint das nun allgemeiner Konsens zu sein, Debian hebt sich damit längst nicht mehr von der Masse anderer Systeme ab.

Mittlerweile bietet Debian sogar selbst LTS-Support an: Die Faustregel ist eigentlich, dass sich das Security-Team der Distribution nur so lange um die Oldstable-Variante kümmert, wie kein ganzes Jahr nach der Release einer neuen Major-Version verstrichen ist. Eine separate Gruppe von Entwicklern hat vor Jahren allerdings ein LTS-Projekt gegründet [1] und pflegt diese älteren Distributionen für einen Gesamtzeitraum von fünf Jahren. Ob das in Zeiten von Microservices und Immutable Underlay überhaupt noch sinnvoll ist, ist eine andere Frage.

Sein oder nicht sein

Als Ian Murdock 1993 mit Debian begann, interessierte sich nur eine Handvoll Mitstreiter überhaupt für das Projekt. Das änderte sich aber schnell: 1995 arbeiteten bereits 60 Leute mit, 1998 zählte Debian schon über 400 aktive Entwickler. Das rasante Wachstum brachte auch Probleme mit sich: Sicherheit war bei Debian schon immer ein wichtiges Thema. Wie war sicherzustellen, dass neue Projektmitglieder vertrauenswürdig sind und auch technisch wissen, was sie tun?

Bei über 400 Entwicklern war es ganz einfach nicht länger möglich, dass jeder jeden kennt und auch im echten Leben schon mal getroffen hat. Ende 1999 überlegte man sich dafür ein Konzept, das in den kommenden Jahren vielen Probanden den letzten Nerv rauben würde: den Debian New Members Process (kurz NM, Abbildung 2).

Abbildung 2: Der New Member Process kann für den Betroffenen schon überraschend viel Zeit in Anspruch nehmen – im Falle des Autors dieses Artikels mehr als ein Jahr.

Die Idee hinter dem NM-Prozess ist simpel und einleuchtend: Wer sich für die Mitarbeit am Projekt interessiert, nimmt Kontakt zu bereits beteiligten Entwicklern auf und arbeitet zunächst mit diesen am gemeinsamen Thema. Hat der Anwärter seine Fertigkeiten unter Beweis gestellt, verfasst ein Debian-Entwickler ein Empfehlungsschreiben und hinterlegt dieses im NM-System. Danach bekommt der Proband einen Application Manager (AM) zugewiesen, der im Dialog mit dem potenziellen Debian-Entwickler verschiedene Fähigkeiten überprüft und Wissen abfragt. Am Ende steht eine Empfehlung an die Debian Account Manager, entweder einen Account anzulegen oder denjenigen abzuweisen.

Freilich lautet die Empfehlung in der absoluten Mehrzahl der Fälle, die Person aufzunehmen – sonst wäre sie zwischenzeitlich bereits aus dem Prozess geflogen. Jedoch: Die Fragen, die im Rahmen des NM-Prozesses auftauchen, haben sich im Verlauf der Jahre überproportional vermehrt. Ursprünglich gab es zwar Vorlagen, die auf Martin Michlmayr zurückgehen (Abbildung 3). An die sind die Application Manager aber nicht gebunden – und viele haben ihre ganz eigenen Methoden entwickelt, potenzielle Debian-Developer zu zwiebeln.

Abbildung 3: Martin Michlmayr baute den New Member Process maßgeblich auf und diente später dem Projekt auch als Debian Project Lead.

Langes Warten

Entsprechend lange zieht sich der NM-Prozess manches Probanden hin. Ein Jahr und mehr sind durchaus nicht ungewöhnlich. Vergleichbar hoch ist der Frust bei vielen Bewerbern. Das hat seit Einführung des NM-Prozesses immer wieder für Zündstoff gesorgt. Mancher gibt irgendwann entnervt auf, und andere wieder erhalten ihren Account zu einem Zeitpunkt, zu dem sie schon gar nicht mehr damit gerechnet hatten. Im Laufe der Jahre haben die Debian-Entwickler aber auch immer wieder Veränderungen am NM-Prozess vorgenommen, sowohl vor als auch hinter den Kulissen.

Wie fast alle relevanten Prozesse auch verantwortet jetzt nicht mehr eine Einzelperson das New Members System, sondern ein Team. Das Gleiche gilt für die DAMs, also die Debian Account Manager: Vor 15 Jahren lag die entsprechende Verantwortung noch einzig und allein auf den Schultern von James Troup, mittlerweile kümmert sich ein Team um die Debian-Accounts.

Mit dieser Aufgabe ist mehr Verantwortung verbunden, als man gemeinhin annimmt: Debian betreibt ein zentrales LDAP, auf das beinahe alle Debian-Maschinen zugreifen. Wer also eine Berechtigung im LDAP hat – und das ist gleichbedeutend damit, Debian Developer zu werden – erlangt Zugriff auf eine Menge Systeme. Zudem hinterlegen die DAMs den Gnu-PG-Schlüssel der jeweiligen Person, sodass er Teil des zentralen Keyrings wird und der angenommene Bewerber folglich Pakete in das Debian-Archiv hochladen darf.

Das Debian Account Management war deshalb gerade in den frühen Jahren des NM-Systems dessen Achillesferse. Die finale Entscheidung über das Anlegen des Accounts lagt beim DAM, was diesen, also seinerzeit James Troup, dazu brachte, den gesamten Mail-Verkehr zwischen AM und Bewerber gegenzulesen und dann auf dieser Basis eine Entscheidung zu treffen. Das konnte dauern, oft genug war bei den Bewerbern die Rede von der sprichwörtlichen “DAMnation”. Heute liegt DAM auf den Schultern eines Teams, dessen einzelne Mitglieder unmittelbar vom Debian Project Leader ernannt werden – die DAMs sind also Delegates.

Das hat in Summe dazu geführt, dass DAM besser und schneller funktioniert. Pikant ist in diesem Kontext übrigens, dass Enrico Zini ebenfalls zum DAM-Team gehört. Zuvor hatte er die Website des New Members Process [2] umgebaut und auch den NM-Prozess selbst an mehreren Stellen verbessert.

Maintainer statt Entwickler

Eine der größeren Veränderungen innerhalb des Projekts war die Einführung des Debian-Maintainer-Status im Jahre 2007. Debian Maintainer unterscheiden sich von Debian-Entwicklern dadurch, dass sie weniger Rechte haben: Sie dürfen zwar Pakete ins Debian-Archiv hochladen, jedoch nicht, wenn das entsprechende Paket noch nicht im Archiv in einer älteren Version existiert. Hinzu kommt noch eine Vielzahl weiterer Einschränkungen.

Wer also statt Debian Developer “nur” Debian Maintainer wird, hat in diesen Grenzen zu leben, kommt im Gegenzug aber auch um den NM-Prozess herum. Es genügt, wenn ein bestehender Debian-Entwickler das Maintainer-Ansinnen befürwortet. Diese “Light-Mitgliedschaft” erfreut sich großer Beliebtheit. Die Generalabstimmung innerhalb des Projekts, die 2007 zum Debian-Maintainer-Status stattgefunden hat, gilt damit als eine der Entscheidungen, die Debian nachhaltig und sichtbar verändert haben.

König ohne Volk?

Apropos Generalabstimmung: Immer wieder diskutieren die Entwickler über die Art und Weise, wie sie Debian-intern Verantwortung delegieren und deren Missbrauch verhindern wollen. Ex iure ist das Projekt hochdemokratisch. Davon zeugt etwa die jährliche Wahl eines Projektleiters, dessen Kompetenzen gar nicht so gering sind, wie manches Debian-Mitglied denkt. Klar, vorrangig hat der DPL – aktuell übrigens Chris Lamb – repräsentative Aufgaben. Die Debian-Verfassung gesteht ihm allerdings auch ein Mitspracherecht bei vielen Entscheidungen zu, die das Projekt weitreichend verändern können.

Die erwähnten Debian Account Manager etwa sind DAM-Delegierte, auch der Projektsekretär ist ein solcher. Hinzu kommt, dass der DPL finanzielle Entscheidungen treffen darf, die das für Debian verwaltete Vermögen betreffen, etwa bei Software in the Public Interest (SPI).

Trotzdem hat sich bei Debian von Anfang an das Prinzip der Meritokratie flächendeckend durchgesetzt. Konkret landet Verantwortung also bei den Leuten, die effektiv und kontinuierlich bestimmte Problemfelder beackern. Alle DAMs etwa haben jahrelange Erfahrung mit dem Debian-NM-Prozess und sich dann zu einem späteren Zeitpunkt bereit erklärt, die DAM-Rolle zu übernehmen.

Ähnliches gilt für Kurt Roeckx, den aktuellen Projektsekretär, der zuvor quasi als Azubi Manoj Srivastava zur Hand ging. Praktisch undenkbar scheint es, dass der DPL Aufgaben an Projektmitglieder delegiert, die nicht in allgemein hohem Ansehen stehen.

Weil dieser Prozess so schön funktioniert, hat sich eine Sache in den vergangenen 25 Jahren kaum verändert: Die Zahl der Mitglieder, die an der DPL-Wahl überhaupt teilnehmen. Regelmäßig stehen höchstens drei Kandidaten auf der Liste und bei seiner Wiederwahl dieses Jahr trat Chris Lamb gar völlig ohne Konkurrenz an. Dass das Gros der Diskussionen im Projekt im selben Zeitraum kontinuierlich sachlicher geworden ist und zumindest nach Wissen des Autors auch keine DPL-Meuterpläne existieren, spricht dafür, dass die Mehrheit der Mitglieder mit dem aktuellen System ganz zufrieden ist.

Vor 15 Jahren war das zumindest in Teilen durchaus anders: Prominente Entwickler wie Brandon Robison oder Anthony Towns führten einen heftigen Wahlkampf und stellten zum Teil ganz unterschiedliche Pläne vor, wie das Projekt in die Zukunft zu führen sei.

Gemeinsame Werte

Das hat freilich auch etwas mit gemeinsamen Grundwerten zu tun – und die haben sich in den vergangenen 25 Jahren ebenfalls kaum verändert. Debian kennt drei elementare Dokumente: seine Verfassung, seinen Social Contract und die Debian Free Software Guidelines.

Das Bekenntnis zu freier Software ist dabei das Fundament, auf dem das ganze Projekt errichtet ist: Damit Software in Debian sein darf, muss sie unter einer freien Lizenz stehen. Die Debian Free Software Guidelines legen fest, welche Kriterien dafür erfüllt sein müssen. Tatsächlich ragt die Bedeutung der DFSG allerdings weit über Debian selbst hinaus: Viele andere Projekte orientieren sich an dem Leitfaden, der kurz und knackig die wichtigsten Anforderungen an freie Software darlegt.

Im Hinblick auf sein Fundament kennt Debian kein Erbarmen: Änderungen am Social Contract oder den DFSG scheinen praktisch undenkbar, und Neuerungen bei der Debian-Verfassung unterliegen stets heftigen Diskussionen auf den diversen Mailinglisten des Projekts – bei denen zum Teil selbst um einzelne Satzzeichen gerungen wird.

Bei allem Zwist, der dabei entsteht, beweist Debian aber auch immer wieder aufs Neue, dass es durchaus wandlungsfähig und kreativ ist – und durchaus nicht nur im Hinblick auf die eigene Distribution: Seit Jahren nimmt Debian etwa am Google Summer of Code teil, und für verschiedene Themen – etwa die chronische Unterrepräsentation von Frauen in der IT – existieren separate Themengruppen. De facto war Debian nie ein rein technisches Projekt, sondern zugleich ein soziales. Die vielen Entwicklerkonferenzen (Debconf), deren kleine Ableger sowie diverse Bug-Squashing-Partys stellen das ebenso unter Beweis.

Dass es auch anders geht, bewies vor Jahren die Diskussion um Systemd: Der Streit innerhalb der Entwicklergemeinde eskalierte so heftig, dass diverse Mitglieder des Technical Committee – also Debians allerhöchstem technischen Entscheidungsgremium – zurücktraten.

Ian Jackson, der lange Zeit tonangebend innerhalb Debians war und die Seite der Systemd-Gegner anführte, warf schließlich gar entnervt komplett hin. Das Ende ist bekannt: In Form von Devuan [3] entwickelte sich ein Debian-Fork, der ohne Systemd auskommt. Zum Glück ist das allerdings die Ausnahme. Meist schaffen die Entwickler es dann doch, sich irgendwie zusammenzuraufen.

Auch bei der Technik geht es weiter

Dass das Hauptaugenmerk freilich auf der eigenen Distribution liegt, ist ebenso klar. Fernab von organisatorischen Details und Änderungen an Projektdokumenten hat Debian in den vergangenen 25 Jahren auch eine sehr beeindruckende technische Entwicklung hingelegt. Das betrifft zunächst die Distribution selbst, also das, was Anwender installieren: Der schon erwähnte Debian Installer hat sich im Laufe der Zeit einen Ruf als zuverlässige und gut funktionierende Installationsroutine erarbeitet und bekommt weiterhin von Release zu Release neue Funktionen.

Größten Wert legen die Debian-Entwickler auch auf die Versionspflege: Die Veröffentlichung einer neuen Debian-Version ist regelmäßig mit massiven Updates auf allen Gebieten verbunden. Debian erwächst hier zum Vorteil, dass sich verschiedene Maintainer freiwillig um verschiedene Projekte kümmern – die Arbeitslast verteilt sich also auf sehr viele Schultern. Und von Release zu Release steigt die Anzahl der Pakete, die in Debian insgesamt vorhanden sind, kontinuierlich an.

Die Masse tut der Qualität allerdings keinen Abbruch: Bis heute gilt Debian allgemein als sehr stabile Basis für Server und Desktops und böse Zungen behaupten, dass selbst Debians Testing-Zweig vielen anderen Linux-Distributionen in Sachen Stabilität haushoch überlegen sei.

Viel Arbeit hinter den Kulissen

Was vielen Debian-Anwendern gar nicht klar ist: Debian betreibt sehr viel eigene Infrastruktur, um den Entwicklern ihre Arbeit zu ermöglichen. Die verschiedenen Abläufe, wie die zuvor bereits beschriebene Migration von Paketen aus dem Unstable- in den Testing-Zweig ist ein gutes Beispiel dafür. Quasi seit Beginn seiner Existenz pflegt Debian eigene Werkzeuge, denn am Markt gibt es entsprechende Software für exakt diese Aufgabe nicht. Die Werkzeuge, die Debian für seine internen Abläufe nutzt, sind natürlich freie Software und stehen im Netz zur Verfügung.

Das betrifft zum Beispiel das Debian Archive Kit (DAK, [4]). Klar ist aber auch, dass man außerhalb des Debian-Projekts mit dieser Software vermutlich nur wenig anfängt. Ähnliches gilt für die Debian-Mailinglisten [5]: Hier kommt eine selbst gebaute Software zum Einsatz, deren Ursprünge weit in die Geschichte des Projekts zurückreichen. Auch das Debiansche Bug Tracking System [6] ist ein Beispiel für Software aus dem Hause Debian, ohne die die Arbeit an der Distribution praktisch unmöglich wäre.

Immer wieder haben die vielen Debianer diese Komponenten in den vergangenen Jahren verändert, angepasst und um zusätzliche Funktionalität erweitert. Am Ende zahlt sich das aber für die gesamte Debian-Gemeinde aus: Heute funktioniert DAK stabiler und zuverlässiger als früher (Abbildung 4).

Abbildung 4: Das Debian Archive Kit nimmt Pakete von Entwicklern entgegen, prüft die Gnu-PG-Signatur und verarbeitet sie dann weiter.

Manchmal skurrile Ideen

Nicht unter den Tisch fallen sollen in diesem Text freilich auch die vielen Debian-internen Projekte, die eher in die Rubrik Kurioses fallen oder auf Außenstehende wenigstens so wirken. Der Ruf von GNU/Hurd etwa ist innerhalb der Open-Source-Gemeinde einigermaßen ruiniert. Denn das Betriebssystem ist zwar seit Jahrzehnten in Entwicklung, kann bis heute allerdings keinen Zustand vorweisen, der stabil und tauglich für den Massenmarkt wäre. Da hilft auch die schönste Microkernel-Architektur nicht weiter. Unbeirrt davon existieren in Debian allerdings ein paar Enthusiasten, die Debian GNU/Khurd als Distribution unter dem Debian-Schirm anbieten wollen, sollte es denn jemals fertig werden.

Deutlich weiter sind die Entwickler von Debian GNU/Kfreebsd: Die Idee, das Debian-Userland auf einem Free-BSD-Kernel zu betreiben, hat ja auch durchaus ihren Charme. Was in der Theorie gut klingt, erweist sich in der Praxis jedoch als tückisch, denn immer wieder stoßen die Entwickler in Programmen und Bibliotheken auf Code, der Linux-spezifisch ist. Immerhin gilt Debian GNU/Kfreebsd mittlerweile als Technology Preview und seine Entwickler reichen fleißig Fehlerberichte ein, wenn ihnen ein Problem vor die Flinte läuft.

Durchschlagenden Erfolg hatte diese Debian-Geschmacksrichtung bisher allerdings nicht und produktiv nutzbar ist sie bis heute ebenso wenig. Hält man sich vor Augen, wie lange Debian bereits an eben diesen Projekten herumdoktert, stellt sich der Eindruck einer gewissen Kontinuität ein.

Wohin die Reise geht

Zweifellos dürfen die vergangenen 25 Debian-Jahre als turbulent, manchmal skurril, meist hochinteressant und am Ende sehr erfolgreich gelten. Stellt sich freilich die Frage, wohin die Reise geht – und die ganz typische Antwort des Debian-Projekts auf diese Frage wäre wohl “Kontinuierlicher Wandel in kleinen Schritten”. Große Umwälzungen liegen dem Projekt und den Entwicklern nicht, auch das macht Debian zu einer so beliebten Basis für andere Systeme.

Nicht immer bleibt das Verhältnis zwischen Debian und seinen Derivaten ganz ohne Spannung: Die Umstände der Ubuntu-Gründung und die Tatsache, dass Mark Shuttleworth damals diverse Debian-Entwickler bei Canonical fest angestellt hat, trüben bis heute den Blick vieler Debian-Entwickler auf Ubuntu. Häufig ist ein Hauptkritikpunkt dabei, dass die Derivate Debian zwar nutzen, jedoch im Umkehrschluss kaum etwas zu seiner Verbesserung beitragen.

So wäre es wünschenswert, dass Ubuntu und Debian künftig besser voneinander profitierten, sonderlich wahrscheinlich ist das jedoch nicht. Denn Canonical verfolgt mit seinem System ganz andere Interessen, als es die Debian-Gemeinschaft mit Debian GNU/Linux tut. Aus Nutzersicht ist das Fluch wie Segen zugleich: Ubuntu ist in vielerlei Hinsicht schließlich ein aufgebohrtes Debian mit mehr Funktionalität, auch wenn mancher Debianer hinter vorgehaltener Hand behauptet, es handele sich im Wesentlichen um ziemlich kaputte Funktionen.

Debian ist andererseits ein Community-Projekt, das nicht von heute auf morgen den Eigentümer wechselt, wie es kürzlich (wieder) mit Suse passiert ist – diese Art von Veränderung erzeugt immer Unsicherheit bei den Nutzern. Letztlich ist Debian also etwas weniger fancy als die kommerziellen Distributoren, dafür aber auch deutlich berechenbarer.

Alles in allem ist Debian heute eine gut geölte Maschine, die bestens funktioniert. Letztlich kann man dem Projekt lediglich wünschen, dass es genau das auch weiterhin sein kann. So oder so werden die Debian-Entwickler auf ihr Baby wie bisher aufpassen. (jcb)