A.2 Fragen und Antworten

Anfang Oktober 2005 veröffentlichte Mark Shuttleworth eine Liste von häufig gestellten Fragen zu Ubuntu. Im Folgenden sollen hier auszugsweise die wichtigsten Fragen und Antworten wiedergegeben werden. Die englische Originalfassung des Interviews können Sie auf https://wiki.ubuntu.com/MarkShuttleworth lesen.

Warum mache ich Ubuntu?

Um den Bug #1 (Bug #1 in Ubuntu: »Microsoft hat den größten Marktanteil«) zu beheben, natürlich. Ich glaube, dass freie Software uns in ein neues Technologiezeitalter bringt, und außerdem verspricht sie den universellen Zugang zu den Werkzeugen des digitalen Zeitalters. Ich treibe Ubuntu voran, weil ich dieses Versprechen Realität werden sehen will.

Wird Ubuntu je Lizenzgebühren verlangen?

Nein. Nie. Es liegt nicht in meiner Absicht, Ubuntu der proprietären Softwareindustrie anzugliedern. Das ist ein schreckliches Geschäft, das

langweilig und schwierig ist und sowieso am Aussterben ist. Meine Motivation und mein Ziel ist es, ein globales Desktop-Betriebssystem zu entwickeln, das nicht nur in jeglicher Hinsicht »frei« ist, sondern auch zukunftsfähig und in der Lage, es qualitätsmäßig mit allem aufzunehmen, für das man bezahlen muss. Wenn wir versagen, tja, dann werde ich eben ein anderes Projekt verfolgen, anstatt in das Geschäft mit der proprietären Software einzusteigen. Davon abgesehen kann ich mir nicht vorstellen, dass irgendeiner der Entwickler aus dem Kern von Ubuntu oder die Community mit dabei wären, wenn ich so verrückt wäre und das versuchen würde.

Wenn Ihnen das nicht reicht, dann wird es Sie freuen zu hören, dass Canonical Verträge mit der Regierung unterzeichnet hat, die besagen, dass es nie eine »kommerzielle« Version von Ubuntu geben wird. Es wird nie einen Unterschied zwischen dem »kommerziellen« und dem »freien« Produkt geben, wie es bei Red Hat (RHEL und Fedora) der Fall ist. Ubuntu-Releases werden immer umsonst zu haben sein.

Das heißt aber nicht, dass Sie nicht für Ubuntu oder etwas, das Ubuntu-Code enthält, zahlen können, wenn Sie wollen. Linspire, das kostenpflichtig ist, enthält bereits Ubuntu-Code. Obwohl Linspire (bisher) nicht direkt auf Ubuntu basiert, ist es nicht unmöglich, dass die Linspire-Leute auf die Idee kommen, das lieber früher als später zu tun. Es ist durchaus wahrscheinlich, dass es viele spezielle Ubuntu-Versionen unter anderen Markennamen geben wird, die kommerzielle oder proprietäre Merkmale besitzen. Dies könnten beispielsweise proprietäre Schriftarten oder Add-ons oder auch die Integration von Diensten usw. sein. Es ist außerdem anzunehmen, dass es eine Menge proprietärer Software für Ubuntu geben wird (davon gibt es inzwischen einige – zum Beispiel wurde kürzlich Opera für Ubuntu angekündigt). Aber weder Canonical noch ich selbst noch der Ubuntu-Community-Rat oder der technische Vorstand werden eine »Ubuntu Professional Edition (XX,00 $)« herausbringen. Es wird ganz sicher kein »Ubuntu Vista« geben.

Wenn Sie keine kommerzielle »Ubuntu Professional Edition« herausbringen,wie kann Ubuntu zukunftsfähig sein?

Wir haben ein erstes Einkommen aus Diensten, die mit Ubuntu in Verbindung stehen. Wir haben Verträge über die Erstellung von maßgeschneiderten Distributionen abgeschlossen und nehmen an groß angelegten Ausschreibungen für große Linux-Einsätze teil, üblicherweise in Kooperation mit Firmen aus der

Region. Unsere Aufgabe ist dabei der Support. Zusätzlich zur weiten Verbreitung von Ubuntu in Entwicklungsländern ist es gut möglich, dass Ubuntu bald überall auf dem Moffett Field der NASA läuft ... Wir haben also die Basis eines zukunftsfähigen Projektes geschaffen, und ich bin zuversichtlich, dass wir eine echte Chance haben, Ubuntu an den Punkt zu bringen, an dem es sein eigenes Wachstum finanziert.

Wie genau das alles von einem geschäftlichen Standpunkt aus aussehen wird, ist schwer zu sagen. Ich kann das nicht beantworten – was in Ordnung ist, da dies ein risikoreiches Unternehmen ist, das sich immer noch in einer frühen Entwicklungsphase befindet. Deshalb erwarte ich nicht, die Antworten zu kennen. Meine Investition in Ubuntu (zumindest das Geld, das wir für Open-Source-Entwicklung und Tools wie Launchpad für Open-Source-Entwickler ausgeben) kann ich persönlich philantropisch begründen, weil ein Großteil meines Glücks und meines Wohlstands nur durch die Verwendung von Open-Source-Tools entstanden ist. Ich schätze mich glücklich, einen Teil davon der Community zurückgeben zu können.

