Wahlrede von Branden Robinson

Einleitung

Ich bin seit in etwa Januar 1998 Debian-Entwickler. Meine bekannteste Arbeit in Debian ist die Betreuung der XFree86-Pakete, was ich nun seit beinahe sechs Jahren mache, seit März 1998. Seit August 2001 bis Februar dieses Jahres diente ich als Schatzmeister von Software in the Public Interest, Inc., Debians rechtlicher Mutterorganisation und Verwalter des Vermögens des Debian-Projekts in den USA. 2002 bin ich dem Debian-Team der Richtlinienhandbuch-Autoren beigetreten. Ich zähle auf der debian-legal Mailingliste zum Inventar und nehme gemeinsam mit anderen Entwicklern an der Untersuchung und Analyse von Bedingungen und Anmeldungen von verschiedenen Softwarelizenzen teil, und wie diese in die Debian-Richtlinien für Freie Software (DFSG) passen. Ich bin 29 Jahre alt, als Freier-Software-Entwickler angestellt, verheiratet, und habe keine Kinder.

Während des vergangenen Jahres war die Arbeit, auf die ich am stolzesten bin, die Umstellung der Debian-XFree86-Paketierung von einem Einzel-Einsatz auf einen Team-Einsatz. Dabei habe ich die tagtägliche Sichtbarkeit der Arbeit, die in die Debian-Pakete von XFree86 fließt, gewaltig erhöht, und die Integration von großen und kleinen Änderungen ist ebenfalls mit großen Schritten weitergekommen. Die öffentliche Verfügbarkeit eines Subversion-Depots erlaubt es jedem, es auszuchecken und die bevorstehenden Pakete zu bauen, saubere Patches einzuschicken und die Änderungen zu überprüfen, die wegen Fehlern vorgenommen werden. Der Umstieg bedeutete einiges an Arbeit, da er gleichzeitig mit der Paketbetreuung geschah, aber der Einsatz hat sich bereits durch größere Offenheit und Begutachtung ausgezahlt, und ich denke, es wird sich in Zukunft noch mehr auszahlen, durch größere Delegierung und Aufgabenteilung. Ich hebe diesen Einsatz deshalb hervor, da viele dieser Vorteile bei der Betreuung der Softwareentwicklung sich auch auf die Projekt-Betreuung umsetzen lassen, wie ich zeigen werde.

Zuerst werde ich meine Motivation erklären, warum ich mich beworben habe, und dann werde ich die Handlungen beschreiben, die ich vornehmen werde, wenn ich gewählt bin.

Wieso ich mich beworben habe

Wir benötigen Verbesserungen in unseren Abläufen.

Die meisten schlimmsten internen Debian-Konflikte (oder Flamewars) während der vergangenen Jahre haben sich um drei Probleme gedreht:

Viel zu häufig sehe ich, wie Diskussionen zu diesem Thema in Geschrei bezüglich zweier Alternativen übergehen: Person X lässt uns nichts daran tun gegen Die Dinge funktionieren recht gut, und deine Beschwerden machen es nicht besser.

Diese Sorte von Argumenten, meiner Meinung nach, und all die Zeit und Seiten von E-Mail-Texten, die dafür eingesetzt werden, gehen am Thema vorbei. Ich glaube, dass wir diese Auseinandersetzungen haben, da relevante Informationen zu schwierig zu bekommen sind, und dass es unzureichend entwickelte Foren zum Lösen von nicht-technischen Beschwerden oder Missständen gibt.

Einfacher ausgedrückt: Es ist zu schwer für jene, die keine Ahnung haben, eine Ahnung zu erhalten, und in Abwesenheit von passenden ablauftechnischen Mitteln für frustrierte Personen werden die Argumente persönlich. Das jedoch zwingt die Leute zur Verteidigung (manchmal von sich selbst, manchmal von anderen) und bringt die Gegenbeschuldigungs-Spirale außer Kontrolle.

Meiner Meinung nach machen wir im Schnitt einen angemessenen Job bei diesen Punkten. Falls sie wirklich schrecklich wären, würde Debian nicht funktionieren. Viele Leute finden, dass der Release-Zyklus zu langsam ist; das kann sein, aber man sollte sich auch an einige der vielen Freie-Software-Projekte (oder selbst Distributionen) erinnern, die es nicht mehr gibt, weil sie niemals die Version 1.0 erreicht haben, oder ihre Entwicklung nicht vertragen haben. Unser Prozess für neue Entwickler funktioniert für einige Leute ebenfalls zu langsam (und manchmal zu geheimnisvoll), jedoch geht auch dies um einiges besser als wenn wir gar keine neuen Entwickler in unser Projekt aufnehmen würden. Es sollte ebenfalls offensichtlich sein, dass von der Systembetreuung bis zu den Mailinglisten, den Build-Daemons und der Fehlerdatenbank die Dinge grundsätzlich funktionieren und sie im Wesentlichen auch ruhig ablaufen. Ich glaube, dass es unklug ist, überschaubare Probleme mit einem großen Aufsehen zu untersuchen; unglücklicherweise vermute ich, dass wir unwissentlich diese Art von Aufsehen ermutigen, da es für einige Leute die einzige Alternative ist, bei der sie sehen, dass sie nicht komplett ignoriert werden.

