054.1 Lektion 1

Es gibt viele Gründe, warum sich Entwickler dafür entscheiden, ein Unternehmen auf Open Source Code aufzubauen: Die Software kann einen Bedarf decken, ein Problem lösen oder Funktionen bereitstellen, die die Entwickler ihren Kunden anbieten. Ein Unternehmen kann Zeit und Geld sparen, indem es die Arbeit an der Software mit anderen Entwicklern teilt, anstatt dieselbe Software von Grund auf neu zu schreiben. Die Teilnahme an dem Projekt ist eine Investition, die sich hoffentlich in nutzbarer, stabiler, zuverlässiger, sicherer und gut gewarteter Software auszahlt.

Viele Open-Source-Entwickler erhoffen sich von ihren Kunden Fehlerkorrekturen (Bugfixes). Einige Kunden fügen sogar neue Funktionen hinzu, portieren die Software auf eine neue Plattform oder nehmen andere bedeutende Verbesserungen vor. Sowohl Fehlerkorrekturen als auch Verbesserungen auf höherem Niveau verbessern die ursprüngliche Software. Wenn Kunden diese an die ursprünglichen Entwickler zurückgeben, können die Änderungen den Code für andere potenzielle Kunden attraktiver machen und seine Verbreitung fördern.

Aber ein Unternehmen kann nicht einfach Beiträge und Aufmerksamkeit erwarten, indem es seinen Code auf einer Website wie GitHub oder GitLab veröffentlicht. Es ist eine Sache, Entwickler zur Teilnahme an einem Projekt zu ermutigen, aber eine größere Herausforderung, sie dafür zu begeistern; unterschätzen Sie also nicht den Arbeitsaufwand, den Community-Beiträge erfordern. Ein Unternehmen muss sich bemühen, Entwickler anzuwerben, sie zu betreuen, sie zu motivieren und ihren Code auf Fehler zu überprüfen.

Ein weiterer Grund für die Öffnung des Codes kann die Schaffung eines Industriestandards sein. Die gemeinsame Nutzung des Codes kann zu besserer Interoperabilität und anderen Vorteilen führen. Das Team, das den Code entwickelt hat, verfügt über wertvolles Fachwissen, das es ihm ermöglichen könnte, die Zukunft des Projekts zu lenken und für die Unterstützung anderer, die den Code verwenden, bezahlt zu werden.

Einige Unternehmen öffnen ihren Code, um bei Kunden Vertrauen zu schaffen. Erstens wissen die Kunden, dass sie den Code weiter nutzen und verbessern können, wenn das Unternehmen scheitert oder beschließt, in einen anderen Markt einzusteigen und den Code aufzugeben. Zweitens können Kunden Qualität und Sicherheit des Codes selbst überprüfen oder einen unabhängigen Experten mit einem Audit beauftragen, was bei geschlossener, proprietärer Software normalerweise nicht möglich ist.

Schließlich könnte ein Unternehmen eine bereits quelloffene Codebasis übernommen haben, um darauf ein kommerzielles Geschäft aufzubauen. Die Lizenz könnte das Unternehmen dazu verpflichten, den Quellcode seiner Änderungen an jeden Benutzer des Programms weiterzugeben.

Zusammengefasst gibt es also einige Gründe, den Code eines Unternehmens offen zu machen:

Die Softwareindustrie hat in den vergangenen Jahrzehnten zahlreiche Geschäftsmodelle entwickelt, die sowohl für proprietäre als auch für Open-Source-Unternehmungen geeignet sind. Dieser Abschnitt konzentriert sich auf die beliebtesten Modelle unter Open-Source-Entwicklern.

