Was ist Open Source, und wie wuchs GitHub und verdient Geld?

Open Source bedeutet nicht einfach, Quellcode öffentlich zu machen. Es ist eine Form, anderen durch eine klar definierte Lizenz Rechte zur Nutzung, Untersuchung, Änderung und Weiterverbreitung von Software einzuräumen. GitHub entwickelte sich zu einer kommerziellen Plattform, indem es diese Art kollaborativer Entwicklung in einem einzigen Workflow für Repositorys, Versionsverwaltung, Code-Review und Automatisierung zusammenführte.

Das Kerngeschäftsmodell von GitHub besteht nicht darin, öffentliche Open-Source-Projekte direkt zu verkaufen. Die Plattform gewinnt eine große Zahl kostenloser Nutzer und berechnet dann Gebühren für private Zusammenarbeit, Zugriffskontrollen, Sicherheit, Compliance, Automatisierung, Cloud-Entwicklungsumgebungen und Funktionen für künstliche Intelligenz, die Unternehmen benötigen.

Inhaltsverzeichnis

• Die genaue Bedeutung von Open Source
• Der Hintergrund der Open-Source-Bewegung
• So funktioniert Open-Source-Entwicklung
• Die Unterschiede zwischen Open Source, Git und GitHub
• Ursprung und Wachstum von GitHub
• Das Erlösmodell von GitHub
• Warum kostenloses Open Source wirtschaftlichen Wert schafft
• Grenzen und Bewertungskriterien

Was genau ist Open Source?

Open-Source-Software ist Software, für die der Urheberrechtsinhaber den Nutzern durch eine Lizenz Rechte einräumt, einschließlich der Rechte, sie auszuführen, zu untersuchen, zu ändern und weiterzuverbreiten. Entscheidend ist nicht nur, ob der Code einsehbar ist, sondern welche Rechte rechtlich erlaubt sind.

Nach der Definition der Open Source Initiative (OSI) muss eine Open-Source-Lizenz die freie Weiterverbreitung erlauben, den Quellcode bereitstellen und die Verbreitung von Änderungen und abgeleiteten Werken zulassen. Sie darf weder Personen, Gruppen noch Anwendungsbereiche diskriminieren. Wenn daher Einschränkungen wie „nur für nichtkommerzielle Nutzung“ oder „darf nicht in Konkurrenzprodukten verwendet werden“ gelten, ist die Software im üblichen Sinn kaum als Open Source anzuerkennen – selbst wenn ihr Quellcode öffentlich ist. OSI의 Open Source Definition↗

Diese Unterscheidung ist besonders bei öffentlichen Repositorys auf GitHub wichtig. Auch wenn ein Repository für alle öffentlich sichtbar ist, gilt das gewöhnliche Urheberrecht, falls keine Open-Source-Lizenz vorhanden ist. Andere können das Repository innerhalb des GitHub-Dienstes ansehen oder forken, erwerben dadurch aber nicht automatisch das Recht, den Code frei zu kopieren, zu ändern und zu verbreiten. GitHub erläutert ebenfalls, dass ein Projekt erst durch eine Lizenz, die Nutzungsrechte festlegt, tatsächlich Open Source wird. GitHub의 저장소 라이선스 안내↗

Die folgenden drei Aussagen bedeuten daher Unterschiedliches:

• „Du kannst den Code ansehen“ beschreibt, ob der Quellcode öffentlich ist.
• „Du kannst ihn kostenlos nutzen“ beschreibt den Preis.
• „Es ist Open Source“ beschreibt die durch die Lizenz eingeräumten Rechte.

Kostenlose Software ist nicht zwangsläufig Open Source, und Open-Source-Software kann auch verkauft werden.

Welcher Hintergrund führte zur Open-Source-Bewegung?

Die Praxis, Softwarecode zu teilen und gemeinschaftlich zu verbessern, gab es bereits in frühen Forschungscommunities der Informatik. Als sich Software jedoch zu einem eigenständigen kommerziellen Produkt entwickelte und Urheberrechte sowie Nutzungsbeschränkungen strenger wurden, wuchs auch die Sorge um die Fähigkeit der Nutzer, Software zu untersuchen und zu reparieren.

In den 1980er-Jahren startete Richard Stallman das GNU-Projekt und die Bewegung für freie Software. Bei freier Software bezieht sich „frei“ nicht auf den Preis, sondern auf die Freiheit der Nutzer, ein Programm auszuführen, zu untersuchen, zu ändern und in ursprünglicher oder veränderter Form weiterzuverbreiten. GNU의 자유 소프트웨어 정의↗

