Samba-Projekt: So läuft die verteilte Entwicklung

In seiner über dreißigjährigen Geschichte stand das Samba-Team immer wieder vor der Herausforderung, konträre Interessen in einem Projekt zu integrieren.

Lesezeit: 16 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 1 Beitrag
Von
  • Volker Lendecke
Inhaltsverzeichnis

Das Open-Source-Projekt Samba gilt als die Standardsuite von Programmen für die Interoperabilität zwischen Windows und Linux/Unix. Das ist ein riesiger Markt potenzieller Clients, die sowohl kommerziell als auch für die Entwickler persönlich interessant sind. Daraus ergibt sich aber auch, dass viele Kontributoren an Samba beteiligt sind, die sich untereinander auf die Ausrichtung des Projekts verständigen müssen.

Da Samba sehr komplex und vielfältig ist, ist es für einen einzelnen Entwickler unmöglich, alles komplett zu überblicken. Daraus ergibt sich eine zentrale Frage, die dieser Artikel näher beleuchtet: die Kommunikation innerhalb des Teams. Wen fragt man als Entwickler, wenn man mit einem Problem nicht weiterkommt, und auf welchem Weg?

Mehr zu Projektmanagement

Eine kurze Anekdote verdeutlicht, was das Projekt bis heute zusammenhält: 1991 hatte Andrew Tridgell das Problem, dass er an seinem Rechner unter MS-DOS Dateien gleichzeitig mit einem Server unter DES Pathworks und einer Sun-Workstation austauschen wollte. Sowohl der Pathworks- als auch der PC-NFS-Client brachten ihre eigenen, nicht kompatiblen TCP/IP-Stacks mit. Damit war nur entweder Pathworks oder PC-NFS möglich. So schrieb er einen Serverprozess, der den Ultrix-Pathworks-Server auf der Sun-Maschine emuliert. Dass der Pathworks-Server vom OS/2 LAN Manager abstammte, der später auch in Windows für den Austausch von Dateien sorgen sollte, war Tridgell nicht klar. Das führte aber dazu, dass Samba, das damals noch nicht so hieß, von Anfang an kompatibel zu sehr vielen Clients war.