Programmieren ist nur ein Teil der Arbeit in einem Open-Source-Projekt, für Freiwillige im Projekt ist es der sichtbarste und glorreichste Teil. Leider können dadurch andere Tätigkeiten, wie die Dokumentation, formale Tests, usw. manchmal vernachlässigt werden, zumindest im Vergleich zu der Aufmerksamkeit die sie bei proprietärer Software oftmals erhalten. Unternehmen können das manchmal auszugleichen, indem Sie einen Teil ihrer internen Infrastruktur für die Software-Entwicklung den Open-Source-Projekten widmen.
Das Wesentliche für den Erfolg dieser Arbeit ist die Übersetzung zwischen den Abläufen in der Firma und denen in der Gemeinschaft. Sie ist nicht Mühelos: Oft passen beide nicht gut zusammen, und die Unterschiede können nur durch menschliche Eingriffe überwunden werden. Die Firma kann beispielsweise einen anderen Bugtracker verwenden, als das öffentliche Projekt. Selbst wenn beide die gleiche Software benutzen, werden die darin gespeicherten Daten sehr unterschiedlich sein, da die Anforderungen einer Firma am Bugtracking ganz andere sind, als die einer freien Software-Gemeinschaft. Eine Information die in einem Bugtracker anfängt, muss vielleicht auf den anderen übertragen werden, wobei vertrauliche Teile entfernt, oder in umgekehrter Richtung hinzugefügt werden müssen.
Die folgenden Abschnitte drehen sich um den Aufbau und die Instandhaltung solcher Brücken. Das Endergebnis sollte ein reibungsloser Betrieb im Open-Source-Projekt sein, die Investitionen der Firma sollten von der Gemeinschaft anerkannt werden, ohne dass das Gefühl entsteht unangemessen durch die Firma beeinflusst zu werden.
Bei der Entwicklung proprietärer Softwareist es üblich dass sich eine gesonderte Abteilung der Qualitätssicherung widmet: Nach Fehlern sucht, die Performance und Skalierbarkeit evaluiert, Schnittstellen, Dokumentation usw. überprüft. Diese Aktivitäten werden üblicherweise nicht so energisch von freiwilligen in einem freien Software-Projekt verfolgt. Das liegt teilweise an der Schwierigkeit Freiwillige für unrühmliche Tätigkeiten wie das Testen zu finden und zum Anderen daran dass man annimmt, dass eine große Nutzergemeinschaft auch eine gute Test-Abdeckung mit sich bringt. Performance und Skalierbarkeit sind sogar ein Gebiet wofür Freiwilligen oftmals sowieso nicht die nötige Hardware zur Verfügung steht.
Die Annahme, dass viele Nutzer auch viele Tester sind, ist nicht ganz ohne Grundlage. Es macht sicherlich wenig Sinn Personen einzustellen, die die Grundfunktionen der Software auf den üblichen Zielumgebungen überprüfen: Die dortigen Fehler werden ohnehin beim normalen Betrieb schnell von gewöhnlichen Nutzern gefunden. Da Nutzer aber lediglich versuchen ihre Arbeit zu erledigen, begegeben Sie sich nicht bewusst auf die Suche nach ungewöhnliche Grenzfällen in der Funktionalität der Software und werden wahrscheinlich bestimmte Fehler unentdeckt lassen. Bei einem Fehler der sich leicht umgehen lässt werden Sie sogar eher im Stillen diese Abhilfe implementieren ohne sich die Mühe zu machen den Fehler zu melden. Am heimtückischsten kann der Umgang Ihrer Kunden (die Quelle von Ihrem Interesse) mit der Software sein, die statistisch ganz anders aussehen kann als das Verhalten eines beliebig anderen Nutzers.
Eine professionelle Testgruppe kann solche Fehler genau so gut in freier, wie in proprietärer Software aufdecken. Die Herausforderung ist, die Ergebnisse der Tester der Öffentlichkeit in einer nützlichen Form mitzuteilen. Die Test-Abteilungen haben im Betrieb meistens ihre eigene Art Ergebnisse zu melden, mit firmenspezifischem Jargon, oder speziellem Fachwissen über bestimmte Kunden und ihre Datensätze. Solche Berichte wären auf einen öffentlichen Bugtracker unangemessen, sowohl wegen ihrer Form als auch aus Datenschutz Gründen. Selbst wenn die interne Bugtracking-Software Ihrer Firma die gleiche wäre wie im öffentlichen Projekt, kann es sein, dass die Betriebsverwaltung firmenspezifische Kommentare sowie Änderungen an den Metadaten der Vorfälle machen muss (zum Beispiel um die interne Priorität eines Vorfalls anzuheben, oder seine Lösung für einen bestimmten Kunden anzusetzen). Für gewöhnlich sind solche Anmerkungen vertraulich – manchmal werden sie nicht einmal dem Kunden gezeigt. Aber selbst wenn diese Daten nicht vertraulich sind, sind diese für das öffentliche Projekt uninteressant und deshalb sollte die Öffentlichkeit nicht von ihnen abgelenkt werden.
Die Meldung des eigentlichen Fehlers ist für die Öffentlichkeit dennoch wichtig. Tatsächlich ist eine Bug-Meldung von Ihrer Test-Abteilung in mancherlei Hinsicht wertvoller als die der üblichen Benutzer, da die Test-Abteilung nach Sachen Ausschau hält, die andere Nutzer nicht interessieren. Angesichts der Tatsache, dass Sie diese Fehler aus keiner anderen Quelle erfahren werden, sollten sie die Fehler unbedingt aufbewahren, und es dem öffentlichen Projekt zur Verfügung stellen.
Entweder kann die Abteilung zur Qualitätssicherung die Meldungen direkt in den öffentlichen Bugtracker eintragen, wenn sie sich dabei wohl fühlen, oder ein Vermittler (gewöhnlich einer der Entwickler) kann die internen Meldungen der Test-Abteilung zu dem Öffentlichen Tracker "übersetzen". Übersetzen bedeutet in diesem Zusammenhang den Bug so zu beschreiben, dass es keine Bezüge auf kundenspezifische Informationen hat (sofern der Kunde dem zustimmt, kann die Anleitung um den Fehler zu reproduzieren natürlich auch Kundendaten beinhalten).
Der Eintrag in den Tracker sollte vorzugsweise von der Abteilung zur Qualitätssicherung gemacht werden. So kann die Öffentlichkeit die Beteiligung Ihrer Firma besser sehen und würdigen: Nützliche Bug-Meldungen tragen ebenso zum guten Ruf Ihrer Organisation bei wie jeder andere technische Beitrag. Es gibt freiwilligen Entwickler auch einen direkten Draht um mit der Test-Abteilung zu kommunizieren. Wenn diese Abteilung den Bugtracker beobachtet, kann ein Entwickler eine Änderung machen um z.B. einen Skalierbarkeits-Bug zu beheben (der Entwickler selber kann die Korrektur nicht überprüfen, da er nicht die nötigen Ressourcen hat), und anschließend dem Ticket eine Anmerkung anhängen, mit der Bitte an die Qualitätssicherung, zu überprüfen, ob es die gewünschte Wirkung hatte. Stellen Sie sich auf den Widerstand einiger Entwickler ein; Programmierer haben die Angewohnheit Qualitätssicherung allerhöchstens als ein notwendiges Übel zu erachten. Die Test-Abteilung kann das leicht überwinden, indem sie schwerwiegende Fehler findet und nachvollziehbare Tickets schreibt; wenn ihre Tickets andererseits nicht mindestens so gut sind, wie die von der übrigen Gemeinschaft, hat es keinen Sinn, dass sie direkt mit den Entwicklern zusammenwirken.
So oder so, sollte sobald es ein öffentliches Ticket gibt sollte das interne Ticket im Bezug auf technische Inhalte nur noch auf das öffentliche Verweisen. Der Betrieb kann weiterhin Anmerkungen firmenspezifischer Angelegenheiten bei Bedarf beifügen, sollte aber Informationen, die allen zur Verfügung stehen sollten, in das öffentliche Ticket schreiben.
Sie sollten sich bei diesem Verfahren auf einen höheren Aufwand einstellen. Die Pflege von zwei Tickets für einen Bug bedeutet natürlich mehr Arbeit als eins. Der Vorteil ist, dass viel mehr Programmierer das Ticket sehen werden und ihre Lösungen beitragen können.
Gesellschaften, ob profitorientiert oder nicht, sind fast die einzigen, die bei einem freien Software-Projekt für komplexe rechtliche Angelegenheiten irgendwelche Aufmerksamkeit aufbringen. Einzelne Entwickler verstehen oft die Nuancen verschiedener Open-Source-Lizenzen, haben im allgemeinen aber weder Zeit noch Ressourcen um Urheber-, Marken- und Patentrecht im Detail zu verfolgen. Wenn Ihre Firma eine Rechtsabteilung hat, kann sie einem Projekt helfen, indem sie den urheberrechtlichen Stand des Quellcodes überprüft und den Entwicklern hilft, mögliche Patent und markenrechtliche Angelegenheiten zu verstehen. Die genauen Ausprägungen, die diese Hilfe annehmen kann, wird in Kapitel 9, Lizenzen, Urheberrecht und Patente diskutiert. Die Hauptsache ist bei einer Kommunikation zwischen der Rechtsabteilung und der Entwicklergemeinschaft sicherzustellen, dass sie die äußerst unterschiedlichen Welten, aus denen beide Parteien kommen gegenseitig anerkennen. Gelegentlich können diese beiden Gruppen aneinander vorbeireden, wenn sie von fachspezifischem Wissen ausgehen, welches die anderen Partei nicht hat. Es ist eine gute Strategie, eine Verbindungsperson zu haben (meistens ein Entwickler, oder ein Anwalt mit technische Fachkenntnisse) die so lange wie nötig zwischen beiden Seiten steht und übersetzt.
Die Dokumentation und Benutzerfreundlichkeit sind beides wohlbekannte Schwachstellen in Open-Source-Projekten, obwohl ich denke, dass der Unterschied zu proprietärer Software in Bezug auf die Dokumentation oftmals hochgespielt wird. Die Erfahrung zeigt trotzdem, dass es Open-Source-Software meistens an einer erstklassigen Dokumentation, sowie Untersuchungen bezüglich ihrer Benutzerfreundlichkeit mangelt.
Wenn Ihre Firma helfen will, diese Lücken für ein Projekt zu füllen, dann sollten Sie wahrscheinlich am ehesten Leute einstellen, die üblicherweise nicht am Projekt mitentwickeln, aber dennoch in der Lage sein werden mit den Entwicklern produktiv zusammenzuarbeiten. Leute einzustellen die keine gewöhnlichen Entwickler sind, ist aus zwei Gründen gut: Erstens entziehen Sie dem Projekt dadurch keine Entwicklerzeit; zweitens sollten diejenigen die der Software am nächsten sind im Allgemeinen sowieso nicht die Dokumentation schreiben oder die Benutzerfreundlichkeit untersuchen, da sie Schwierigkeiten haben die Software aus der Sicht eines Außenstehenden zu betrachten.
Eine Kommunikation zwischen diesen beiden Parteien wird allerdings trotzdem immer nötig sein. Finden Sie Leute, die genügend technische Kenntnisse haben, um mit den Entwicklern zu kommunizieren, aber nicht so weit Experten mit der Software sind, dass sie kein Einfühlungsvermögen für gewöhnliche Benutzer haben.
Ein halbwegs erfahrener Benutzer ist wahrscheinlich die richtige Person um eine gute Dokumentation zu schreiben. Ich bekam nach der ersten Veröffentlichung dieses Buchs sogar eine E-Mail von einem Open-Source-Entwickler namens Dirk Reiners:
Eine Anmerkung im Bezug auf Geld::Dokumentation und Benutzerfreundlichkeit: Als wir etwas Geld übrig hatten und uns entschieden, dass eine Einleitung für Anfänger das wichtigste war, stellten wir einen halbwegs erfahrenen Benutzer ein. Er war erst kürzlich in das System eingewiesen worden, sodass er sich an seine Probleme erinnern konnte, er hatte es aber daran vorbei geschafft und konnte sie dementsprechend beschreiben. Er konnte dadurch etwas schreiben, dass von den Hauptentwicklern nur wenige Korrekturen bedurfte, bei Dingen die er nicht richtig aufgefasst hatte. Trotzdem konnte er das 'Offensichtliche' abdeckten, dass die Entwicklern übersehen hätten. In seinem Fall war es sogar noch besser, da es seine Aufgabe gewesen war einen Haufen anderer Personen (Studenten) in das System einzuführen, also kombinierte er die Erfahrung vieler Personen, was etwas ist, dass einfach nur ein glücklicher Zufall war und wahrscheinlich schwer in den meisten Fällen zu erreichen ist.
Bei einem Projekt, welches nicht einer der freien Hosting-Pakete benutzt (siehe „Hosting-Pakete“ im Kapitel Kapitel 3, Technische Infrastruktur), kann die Bereitstellung von Server und Netzwerkverbindung – und besonders die Hilfe bei der System-Administration – eine wesentliche Unterstützung sein. Selbst wenn das alles ist was Ihre Firma für das Projekt macht, kann es eine halbwegs effektive Art sein Karma in der Öffentlichkeit zu sammeln, auch wenn es Ihnen keinen Einfluss auf die Richtung des Projekts bringen wird.
Sie können wahrscheinlich einen Banner oder eine Anerkennung auf der Projekt-Seite erwarten, auf dem man Ihrer Firma für das Hosting dankt. Wenn Sie das Hosting so einrichten, dass die Webseite des Projekts auf Ihrer Domain ist, werden Sie alleine schon durch die URL eine etwas größere Assoziierung bekommen. Das wird die meisten Benutzer dazu bringen, zu denken, dass das Projekt irgendetwas mit Ihrer Firma zu tun hat, selbst wenn Sie gar nicht zu der Entwicklung beitragen. Das Problem ist, dass die Entwickler sich dieser Assoziation auch bewusst sind, und werden sich nicht sonderlich wohl dabei fühlen, das Projekt unter Ihrer Domain zu hosten, wenn Sie nicht mehr Ressourcen als lediglich Bandbreite zu dem Projekt beitragen. Schließlich gibt es heutzutage viele Orte für Hosting. Die Gemeinschaft mag irgendwann der Meinung sein, dass die angedeutete falsche Anerkennung nicht dem Komfort vom Hosting wert ist und das Projekt anderswo unterbringen. Wenn Sie also Hosting anbieten wollen, machen Sie es – planen Sie aber entweder sich eingehender zu beteiligen oder seien sie umsichtig darüber wieviel Beteiligung sie sich Zusprechen.