Die Bezeichnung „Open Source“ entstand bei einem Strategietreffen kurz nachdem Netscape 1998 angekündigt hatte, den Quellcode seines Browsers freizugeben. Im selben Jahr gründeten Eric Raymond, Bruce Perens und andere die OSI und formulierten die Open Source Definition auf Grundlage der Debian Free Software Guidelines. Ziel war es, Unternehmen und Öffentlichkeit die praktischen Vorteile kollaborativer Entwicklung klarer zu vermitteln. OSI 역사↗

Freie Software und Open Source überschneiden sich bei den akzeptierten Lizenzen weitgehend, setzen aber unterschiedliche Schwerpunkte.

Dieser Unterschied bedeutet nicht, dass eine Seite immer überlegen ist. Dasselbe Programm kann aus der einen Perspektive mit Fokus auf Nutzerrechte und aus der anderen mit Fokus auf die Effizienz transparenter Entwicklung und verteilter Zusammenarbeit erklärt werden.

Wie funktioniert Open-Source-Entwicklung?

Open Source bedeutet nicht, dass „jeder den Code beliebig ändern kann“. Die Teilnahme kann offen sein, doch Projekt-Maintainer und festgelegte Verfahren bestimmen, was in eine offizielle Version übernommen wird.

Ein typischer Entwicklungsprozess läuft wie folgt ab:

1. Ein Maintainer veröffentlicht Quellcode, Lizenz, Nutzungsanweisungen und Beitragsregeln.
2. Ein Nutzer klont oder forkt das Repository, um einen unabhängigen Arbeitsbereich zu erstellen.
3. Fehlerbehebungen oder die Entwicklung neuer Funktionen erfolgen in einem separaten Branch.
4. Der Beitragende reicht einen Pull Request mit den Änderungen und deren Begründung ein.
5. Maintainer prüfen Code, Testergebnisse, Designausrichtung und Sicherheitsauswirkungen.
6. Nur Änderungen, die den Kriterien entsprechen, werden in das offizielle Repository gemergt.
7. Eine neue Version wird veröffentlicht; danach entdeckte Probleme werden erneut nachverfolgt.

In diesem Prozess gibt es verschiedene Rollen. Nutzer verwenden die Software und melden Probleme. Beitragende reichen Code oder Dokumentation ein. Maintainer führen Reviews und Releases durch. Auch ein Lenkungsausschuss oder eine Stiftung kann Markenrechte, Budgets und Entscheidungsregeln verwalten.

Mit anderen Worten: Die „Offenheit“ von Open Source bedeutet nicht, dass es keine Entscheidungsinstanz gibt. Die Möglichkeiten zur Teilnahme und die Rechte zur Nutzung des Codes sind offen, während offizielle Projekte Kontrollstrukturen zur Qualitätssicherung haben.

Wie unterscheiden sich Open-Source-Lizenzen?

Open-Source-Lizenzen lassen sich grob in permissive Lizenzen und Copyleft-Lizenzen einteilen.

Permissive Lizenzen

MIT, BSD und Apache License 2.0 sind verbreitete Beispiele. Solange Bedingungen wie die Beibehaltung von Urheberrechtshinweisen und Lizenztext erfüllt werden, erlauben diese Lizenzen im Allgemeinen, geänderten Code in proprietäre Software einzubinden.

Das erleichtert Unternehmen die Integration in kommerzielle Produkte, garantiert jedoch nicht, dass verbesserter Code an die ursprüngliche Community zurückfließt. Apache License 2.0 enthält außerdem ausdrückliche patentbezogene Bestimmungen; ihre rechtlichen Bedingungen sind daher nicht identisch mit denen der MIT License.

Copyleft-Lizenzen

Die GNU General Public License (GPL) ist ein typisches Beispiel. Werden geänderter Code oder ein abgeleitetes Werk, das mit diesem Code kombiniert wurde, verbreitet, kann sie verlangen, dass der Quellcode unter derselben Lizenz bereitgestellt wird.

Copyleft verbietet keine kommerzielle Nutzung. Software darf kommerziell verkauft werden, allerdings müssen die innerhalb des von der Lizenz definierten Umfangs geltenden Offenlegungspflichten erfüllt werden. Varianten wie LGPL und AGPL sind mit unterschiedlichen Bedingungen für Bibliotheksverlinkung und Netzwerkdienste konzipiert.

