Bis an die Zähne - wie GNOME für den Erfolg gerüstet wurde

Als GNOME 2.0 am 26.06.2002 veröffentlicht wurde, geschah das 9(!) Monate nach dem zuerst angekündigten Termin. Folge dessen war, dass Sun Solaris 10 noch ohne GNOME 2 als Standard-Desktop ausgeliefert wurde.

Im Vorfeld dieser Entwicklung wurde beschlossen ab der Veröffentlichung von GNOME 2.0 einen Veröffentlichungsablauf umzusetzen. Neue Major-Versionen (3.0, 4.0, 5.0, ...) sollen jeweils 12 Monate nach der letzten Minor-Version (1.4, 2.10, ...) veröffentlicht werden, Minor-Versionen (2.2, 2.4, 2.6, ...) sollen in einem 6-monatigen Zyklus veröffentlicht werden.

Dies geschieht aus 2 Gründen:

Einige Gründe sprechen gegen dieses Verhalten:

In den vergangenen 2 Jahren wurde festgestellt, dass GNOME entgegen der Befürchtungen nicht instabiler wurde, sondern immer stabiler. Dadurch dass neue Features innerhalb der ersten 4 Monate eines Zyklus nahezu fertig implementiert sein müssen, bleiben 2 Monate, um dem Code die nötige Stabilität beizubringen.

Statt instabliler Software holen wir mehr aus den Entwicklern raus, indem diese einem gewissen Druck unterworfen werden.

GNOME wird nicht von einem Haufen chaotischer Entwickler erstellt und gewartet, sondern von mehreren Teams, die sich um die Umsetzung verschiedener Ziele kümmern.

Zum einen sind da natürlich die Entwickler , die sich in erster Linie darum kümmern, dass neue Features implementiert werden und Fehler behoben werden.

Das Usability -Team kümmert sich darum, dass sich die Anwendungsoberflächen und Dialoge an die Human Interface Guidelines (HIG) halten, sodass ein einheitliches Aussehen und einheitliches Verhalten durchgesetzt werden können. Dazu muss sich ein Mitglied des Usability-Teams glücklicherweise nicht mit Quelltext rumschlagen, da dies weniger Anforderungen an Team-Mitglieder stellt, weil viele Usability-Experten keine Programmierer sind.

Das Dokumentations -Projekt schreibt und übersetzt Dokumentation zu den Anwendungen. Dieses Projekt ist leider stark unterbesetzt, aber Dank des Engagenments von SUN ist der Bedarf wenigstens halbwegs gedeckt.

Das Barrierefreiheits -Team kümmert sich um verschiedene Aspekte, den GNOME-Desktop auch Behinderten zugängig zu machen. Da dies einer der Aspekte ist, die von den Entwicklern persönlich selten benötigt werden, ist auch hier der Einsatz von bezahlten Kraeften oft anzutreffen.

Die Bugsquad kümmert sich darum, dass unser Bug-Tracking-System nicht von doppelten, fehlerhaften und inkorrekten Einträgen überquillt. Desweiteren erinnert das Team regelmässig an alte Fehler und versucht Bug-Days zu organisieren, an denen möglichst viele Fehler ausgemerzt werden.

Die Übersetzungs -Teams und das Internationalisierungs -Projekt beschäftigen sich mit der Anpassung an lokale Gegebenheiten, hauptsächlich der Sprache. Dabei wird auch stark darauf geachtet, dass die Anwendungs-Entwickler und Usability-Mitglieder nicht bis kurz vor der Veröffentlichung noch Mitteilungen ändern, sodass die Uebersetzungen löchrig werden. Einige Mitglieder dieser Teams sind selber Anwendungs-Entwickler, was zur Entwicklung von intltool geführt hat, einem Werkzeug, dass übersetzbare Mitteilungen aus vielerlei Dateiformaten extrahieren kann und u.a. auch für die Übersetzung Debians zum Einsatz kommt.

Das Team GNOME-Love organisiert in unregelmässigen Abständen sogenannte Love-Days, an denen man sich vermehrt darum kümmert, Nachwuchs zu rekrutieren. So wird zur Zeit eine grafische Oberflaeche für die Passwort-Verwaltung entwickelt, die in GNOME 2.8 ausgeliefert werden soll.

Das Release-Team ist letztendlich für das Aufstellen von Zeitplänen zuständig. Dies geschieht im Rahmen dessen, was die GNOME-Foundation vorgegeben hat, sodass diese Zeitrahmen von allen Entwicklern akzeptiert werden. Desweiteren sind die Mitglieder des Release-Teams diejenigen, die den anderen ab und zu auch mal ein wenig Kohle unter'm Hinter machen müssen, damit deren Entwicklungen zu einen guten Abschluss kommen.