Gegenwärtig verdienen wir etwas Geld damit, dass wir Zertifizierungsdienste anbieten (Zertifizierung von Entwicklern, Administratoren, Anwendungen und Hardware) sowie kundenspezifische Anfertigungen (Sie wollen Ihre eigene auf Ubuntu basierende Distribution? Reden wir darüber.) Die Nachfrage nach diesem Service wächst. Ich bin mir ziemlich sicher, Canonical auf dieser Basis kostendeckend arbeiten lassen zu können. Und das reicht mir, denn es bedeutet, dass Ubuntu weiterhin für Aufruhr sorgen wird, selbst wenn ich beschließe, dass es Zeit ist, zurück ins All zu gehen, und dabei die falsche Sojus erwische.

Es ist auch wichtig, zwischen Canonical, dem profitorientierten Servicebetrieb, und der Ubuntu Foundation, die ihr Kapital von mir auf einer Non-Profit-Basis erhalten hat, zu unterscheiden, um die Arbeit mit Ubuntu fortzuführen. Mit der Gründung der Ubuntu Foundation habe ich im Grunde gesagt: »O. K., dieses Projekt hat Hand und Fuß, ich stecke genügend Kapital hinein, um das Ganze eine längere Zeit am Laufen zu halten, egal was mit mir oder Canonical geschieht.« Wir haben also jede Menge Zeit, um die Zukunftsfähigkeit des Projekts zu entwickeln. Wenn Sie an dieser Front mithelfen wollen, schicken Sie Canonical Arbeit, wenn Sie das nächste Mal etwas mit Ubuntu erledigt haben wollen. Wir werden Sie nicht im Stich lassen.

Wie sieht es mit der Programmkompatibilität zwischen den Distributionen aus?

Es wurde schon viel darüber diskutiert, dass Debian nicht kompatibel mit Ubuntu ist. Manchmal zeigt sich das als »Ich kann keine Ubuntu-Pakete unter Debian installieren«, manchmal eher als die Frage »Warum verwendet Ubuntu GCC 4, wo doch Debian GCC 3.3 benutzt?« oder als die Frage »Warum sind der Kernel und glibc von Ubuntu 5.04 andere als in Debian Sarge?«. Ich werde versuchen, auf alle diese Fragen einzugehen.

Ich werde mit unserer grundlegenden Politik und Herangehensweise beginnen und dann auf einige der obigen Beispiele näher eingehen.

Zunächst muss gesagt werden, dass »Programmkompatibilität« für verschiedene Menschen verschiedene Bedeutungen hat. Falls Sie die Verhandlungen rund um den LSB-Standardprozess verfolgt haben, werden Sie verstehen, wie schwierig eine aussagefähige Definition des Begriffs über die Distributionsgrenzen hinweg ist. Im Wesentlichen ist das der Grund, warum wir uns »Programmkompatibilität« bei Ubuntu nicht als Ziel gesetzt haben. Manchmal kommt das zwar vor, aber das ist dann zufällig oder weil sich die Gelegenheit dazu ergab – nicht weil es ein spezielles Ziel wäre.

Um es ganz klar zu machen: Wir streben keine »Programmkompatibilität« mit irgendeiner anderen Distribution an. Warum?

Kurz gesagt, weil wir an freie Software als einen gemeinschaftlichen Prozess glauben, der auf Quellcode basiert. Wir betrachten sie als dem auf spezifische Anwendungen und Binärzeichen fokussierten proprietären Prozess überlegen. Wir haben entschieden, den größten Teil unserer Energie in die Verbesserung des fast überall und frei erhältlichen Quellcodes zu investieren, anstatt Arbeit in Binärzeichen zu stecken, die nicht so weitgehend geteilt werden können. Wenn wir Stunden an einem Feature arbeiten, dann wollen wir, dass diese Arbeit von so vielen Distributionen wie möglich genutzt werden kann. Deshalb veröffentlichen wir den Quellcode in »Realtime«, sobald wir neue Paketversionen veröffentlichen. Wir unternehmen große Anstrengungen, um diese Korrekturen in einem leicht zu findenden Format verfügbar zu machen, damit sie den Upstreams und anderen Distributionen nützlich sein können. Davon profitiert Debian, aber auch SUSE und Red~Hat, wenn sie willens sind, die Zeit in das Studium und die Anwendung der Korrekturen zu investieren.

Wir synchronisieren unsere Entwicklung regelmäßig mit Upstream, mit Debian und mit anderen Distributionen wie SUSE, Gentoo, Mandrake und Red Hat. Wir beziehen Code von den neuesten Upstreams (der teilweise weder in Debian noch in Red Hat enthalten ist noch in der LSB behandelt wird). Wir versuchen, gleichzeitig mit Debian Unstable (auch als Sid bekannt) alle sechs Monate zu veröffentlichen. Wir haben keine Kontrolle über die Release-Prozesse anderer Distributionen oder Upstreams. Daher ist es uns nicht möglich, ein API oder ABI für jedes Release im Voraus zu definieren.