Bei der Wahl einer Lizenz sollte man sie nicht einfach auswählen, weil ein bekanntes Projekt sie verwendet. Zu prüfen sind der Offenlegungsumfang für abgeleitete Werke, Patentbestimmungen, die Bereitstellung als Netzwerkdienst sowie die Kompatibilität mit anderen Lizenzen.

Was ist der Unterschied zwischen Open Source, Git und GitHub?

Diese drei Konzepte treten häufig gemeinsam auf, arbeiten jedoch auf unterschiedlichen Ebenen.

• Open Source ist ein Konzept, das Softwarenutzungsrechte und eine Methode kollaborativer Entwicklung beschreibt.
• Git ist ein Open-Source-Programm zur Versionsverwaltung, das die Historie von Dateiänderungen verteilt verwaltet.
• GitHub ist ein kommerzieller Dienst, der Git-Repositorys online hostet und Funktionen für Code-Review, Issue-Management, Automatisierung, Sicherheit und Zusammenarbeit bereitstellt.

Git wurde 2005 entwickelt, nachdem die Beziehung zwischen der Linux-Kernel-Entwicklungscommunity und dem proprietären verteilten Versionsverwaltungstool BitKeeper endete. Benötigt wurde ein Werkzeug, das die Geschwindigkeit, verteilte Arbeit und große Zahl paralleler Branches eines Projekts in der Größenordnung von Linux bewältigen konnte. Git 공식 역사↗

Mit Git kann jeder Entwickler ein Repository mit der vollständigen Änderungshistorie führen, ohne dauerhaft mit einem zentralen Server verbunden zu sein. Doch Git über die Kommandozeile allein machte es umständlich, zu verwalten, wer eine Änderung vorgeschlagen hatte, warum sie nötig war, wer sie prüfen sollte und wann sie gemergt würde. GitHub organisierte genau diesen Kollaborationsprozess über eine Weboberfläche.

Git kann ohne GitHub verwendet werden, und Repositorys können auf GitLab, Bitbucket oder selbst gehosteten Servern betrieben werden. Umgekehrt enthält GitHub nicht nur Open Source, sondern auch privaten Unternehmenscode und öffentlichen Code ohne Lizenz. GitHub und Open Source sind nicht gleichbedeutend.

Wie begann GitHub?

GitHub wurde um Tom Preston-Werner, Chris Wanstrath und PJ Hyett entwickelt und 2008 als öffentlicher Dienst gestartet. Scott Chacon, ein Git-Experte, der später als Autor von Pro Git bekannt wurde, gehörte ebenfalls zum frühen Team.

Der erste Commit in GitHubs internem Repository erfolgte im Oktober 2007, der Dienst startete im April 2008. Um seinen ersten Jahrestag herum hatte GitHub über 20.000 öffentliche Repositorys und vier Vollzeitbeschäftigte, ohne externe Investitionen erhalten zu haben. GitHub의 첫해 기록↗

Das Problem, das GitHub lösen wollte, war nicht bloß Dateispeicherung. Ziel war eine kollaborative Umgebung, die Änderungen in verteilten Git-Repositorys sichtbar machte, Entwicklern half, die Arbeit anderer zu entdecken, und Änderungsvorschläge einfach überprüfbar machte. Der 2008 veröffentlichte Network Graph von GitHub war ebenfalls ein Versuch, die Beziehungen zwischen Branches und Commits mehrerer Nutzer auf einem Bildschirm darzustellen. 초기 Network Graph 소개↗

Dieser Ansatz wurde später als „Social Coding“ bezeichnet. Profile, Aktivitätsverläufe, Follows, Forks, Stars, Issues und Pull Requests von Entwicklern wurden mit Code-Repositorys verknüpft. Dadurch wurde der Entwicklungsprozess selbst zu einem durchsuchbaren und beobachtbaren Netzwerk.

Warum wuchs GitHub so schnell?

Das Wachstum von GitHub lässt sich nicht allein durch kostenlosen Git-Speicher erklären. Technisches Timing, Nutzererlebnis, Netzwerkeffekte und ein Enterprise-Geschäftsmodell wirkten zusammen.

Es machte Gits komplexen Kollaborationsprozess im Web verständlich

Branches, Commits und Merges sind leistungsstarke Git-Funktionen, für Einsteiger aber allein über Befehle nicht leicht verständlich. GitHub führte Codeunterschiede, Diskussionen, Review-Ergebnisse und Teststatus in der Pull-Request-Oberfläche zusammen.