Gut ist gut, aber wir können besser sein. Angemessen ist angemessen, aber wir sollten nach Vortrefflichkeit streben. Ich freue mich darauf, uns besser zu machen bei dem, was wir tun.

Wir benötigen offenere und sichtbarere Abläufe.

Verbesserungen sind weniger wertvoll und werden weniger anerkannt oder selbst bemerkt, wenn sie im Geheimen passieren. Gleichermaßen ist schwer zu erkennen, was zu beheben ist, wenn es nicht klar ist, was falsch ist. Es ist schon passiert, dass die Verbesserungsvorschläge von Leuten verworfen wurden, da sie die zugrundelegenden Fakten nicht korrekt hatten. Obwohl ich sicherlich den Wunsch nach Korrektheit in den Beschwerden der Leute über unser Projekt nachempfinden kann, ist es nicht immer der Fall, dass ein sachlicher Fehler bei der Darlegung ein Problem als nichtig erklärt. Ich habe genügend Leute gesehen, die einen enormen Einsatz dabei zeigen, solche Fehler zu korrigieren und zu entkräften, oftmals in einem hochgradig irritierenden Tonfall.

Interaktive Kommunikation kann sehr ineffizient sein. In vielen Bereichen ist die Dokumentation darüber, wie unser Projekt funktioniert, nicht vorhanden, mangelhaft, unzugänglich oder einfach zu schwierig zu finden. Ich vermute, dass wir dabei helfen können, unsere vertrauenswürdigsten Infrastruktur-Betreuer von abgehobenen Kritiken fernzuhalten, indem wir sowohl die Präsenz von sachlichen Informationen, wie wir arbeiten, verbessern, als auch indem wir strukturiertere Methoden für das Weiterleiten solcher Beschwerden an die entsprechenden Personen definieren. Es wäre nett, wenn wir den Spreu vom Weizen – die fehlinformierten Beschwerden von den berechtigten – in einer offenen und sichtbaren Art trennen könnten, damit die Leute nicht nur sehen können, wie es funktioniert, sondern dass es funktioniert.

Wir benötigen einen Leiter, der unsere Anliegen meistert.

Bei meiner Arbeit hab ich das Privileg, mit Leuten aus der Industrie (und nicht nur in den USA) darüber zu sprechen, was sie von einer GNU/Linux-Distribution benötigen. Ich sehe dabei selten Fälle, bei denen dies keine Gelegenheit für eine Übernahme von Debian ist. (Die Ausnahmen sind Leute, die Red-Hat- oder SuSE-Kompatibilität suchen – oder das RPM-Paketformat – einzig allein wegen eben dem, und nicht, weil sie es mit einem Computer erledigen wollen.) Ich habe bemerkt, dass das Interesse an Debian während der vergangenen vier oder fünf Jahren gewaltig gestiegen ist. Debian hat viele Unterprojekte und kompatible Ableger hervorgebracht, die uns dabei helfen, den Universelles Betriebssystem-Spitznamen auszuleben.

Debian prescht vor, anscheinend überall; ich will diesen Prozess beschleunigen und Debian überall bewerben, wo ich kann. Ich sehe das Phänomen der Unterprojekte oder kompatiblen Ableger überhaupt nicht als eine Bedrohung an; stattdessen sind es die Perlen unseres Erfolges. Es ist meine Meinung, dass es in unserer Macht steht, Debian zum de facto Industriestandard zu machen; die Firma, für die ich arbeite, erreichte LSB-Kompatibilität mit einem Schnappschuss von Debian-Sarge im Januar. Ich war von Debian von dem Tag an begeistert, an dem ich ein Entwickler wurde, und ich bin immer noch davon begeistert. Des Weiteren kann ich diese Begeisterung und Aufregung auf ein Publikum übertragen.

Wir sollten unsere Satzung ernster nehmen.