Ein Geschäftsmodell, das sowohl bei proprietärer als auch bei Open Source Software üblich ist, besteht darin, für Support Geld zu verlangen. Kunden haben möglicherweise Probleme bei Installation und Konfiguration der Software, bei der Behebung von entdeckten Fehlern, beim Hinzufügen neuer Funktionen für den eigenen Einsatz und bei der Verwaltung ihrer Systeme. Mitarbeiter, die die Software entwickelt haben, sind ausgezeichnet für den Support. Tatsächlich bieten diese Mitarbeiter wahrscheinlich bereits kostenlosen Support in Foren an, in denen die Software diskutiert wird.

Beim Support-Modell bezahlt der Kunde den Anbieter dafür, dass er die Open Source Software auf seiner Hardware installiert (Self-Hosting), oder er erhält Zugriff auf die Software auf der Hardware des Anbieters (Cloud-basiertes Modell). Support-Verträge stellen sicher, dass der Kunde rechtzeitig Hilfe vom Unternehmen für seine komplexeren Probleme erhält. Unternehmen, die dieses Modell nutzen, erhalten vom Kunden in der Regel eine regelmäßige (meist monatliche) Zahlung.

Ein weiteres Geschäftsmodell für proprietäre Software — eigentlich eine Reihe von sich überschneidenden Modellen — nennt sich Freemium, ein Begriff, der 2009 vom Autor und Redakteur Chris Anderson eingeführt wurde und auf einem viel älteren Geschäftsmodell basiert, das als Razor and Blades (Rasierer und Klingen) bekannt ist. Dabei zahlen Kunden sehr wenig für das Basisprodukt (beispielsweise ein Rasierer oder einen Drucker), aber deutlich mehr für notwendige Komponenten, die sich abnutzen (Klingen für den Rasierer, Tintenpatronen für den Drucker).

Beim Freemium-Modell können Kunden ein Produkt bis zu einem bestimmten Grad kostenlos nutzen und werden dann ermutigt, für weitere Funktionen zu zahlen. Sie kennen wahrscheinlich Online-Nachrichtenseiten, die eine bestimmte Anzahl von Artikeln kostenlos anbieten und die Leser auffordern, ein Abonnement für den vollen Zugang zu ihren Seiten abzuschließen; dies ist ein bekanntes Beispiel für ein Freemium-Modell. Ein anderes Beispiel ist eine Spieleplattform, die das Basisspiel kostenlos zur Verfügung stellt, aber für bestimmte Inhalte Geld verlangt.

Andere proprietäre Softwareunternehmen setzen bei ihrem Freemium-Modell auf Zeit: “Testen Sie die Software drei Monate lang kostenlos und zahlen Sie dann, um sie weiter nutzen zu können.”

Proprietäre Softwareunternehmen nutzen manchmal eine Variante des Freemium-Modells, die als Open Core bekannt ist. Dabei sind bestimmte Grundfunktionen (der “Kern” des Produkts) quelloffen, und zusätzliche proprietäre Funktionen können lizenziert werden.

Oft ist der offene Teil voll funktionsfähig, funktioniert aber am besten für Wissenschaftler oder einzelne Benutzer und ist schwer zu verwalten, wenn viele Menschen ihn in einem Unternehmen gemeinsam nutzen. Daher können die proprietären Funktionen bequeme Webschnittstellen für die Verwaltung, Werkzeuge für die Buchhaltung und die Zusammenarbeit und andere Dinge umfassen, die für große Websites von besonderem Interesse sind.

Auch wenn Open-Core-Geschäftsmodelle Open Source Software nutzen, sind Kunden klug genug zu erkennen, dass das gesamte Produkt eigentlich proprietär ist. Open Core mag zwar den Vorteil haben, auf einem bestehenden Open-Source-Projekt aufzubauen, bietet aber nicht die anderen Vorteile von Open Source Software. Ein Open-Core-Geschäftsmodell schafft kein Vertrauen bei Kunden, inspiriert sie nicht dazu, zur Basissoftware beizutragen, gibt Kunden keinen Zugang zur Prüfung des Codes, baut kein Netzwerk von qualifizierten Entwicklern außerhalb des Hauptunternehmens auf und funktioniert nicht als Industriestandard. Schlimmer noch, das Open-Core-Entwicklungsmodell hat die gleichen Entwicklungskosten, ohne die Vorteile, die es lohnenswert machen. Unternehmen, die ein Open-Core-Geschäftsmodell ausprobieren, sind im Allgemeinen von den Ergebnissen enttäuscht, und viele wechseln später zu einem rein proprietären Modell.