Anstatt Patch-Dateien per E-Mail zu versenden, konnten Entwickler Änderungen über einen einzigen Link teilen. Projekt-Maintainer konnten Review-Kosten senken, weil Code und Diskussionsverlauf gemeinsam dokumentiert wurden.

Öffentliche Repositorys schufen ein Entwicklernetzwerk

Wenn ein Projekt GitHub beitritt, erstellen auch dessen Nutzer und Beitragende mit höherer Wahrscheinlichkeit Konten. Diese Nutzer gründen dann weitere Projekte oder beteiligen sich an bestehenden.

Mit zunehmender Zahl an Repositorys besuchen Entwickler GitHub, um Code zu finden. Mit zunehmender Zahl an Entwicklern wählen Projekt-Maintainer GitHub, um Beitragende zu gewinnen. Dies ist ein zweiseitiger Netzwerkeffekt.

Öffentliche Aktivitätsverläufe dienten zudem als Entwicklerportfolios. Unternehmen konnten den tatsächlichen Code und die Zusammenarbeitserfahrung von Bewerbern prüfen, während Entwickler einen Anreiz hatten, Aktivitätsverläufe für Beschäftigungschancen und Reputation aufzubauen.

Open Source und Enterprise-Produkte wuchsen gleichzeitig

GitHub senkte die Einstiegshürde für öffentliche Open-Source-Repositorys und verlangte bereits früh Gebühren für private Repositorys. 2011 führte es GitHub Enterprise ein, das auf internen Unternehmensservern betrieben werden konnte und Enterprise-Anforderungen wie Authentifizierung, Backups und Teamverwaltung abdeckte. GitHub Enterprise 출시 기록↗

Diese Struktur ermöglichte es einzelnen Entwicklern, GitHub über Open-Source-Projekte kennenzulernen und nach Eintritt in ein Unternehmen eine Enterprise-Version desselben Workflows zu verwenden. Sie ermöglichte eine Bottom-up-Einführung, bei der Entwickler das Produkt ohne separate Vertriebsbemühungen für Einzelpersonen in ihre Organisationen brachten.

GitHub erklärte, durch kostenpflichtige Dienste ohne externe Investitionen profitabel gewachsen zu sein, und nahm 2012 seine erste externe Investition auf. GitHub의 2012년 투자 발표↗

Der kostenlose Tarif wurde erweitert und Gründe für den Wechsel zur Konkurrenz verringert

2019 begann GitHub, privaten Repositorys für kostenlose persönliche Konten anzubieten. 2020 entfielen außerdem die Beschränkungen für Mitwirkende in kostenlosen privaten Repositorys, und zentrale Teamfunktionen wurden kostenlos. Erweiterte Berechtigungsverwaltung sowie Sicherheits- und Supportfunktionen, die Unternehmen benötigen, blieben kostenpflichtig. GitHub Free 확대 발표↗

Die Erweiterung des kostenlosen Tarifs bedeutet kurzfristig Verzicht auf Teile der Abonnementumsätze. Sie hält jedoch mehr Einzelpersonen und kleine Teams auf der Plattform und schafft Gelegenheiten, sie mit dem Wachstum ihrer Organisationen zu Team-, Enterprise-, Sicherheits- und KI-Produkten zu konvertieren.

Wie beeinflusste die Übernahme durch Microsoft das Wachstum von GitHub?

Microsoft vereinbarte 2018 die Übernahme von GitHub für 7,5 Milliarden US-Dollar in Microsoft-Aktien. GitHub berichtete damals von mehr als 28 Millionen Nutzern. Microsoft erklärte, GitHub werde unabhängig arbeiten und seinen auf Entwickler ausgerichteten Charakter bewahren. Microsoft의 GitHub 인수 발표↗

Die Übernahme entsprach den strategischen Bedürfnissen beider Seiten. GitHub konnte globale Cloud-Infrastruktur, ein Enterprise-Vertriebsnetz sowie Sicherheits- und Compliance-Fähigkeiten nutzen. Microsoft konnte sich über sein früheres Image als auf Windows und proprietäre Software ausgerichtetes Unternehmen hinaus entwickeln und Kontaktpunkte zu Entwicklern unabhängig von Betriebssystem oder Programmiersprache schaffen. Zudem entstanden Möglichkeiten, Azure, Visual Studio, VS Code und GitHub zu verbinden.