Ich war enttäuscht, als ich im November erfahren hab, dass der aktuelle Projektleiter nicht glaubt, dass der Abgeordnetenprozess in unserer Satzung die Art ist, wie Debian wirklich funktioniert. Er charakterisierte eine Ablehnung, Delegierte der Archiv-Administratoren, System-Administratoren und so weiter zu bestellen, als pragmatisch. Ob dies etwas ist, das wahr ist, lasse ich unsere Entwickler und Benutzer selbst entscheiden, aber ich weiß, dass diese Einstellung entgegen unserer Satzung ist, wie ich sie verstehe. Unsere Website nennt die Debian-Satzung das Dokument, das für diese Organisation am allerwichtigsten ist. In Hinblick darauf sollten wir ihm etwas mehr Respekt zollen. Die Debian-Satzung erkennt sechs entscheidungstreffende Körperschaften oder Einzelpersonen: Die Entwickler (als Gruppe agierend durch einen Allgemeinen Beschluss), der Projektleiter, der technische Ausschuss, die an einer bestimmten Aufgabe arbeitenden einzelnen Entwickler, der Schriftführer des Projekts und die Abgesandten des Projektleiters.

Wir müssen den Delegierten-Prozess respektieren, oder ihn ändern. Ich glaube nicht, dass jede einzelne Aufgabe im Projekt das gleiche wie das Betreuen eines Pakets ist. Die Rollen der Archiv-Administratoren, Projekt-Keyring-Betreuer und Projekt-Systemadministratoren sind wichtig. In der Praxis unterscheiden wir diese Rollen von jener eines Paketbetreuers auf verschiedene Arten. Sie sind von spezieller Bedeutung und verdienen besondere Aufmerksamkeit. Ich glaube nicht, dass sie vernünftig in die selbe Kategorie eingeordnet werden können wie die einzelnen Paketbetreuer. Sie haben besondere Rechte und sollten besonders behandelt werden. Das Konzept der Delegierten in der Satzung wurde mit diesen Rollen im Hinterkopf entworfen. Dass kein früherer DPL diesen offensichtlichen Schritt getan hat, enttäuscht mich.

Die Debian-Satzung beschreibt den Prozess für die Wahl des Projektleiters. Dies wurde in der Erwartung niedergeschrieben, dass die Rolle wichtig wäre. Wir sollten einen sinnvollen Wettkampf zwischen den Kandidaten haben, da der Prozess uns dabei helfen wird zu verstehen, wer wir sind und wohin wir gehen. Ich würde mich nicht bewerben, wenn niemand Probleme sehen würde, die der Debian-Projektleiter zu lösen ermächtigt ist.

Ich wurde gebeten, mich zu bewerben.

Ich habe mich vergangenes Jahr in einem recht knappen dreigeteilten Rennen gut behauptet, und ich habe mich erneut aufgestellt, um zu sichern, dass den Bedürfnissen unserer Entwickler und Benutzer entsprochen wird. Der Wahlkampf ist für mich weder besonders erfreulich, noch erwarte ich, dass das Angehen der Probleme, die ich als nötig ansehe, sonderlich spaßig sein wird. Nachdem ich jedoch um die Meinung unserer Entwickler auf der debian-project Mailingliste gebeten habe, hatten mich viele per Mail gedrängt, mich zu bewerben, und sie hatten sehr übereinstimmende Ansichten, was im Projekt falsch läuft und was ich dagegen tun könne. Das sind Verantwortungen, die ich gerne auf mich nehme, da ich mich zu sehr um das Debian-Projekt sorge, als dass ich nicht alles dafür geben würde, was ich kann.

Was ich tun werde

Nachdem einige unserer Herausforderungen und Möglichkeiten ausgesprochen wurden, erscheinen die Lösungen ziemlich direkt.

Ich werde Mechanismen etablieren, um unsere Abläufe sichtbarer zu machen.

Ich installiere den Request Tracker (Debian-Paket request-tracker3) auf einem eigenen Rechner, der als Ombudsmann-Site (Streitschlichtung) dient. Die Debian-Fehlerdatenbank ist meiner Meinung nach nicht genügend flexibel, um Probleme zu behandeln, die nicht mit Software zu tun haben, und Mailinglisten, wie wir immer wieder gesehen haben, sind häufig eine armselige Alternative. Ich habe Erfahrungen mit der Verwendung von Request Tracker an meinem Arbeitsplatz, und es ist nicht schwierig zu lernen. Sollte sich dieses Experiment als erfolgreich herausstellen, werde ich mit den Debian-Systemadministratoren zusammenarbeiten, um die Installation auf einen Debian-Projekt-Rechner umzusiedeln. Zusätzlich (und mit größerer Betonung, falls dieses Experiment fehlschlägt) werde ich andere Wege beschreiten, um die Tätigkeiten unseres Projekts klar zu machen, wo sie zurzeit undurchsichtig sind.