Dadurch, dass es eine sehr starke Abgrenzung dessen gibt, was als “GNOME Desktop & Developer Platform” (GDDP) gilt, gibt es viele Projekte um GNOME herum. Diese starke Abgrenzung geschieht aus dem Grund, dass alles, was in die GDDP, recht hohen Ansprüchen gerecht werden muss.

So gibt es viele Projekte um GNOME herum, das jüngste sind die GNOME Language Bindings , die es Anwendungs-Entwicklern ermöglichen, GNOME-Anwendungen auch in anderen Sprachen als C zu schreiben. Diese Language Bindings haben sich seit der Version 2.6.0, die kurz nach GNOME 2.6.0 veröffentlicht wurde, zum Ziel gesetzt einen ebenfalls recht hohen Qualitäts-Standard einzuhalten, sodass damit zu rechnen ist, dass die Language Bindings ab GNOME 3.0 dann direkt mit der GDDP veröffentlicht werden können, was dazu führt, dass Anwendungen aus dem GNOME Desktop auch in anderen Sprachen als C implementiert werden können.

Ein weiteres interessantes Projekt ist das GNOME Office , ein loser Zusammenschluss von Anwendungen aus dem Bereich Office, die sich immer besser ineinander integrieren und teilweise anderen Produkten aus dem Umfeld Freier Software um einiges voraus sind. GNOME Office beinhaltet die Kernkomponenten Abiword, Gnumeric und GNOME-DB und wird dann mit vielen anderen Tools ergänzt.

Fifth Toe (“Fünfter Zeh”) beinhaltet viele Anwendungen, die es (noch) nicht in die GDDP geschafft haben, die aber bereits auf einem guten Weg sind und sich ebenfalls sehr gut in den Desktop integrieren.

GNOMEs Bugzilla hatte im März über 30000 registrierte Nutzer, auf den GNOME Quelltext dürfen gut 1000 Personen schreibend zugreifen, die wahre Anzahl der Entwickler wird wohl irgendwo dazwischen liegen.

Wer einen “signifikanten Beitrag” geleistet hat, kann für 2 Jahre Mitglied der GNOME Foundation werden; die Mitgliedschaft muss nach dieses 2 Jahren wieder neu beantragt werden; dadurch werden “Altlasten” automatisch entsorgt. Die GNOME Foundation hatte Anfang März 353 Mitglieder.

Diese Mitglieder wählen einmal im Jahr den Vorstand der Foundation, der dann für einige Kern-Entscheidungen zuständig ist. All diese Entscheidungen finden öffentlich statt, sodass jeder Interessierte jederzeit sehen kann, wer was aus welchem Grund entschieden hat und wer eventuell etwas gegen diese Entscheidung hatte.

Bei GNOME kümmert man sich stark um eine gute Kooperation mit anderen Projekten.

Paradebeispiel in diesem Zusammenhang ist mittlerweile das Mozilla-Projekt , das sich mit der Erstellung eines freien standard-konformen Webbrowser beschäftigt. Die Rendering-Engine von Mozilla, Gecko, wird in GNOMEs Webbrowser Epiphany verwendet und man überlegt weitere Technologien aus Mozilla in GNOME zu integrieren.

GStreamer ist das Multimedia-Framework, das bei GNOME zum Einsatz kommt, es ist stark modularisiert und basiert vollständig auf Generics; die einzigen Abhängigkeiten von GStreamer sind andere Multimedia-Bibliotheken und glib/GObject. Dies hat dazu geführt, dass beim KDE überlegt wird, ebenfalls GStreamer als Multimedia-Framework zu verwenden.

Die freie Office-Suite OpenOffice.org ist stark an einer besseren Integration in GNOME interessiert, was sich jetzt darin äussert, dass mehr und mehr GNOME-Technologien in OpenOfiice.org einfließen. Optisch passt sich OOo mittlerweile schon sehr gut in das Erscheinungsbild von GNOME an, was u.a. an den GNOME-typischen Icons liegt, die Ximian OOo spendiert hat.

Als Keith Packard aus dem XFree86-Projekt geworfen wurde, stellte sich heraus, dass sich viele GNOME-Entwickler (von denen einige Keith kennen) hinter Keith gestellt hatten und mit ihm zusammen am X.org Server arbeiten.

FreeDesktop.org ist die Leidenschaft von GNOMEs Havoc Pennington; Unter dem Dach von FDo organisieren sich einige Projekte (GNOME, KDE, Rox, Wine; um einige zu nennen), um Spezifikationen auszuarbeiten, an die sich Anwendungen zu halten haben, wenn sie sauber mit og. Umgebungen zusammenarbeiten sollen. Dadurch integrieren sich GNOME-Anwendungen fast genau so gut in's KDE wie umgekehrt.

Das GNU Palmtop Environment (GPE) ist eine grafische Oberflaeche für PDAs, die auf dem GTK+ aufbaut. Viele der Entwickler sind selber auch GNOME-Entwickler und arbeiten stark daran, dass diese Technologie auf PDAs immer besser läuft.