Jedes Mal, wenn wir Ubuntu in der Vorbereitung auf eine neue Version »einfrieren«, sind wir Hunderten anderer Entwickler ausgeliefert. Obwohl die Ubuntu-Community Substanz besitzt und schnell wächst, ist sie immer noch winzig im Vergleich zur Gesamtzahl der Entwickler, die an den ganzen freien Anwendungen arbeiten, die die Distribution selbst ausmachen. Unsere Aufgabe ist es, das Verfügbare effizient und zusammenhängend zu bündeln und nicht zu versuchen, es in eine Kompatibilitätsform zu pressen. Wir konzentrieren uns darauf, die neuesten, aber stabilen und ausgefeilten Versionen der besten Open-Source-Anwendungen für Ihren Server oder Desktop zu liefern. Wenn wir Programmkompatibilität (egal in welchem Ausmaß) die höchste Priorität geben würden, würde dies unsere Fähigkeit einschränken, neuere Software zu liefern oder bessere Integration und den letzten Schliff zu bieten. Und wir sind der Meinung, dass es unseren Usern am wichtigsten ist, die besten und bestintegrierten Anwendungen auf CD zu bekommen.

Erwähnenswert ist, dass der Linux-Kernel selbst denselben Weg geht: Die »Programmkompatibilität« wird zugunsten eines »maßgeschneiderten Kernels aus einem Guss« vernachlässigt. Jeder Kernel-Release erfordert, dass er getrennt von vorherigen Releases kompiliert wird. Module (Treiber) müssen mit dem neuen Release neu kompiliert werden, sie können nicht einfach in ihrer Binärform genutzt werden. Linus hat besonders betont, dass der monolithische Kernel – der auf Quellcode basiert und nicht versucht, eine binäre Schnittstelle für Treiber über die Releases hinweg aufrechtzuerhalten – besser für den Kernel ist. Wir glauben, dass das auch für die Distribution gilt. So setzt das Gebot, mit sehr aktuellem Code zu arbeiten, die Idee der Kompatibilitätspflege mit einem spezifischen ABI außer Kraft. Insbesondere, wenn wir wenig oder nichts im ABI zu sagen haben, sollten wir versuchen, damit kompatibel zu bleiben.

Ich habe aber gehört, dass Ubuntu weniger kompatibel als vergleichbare Projekte ist?

Das stimmt absolut nicht. Wenn Sie den Kernel oder X-Server oder Clients oder libc oder Compiler verändern, dann haben Sie sich im Endeffekt selbst inkompatibel gemacht. Und soweit ich weiß, hat jede Distribution von Bedeutung mit gutem Grund Arbeit in diese Komponenten gesteckt, um sicherzustellen, dass sie die Bedürfnisse ihrer User erfüllt. Währenddessen machen sie sich selbst »programminkompatibel«. Was die Arbeit mit Open Source trotzdem so interessant macht, ist die Tatsache, dass sich Quellcode und Patches üblicherweise distributionsübergreifend verbreiten. Dies ist der Grund, warum wir uns darauf konzentrieren und nicht auf die Binärzeichen.

Einige Leute sagen vielleicht: »Aber ich habe ein Linspire-Paket unter Ubuntu installiert, und es funktionierte. Also müssen sie kompatibel sein.« Und ja, in vielen Fällen wird ein Binärpaket von Linspire oder Debian ganz einfach funktionieren. Aber das ist »unbeabsichtigte Kompatibilität«, keine »zertifizierte Programmkompatibilität«. »Ihr individueller Gebrauch kann von den Herstellerangaben abweichen« – das ist nicht die Art von Sicherheit, die die meisten Leute akzeptieren würden, und kann auch kaum als »Kompatibilität« bezeichnet werden. Viele Pakete haben sehr simple Abhängigkeiten und erfordern eigentlich keine bestimmten Versionen von Systembibliotheken – sie können durchaus problemlos funktionieren. Aber wenn man sich das Ganze genauer anschaut, dann findet man Programminkompatibilität in jedem Distributionsabkömmling von Bedeutung – von Knoppix über Linspire und den DCC bis zu Ubuntu.

Es ist möglich, nur mit Paketen aus anderen Distributionen eine neue Distribution zu entwickeln, und das ist auch nützlich. Es ist wie mit dem CDD-Projekt – und wird in Zukunft auch in der Ubuntu-Welt Bedeutung haben. Aber es ist grundsätzlich nicht besonders interessant – es ist nur ein Selektieren von Paketen, das einer bestimmten Usergruppe nützen mag, aber die Open-Source-Technik nicht voranbringt.

O. K., warum kompilieren Sie Pakete neu?

Wir stellen sicher, dass Ubuntu vollständig mit der Standard-Tool-Ausstattung von Ubuntu erstellbar ist. Normalerweise setzen wir eine neue Version von GCC in Ubuntu ein, und mit Sicherheit eine neuere Version als Debian. So stellen wir sicher, dass wir alle Pakete in Ubuntu mit dieser neuen Version erzeugen.