Unternehmen können auch einen Webdienst auf einer quelloffenen oder proprietären Codebasis aufbauen: Software as a Service (SaaS). Kunden zahlen auf monatlicher oder jährlicher Basis.

Viele Unternehmen, die SaaS betreiben oder mobile Apps anbieten, verdienen ihr Geld mit Werbung. Einige Unternehmen sammeln auch Daten über die Benutzer des Dienstes oder der App und verkaufen diese Daten an Dritte, die sie für Werbung nutzen können. Werbung kann jedoch als lästig empfunden werden. Der Verkauf von Daten ist umstritten, und einige Länder schränken die Datenerfassung ein.

Schließlich können Unternehmen auch Open Source Software entwickeln und veröffentlichen, ohne zu versuchen, damit Geld zu verdienen. Dieses Modell steht Unternehmen zur Verfügung, die nicht nur mit der Software Geld verdienen, sondern auch mit anderen Dingen. So arbeiten beispielsweise Automobilhersteller zusammen, um große Mengen an freier Software für ihre Autos zu entwickeln (die heutzutage vollständig computerisiert sind).

Große Softwareunternehmen, die ihre Umsätze mit proprietären Angeboten erzielen, wie etwa Google und Amazon, geben manchmal Verwaltungssoftware oder andere nützliche Tools als Open Source frei, da diese Tools nicht zu ihrem Kerngeschäft gehören. Die Unternehmen, die den Code unter einer offenen Lizenz freigeben, profitieren von den Rückmeldungen, Fehlerberichten und Funktionsverbesserungen der Open Source Community.

Viele Unternehmen integrieren Open Source Software in ihre Produkte oder Webplattformen; schließlich ist Open Source Software kostenlos. Aber das ist nicht der wichtigste Grund (und vielleicht nicht einmal ein guter Grund), sie zu übernehmen. Viel wichtiger ist, dass diese Software meist von hoher Qualität ist (obwohl das Entwicklerteam sie sorgfältig prüfen sollte, bevor es sie übernimmt) und vielleicht sogar ein Industriestandard ist.

Ein weiterer Vorteil von Open Source Software besteht darin, dass sie auch dann noch verfügbar ist, wenn die Entwickler oder die Gemeinschaft, die sich um sie herum gebildet hat, verschwinden.

Aber freie und Open Source Software bringt auch Verantwortung mit sich. In diesem Abschnitt werden kurz die wichtigsten Punkte aufgeführt, die vor der Übernahme zu beachten sind.

Die ersten Fragen gelten für jede Software von Drittanbietern, die für eine Übernahme in Frage kommt: Wird die Software den Bedürfnissen der Benutzer jetzt und in Zukunft gerecht? Wird die Software von einer starken Gemeinschaft unterstützt, die technischen Support bieten und die Software weiterentwickeln kann? Weist die Software erhebliche Sicherheitslücken auf?

Darüber hinaus müssen Manager die Verantwortung des Unternehmens im Blick haben, wenn es ein Open-Source-Projekt in seine eigene Software einbindet. Wenn Entwickler neuen Code auf dem Open Source Code aufbauen, ist zu prüfen, was die Lizenz der Open Source Software vorgibt. Einige Lizenzen verlangen, dass der Quellcode der Änderungen unter der gleichen freien Lizenz wie die ursprüngliche Codebasis weitergegeben wird.