Ich werde mit meinen Abgesandten, mit den Entwicklern, und mit den Benutzern zusammenarbeiten, um spezielle Bereiche zu finden, die Verbesserungen bedürfen, inklusive der Release-Betreuung und dem Prozess für neue Entwickler.

Ich werde den offensichtlichen Schritt tun, der im vorhergehenden Abschnitt beschrieben wurde, und den Abgesandten-Status von vielen wichtigen Leuten formalisieren, die kritische Arbeit für unser Projekt durchführen, sofern sie nicht bereits den Abgesandten-Status besitzen. Falls ich dies nicht tun kann oder überredet werde, dass dies eine schlechte Idee ist, werde ich dem gesamten Projekt erklären, warum ich es nicht tun kann, und dann, falls notwendig, einen Allgemeinen Beschluss für eine Satzungsänderung vorschlagen, um die Tatsachen in der Organisation von Debian wiederzugeben.

Ich werde regelmäßige Berichte an die Entwickler verschicken, die meine Aktivitäten als Projektleiter beschreiben.

Ich war von der Häufigkeit und dem Inhalt der Berichte des Projektleiters an die Entwickler während der vergangenen Jahre enttäuscht. Als Projektleiter werde ich zumindest einmal monatlich einen Bericht an die Entwickler bezüglich meiner Aktivitäten in meiner gewählten Rolle versenden. Diese Berichte werden sich nicht auf die Beschreibungen von Konferenzen beschränken, die ich besucht habe oder besuchen werde, oder auf hochtrabende Überblicke über den Status des Projekts; zusätzlich werde ich spezielle Aufgaben, an denen ich arbeite, und Probleme, um deren Lösung ich gebeten wurde, beschreiben.

Ich werde unser Satzungsmäßiges Führungssystem respektieren und verstärken.

Ich werde alles tun, was ich kann, damit unsere tatsächliche Organisation unsere Satzung widerspiegelt, und umgekehrt. Ein Projekt, das keinen Gedanken an seine Gründungsdokumente und -prinzipien verschwendet, ist ein Projekt mit Problemen, und kann den Eindruck jener schädigen, die nicht mit der Art vertraut sind, wie Debian wirklich funktioniert und erwarten, es durch das Lesen der Informationen auf unserer Website herauszufinden, die behaupten, es ihnen zu erklären.

Ich werde das technische Komitee reaktivieren – es ist wieder zur Ruhe gekommen – oder die Satzung entsprechend ändern, um es mit einer Körperschaft zu ersetzen, die besser funktioniert. Dass beinahe ein Jahr ohne Mail an die Liste vergangen ist (mit der Ausnahme einer Testmail von Wichert Akkerman), wenn man von einem Streit absieht, der zu schlichten war, lässt mich vermuten, dass diese Körperschaft das Vertrauen der Entwickler verloren hat. Ich möchte mit den Mitgliedern des Komitees zusammenarbeiten, die nach wie vor daran interessiert sind, herauszufinden, wie diese Körperschaft verbessert und wiederbelebt werden kann.

Ich werde den Wert und die Beiträge jedes einzelnen Entwicklers respektieren.

Das Debian-Projekt existiert entsprechend unserem Gesellschaftsvertrag, um unseren Benutzern und der Freien Software zu dienen. Um dies effizient tun zu können, muss die Debian-Organisation die Bedürfnisse aller seiner Entwickler als Gruppe erfüllen. Dies ist zeitweise eine Herausforderung, da wir alle sehr verschieden sind und unsere Mitglieder rund um die Welt verteilt sind. Diese Herausforderung kann uns manchmal dazu verleiten, unsere Freunde im Projekt zu bevorzugen, oder jene, die uns geographisch näher sind. Solchen Versuchungen nachzugeben erstellt jedoch eine Ungerechtigkeit und Ungleichheit unter den Entwicklern. Debian sollte eine Leistungsgesellschaft sein, und die Leistung sollte an den Beiträgen zum Projekt gemessen werden, nicht an der Nationalität oder nicht-elektronischen sozialen Beziehungen. Debian wurde im Internet geboren und könnte ohne es nicht existieren. Die Einfachheit der elektronischen Kommunikation ist unserer größter Gewinn, und die effizienteste Nivellierung der Ungerechtigkeit, die wir besitzen. Wir dürfen diese wesentliche Eigenschaft nicht zugunsten eines Provinzialismus jeglicher Art herabsetzen. Entwickler, die unsere jährlichen Konferenzen oder andere physische Zusammenkünfte nicht besuchen können, dürfen nicht als weniger wertvoll angesehen werden. Wir würden gut daran tun, uns an die gewaltigen Beiträge von Joel Klecker zu erinnern, dessen Beiträge nicht dadurch schlechter wurden, dass es ihm beinahe unmöglich war, einer physischen Zusammenkunft der Entwickler beizuwohnen.

