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, 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 Bug-Tracker 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 an einem Bug-Tracking ganz andere sind, als die einer freien Software Gemeinschaft. Eine Information die in einem Bug-Tracker 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, die Anerkennung der Investition der Firma durch die Gemeinschaft, ohne das das Gefühl unangemessen durch die Firma beeinflusst zu werden.
Bei der Entwicklung proprietärer Software, hat man üblicherweise eine gesonderte Abteilung die sich 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 weil Leute annehmen, dass eine große Nutzergemeinschaft auch eine gute Test Abdeckung mit sich bringt. Performance und Skalierbarkeit sind sogar ein Gebiet wofür Freiwillige 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 Grundfunktionen auf der ü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, setzen Sie sich nicht bewusst auf der Suche nach ungewöhnliche Grenzfälle in der Funktionalität der Software zu entdecken, 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, dass statistisch ganz anderers 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 Bug-Tracker unangemessen, sowohl wegen ihrer Form als auch aus Datenschutz Gründen. Selbst wenn die interne Bug-Tracking 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 diese Daten nicht vertraulich sind für das öffentliche Projekt uninteresant und sollte deshalb 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 interesieren. Angesichts der Tatsache, dass Sie diese Fehler aus keiner anderen Quelle erfahren werden, sollten sie es unbedingt aufbewahren, und es dem öffentlichen Projekt zur Verfügung stellen.
Um das zu erreichen, kann entweder die Abteilung zur Qualitätssicherung die Meldungen direkt in den öffentlichen Bug-Tracker 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 Organization bei, wie jeder andere technische Beitrag. Es gibt freiwillige Entwickler auch einen direkten Draht um mit der Test Abteilung zu kommunizieren. Wenn diese Abteilung den Bug-Tracker 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 denen von der übrigen Gemeinschaft, hat es keinen Sinn, dass sie direkt mit den Entwicklern zusammenwirken.
So oder so, sollte sobald es den Öffentlichen Ticket gibt, der interne Ticket im Bezug auf technische Inhalte, nur noch auf den öffentlichen Verweisen. Der Betrieb kann weiterhin, Anmerkungen firmenspezifischer Angelegenheiten bei bedarf beifügen, sollten 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 den 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 werden 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 beide steht und übersetzt.
Die Dokumentation und Benutzerfreundlichkeit sind beides wohl bekannte Schwachstellen in Open-Source Projekten, obwohl ich denke, dass der Unterschied zu proprietärer Software, im Falle der Dokumentation, oftmals hochgespielt wird. Die Erfahrung zeigt trotzdem, dass es Open-Source Software meistens an einer erstklassigen Dokumentation, sowie einer Untersuchung ihrer Benutzerfreundlichkeit mangelt.
Wenn Ihre Gesellschaft helfen will, diese Lücken für ein Projekt zu füllen, sollten Sie wahrscheinlich am ehesten Leute einzustellen, 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, diejenigen die der Software am nächsten sind, sollten 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 immer noch 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 Sachen die er nicht richtig aufgefasst hatte. Trotzdem konnte er das 'Offensichtliche' abdeckten, dass die Entwicklern übersehen hätten. Sein Fall war 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 gebündelten Hosting Seiten benutzt (siehe „Hosting Bündel“ im Kapitel Kapitel 3, Technische Infrastruktur), kann die Bereitstellung von Server und Netzwerkverbindung—und am wichtigsten Hilfe bei der System Administration—eine wesentlichem Unterstützung sein. Selbst wenn das alles ist was Ihre Gesellschaft 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önne wahrscheinlich einen Banner oder eine Anerkennung auf der Projekt Seite erwarten, welches Ihre Firma für das Hosting bedankt. Wenn Sie das Hosting so einrichten, dass die Webseite des Projekts bei 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 haben 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.