Mit Auftragsarbeit muss in freien Software-Projekten vorsichtig umgehen. Im Idealfall wollen Sie, dass die Arbeit des Auftragnehmers von der Gemeinschaft angenommen wird und in die veröffentlichte Version aufgenommen wird. Theoretisch würde es keinen Unterschied machen, wer der Auftragnehmer ist, solange er gute Arbeit macht und die Richtlinien des Projekts beachtet. Theorie und Praxis kann manchmal auch zusammenpassen: Ein komplett Fremder, der mit einem guten Patch auftaucht, wird es im Allgemeinen schaffen, diesen in die Software hineinzubekommen. Das Schwierige ist, dass es als komplett Fremder sehr mühevoll ist, einen guten Patch für eine nicht triviale Erweiterung oder Funktion zu produzieren; man muss es zuerst mit dem übrigen Teilnehmern diskutieren. Die Dauer dieser Diskussion kann man nicht genau voraussehen. Wenn der Auftragnehmer nach Arbeitszeit bezahlt wird, werden Sie vielleicht mehr Bezahlen, als Sie erwartet haben; wenn er Pauschal bezahlt wird, kann es passieren, dass er länger arbeitet, als er es sich leisten kann.
Es gibt zwei Möglichkeiten das Problem zu umgehen. Der bevorzugte Weg ist, eine fundierte Vermutung über die Dauer der Diskussion, beruhend auf der bisherigen Erfahrung, zu machen, mit einem Puffer für Fehler, und den Vertrag darauf fußen lassen. Es hilft auch, das Problem in möglichst viele, unabhängige Einzelteile zu spalten, um die einzelnen Teile eher einschätzen zu können. Der andere Weg ist, den Auftrag auf den eigentlichen Patch zu beschränken, unabhängig von seiner Aufnahme im Projekt. Es ist dadurch viel einfacher, den Vertrag zu schreiben, hat aber den Nachteil, dass Ihnen dann der Klotz am Bein hängt, den Patch so lange zu pflegen, wie Sie auf die Software angewiesen sind, oder zumindest so lange, bis Sie es schaffen, eine gleichwertige Funktion in den Hauptzweig zu bekommen. Natürlich, auch beim bevorzugten Weg kann der Vertrag selbst nicht verlangen, dass die Aufnahme des Patches in den Code akzeptiert wird, weil das den Verkauf von etwas bedeuten würden, das nicht zum Verkauf steht. (Was passiert, wenn die Übrigen im Projekt sich entscheiden, die Funktion nicht zu unterstützen)? Der Vertrag kann allerdings eine gewisse angemessen und glaubwürdige Anstrengung beinhalten, um die Änderung von der Gemeinschaft angenommen und sie danach im Projektarchiv eingespielt zu bekommen. Wenn das Projekt beispielsweise Normen über Codeänderungen festgelegt hat, kann der Vertrag auf diese verweisen und festlegen, das die Arbeit sich danach richten muss. In der Praxis verläuft das meistens positiv für alle Parteien.
Die beste Taktik für erfolgreiche Auftragsarbeit ist, einen der Entwickler des Projekts – vorzugsweise einen etablierten Beteiligten – als Auftragnehmer anzustellen. Das mag sich nach erkauftem Einfluss anhören, und nun ja, dass ist es auch. Es ist aber nicht so korrupt, wie es sich anhört. Der Einfluss, den ein Entwickler innerhalb eines Projekts hat, hängt vorrangig von der Qualität seiner Arbeit, sowie seinen Umgang mit anderen Entwicklern ab. Die Tatsache, dass er ein Vertrag hat, um bestimmte Sachen erledigt zu bekommen, hebt seinen Status in keiner Weise und es senkt ihn auch nicht, auch wenn Leute ihn vielleicht etwas vorsichtiger hinterfragen werden. Die meisten Entwickler würden ihre auf Dauer angelegte Position in einem Projekt nicht für die Unterstützung einer weitestgehend unbeliebten Funktion riskieren. Tatsächlich sollte ein Teil von dem, was Sie erhalten, wenn Sie einen solchen Entwickler einstellen, Ratschläge darüber sein, welche Änderungen wahrscheinlich von der Gemeinschaft angenommen werden. Sie erzielen auch eine gewisse Umstellung der Prioritäten im Projekt. Weil die Priorisierung oft aus der Frage resultiert, wer an welchem Teil Zeit hat zu arbeiten, wird, da Sie jemandes Zeit bezahlen, dessen Arbeit in der Prioritätenlist ein wenig nach oben wandern. Unter erfahrenen Open-Source-Entwicklern ist diese Tatsache wohlbekannt und zumindest manche werden der Arbeit eines Auftragnehmers Aufmerksamkeit widmen, einfach nur weil zu vermuten ist, dass es fertig wird, also wollen sie dabei helfen, dass es richtig gemacht wird. Sie schreiben dabei zwar vielleicht keinen Code, werden aber Entwürfe diskutieren und Kritik am Code üben, was alles sehr nützlich sein kann. Aus all diesen Gründen, sollte der Auftragnehmer am ehesten aus den Reihen der bereits am Projekt Beteiligten gezogen werden.
Dadurch stellen sich zwei Fragen: Sollten Verträge jemals privat sein? Und wenn sie es nicht sind, sollten Sie sich darüber Sorgen machen, Spannungen in der Gemeinschaft zu verursachen, indem Sie mit manchen der Entwickler Verträge geschlossen haben und nicht mit anderen?
Verträge sollten wo möglich offen sein. Sonst kann das Verhalten des Beauftragten anderen in der Gemeinschaft komisch vorkommen – vielleicht gibt er bestimmten Funktionen plötzlich eine unerklärlich hohe Priorität, die ihn früher aber nicht interessierten. Wenn Leute ihn darauf ansprechen, wie soll er überzeugend antworten, wenn er nicht darüber reden kann, dass er beauftragt wurde sie zu schreiben?
Gleichzeitig sollten weder Sie noch der Auftragnehmer so tun, als ob andere ihre Vereinbarung als etwas besonderes behandeln sollten. All zu oft habe ich Auftragnehmer erlebt, die auf der Mailingliste mit der Einstellung auftraten, dass ihre Nachrichten ernster genommen werden sollten, einfach nur, weil sie bezahlt werden. Diese Einstellung zeigt den anderen Teilnehmern, dass der Auftragnehmer den Vertrag an sich als das Wesentliche erachtet – im Gegensatz zu dem aus dem Vertrag resultierenden Code. Aus Sicht der anderen Entwickler ist der Code das einzig Wichtige. Technische Probleme sollten immer im Mittelpunkt stehen, nicht die Details darüber, wer von wem bezahlt wird. Einer der Entwickler in der Subversion-Gemeinschaft geht mit Auftragsarbeit besonders elegant um. Während er seine Änderungen am Code im IRC bespricht, macht er nebenbei Anmerkungen (oftmals in einer privaten Nachricht, also privmsg im IRC, an andere Entwickler), dass er für die Arbeit an diesem bestimmten Fehler oder Funktion bezahlt wird. Er vermittelt aber durchweg den Eindruck, dass er an dieser Änderung auch so arbeiten wolle, und dass er froh ist, dass das Geld es ihm ermöglicht. Egal ob er sagt für wen er arbeitet oder nicht, den Vertrag macht er nie zum eigentlichen Thema. Seine Anmerkungen darüber sind lediglich eine Zierde einer ansonsten technische Diskussion über die Lösung eines Problems.
Das folgende Beispiel zeigt einen weiteren Grund für das Offensein über Verträge auf: Es mag mehrere Organisationen geben, die bei einem Open-Source-Projekt Verträge beisteuern, und wenn jeder über die Arbeit des anderen bescheid weiß, können sie vielleicht ihre Ressourcen bündeln. Im obigen Fall ist der größte Finanzierer (CollabNet) in keinster Weise an diesen Einzelverträgen beteiligt. Aber mit dem Wissen, dass jemand anderes bestimmte Bugfixes fördert, wird es CollabNet ermöglicht, sich auf andere Fehler zu konzentrieren, und dadurch insgesamt die Effizienz im Projekt erhöht.
Nehmen andere Entwickler es den beauftragten Mitgliedern übel, dass sie für die Arbeit am Projekt bezahlt werden? Im allgemeinen nicht, insbesondere wenn diejenigen, die bezahlt werden, sowieso anerkannte, geachtete Mitglieder der Gemeinschaft sind. Keiner erwartet, dass Auftragsarbeit gleichmäßig auf die Beteiligten aufgeteilt wird. Leute verstehen, wie wichtig dauerhafte Beziehungen sind: Die Ungewissheiten bei Auftragsarbeit sind derart, dass, wenn man einen zuverlässigen Geschäftspartner gefunden hat, man nur widerwillig zu jemand anderen wechselt, nur der Gerechtigkeit halber. Sie können es sich so vorstellen: Wenn Sie das erste mal jemand wählen wird es bestimmt keine Beschwerden geben, denn schließlich mussten Sie ja irgendjemand wählen – Sie können schließlich nicht alle beauftragen. Wenn Sie später dieselbe Person ein zweites mal beauftragen, ist das nur vernünftig: Sie kennen ihn schon, der letzte Auftrag verlief erfolgreich, warum sollten Sie ein unnötiges Risiko eingehen? Es ist deshalb ganz natürlich, ein-zwei Leute in der Gemeinschaft zu haben, an die man sich wenden kann, anstatt die Arbeit gleichmäßig aufzuteilen.
Die Gemeinschaft ist trotzdem wichtig für den Erfolg der Auftragsarbeit. Ihre Beteiligung beim Entwurf und der Beurteilung der Änderung darf nicht beiläufig geschehen. Sie müssen es als Teil der Arbeit auffassen und vollständig im Auftrag einbeziehen. Betrachten Sie die Kritik der Gemeinschaft nicht als ein Hindernis, das es zu überwinden gilt – sondern als kostenlose Platform für Entwürfe, Fragen und Antworten. Es ist ein Vorteil, den Sie entschlossen nutzen sollten, anstatt ihn lediglich hinzunehmen.
1995 war ich an einer Partnerschaft für technische Unterstützung und Erweiterungen an CVS (das Concurrent Versions System; siehe http://www.cvshome.org/) beteiligt. Mein Partner Jim und ich waren damals informell für die Instandhaltung von CVS zuständig. Wir hatten aber nie sorgfältig darüber nachgedacht, wie wir mit der vorhandenen, größtenteils freiwilligen Entwicklergemeinschaft von CVS umgehen sollten. Unsere Erwartung war einfach Patches zu bekommen, die wir anwenden würden, und so war auch weitestgehend der Ablauf.
Damals konnte man CVS im Netzwerk nur über ein Fernzugriff
Programm wie rsh betreiben. Man brauchte dasselbe
Passwort für CVS wie für den Fernzugriff, was ein offensichtliches
Sicherheitsrisiko darstellte und viele Organisationen abschreckte. Eine
bedeutende Anlagebank beauftragte uns einen neuen
Authentifizierungsmechanismus zu implementieren, damit sie ihr
vernetztes CVS sicher mit ihren Außenstellen benutzen konnten.
Jim und ich nahmen den Vertrag an und fingen an ein Entwurf für das neue Authentifizierungssystem auszuarbeiten. Unser Entwurf war relativ einfach (die Vereinigten Staaten hatten damals Einschränkungen auf den Export von Kryptographischem Code, also hatte der Kunde Verständnis dafür, dass wir keine Starke Authentifizierung implementieren konnten). Da wir aber keine Erfahrung mit derartigen Protokollen hatten, machten wir dennoch einige grobe Fehler, die einem Experten sofort aufgefallen wären. Diese Ausrutscher wären mit Leichtigkeit erkannt worden, hätten wir uns die Zeit genommen hätten einen Vorschlag zu verfassen und den anderen Entwickler zur Überprüfung vorgestellt hätten. Uns kam es nie in den Sinn, die Entwickler auf dem Verteiler als Ressource zu betrachten und machten alleine weiter. Wir wussten, dass unsere Arbeit, egal wie sie aussah, wahrscheinlich angenommen werden würde, und – da wir nicht wussten was wir nicht wussten – machten wir uns nicht die Mühe, unsere Arbeit für alle sichtbar offenzulegen, d.h. häufig Patches abzuschicken, kleine, leicht verdauliche Änderungen an einem bestimmten Branch, usw. Das entstandene Authentifizierungsprotokoll war nicht sonderlich gut, und nach seiner Etablierung ließ es sich es natürlich aufgrund von Sorgen um die Kompatibilität nur sehr schwer verbessern.
Im Kern lag das Problem nicht an unserem Mangel an Erfahrung; wir hätten das Nötige mit Leichtigkeit lernen können. Das Problem lag an unserer Einstellung zur Entwicklergemeinschaft. Wir betrachteten die Annahme der Änderungen als eine Hürde die es zu überwinden galt, nicht als Ablauf um die Qualität der Änderungen zu verbessern. Wir waren zuversichtlich, dass jedwede Arbeit von uns angenommen würde (was auch geschah), und machten uns deshalb wenig Mühe um äußere Beteiligung.
Es ist offensichtlich, dass Sie bei der Suche nach einem Auftragnehmer auf die richtigen technischen Fähigkeiten und Erfahrung achten. Es ist aber auch wichtig jemanden zu wählen, der nachweislich mit den anderen Entwicklern in der Gemeinschaft eine konstruktive Zusammenarbeit pflegt. Sie bekommen dadurch mehr als nur eine Person; Sie bekommen einen Agenten, der in der Lage sein wird aus einem Netzwerk von Fachwissen zu schöpfen um robuste und wartbare Arbeit sicherzustellen.