Nach der Übernahme weitete GitHub sich über das Hosting von Repositorys hinaus zu einer Plattform für den gesamten Entwicklungslebenszyklus aus. GitHub Actions automatisiert Builds, Tests und Deployments; Codespaces bietet Cloud-Entwicklungsumgebungen; Advanced-Security-Produkte scannen Code, Abhängigkeiten und Secrets; und Copilot bietet KI-gestützte Funktionen zum Schreiben und Prüfen von Code.

Im Oktober 2022 gab Microsoft bekannt, dass GitHub 1 Milliarde US-Dollar an jährlich wiederkehrenden Umsätzen (ARR) erreicht hatte und auf über 90 Millionen Nutzer gewachsen war – das Dreifache der Nutzerzahl zum Übernahmezeitpunkt. Microsoft FY2023 1분기 실적 발표↗

GitHub teilte mit, dass 2023 mehr als 100 Millionen Entwickler die Plattform nutzten und 2025 mehr als 180 Millionen. 2025 erreichte die Gesamtzahl der Projekte 630 Millionen; GitHub zählte etwa 81,5 % aller Beiträge in privaten Repositorys. Das zeigt, dass GitHub sowohl ein Open-Source-Raum als auch eine groß angelegte Infrastruktur für Unternehmensentwicklung geworden ist. GitHub Octoverse 2025↗

Diese Zahlen sind jedoch Plattformkennzahlen, die nach GitHubs eigenen Kriterien gezählt werden. Die Zahl registrierter Entwickler darf nicht mit monatlich aktiven Nutzern oder zahlenden Kunden gleichgesetzt werden. Microsoft veröffentlicht die aktuellen Umsätze und Betriebsgewinne von GitHub auch nicht jedes Jahr detailliert als eigenständige Geschäftseinheit. Die 2022 gemeldete ARR von 1 Milliarde US-Dollar sollte daher als damals veröffentlichte repräsentative Größenkennzahl und nicht als aktueller Umsatz betrachtet werden.

Womit verdient GitHub konkret Geld?

Das Erlösmodell von GitHub lässt sich als Freemium-Modell zusammenfassen: Es gewinnt Nutzer über eine kostenlose öffentliche Plattform und berechnet Gebühren für die Kontrolle und Produktivität, die Organisationen für ihren Betrieb benötigen.

Abonnements pro Nutzerlizenz

Der kostenlose Tarif ermöglicht Einzelpersonen und kleinen Teams die Nutzung zentraler Repository-Funktionen. Der Team-Tarif bietet erweiterte Funktionen für die Zusammenarbeit, während der Enterprise-Tarif Sicherheit, Compliance, zentrale Verwaltung und Bereitstellungsoptionen bietet.

Laut der im September 2026 geprüften offiziellen Preisseite beginnt Team bei 4 US-Dollar pro Nutzer und Monat, Enterprise bei 21 US-Dollar pro Nutzer und Monat. Die tatsächlichen Beträge können je nach Vertragslaufzeit, Region, Steuern und Bedingungen großer Verträge abweichen. GitHub 공식 가격표↗

Die Abrechnung nach Nutzerlizenzen hat den Vorteil, dass wiederkehrende Umsätze mit der Mitarbeiterzahl eines Unternehmens wachsen können. Sobald Code und Arbeitsprozesse auf der Plattform etabliert sind, steigen auch die Wechselkosten, wodurch Verträge eher erhalten bleiben.

Abonnements für KI-Produkte und nutzungsabhängige Abrechnung

GitHub Copilot bietet kostenpflichtige Tarife für Einzelpersonen und Organisationen. Unternehmen kaufen Lizenzen für jeden Nutzer; zusätzliche Nutzungsgebühren können anfallen, wenn die im Tarif enthaltene KI-Nutzung überschritten wird. Copilot entwickelt sich damit zu einem Modell, das klassische Softwareabonnements mit der Abrechnung von KI-Rechenleistung kombiniert. GitHub Copilot 조직 청구 안내↗

Copilot schafft nicht nur eine neue Umsatzquelle für GitHub, sondern führt auch dazu, dass KI innerhalb etablierter Workflows rund um Repositorys, Issues, Pull Requests und Code-Reviews genutzt wird. Das erleichtert den Cross-Selling weiterer Produkte an bestehende Plattformkunden gegenüber dem Verkauf eines separaten KI-Tools.

Sicherheits- und Compliance-Produkte