Theoretisch sollte die Verwendung von neueren GCC-Versionen auch bessere Programme erzeugen (obwohl in der Vergangenheit in einigen GCC-Versionen auch Rückschritte die Basis für spätere Fortschritte bildeten). Außerdem erlaubt sie uns, mit ABI-Veränderungen umzugehen, besonders im C++-Code, und die Zahl der ABI-Pakete, die wir im Archiv herumliegen haben, zu reduzieren.

Das gilt genauso für Pakete aus dem »Universe«-Repository, das die Tausende von Paketen in Ubuntu, die von Debian kommen, einschließt, obwohl es auch alternative Quellen gibt. Das MOTU-Team (»Masters of the Universe«) von Ubuntu kümmert sich um diese Pakete und stellt sicher, dass die ABI-Wechsel und (zum Beispiel) die Python-Versionswechsel auch dort vorgenommen werden. Um die Konsistenz zu gewährleisten, werden alle diese Pakete ebenfalls neu erstellt.

Wie wäre es mit ein paar konkreten Beispielen?

Es gibt einige gute Beispiele von anderen Distributionen, die dasselbe tun. Da sich Ian Murdock und Progeny darüber lautstark geäußert haben, lassen Sie uns dort beginnen. Progeny 1.x war nicht »programmkompatibel« mit dem damaligen stabilen Debian-Release. Ja, in der Tat. Das aktuelle »DCC

Alliance«-Release verwendet einen anderen Kernel und libc als Debian Sarge. In beiden Fällen allerdings werden Quellcode-Patches von diesen Projekten zu Ubuntu (und zu Debian) übertragen, und wir sind froh, sie zu verwenden. Das ist es, was die Open-Source-Entwicklung ausmacht: Fokussierung auf den Quellcode und Zusammenarbeit rund um den Code selbst – das ist produktiver als proprietäre Entwicklung.

Es liegt nicht in meiner Absicht, die anderen Distributionen schlecht zu machen. Doch es ist bemerkenswert, dass die Leute, die am lautesten nach »Programmkompatibilität« rufen, diese in ihrer eigenen Arbeit fröhlich ignorieren. Denn in der Open-Source-Welt ist sie ganz einfach nicht so wichtig und als ein Ziel höchster Priorität auch nicht praktikabel.

Warum war Ubuntu 5.04 (»Hoary Hedgehog«) nicht »programmkompatibel« mit DebianSarge?

Es gibt viele Leute, die keine Probleme mit dem Paketaustausch zwischen Ubuntu 5.04 und Sarge haben, diese sind aber nicht völlig kompatibel. Sie besitzen kleine, aber bedeutende Unterschiede in den libc-Versionen. Als Ubuntu 5.04 veröffentlicht wurde, war es mit der damaligen »deep freeze«-Sarge-Version kompatibel. Nach dem Release von Hoary wurde eine Änderung von Debian vorgeschlagen. Um diese zu implementieren, musste das Debian-Team die Kompatibilität mit Hoary aufgeben. Dies wurde öffentlich diskutiert, und die Entscheidung fiel zugunsten der Änderung aus. Wir (von Ubuntu) glauben, dass diese Entscheidung absolut richtig von Debian war. Es geht um Open Source, und wir können effektiv zusammenarbeiten, wenn wir uns auf den Quellcode konzentrieren. Hätte Debian sich verpflichtet gefühlt, die Änderung nicht einzupflegen, um die Kompatibilität mit Ubuntu zu bewahren, dann hätte die Open-Source-Welt darunter gelitten.

Soweit es also eine Programmkompatibilität zwischen diesen zwei Releases gibt, wurde sie nicht vom Ubuntu-Team eingeführt. Im Gegenteil, wir unterstützten aktiv den Entscheidungsprozess, der zu der Inkompatibilität führte – das ist es, was Open Source stark macht.

Was ist mit dem Wechsel zu GCC 4.0? Warum haben Sie GCC 4.0 übernommen?

Wir sind stets bemüht, die neuesten stabilen Entwicklungswerkzeuge, Bibliotheken und Anwendungen einzubinden. GCC 4.0 wurde zu Beginn des Breezy-Entwicklungszyklus veröffentlicht, deshalb war es die geeignete Compiler-Wahl für dieses Release. Das bedeutete, dass unter Breezy kompilierte C++-Anwendungen standardmäßig ein anderes Application Binary Interface (ABI) zu den entsprechenden unter Sarge (das GCC 3 benutzt) kompilierten Bibliotheken haben.

Dieses Thema wurde mit den Entwicklern der Debian-Tool-Kette besprochen, die ebenfalls planten, GCC 4.0 zu gegebener Zeit zu übernehmen. Man kam überein, Programmpakete, die mit GCC 4.0 kompiliert wurden, besonders zu benennen, so dass Übernahme und Upgrade für User, die von vorherigen Versionen von Ubuntu (oder Debian) aktualisieren, elegant möglich sind. Das Ubuntu-Team ging voran und bereitete den Weg, indem es Patches für Hunderte von Paketen bereitstellte, um die vereinbarte Namensgebung für GCC 4.0 vorzunehmen. Diese Patches sind allen Debian-Entwicklern zugänglich und machen die GCC-4.0-Übernahme in Debian sehr viel einfacher.