Als Projektleiter werde ich mich bemühen sicherzustellen, dass unter meiner Überwachung kein besonderes Privilegiensystem erstellt oder betreut wird. Ich bin sicher, dass unseren wertvollsten Beitragenden keine speziellen Vorteile übertragen werden müssen, und dementsprechend wir das Potenzial von zukünftigen Mitarbeitern nicht durch Praktiken schwächen müssen, die praktisch ausschließend sind, selbst wenn sie unschuldig und nützlich erscheinen.

Je wichtiger ein Entscheidung ist, desto kritischer ist es, dass sie auf offene und öffentliche Art ohne Verfahren zur Bevorzugung für oder gegen einen Entwickler stattfindet. Dies ist ein hoher Standard, aber ein wesentlicher, und ich verspreche, alles in meiner Macht stehende zu tun, dass wir ihn einhalten.

Ich werden Beziehungen zu anderen Freien (Liberalen) Open-Source-Firmen und -Organisationen aufbauen.

Ich werde nach Freiwilligen suchen, die als offizielle Delegierte für andere Organisationen dienen, wo dies notwendig ist. Der aktuelle DPL hat einige Personen ernannt, die mit der Freie-Software-Stiftung bezüglich einiger Besorgnisse unserer Entwickler hinsichtlich der GNU Free Documentation Lizenz reden und wie diese Lizenz mit den Debian-Richtlinien für Freie Software zusammenspielt. Im vorangegangenen Jahr hat Bdale Garbee Mark Johnson dazu erwählt, als unser Repräsentant in OASIS zu dienen. Ich denke, dass dies großartige Beispiele waren, und eine Erscheinung sind, auf der ich aufbauen will. Ich verstehe nicht, wieso wir nicht einen Botschafter in der FSF haben, oder anders ausgedrückt, eine Person, die die Bedürfnisse und Interessen beider Organisationen versteht, und dabei helfen kann, unnötige Reibereien zu vermeiden. Das selbe könnte für Red-Hat-Software, Novell, FFII, FSF-Europe und so weiter geschehen.

Ich werde alles unternehmen, um das Debian-Projekt zu einem bezwingenden Beispiel zu machen, dem man folgen will.

Kürzlich hat eine Person an die debian-project-Liste geschrieben und um den Rat gebeten, wie er Debian als organisatorisches Beispiel für seine gemeinnützige Software-Gemeinschaft nutzen könne. Ich fühlte mich geschmeichelt, und ich glaube, wir können es alle, wenn wir die Mail lesen; aber wie man oben sehen kann, könnten wir ein besseres Beispiel sein, als wir sind. In zu vielen Fällen würde eine Organisation, die unserem Beispiel folgen will, zu der enttäuschenden Erkenntnis gelangen, dass unsere Umsetzung nicht unserer Spezifikation entspricht – dass wir nicht praktizieren, was wir predigen. Jedes Projekt ist einzigartig, und das ist der Grund, warum wir dem Rest der Welt genauer erklären sollten, was wir tun – weil wir uns dadurch auch die Zeit dafür nehmen, das warum zu erklären. Während dieses Prozesses werden wir die Annahmen, die wir getroffen haben, wieder untersuchen, und durch solch einen Prozess können wir nicht anders als uns zu verbessern.

Als Debian-Projektleiter werde ich mich dafür einsetzen, das Debian-Projekt zu der Art von Organisation zu machen, in der die Dinge korrekt durchgeführt werden. Wir haben bereits eine praktisch universelle Übereinstimmung in diesem Punkt, wenn es sich um technische Probleme handelt. Warum sollten wir uns mit weniger zufrieden geben, wenn es sich um unsere Organisation handelt?

Ich habe mich auf die Herausforderungen gefreut, die ich in der Arbeit bis jetzt im Debian-Projekt geleistet habe, und ich bin bereit für die Herausforderung, Debian-Projektleiter zu werden.

Danke für Ihre Unterstützung, und für Ihre Teilnahme an dem Projekt, an das ich glaube.


Gültiges XHTML 1.0! Gültiges CSS!

Prüfen Sie das XHTML dieser Seite.
Prüfen Sie die CSS dieser Seite.

$Id$