Große Unternehmen zahlen nicht nur für einen Ort zur Speicherung von Code. Sie benötigen Kontokontrollen, Audit-Logs, Single Sign-on, Erkennung von Secrets, Analyse von Code-Schwachstellen, Lieferkettenmanagement und regulatorische Compliance.

Mit der wachsenden Abhängigkeit von Open-Source-Abhängigkeiten müssen Organisationen fortlaufend nach anfälligen Paketen und offengelegten Zugangsdaten suchen. Die Ausweitung des kostenlosen Ökosystems steigert paradoxerweise auch den Bedarf an Enterprise-Sicherheitsprodukten.

Nutzung von Rechenleistung, Speicher und Automatisierung

Dienste wie GitHub Actions, Codespaces und Packages enthalten ein bestimmtes Nutzungsvolumen im Tarif und berechnen Überschreitungen. Eine Enterprise-Rechnung kann neben Enterprise-Lizenzen auch die Mehrnutzung von Actions oder Codespaces sowie zusätzliche Lizenzen für Produkte wie Copilot und Sicherheitstools enthalten. GitHub Enterprise 청구 구조↗

Dieses Modell ermöglicht es GitHub, seine Umsätze mit zunehmender Entwicklungsaktivität zu steigern. Andererseits trägt GitHub auch die Kosten für Ausführungsserver, Speichergeräte, Netzwerke und KI-Modelle; nicht jeder Nutzungsumsatz ist daher Gewinn.

Transaktionsgebühren im Marketplace

Drittanbieter können kostenpflichtige Apps über GitHub Marketplace verkaufen. GitHub stellt Zahlungs- und Abonnementverwaltung bereit und behält einen Teil des Transaktionswerts als Betriebsgebühr ein. Laut offizieller Dokumentation beträgt der seit 2021 auf App-Transaktionen angewandte einbehaltene Anteil 5 %. GitHub Marketplace 판매 대금 안내↗

Neben direkten Marketplace-Gebühren ist auch wichtig, dass externe Werkzeuge auf GitHub ausgerichtet werden. Je mehr Apps genutzt werden, desto mehr Entwicklungstools müssen beim Verlassen von GitHub ersetzt werden, was die Bindung an die Plattform stärkt.

Warum hat kostenloses Open Source wirtschaftlichen Wert für GitHub?

Für GitHub sind kostenlose öffentliche Repositorys nicht bloß ein Kostenfaktor. Sie sind ein zentraler Vermögenswert für Nutzergewinnung und die Bildung eines Ökosystems.

Erstens bringen Open-Source-Projekte neue Nutzer. Entwickler, die eine bestimmte Bibliothek verwenden, ein Problem melden oder einen Patch einreichen möchten, erstellen GitHub-Konten. GitHub kann diese Nutzer ohne Werbeausgaben gewinnen.

Zweitens macht Open-Source-Aktivität die Arbeitsweise von GitHub zu einem de-facto-Industriestandard. Entwickler lernen Forks, Issues und Pull Requests in der Schule oder über persönliche Projekte kennen und bevorzugen dann denselben Ansatz bei der Arbeit.

Drittens sind das öffentliche Ökosystem und die private Unternehmensentwicklung voneinander abhängig. Auch private Produkte von Unternehmen nutzen unzählige öffentliche Bibliotheken und Werkzeuge. In GitHubs Daten für 2025 fand der Großteil der Beitragsaktivität in privaten Repositorys statt, während öffentliche Projekte nach Repository-Anzahl die Mehrheit ausmachten. Das kostenlose öffentliche Ökosystem bildet die Grundlage für bezahlte Enterprise-Arbeit.

Viertens steigert eine größere Zahl aktiver öffentlicher Projekte die Nachfrage nach Sicherheit und Automatisierung. Aktualisierungen von Abhängigkeiten, die Erkennung bösartiger Pakete, Lizenzmanagement sowie groß angelegte Tests und Deployments werden notwendig.

GitHubs Unterstützung für kostenloses Open Source lässt sich daher schwer allein als Philanthropie oder allein als kommerzielle Tätigkeit erklären. Sie bietet der Entwicklercommunity echten Nutzen und dient zugleich als langfristige Vertriebsstrategie für den kostenpflichtigen Enterprise-Markt.

Wie verdienen Open-Source-Unternehmen im Allgemeinen Geld?

Das Geschäftsmodell von GitHub ist eines von mehreren Erlösmodellen, die Open Source nutzen. Open-Source-Unternehmen berechnen häufig nicht für den reproduzierbaren Code selbst Gebühren, sondern für Betriebskomfort, Verantwortlichkeit, Sicherheit und Fachwissen.