Warum ist der Standard-Desktop von Ubuntu braun?

Das alles überspannende Thema der ersten Reihen von Ubuntu-Releases ist »Menschlichkeit«. Dies bestimmt unsere Wahl des Artworks genauso wie unsere

Auswahl der Pakete und Entscheidungen rund um den Installer. Unser Standard-Theme in den ersten vier Ubuntu-Versionen heißt »Menschlichkeit« und betont warme, menschliche Farben – braun.

Ja, das ist in einer Welt voller blauer und grüner Desktops recht ungewöhnlich, und das Mac OS X ist zum Küchengerät geworden. Zum Teil gefiel uns die Tatsache, dass Ubuntu anders, wärmer ist. Der Computer ist nicht länger nur ein Gerät, er ist eine Erweiterung Ihres Geistes, Ihr Gateway zu anderen Menschen (per E-Mail, VoIP, IRC und über das Internet). Wir wollten ein einmaliges, bemerkenswertes, beruhigendes und vor allem menschliches Gefühl vermitteln. Wir haben uns für Braun entschieden, was eine ziemlich riskante Sache ist – um Braun zu erzeugen, muss Ihr Bildschirm zarte Schattierungen von Blau, Grün und Rot erzeugen. Selbst leichteste Abweichungen von der Norm können das »Braun« gewaltig verändern. Doch heutzutage sind die Monitor- und LCD-Bildschirm-Standards so einheitlich, dass wir das Risiko als akzeptabel ansahen. In Hoary und Breezy haben wir aufgrund des Feedbacks von Lower-End-Laptop- und LCD-Bildschirm-Nutzern ein kräftigeres, rötliches Braun verwendet.

Wird Braun immer die Standard-Desktop-Farbe bleiben?

Es ist unwahrscheinlich, dass die Farbe des Desktops für immer unverändert bleibt, schließlich erwarten wir, dass es Ubuntu eine lange Zeit geben wird. :-)

Gegenwärtig planen wir, dass der »Dapper Drake« (Ubuntu 6.04, wenn wir unser Release-Datum April 2006 einhalten) der letzte der ersten »Serie« von Versionen wird. So können wir anschließend ein neues »Feeling« oder übergreifendes Theme definieren. Es wird höchstwahrscheinlich nicht ... blau sein. Aber es kann gut sein, dass es sich grundlegend vom aktuellen Menschlichkeits-Theme unterscheidet. Momentan wollen wir uns auf den Weg zu Dapper konzentrieren und dem existierenden Human-Theme den letzten Schliff verpassen und danach neue Wege beschreiten.[Fn. Anmerkung: Dieser Absatz ist inzwischen veraltet. Das Aussehen von Ubuntu hat sich in der Zwischenzeit mehrfach geändert.]

Ist Ubuntu ein Debian-Ableger?

Ja, Ubuntu ist ein Ableger. Nein, ist es nicht. Doch, ist es! Ach, was auch immer. Kurz gesagt sind wir ein Projekt, das mit vielen anderen Projekten zusammenzuarbeiten versucht – so wie Upstream X.org, GNOME und natürlich Debian. Häufig ist der Code, den wir ausliefern, verändert oder anders als der Code, der von den anderen Projekten ausgeliefert wird. Wenn das geschieht, bemühen wir uns sehr, dass unsere Änderungen in einem geeigneten, für andere Entwickler leicht zu verstehenden und einzubindenden Format weit verbreitet werden.

Wir haben große Anstrengungen unternommen, um Entwicklungswerkzeuge zu entwerfen, die eine Zusammenarbeit mit Ubuntu einfach machen und uns helfen, mit Upstreams und anderen Distributionen zusammenzuarbeiten. Zum Beispiel gibt es einen automatischen »Patch Publisher«, der Debian-Entwicklern zeigt, welche Patches für ihre Pakete für Ubuntu erhältlich sind. Es ist sehr einfach für sie zu entscheiden, welche Patches sie wollen und welche nicht. Und natürlich ist es für uns sehr viel einfacher, wenn sie sie anwenden, aber dazu können wir sie nicht zwingen. Viele der Patches sind nur in Ubuntu sinnvoll. Als Nebeneffekt sind diese Patches auch für Gentoo, Red Hat, Linspire (ja, ehrlich) und SUSE erhältlich. Und wir wissen, dass sie sich die ansehen und einige verwenden – was völlig in Ordnung ist.

Doch die Zusammenarbeit geht über Patches hinaus. Wir haben Malone entwickelt, einen »Bug-Tracker«, der eine Zusammenarbeit zwischen Ubuntu und anderen Distributionen beim Beseitigen von Bugs herzustellen versucht. Jeder Bug kann an vielen verschiedenen Orten gefunden werden, und an einem einzigen Ort kann man den Status des Bugs an allen Orten einsehen. Das ist echt klasse.

