Auftragsarbeit

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, diese in die Software zu bekommen. Das Schwierige ist, dass es als komplett Fremder sehr schwer 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. Man sollte vorzugsweise eine fundierte Vermutung über die Dauer der Diskussion machen, beruhend auf der vergangenen Erfahrung mit einem Puffer für Fehler, was dem Vertrag zugrunde liegt. Es hilft auch das Problem in möglichst viele Einzelteile zu spalten, um die einzelnen Brocken 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 kann man selbst beim ersten Vorgehen nicht im Vertrag darauf bestehen, etwas über die Aufnahme im Projekt festzulegen, weil das den Verkauf von etwas bedeuten würden, was 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 zu bekommen, und sie danach im Projektarchiv einzuspielen. Wenn das Projekt Normen über Änderungen am Code 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 längerfristige Position in einem Projekt nicht riskieren um eine weitestgehend unbeliebte Funktion zu unterstützen. 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 bekommen auch eine gewisse Umstellung der Prioritäten im Projekt. Da die Prioritäten lediglich davon abhängen, wer Zeit hat an etwas zu arbeiten, sorgen Sie durch Entlohnung bestimmter Arbeiten dafür, dass diese eine etwas höhere Priorität bekommen. Unter erfahrenen Open-Source-Entwicklern ist diese Tatsache wohlbekannt, und zumindest manche werden der Arbeit eines Auftragnehmers Aufmerksamkeit widmen, einfach nur weil es den Anschein hat fertig zu werden, 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 auftreten, 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 gibt 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. 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.

Dieses Beispiel zeigt einen weiteren Grund offen über Verträge zu reden: 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 Finanzier (CollabNet) in keinster Weise an diesen Einzelverträgen beteiligt. Aber mit dem Wissen, dass jemand anderes bestimmte Bugfixes fördert, wird CollabNet ermöglicht sich auf andere Fehler zu konzentrieren, und insgesamt die Effizienz im Projekt zu erhöhen.

Nehmen es andere Entwickler es den beauftragten Mitgliedern übel, dass sie für die Arbeit am Projekt bezahlt werden? Im allgemeinen nein, 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.

Kritik und Annahme von Änderungen

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.

Fallbeispiel: Das CVS-Protokoll zur Passwort-Authentifizierung

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.