• Support und Beratung: Sie stellen Software kostenlos bereit und berechnen Gebühren für Installation, Störungsbehebung, Schulungen und langfristigen Support.
• Managed Cloud: Neben Open Source, die Kunden selbst installieren können, verkaufen sie SaaS, das sie im Auftrag des Kunden betreiben.
• Open Core: Sie veröffentlichen Kernfunktionen, bieten jedoch Enterprise-Funktionen für Verwaltung, Sicherheit und Analysen unter proprietären Lizenzen an.
• Doppellizenzierung: Sie bieten denselben Code sowohl unter einer Open-Source- als auch unter einer kommerziellen Lizenz an, damit Nutzer entsprechend ihrer Situation wählen können.
• Hosting und Nutzung: Sie berechnen Gebühren nach Speicher-, Netzwerk-, Rechen- und Automatisierungsausführung.
• Sponsoring und Spenden: Einzelpersonen, Unternehmen und Stiftungen unterstützen Maintainer oder den Betrieb von Projekten.
• Zertifizierung und Schulung: Sie erzielen Einnahmen durch offizielle Schulungen, Prüfungen, technische Zertifizierungen oder Partnerprogramme.

Diese Modelle funktionieren, weil sich Softwarekosten nicht auf den Lizenzpreis beschränken. Unternehmen betrachten die Gesamtbetriebskosten, einschließlich Installationszeit, Ausfallrisiko, Sicherheitsvorfällen, Updates, regulatorischer Compliance und Mangel an spezialisiertem Personal. Auch wenn sie den Code kostenlos erhalten können, sind sie möglicherweise bereit, für verlässliche betriebliche Verantwortlichkeit zu zahlen.

Was sind die Grenzen von Open Source und GitHub?

Open Source wird nicht automatisch zu sicherer und nachhaltiger Software, nur weil viele Personen beteiligt sind.

Wartungslasten können sich auf wenige Personen konzentrieren

Selbst eine weit verbreitete Bibliothek kann für tatsächliche Reviews und Releases von nur wenigen Maintainern abhängen. Mit zunehmender Nutzung wächst die Last durch Problemberichte und Sicherheitsreaktionen, während die Vergütung der Maintainer möglicherweise nicht entsprechend steigt.

Öffentliche Prüfung garantiert keine Qualität

Dass Quellcode öffentlich ist, unterscheidet sich davon, dass ihn jemand ausreichend geprüft hat. Risiken in der Lieferkette umfassen Schwachstellen, bösartige Beiträge, kompromittierte Maintainer-Konten und manipulierte Abhängigkeiten.

Lizenzpflichten können übersehen werden

Open Source ist kein urheberrechtsfreies öffentliches Gut. Die Bedingungen jeder Lizenz müssen eingehalten werden, einschließlich der Beibehaltung von Urheberrechtshinweisen, der Bereitstellung von Quellcode, der Kennzeichnung von Änderungen und der Anwendung derselben Lizenz. Besonders bei kommerziellen Produkten, die viele Abhängigkeiten kombinieren, muss die Lizenzkompatibilität geprüft werden.

Plattformkonzentration schafft neue Abhängigkeiten

Da Git verteilt ist, können Repositorys auf andere Server verschoben werden. Issues, Pull-Request-Diskussionen, Actions-Workflows, Zugriffsrichtlinien, Marketplace-Apps und Sicherheitsaufzeichnungen vollständig zu migrieren, ist jedoch wesentlich schwieriger.

Je bequemer GitHub wird, desto stärker können Entwicklungsgemeinschaften von Preisgestaltung, Richtlinien, Störungsreaktionen und Funktionsänderungen eines einzelnen Unternehmens abhängen. Es ist notwendig, Code lokal zu klonen, Releases und Dokumentation zu sichern und die Abhängigkeit von spezifischen Plattformfunktionen zu verstehen.

Was sind verbreitete Missverständnisse?

„Es ist auf GitHub öffentlich, also ist es Open Source“

Ohne Lizenz entstehen keine gewöhnlichen Open-Source-Nutzungsrechte. Sichtbarkeit und Lizenzierung sind getrennte Einstellungen.

„Jede Open-Source-Software ist kostenlos“

Es kann zwar keine Kopierkosten geben, aber Betrieb, Support, Cloud-Dienste, Schulungen und Sicherheitsfunktionen können Kosten verursachen. Open-Source-Lizenzen verbieten keinen kostenpflichtigen Verkauf.