Eines der Dinge, die mich dazu gebracht haben, mit dem »Kosmonauten-Playboy-internationaler-Schürzenjäger-des-Geheimnisvollen«-Spiel aufzuhören und Ubuntu ins Leben zu rufen, war die Notwendigkeit von Tools wie TLA, das eine noch bessere Zusammenarbeit zwischen den Distributionen und Upstreams am Quellcode versprach. Also haben wir viel an TLA gearbeitet, bis es so verändert war, dass wir es »Bazaar« nannten. Anschließend haben wir ein grundlegendes Re-Write in Python gemacht, und heraus kam Bazaar-NG, oder Bzr, das bis März 2006 Bazaar 2.0 sein wird. Warum das wichtig ist? Weil das Herumreichen von Patches nicht halb so effektiv ist wie das Arbeiten in einem wirklich verteilten Revisionskontrollsystem. Viele der Ubuntu-Leute arbeiten an Tools wie Bazaar und HCT, nicht an der Distribution. Wir hoffen, dass das die effektive Art der Zusammenarbeit in der Open-Source-Welt beschleunigen wird. Die Zukunft wird es zeigen.

Zusammengefasst: Die Kompatibilität zwischen Ubuntu und Debian hat für uns keine Priorität. Unserer Meinung nach helfen wir der Open-Source-Welt mehr, wenn wir Patches anbieten, die Ubuntu- (und Debian-)Pakete besser funktionieren lassen, und eine topaktuelle Distribution anbieten, an der andere mitarbeiten können. Wir stecken eine Menge Energie in die Verbreitung und einfache Erreichbarkeit unserer Pakete für Entwickler aller anderen Distributionen genauso wie in Upstream, weil wir glauben, dass unsere Arbeit so den größten Langzeiteffekt haben wird. Und wir entwickeln Tools (siehe Bazaar, Bazaar-NG, Launchpad, Rosetta und Malone), die, wie wir hoffen, die Zusammenarbeit am Quellcode noch effizienter machen werden.

Was das Aufspalten der Community angeht: Die Ubuntu-Community ist sehr schnell gewachsen, einige Leute befürchten, dass dieses Wachstum zu Lasten der anderen Open-Source-Communitys, besonders Debian, gehen könnte.

Unter den gegebenen Umständen, dass Patches so einfach zwischen Ubuntu und Debian hin und her fließen, scheint es mir besser für beide Projekte zu sein, dass wir unsere gesamte Entwicklergemeinschaft möglichst groß machen. Ubuntu profitiert von einem starken Debian und Debian von einem starken Ubuntu. Das gilt besonders deshalb, weil die beiden Projekte etwas unterschiedliche Ziele haben. Ubuntu wird neue Anwendungsfelder schneller erschließen, und Debian profitiert stark von den Patches. (Schauen Sie sich nur einmal die Changelogs von Debian Sid seit den Sarge-Releases an, dann sehen Sie, wie viele Bezüge zu Ubuntu sich darin befinden. Und das sind nur die Fälle, in denen »danke« gesagt wurde.)

Würden die Ubuntu- und Debian-Communitys in derselben Weise funktionieren, dann hätten diese Bedenken mehr Substanz, weil wir dieselben Leute ansprechen würden. Das würde bedeuten, dass wir um Können konkurrieren. Aber die beiden Communitys sind sehr unterschiedlich. Die Organisation ist anders, und wir haben verschiedene Prioritäten – was dazu führt, dass wir verschiedene Typen von Entwicklern anziehen.

Klar, es gibt bestimmt Debian-Entwickler, die den Großteil ihrer Arbeit an Ubuntu verrichten. Genauso gibt es Entwickler, die an Ubuntu und Debian gleich viel arbeiten. Aber der Großteil der Ubuntu-Community besteht aus Entwicklern, die sich von der Art, wie Ubuntu Dinge tut, angesprochen fühlen. Es wird immer etwas Abwanderung und Bewegung zwischen den Communitys geben, aber das ist nur gut, weil es gute Ideen verbreiten hilft.

Was geschieht, wenn der Erfolg von Ubuntu zum Tod von Debian führt?

Das wäre sehr schlecht für Ubuntu, denn jeder Debian-Entwickler ist auch ein Ubuntu-Entwickler. Wir stimmen unsere Pakete regelmäßig auf Debian ab, weil das die neueste Arbeit, den neuesten Upstream-Code und die neuesten Paketentwicklungen einer großen und kompetenten Open-Souce-Community implementiert. Ohne Debian wäre Ubuntu nicht machbar. Doch der Weg von Debian ist nicht gefährdet, es bekommt viel mehr Aufmerksamkeit, seit Ubuntu gezeigt hat, was alles in dieser Community verwirklicht werden kann.

Warum gehört Ubuntu nicht zur DCC-Allianz?

Ich glaube nicht, dass die DCC Erfolg haben wird, obwohl ihre Ziele hochfliegend und rühmlich sind. Die Teilnahme wäre teuer und würde uns verbieten, die neuen Features, den Glanz und die Integration einzupflegen, die wir in neuen Versionen wollen. Ich bin nicht bereit, knappe Ressourcen einer Initiative zu opfern, die nach meiner Überzeugung unweigerlich fehlschlagen wird. Es ist zwecklos, hier auf die genauen Gründe für meine Überzeugung einzugehen – die Zeit wird es zeigen. Ich würde die Mitglieder der Ubuntu-Community ermutigen, an den DCC-Diskussionen teilzunehmen, sofern sie Zeit und Interesse daran haben. Sollte die DCC guten Code produzieren, dann sollten wir den in die Ubuntu-Releases aufnehmen, und das sollte einfach sein.