Selbst wenn ein Entwickler nicht verpflichtet ist, veränderten Quellcode weiterzugeben, und ein proprietäres Produkt auf der Grundlage des Open Source Codes erstellt, möchte er vielleicht bestimmte Dinge zurückgeben, wie beispielsweise Fehlerkorrekturen und Erweiterungen des Open Source Codes. Indem er diese Korrekturen und Erweiterungen beisteuert, erlaubt er dem Projekt, sie zu übernehmen (wenn die Kernentwickler sich dazu entschließen) und zu pflegen. Entwickler, die keine Verbesserungen zurückgeben, müssen die Korrekturen und Erweiterungen möglicherweise jedes Mal neu implementieren, wenn sie auf eine neue Version des ursprünglichen Codes aktualisieren.

Wegen dieser Abhängigkeit und aus anderen Gründen sollten die Mitarbeiter des Unternehmens in Erwägung ziehen, aktive Mitglieder der Community zu werden, die den Code entwickelt. Die Entwickler können durch ihre Mitarbeit viel über den Code lernen und die Richtung der zukünftigen Entwicklung mitbestimmen. Natürlich sollte das Unternehmen seine Entwickler für die Zeit bezahlen, die sie in die Aktivitäten der Community investieren. Für ein Unternehmen, das freie Software ernsthaft nutzen möchte, ist sie nicht kostenlos.

Die Öffnung des Codes ist für Kunden aus mehreren Gründen von Vorteil, setzt aber auch eine andere Beziehung zwischen dem Unternehmen und seinen Kunden voraus. Die Kunden sollten sowohl die Vorteile als auch die Implikationen verstehen.

Der bereits erwähnte Hauptvorteil für Kunden besteht darin, dass sie größeres Vertrauen in die Software haben können. Sie wissen, dass die Software nicht verschwinden wird. Viele Unternehmen schließen oder schlagen plötzlich eine neue Richtung ein und lassen ihre Kunden im Stich, die nur eine kurze Frist haben, um auf ein anderes Produkt umzusteigen, das ihnen vielleicht gar nicht gefällt. Open Source Software hingegen hängt nicht von einer einzelnen Organisation ab. Wenn das Projekt wichtig ist, werden es andere Mitglieder der Community weiterführen, wenn sich die ursprünglichen Entwickler zurückziehen.

Kunden können zudem Qualität und Sicherheit von Open Source Software prüfen und testen, wie leicht sie eigene Funktionen hinzufügen oder die Software auf eine neue Umgebung portieren können.

Da der Quellcode eines Open-Source-Projekts für alle einsehbar ist, kann sich ein breites Spektrum von Entwicklern damit vertraut machen. Bei einem Projekt mit aktiver Community bieten viele Mitglieder im Forum Unterstützung an. Oft ist es einfach, Leute für Support, Verwaltung und Nutzung der Software zu finden, da neue Mitarbeiter den Code bereits kennen.

Es ist sehr beruhigend für Kunden, die in ihrem Tagesgeschäft auf den Code angewiesen sind, dass sie Fehler selbst beheben oder jemanden damit beauftragen können. Bei einem obskuren Fehler, der nur wenige Kunden betrifft, kann es Jahre dauern, bis er vom Hauptentwicklungsteam proprietärer Software behoben wird, was für Benutzer permanente Frustration bedeutet. Ist der Quellcode verfügbar, sind Fehler schneller zu erkennen und zu beheben.

Was bedeutet das für die Beziehung zwischen einem Unternehmen und seinen Kunden? Ein Unternehmen kann sich für ein typisches proprietäres Modell entscheiden, indem es seinen Kunden regelmäßige Updates und einen Supportvertrag anbietet. Der Kunde muss sich niemals den Quellcode ansehen oder den Community-Foren beitreten.