„Jeder kann den offiziellen Code beliebig ändern“

Das Recht, dass jeder seine eigene Kopie ändern darf, unterscheidet sich von der Befugnis, Änderungen in das offizielle Projekt aufzunehmen. Maintainer und Governance-Regeln entscheiden, ob Änderungen offiziell einbezogen werden.

„GitHub selbst ist Open Source“

GitHub hostet Open-Source-Projekte in großem Umfang und veröffentlicht verschiedene Open-Source-Werkzeuge, aber der gesamte GitHub-Dienst ist kein einzelnes Open-Source-Produkt. GitHub ist eine kommerzielle Plattform im Besitz von Microsoft.

„Weil GitHub viele Nutzer hat, zahlen die meisten von ihnen“

Die von GitHub gemeldeten Entwicklerzahlen schließen kostenlose Konten ein. Registrierte Entwickler insgesamt, aktive Entwickler, Enterprise-Kunden und kostenpflichtige Lizenzen sind unterschiedliche Kennzahlen.

„Microsoft betreibt GitHub kostenlos“

Obwohl kostenlose Repositorys breit verfügbar sind, erzielt GitHub Einnahmen mit Enterprise-Lizenzen, KI, Sicherheit, Automatisierung, Rechenleistung, Speicher und dem Marketplace. Kostenlose Nutzer stellen sowohl potenzielle Konversionen zu zahlenden Kunden als auch Netzwerkwert dar.

Wie sollten Sie ein Open-Source-Projekt bewerten?

Bei der Einführung von Open Source in einem realen Projekt sollten Sie nicht nur auf Star-Zahlen oder GitHub-Rankings achten. Prüfen Sie die folgenden Punkte gemeinsam:

• Die Datei LICENSE und die rechtliche Kompatibilität mit Ihrer beabsichtigten Nutzung
• Die Häufigkeit aktueller Releases und Sicherheitsupdates
• Die Zahl der Kern-Maintainer und die Abhängigkeit von bestimmten Personen
• Die Geschwindigkeit bei der Bearbeitung von Issues und Pull Requests
• Das Vorhandensein von Tests, Automatisierung und Verfahren zur Meldung von Schwachstellen
• Die Vollständigkeit der Dokumentation und der Upgrade-Anleitungen
• Personal und Kosten für Self-Hosting
• Die Abhängigkeit von GitHub oder einem bestimmten Cloud-Dienst
• Verfügbare Alternativen und die Machbarkeit einer Migration, falls das Projekt eingestellt wird

Dieselben Grundsätze gelten bei der Auswahl von GitHub als Arbeitsplattform. Vergleichen Sie nicht nur kostenlose Preise, sondern bewerten Sie erforderliche Berechtigungsverwaltung, Auditing, Sicherheit, Automatisierungsnutzung, KI-Nutzung, Datenstandort, Störungsreaktion und Migrationskosten gemeinsam.

Wie sollte das Verhältnis zwischen Open Source und GitHub verstanden werden?

Open Source ist ein Regelwerk, das Rechte zur gemeinschaftlichen Nutzung und Verbesserung von Software verteilt. Git ist ein Werkzeug, um die Historie dieser Änderungen verteilt zu verwalten, und GitHub ist eine Plattform, die Git-basierte Zusammenarbeit in großem Maßstab vermittelt.

GitHub hat Open Source nicht erfunden. Stattdessen vereinfachte es die Prozesse des Findens, Kopierens, Diskutierens, Prüfens und Zusammenführens, die Open-Source-Communities benötigen, zu einem einheitlichen Web-Workflow. Öffentliche Projekte schufen ein Entwicklernetzwerk, und dieses Netzwerk zog auch private Unternehmensentwicklung auf GitHub.

Statt Eintritt für öffentlichen Code zu verlangen, baute GitHub daher ein Modell auf, das Gebühren für Kontrolle, Sicherheit, Automatisierung, Rechenleistung und KI erhebt, die Unternehmen für Zusammenarbeit im großen Maßstab benötigen. Es begann mit einem frühen Modell, bei dem „öffentlich kostenlos und privat kostenpflichtig“ war, kann heute jedoch als Entwicklungsplattform-Geschäft verstanden werden, in dem „grundlegende Zusammenarbeit kostenlos ist und Funktionen zur Lösung organisatorischer Komplexität kostenpflichtig sind“.