Warum haben Sie Ubuntu gegründet, anstatt Debian Geld zu geben?

Ich habe viel darüber nachgedacht, wie ich am besten einen Beitrag zur Open-Source-Welt leisten kann, wie ich am besten den Einfällen, die mich am meisten interessieren, nachgehen kann: Zum Beispiel, was der beste Weg ist, um Open Source auf den Desktop zu bringen. Eine Möglichkeit war, der Position des DPL (»Ich bin ein DD, erster Entwickler von Apache 1996 blabla ...«) zu folgen und diese Ideen in Debian einzubringen. Doch ich entschied mich, eine parallele Distribution ins Leben zu rufen und eine Infrastruktur zu finanzieren, um die Zusammenarbeit zwischen Distributionen viel effizienter zu gestalten.

Warum?

Erstens: Viele der Dinge, die mir vorschwebten, schlossen eine Verringerung des Spielraums der Distribution ein. Das würde ihren Nutzen für einen Teil von Leuten vergrößern, ihn aber auf der anderen Seite für andere verkleinern. Beispielsweise unterstützen wir momentan nur drei Architekturen von Ubuntu. Das ist toll für die Leute, die eine dieser Architekturen verwenden, aber offensichtlich nicht so praktisch für die, die etwas anderes verwenden.

Des Weiteren unterstützen wir etwa 1.000 Kernanwendungen unter Ubuntu. Dies sind die Herzstücke, die die Hauptanteile für Ubuntu, Kubuntu und Edubuntu darstellen. Alles andere ist über Universe oder Multiverse zugänglich, wird aber nicht offiziell unterstützt.

Mir wurde nach und nach klar, dass dies der falsche Weg für Debian war, das einen Großteil seiner Stärke aus seiner »Universalität« zieht. Es war sinnvoller, diese Vorhaben in einem eigenen Projekt durchzuführen. Wir können für diese Dinge Pionierarbeit leisten und uns darauf konzentrieren; die Patches sind sofort für die DDs verfügbar, die sie ebenfalls geeignet für Debian halten.

Zweitens: Das Problem des »Teilens zwischen Distributionen« ist sehr interessant. Momentan neigen wir dazu, die Welt als Upstream, Distro und Abkömmlinge zu sehen. In Wirklichkeit besteht die Welt mehr aus einem Bündel verschiedener Projekte, die zusammenarbeiten müssen. Wir müssen mit Debian zusammenarbeiten, aber wir sollten auch in der Lage sein, mit Upstream und Gentoo zusammenzuarbeiten. Mit Red Hat ebenfalls. Wir müssen herausfinden, wie eine effektive Zusammenarbeit mit Distributionen möglich ist, die ein ganz anderes Paketsystem verwenden als wir. Denn die Zukunft der

Open-Source-Welt liegt in einer wachsenden Zahl an Distributionen, von denen jede die Bedürfnisse einer kleinen Gruppe erfüllt – je nach ihrem Job, ihrer kulturellen Identität, der Institution, für die sie arbeiten, oder ihren persönlichen Interessen.

Das Problem der Zusammenarbeit der Distros zu lösen, würde Open Source sehr voranbringen. Also ist es das, was wir mit Ubuntu erreichen wollen. Wir arbeiten an Launchpad, das ist ein Webservice für die gemeinsame Arbeit an Bugs, Übersetzungen und technischem Support. Wir arbeiten an Bazaar, einem Revisionskontrollsystem, das Zweige und Distributionen versteht und in Launchpad integriert ist. Wir hoffen, dass diese Tools unsere Arbeit leicht verfügbar für Debian, Gentoo und Upstream machen. Und sie erlauben uns ebenfalls, gute Arbeit von anderen Distros zu nehmen (selbst wenn diese es lieber hätten, wenn wir das nicht täten ;-)).

Schließlich scheint es mir, dass der schwierige Part nicht das Verfügbarmachen von Geldern ist, sondern vielmehr, diese an Leute und Projekte zu verteilen. Ich könnte ganz einfach einen Scheck auf SPI, Inc. ausstellen, über denselben Betrag, den ich in Ubuntu investiert habe. Aber wer würde entscheiden, wofür das Geld verwendet wird? Haben Sie etwa die Jahresabschlussberichte von SPI, Inc. der letzten Jahre gelesen? Wer würde bestimmen, wer einen Vollzeitjob bekommt und wer nicht? Wer würde entscheiden, welche Projekte weiterhin finanziert werden und welche nicht? So sehr ich auch die Führung und soziale Struktur von Debian bewundere – ich glaube nicht, dass die Verteilung von Geldern an Debian effektiv wäre. Ich glaube nicht, dass dieselbe Produktivität herauskäme, die wir bisher im Ubuntu-Projekt erreichen konnten.