Die meisten Kunden würden jedoch von den einzigartigen Möglichkeiten profitieren, die Open-Source-Projekte bieten: Sie können ihren eigenen Entwicklern erlauben, sowohl Informationen als auch Code beizusteuern. Eine solche Beteiligung vertieft das Verständnis der Mitarbeiter und hilft, neue Mitarbeiter zu rekrutieren. Zudem eröffnet es die Möglichkeit, die zukünftige Entwicklung mitzugestalten.

Programmierer sind sehr gefragt, so dass jede Softwareentwicklung kostenintensiv ist. Experten für große Open-Source-Projekte sind sogar noch gefragter, weil die jeweilige Codebasis weit verbreitet sind.

Ein Open-Source-Projekt bietet Potenzial für Kosteneinsparungen, da verschiedene Organisationen und Einzelpersonen ihre Bemühungen in einer gemeinsamen Codebasis bündeln können. Der Betrieb eines solchen Projekts führt jedoch zu neuen Kosten.

Wenn ein Unternehmen ein Projekt öffnet, das intern entwickelt wurde, muss es investieren, um es für eine größere (möglicherweise weltweite) Community nutzbar zu machen. Funktionen, die auf die geschäftlichen Anforderungen des Unternehmens zugeschnitten waren, müssen möglicherweise überdacht werden, um auch anderen Unternehmen zu nutzen.

Ist der Code mangelhaft oder umständlich, sollte ein Unternehmen ihn wahrscheinlich nicht freigeben. Die Qualität könnte potenzielle Beiträger oder auch Kunden abschrecken. Es liegt jedoch im Interesse der Entwickler, diese Probleme trotzdem zu beheben, denn schlecht programmierte Software ist sperrig: Sie lässt sich nur schwer mit neuen Funktionen aktualisieren und neigt dazu, komplexe Fehler zu werfen, die schwer zu beheben sind. Diese Probleme werden technical debt (technische Schulden) genannt, und je früher sie behoben werden, desto besser ist es für alle Beteiligten.

Schließlich ist es erstaunlich, wie oft Unternehmen Geschäftsgeheimnisse, Passwörter, persönliche Hinweise auf Personen oder andere sensible Informationen in Code einbetten. Entwickler müssen Zeit investieren, um solche Schwachstellen zu beseitigen. Passwörter, API-Schlüssel, Zertifikate und Cloud-Zugangsdaten sollten nie im Code stehen, sondern extern über einen sicheren Dienst verwaltet werden.

Nehmen wir an, ein Unternehmen hat seinen Code freigegeben und hofft, von externen Beiträgen zu profitieren. Einige Kunden werden Entwickler für die Wartung und neue Funktionen bezahlen. Andere werden ihre eigenen Entwickler auf das Projekt ansetzen, aber das Hauptentwicklungsteam muss Zeit für deren Unterstützung aufwenden. Das Hauptentwicklungsteam muss Außenstehende über den Code und die damit verbundenen Codierungsstandards aufklären. Dieses Team sollte Außenstehende auch anleiten, was sie hinzufügen und wohin sie Kommentare zu ihrem Code zurücksenden sollen.

Halten Sie Ausschau nach externen Helfern, die sich als talentiert erweisen. Sie könnten wertvolle Verstärkung für das Kernteam sein. Sie wollen sich möglicherweise gern dem Team anschließen und beträchtliches Wissen einbringen.

Wenn ein Team von Entwicklern bezahlt wird, während andere ihre Zeit freiwillig zur Verfügung stellen, könnten sich die Freiwilligen ausgenutzt fühlen oder sich fragen, warum sie helfen sollten. Jeder, der einen Beitrag leistet, sei es ein einzelner Freiwilliger oder eine Organisation, muss die zuvor in dieser Lektion beschriebenen Überlegungen anstellen, um zu entscheiden, ob ein Beitrag sinnvoll ist.

Freier Code ist nicht kostenlos, auch wenn er nicht mit Lizenzkosten verbunden ist. Es handelt sich schlichtweg um ein anderes Entwicklungsmodell.