Verteilte Entwicklung im Samba-Projekt
In seiner über dreißigjährigen Geschichte stand das Samba-Team immer wieder vor der Herausforderung, kommerzielle – auch konträre – und Open-Source-Interessen in einem Projekt zu integrieren. Doch mit welchen Methoden funktioniert das überhaupt?
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.
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.