Die Vermischung von Finanzierung mit ehrenamtlicher Arbeit führt zu allen möglichen Problemen. Fragen Sie Mako[Fn. Benjamin Mako Hill war einer der Gründungsmitglieder von Ubuntu.] nach dem Experiment, das zeigt, dass diese Schwierigkeiten in unseren Genen verankert sein könnten. Es gibt schwerwiegende soziale Schwierigkeiten in Projekten, die bezahlte Vollzeitarbeit mit ehrenamtlicher verbinden. Ich bin nicht sicher, ob Debian diese Art der Herausforderung gebrauchen kann. Man kann sehr schnell in ernsten Streit darüber geraten, wer Geld verteilen und Leute engagieren und wer über die Finanzierung von Vorhaben entscheiden darf und wer nicht. Eines der Dinge, die meiner Meinung nach Debian seine wahre Stärke verleihen, ist der Sinn für »Unbeflecktheit«. Bis zu einem gewissen Grad hat die Tatsache, dass Ubuntu Debian keine Änderungen aufzwingt, Debians gesunde Reputation gestärkt.

O. K., aber warum nennen Sie es dann nicht einfach »Debian für Desktops«?

Weil wir die Markenpolitik von Debian respektieren. Möglicherweise haben Sie kürzlich die verwirrenden Verzerrungen um die Definition der »DCC Alliance« verfolgt – ein Beispiel dafür, was geschieht, wenn Leute das nicht tun. Ganz einfach ausgedrückt ist das Ubuntu-Projekt nicht Debian, also hat es auch kein Recht auf diesen Namen. Und die Verwendung des Namens würde Debians eigenen Markennamen schwächen. Abgesehen davon gefällt uns der »Menschlichkeits«-Aspekt des Namens Ubuntu, also haben wir uns für ihn entschieden.

Wo wir gerade bei der Namensgebung sind: Was hat es mit dieser »Funky Fairy« (»Irre Fee«) Nomenklatur auf sich?

Der offizielle Name von jeder Ubuntu-Version lautet »Ubuntu X.YY«, wobei X die letzte Ziffer der Jahreszahl und YY den Monat des Release in dem betreffenden Jahr bezeichnet. Die erste Version, die im Oktober 2004 herauskam, heißt also »Ubuntu 4.10«.

Der Entwicklungsname einer Version besitzt die Form »Adjektiv Tier«. Zum Beispiel sind »Warty Warthog« (Ubuntu 4.10, »warziges Warzenschwein«), »Hoary Hedgehog« (Ubuntu 5.04, »altersgrauer Igel«) und »Breezy Badger« (Ubuntu 5.10, »Frechdachs« oder »frecher Dachs«) die Namen der ersten drei Ubuntu-Versionen. Im Allgemeinen wird die Version mit dem Adjektiv bezeichnet, wie »Warty« oder »Breezy«.

Viele vernünftige Menschen haben sich gefragt, warum wir uns für dieses Benennungsmuster entschieden haben. Es entstand aus einem Scherz auf einer Fähre zwischen Circular Quay und irgendwo in Sydney:

lifeless: Wie lange haben wir noch bis zum ersten Release?
sabdfl: Das muss was Schlagkräftiges sein. Höchstens sechs Monate.
lifeless: Sechs Monate! Das ist nicht viel Zeit für den letzten Schliff.
sabdfl: Na, dann wird das eben das »Warty-Warthog-Release«.

Und voil\`a, der Name blieb. Die erste Mailingliste für das Ubuntu-Team erhielt den Namen »Warthogs«, und wir pflegten auf #warthogs auf irc.freenode.net herumzuhängen. Für die folgenden Versionen wollten wir an den »hog«-Namen festhalten, also kamen wir auf »Hoary Hedgehog« und »Grumpy Groundhog«. Aber »Grumpy« hörte sich nicht richtig an für eine Version, die richtig gut zu werden versprach und eine fantastische Beteiligung der Community hatte. Wir suchten also weiter und entschieden uns für »Breezy Badger«. Wir werden »Grumpy Groundhog« noch verwenden, aber diese Pläne sind noch eine Überraschung ...

An alle, die meinen, dass die gewählten Namen noch verbesserungsfähig wären: Sie werden möglicherweise erleichtert darüber sein, dass der »Frechdachs« ursprünglich ein »Bendy Badger« (»Gelenkiger Dachs«) werden sollte. (Ich finde immer noch, dass das »gerockt« hätte.) Es gab noch andere ...

Wir werden alles geben, um die Namen nach Breezy alphabetisch zu vergeben. Vielleicht werden wir Buchstaben überspringen, und irgendwann einmal werden wir einen Umbruch vornehmen müssen. Aber zumindest die Namenskonvention wird noch ein Weilchen bestehen bleiben. Die Möglichkeiten sind unendlich. »Gregarious Gnu« (»geselliges Gnu«)? »Antsy Aardvark« (»nervöses Erdferkel«)? »Phlegmatic Pheasant« (»phlegmatischer Fasan«)? Schicken Sie uns Ihre Vorschläge, wir ziehen sie in Betracht.

---

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

Name
E-Mail
Ihr Kommentar