Wat is open source, en hoe groeide GitHub en verdiende het geld?

Open source betekent niet simpelweg dat broncode openbaar wordt gemaakt. Het is een manier om anderen via een vastgelegde licentie het recht te geven software te gebruiken, te bestuderen, te wijzigen en opnieuw te verspreiden. GitHub groeide uit tot een commercieel platform door dit type gezamenlijke ontwikkeling in één workflow voor repositories, versiebeheer, codereview en automatisering te verbinden.

Het kernverdienmodel van GitHub is niet om openbare open-sourceprojecten rechtstreeks te verkopen. Het trekt een grote groep gratis gebruikers aan en rekent vervolgens voor de privésamenwerking, toegangscontroles, beveiliging, compliance, automatisering, cloudontwikkelomgevingen en functies voor kunstmatige intelligentie die bedrijven nodig hebben.

Inhoudsopgave

• De precieze betekenis van open source
• De achtergrond van de open-sourcebeweging
• Hoe open-sourceontwikkeling werkt
• De verschillen tussen open source, Git en GitHub
• De oorsprong en groei van GitHub
• Het verdienmodel van GitHub
• Waarom gratis open source economische waarde creëert
• Beperkingen en beoordelingscriteria

Wat is open source precies?

Open-sourcesoftware is software waarvoor de auteursrechthebbende gebruikers via een licentie rechten verleent, waaronder het recht om de software uit te voeren, te bestuderen, te wijzigen en opnieuw te verspreiden. De kernvraag is niet alleen of de code zichtbaar is, maar welke rechten juridisch zijn toegestaan.

Volgens de definitie van het Open Source Initiative (OSI) moet een open-sourcelicentie vrije herdistributie toestaan, broncode beschikbaar stellen en de verspreiding van wijzigingen en afgeleide werken toestaan. De licentie mag geen persoon, groep of toepassingsgebied discrimineren. Als er dus beperkingen gelden zoals „alleen voor niet-commercieel gebruik” of „mag niet worden gebruikt in concurrerende producten”, is de software moeilijk als open source in de gebruikelijke betekenis te erkennen, ook wanneer de broncode openbaar is. OSI의 Open Source Definition↗

Dit onderscheid is vooral belangrijk voor openbare repositories op GitHub. Zelfs als een repository voor iedereen zichtbaar is, geldt het standaardauteursrecht wanneer er geen open-sourcelicentie is opgenomen. Anderen kunnen de repository binnen de GitHub-dienst bekijken of forken, maar verkrijgen niet automatisch het recht om de code vrij te kopiëren, wijzigen en verspreiden. GitHub legt ook uit dat een licentie met gebruikstoestemmingen noodzakelijk is opdat een project werkelijk open source is. GitHub의 저장소 라이선스 안내↗

De volgende drie uitspraken betekenen daarom iets anders:

• „Je kunt de code bekijken” beschrijft of de broncode openbaar is.
• „Je kunt het gratis gebruiken” beschrijft de prijs.
• „Het is open source” beschrijft de rechten die de licentie verleent.

Vrije software is niet noodzakelijk open source, en open-sourcesoftware kan ook worden verkocht.

Welke achtergrond leidde tot de open-sourcebeweging?

De praktijk om softwarecode te delen en gezamenlijk te verbeteren bestond al in vroege onderzoeksgemeenschappen rond computers. Maar toen software zich ontwikkelde tot een zelfstandig commercieel product en auteursrechten en gebruiksbeperkingen strenger werden, groeide ook de bezorgdheid over het vermogen van gebruikers om software te bestuderen en te herstellen.

In de jaren tachtig startte Richard Stallman het GNU-project en de beweging voor vrije software. Bij vrije software verwijst „vrij” niet naar de prijs, maar naar de vrijheid van gebruikers om een programma uit te voeren, te bestuderen, te wijzigen en opnieuw te verspreiden, in oorspronkelijke of aangepaste vorm. GNU의 자유 소프트웨어 정의↗

De naam „open source” ontstond tijdens een strategiebijeenkomst die kort plaatsvond nadat Netscape in 1998 plannen had aangekondigd om de broncode van zijn browser vrij te geven. In datzelfde jaar richtten Eric Raymond, Bruce Perens en anderen de OSI op en formuleerden zij de Open Source Definition op basis van de Debian Free Software Guidelines. Het doel was de praktische voordelen van gezamenlijke ontwikkeling duidelijker uit te leggen aan bedrijven en het publiek. OSI 역사↗

Vrije software en open source overlappen grotendeels in de licenties die zij accepteren, maar verschillen in nadruk.

Dit verschil betekent niet dat één van beide kanten altijd superieur is. Het betekent dat hetzelfde programma vanuit het ene perspectief kan worden uitgelegd met nadruk op de rechten van gebruikers, en vanuit het andere met nadruk op de efficiëntie van transparante ontwikkeling en gedistribueerde samenwerking.

Hoe werkt open-sourceontwikkeling?

Open source betekent niet dat „iedereen de code naar wens mag aanpassen”. Deelname kan open zijn, maar projectonderhouders en vastgelegde procedures bepalen wat in een officiële versie wordt opgenomen.

Een typisch ontwikkelproces verloopt als volgt:

1. Een maintainer publiceert de broncode, licentie, gebruiksinstructies en regels voor bijdragen.
2. Een gebruiker kloont of forkt de repository om een onafhankelijke werkruimte te maken.
3. Bugfixes of functieontwikkeling worden in een afzonderlijke branch uitgevoerd.
4. De bijdrager dient een Pull Request in met de wijzigingen en de onderbouwing ervan.
5. Maintainers beoordelen de code, testresultaten, ontwerprichting en gevolgen voor de beveiliging.
6. Alleen wijzigingen die aan de criteria voldoen, worden samengevoegd met de officiële repository.
7. Er wordt een nieuwe versie uitgebracht en problemen die daarna worden ontdekt, worden opnieuw bijgehouden.

In dit proces bestaan verschillende rollen. Gebruikers gebruiken de software en rapporteren problemen. Bijdragers dienen code of documentatie in. Maintainers voeren reviews en releases uit. Een projectstuurgroep of stichting kan ook handelsmerken, budgetten en regels voor besluitvorming beheren.

Met andere woorden: de „openheid” van open source betekent niet dat er geen beslissingsbevoegdheid bestaat. De mogelijkheden om deel te nemen en de rechten om de code te gebruiken zijn open, terwijl officiële projecten besturingsstructuren hebben om de kwaliteit te behouden.

Hoe verschillen open-sourcelicenties?

Open-sourcelicenties kunnen grofweg worden ingedeeld in permissieve licenties en copyleftlicenties.

Permissieve licenties

MIT, BSD en Apache License 2.0 zijn bekende voorbeelden. Zolang wordt voldaan aan voorwaarden zoals het behouden van auteursrechtvermeldingen en de licentietekst, staan deze licenties in het algemeen toe dat aangepaste code in propriëtaire software wordt opgenomen.

Daardoor zijn ze gemakkelijk voor bedrijven te integreren in commerciële producten, maar er is geen garantie dat verbeterde code terugvloeit naar de oorspronkelijke gemeenschap. Apache License 2.0 bevat ook expliciete bepalingen over patenten, waardoor de juridische voorwaarden niet identiek zijn aan die van de MIT License.

Copyleftlicenties

De GNU General Public License (GPL) is een representatief voorbeeld. Wanneer aangepaste code wordt verspreid, of wanneer een afgeleid werk gecombineerd met die code wordt verspreid, kan de licentie vereisen dat de broncode onder dezelfde licentie beschikbaar wordt gesteld.

Copyleft verbiedt commercieel gebruik niet. Software mag commercieel worden verkocht, maar de verplichtingen tot openbaarmaking van broncode binnen de door de licentie bepaalde reikwijdte moeten worden nageleefd. Varianten zoals de LGPL en AGPL zijn ontworpen met verschillende voorwaarden voor het koppelen van bibliotheken en netwerkdiensten.

Kies een licentie niet enkel omdat een bekend project die gebruikt. Onderzoek de openbaarmakingsreikwijdte voor afgeleide werken, patentbepalingen, levering via netwerkdiensten en compatibiliteit met andere licenties.

Wat is het verschil tussen open source, Git en GitHub?

Deze drie begrippen verschijnen vaak samen, maar werken op verschillende lagen.

• Open source is een concept dat softwaregebruiksrechten en een methode voor gezamenlijke ontwikkeling beschrijft.
• Git is een open-sourceprogramma voor versiebeheer dat de geschiedenis van bestandswijzigingen gedistribueerd beheert.
• GitHub is een commerciële dienst die Git-repositories online host en functies biedt voor codereview, issuebeheer, automatisering, beveiliging en samenwerking.

Git werd in 2005 gemaakt nadat de relatie tussen de ontwikkelgemeenschap van de Linux-kernel en de propriëtaire gedistribueerde versiebeheertool BitKeeper was geëindigd. Er was een tool nodig die de snelheid, het gedistribueerde werk en het grote aantal parallelle branches aankon die een project zo groot als Linux vereist. Git 공식 역사↗

Met Git kan iedere ontwikkelaar een repository met de volledige wijzigingsgeschiedenis onderhouden zonder altijd met een centrale server verbonden te zijn. Maar Git vanaf de commandoregel alleen maakte het onhandig om te beheren wie een wijziging voorstelde, waarom deze nodig was, wie deze zou beoordelen en wanneer deze zou worden samengevoegd. GitHub ordende juist dit samenwerkingsproces via een webinterface.

Git kan zonder GitHub worden gebruikt, en repositories kunnen op GitLab, Bitbucket of zelfgehoste servers draaien. Omgekeerd bevat GitHub niet alleen open source, maar ook private bedrijfscode en openbare code zonder licentie. GitHub en open source zijn geen synoniemen.

Hoe is GitHub begonnen?

GitHub werd ontwikkeld rond Tom Preston-Werner, Chris Wanstrath en PJ Hyett, en ging in 2008 als openbare dienst van start. Scott Chacon, een Git-expert die later bekend werd als auteur van Pro Git, maakte ook deel uit van het vroege team.

De eerste commit in de interne repository van GitHub vond plaats in oktober 2007 en de dienst werd in april 2008 gelanceerd. Rond de eerste verjaardag had GitHub meer dan 20.000 openbare repositories en vier fulltimewerknemers, zonder externe investeringen te hebben ontvangen. GitHub의 첫해 기록↗

Het probleem dat GitHub wilde oplossen was niet slechts bestandsopslag. Het wilde een samenwerkingsomgeving creëren die wijzigingen in gedistribueerde Git-repositories visualiseerde, ontwikkelaars hielp elkaars werk te ontdekken en wijzigingsvoorstellen eenvoudig te beoordelen maakte. De network graph die GitHub in 2008 uitbracht was eveneens een poging om de relaties tussen branches en commits van meerdere gebruikers op één scherm te tonen. 초기 Network Graph 소개↗

Deze aanpak werd later „social coding” genoemd. Profielen, activiteitsgeschiedenissen, follows, forks, stars, issues en pull requests van ontwikkelaars raakten verbonden met coderepositories, waardoor het ontwikkelproces zelf veranderde in een netwerk dat doorzoekbaar en observeerbaar was.

Waarom groeide GitHub zo snel?

De groei van GitHub kan niet alleen worden verklaard door gratis Git-opslag aan te bieden. Technische timing, gebruikerservaring, netwerkeffecten en een bedrijfsmodel voor ondernemingen werkten samen.

Het maakte het complexe samenwerkingsproces van Git begrijpelijk op het web

Branches, commits en merges zijn krachtige Git-functies, maar voor beginners niet eenvoudig te begrijpen met alleen commando's. GitHub bracht codeverschillen, discussies, reviewresultaten en teststatus samen in de pull-requestinterface.

In plaats van patchbestanden per e-mail rond te sturen, konden ontwikkelaars wijzigingen via één link delen. Projectmaintainers konden reviewkosten beperken doordat de code en het discussieproces samen werden vastgelegd.

Openbare repositories creëerden een ontwikkelaarsnetwerk

Wanneer een project zich bij GitHub aansluit, maken gebruikers en bijdragers van dat project ook vaker accounts aan. Die gebruikers creëren vervolgens andere projecten of nemen deel aan bestaande projecten.

Naarmate het aantal repositories stijgt, bezoeken ontwikkelaars GitHub om code te vinden. Naarmate het aantal ontwikkelaars groeit, kiezen projectmaintainers GitHub om bijdragers aan te trekken. Dit is een tweezijdig netwerkeffect.

Openbare activiteitsgeschiedenissen fungeerden ook als portfolio's voor ontwikkelaars. Bedrijven konden de feitelijke code en samenwerkingservaring van sollicitanten beoordelen, terwijl ontwikkelaars een prikkel hadden om een activiteitshistorie op te bouwen voor carrièremogelijkheden en reputatie.

Het liet open source en bedrijfsproducten tegelijk groeien

GitHub verlaagde de toetredingsdrempel voor openbare open-sourcerepositories en rekende vanaf het begin voor private repositories. In 2011 lanceerde het GitHub Enterprise, dat op interne bedrijfsservers kon draaien en tegemoetkwam aan bedrijfsbehoeften zoals authenticatie, back-ups en teambeheer. GitHub Enterprise 출시 기록↗

Door deze structuur konden individuele ontwikkelaars via open-sourceprojecten leren GitHub te gebruiken en vervolgens na indiensttreding bij een bedrijf een enterpriseversie van dezelfde workflow gebruiken. Dit maakte bottom-upadoptie mogelijk: ontwikkelaars brachten het product hun organisaties binnen zonder afzonderlijke verkoopinspanningen die op individuen waren gericht.

GitHub verklaarde dat het via betaalde diensten winstgevendheid en groei had bereikt zonder externe investeringen, en haalde in 2012 zijn eerste externe investering op. GitHub의 2012년 투자 발표↗

Het breidde de gratis laag uit en verminderde redenen om naar concurrerende diensten over te stappen

In 2019 begon GitHub private repositories aan gratis persoonlijke accounts aan te bieden. In 2020 schafte het ook de limieten voor bijdragers aan gratis private repositories af en maakte het kernfuncties voor teams gratis. Geavanceerd rechtenbeheer, beveiliging en supportfuncties die bedrijven nodig hebben, bleven betaalde aanbiedingen. GitHub Free 확대 발표↗

De gratis laag uitbreiden betekent op korte termijn afstand doen van bepaalde abonnementsinkomsten. Het houdt echter meer individuen en kleine teams op het platform en creëert mogelijkheden om hen te converteren naar Team-, Enterprise-, beveiligings- en AI-producten naarmate hun organisaties groeien.

Hoe beïnvloedde de overname door Microsoft de groei van GitHub?

Microsoft stemde in 2018 in met de overname van GitHub voor 7,5 miljard dollar in Microsoft-aandelen. GitHub meldde toen meer dan 28 miljoen gebruikers. Microsoft verklaarde dat GitHub zijn onafhankelijke bedrijfsvoering en ontwikkelaarsgerichte karakter zou behouden. Microsoft의 GitHub 인수 발표↗

De overname sloot aan op strategische behoeften van beide kanten. GitHub kon gebruikmaken van wereldwijde cloudinfrastructuur, een verkoopnetwerk voor ondernemingen en mogelijkheden voor beveiliging en compliance. Microsoft kon zich losmaken van zijn eerdere imago als bedrijf dat draaide om Windows en propriëtaire software en contactpunten met ontwikkelaars opbouwen ongeacht besturingssysteem of programmeertaal. Het kreeg ook mogelijkheden om Azure, Visual Studio, VS Code en GitHub te verbinden.

Na de overname breidde GitHub zich uit van repositoryhosting naar een platform voor de volledige ontwikkelcyclus. GitHub Actions automatiseert builds, tests en deployments; Codespaces biedt cloudontwikkelomgevingen; Advanced Security-producten scannen code, afhankelijkheden en secrets; en Copilot biedt AI-gestuurde functies voor het schrijven en reviewen van code.

In oktober 2022 maakte Microsoft bekend dat GitHub 1 miljard dollar aan jaarlijks terugkerende omzet (ARR) had bereikt en was gegroeid tot meer dan 90 miljoen gebruikers, driemaal het aantal bij de overname. Microsoft FY2023 1분기 실적 발표↗

GitHub maakte bekend dat meer dan 100 miljoen ontwikkelaars het platform in 2023 gebruikten en dat meer dan 180 miljoen dat in 2025 deden. In 2025 bereikte het totale aantal projecten 630 miljoen, en GitHub telde ongeveer 81,5% van alle bijdragen als verricht in private repositories. Dit toont dat GitHub zowel een open-sourceomgeving als grootschalige infrastructuur voor bedrijfsontwikkeling is geworden. GitHub Octoverse 2025↗

Deze cijfers zijn echter platformstatistieken die volgens GitHubs eigen criteria worden geteld. Het aantal geregistreerde ontwikkelaars mag niet worden geïnterpreteerd als gelijk aan het aantal maandelijks actieve gebruikers of betalende klanten. Microsoft maakt de actuele omzet en operationele winst van GitHub bovendien niet ieder jaar gedetailleerd bekend als zelfstandige bedrijfseenheid. Daarom moet de in 2022 gemelde ARR van 1 miljard dollar worden gezien als een representatieve schaalindicator die op dat moment werd gepubliceerd, en niet als de actuele omzet.

Waar verdient GitHub concreet geld mee?

Het verdienmodel van GitHub kan worden samengevat als een freemiummodel: het verwerft gebruikers via een gratis openbaar platform en rekent voor de controle en productiviteit die organisaties nodig hebben om te opereren.

Abonnementen per gebruikersseat

Met het gratis abonnement kunnen individuen en kleine teams kernfuncties voor repositories gebruiken. Het Team-abonnement biedt geavanceerde samenwerkingsfuncties, terwijl het Enterprise-abonnement beveiliging, compliance, centraal beheer en implementatieopties biedt.

Volgens de officiële prijspagina die in september 2026 werd gecontroleerd, begint Team bij 4 dollar per gebruiker per maand en Enterprise bij 21 dollar per gebruiker per maand. Werkelijke bedragen kunnen verschillen op basis van contractduur, regio, belastingen en voorwaarden voor grote contracten. GitHub 공식 가격표↗

Facturering op basis van seats heeft als voordeel dat terugkerende inkomsten kunnen toenemen wanneer het personeelsbestand van een bedrijf groeit. Zodra code en werkprocessen op het platform zijn gevestigd, nemen ook de overstapkosten toe, waardoor contracten waarschijnlijker worden behouden.

Abonnementen voor AI-producten en facturering op basis van gebruik

GitHub Copilot heeft betaalde abonnementen voor individuen en organisaties. Bedrijven kopen seats voor elke gebruiker, en er kunnen extra gebruikskosten gelden wanneer het in een abonnement opgenomen AI-gebruik wordt overschreden. Copilot ontwikkelt zich daarom tot een model dat traditionele softwareabonnementen combineert met facturering voor AI-rekengebruik. GitHub Copilot 조직 청구 안내↗

Copilot voegt niet alleen een nieuwe inkomstenbron toe voor GitHub, maar zorgt er ook voor dat AI wordt gebruikt binnen bestaande workflows rond repositories, issues, pull requests en codereview. Daardoor is het eenvoudiger extra producten aan bestaande platformklanten te verkopen dan wanneer een afzonderlijke AI-tool zou worden verkocht.

Producten voor beveiliging en compliance

Grote ondernemingen betalen niet alleen voor een plek om code op te slaan. Zij hebben accountcontroles, auditlogs, single sign-on, detectie van secrets, analyse van kwetsbaarheden in code, beheer van de supply chain en naleving van regelgeving nodig.

Naarmate de afhankelijkheid van open-sourceafhankelijkheden groeit, moeten organisaties voortdurend scannen op kwetsbare packages en gelekte inloggegevens. De uitbreiding van het gratis ecosysteem vergroot paradoxaal genoeg ook de behoefte aan beveiligingsproducten voor ondernemingen.

Gebruik van computing, opslag en automatisering

Diensten zoals GitHub Actions, Codespaces en Packages bevatten een bepaalde hoeveelheid gebruik in een abonnement en rekenen voor overschrijdingen. Een bedrijfsfactuur kan niet alleen Enterprise-licenties bevatten, maar ook overmatig gebruik van Actions of Codespaces en aanvullende licenties voor producten als Copilot en beveiligingstools. GitHub Enterprise 청구 구조↗

Met dit model kunnen de inkomsten van GitHub toenemen naarmate de ontwikkelactiviteit stijgt. GitHub draagt echter ook kosten voor uitvoeringsservers, opslagapparatuur, netwerken en AI-modellen, dus niet alle gebruiksinkomsten zijn winst.

Transactiekosten van Marketplace

Externe ontwikkelaars kunnen betaalde apps verkopen via GitHub Marketplace. GitHub biedt beheer van betalingen en abonnementen en houdt een deel van de transactiewaarde in als exploitatievergoeding. Volgens de officiële documentatie bedraagt het ingehouden aandeel dat sinds 2021 op apptransacties wordt toegepast 5%. GitHub Marketplace 판매 대금 안내↗

Naast directe Marketplace-kosten is ook belangrijk dat externe tools rond GitHub worden gecentreerd. Naarmate meer apps worden gebruikt, moeten meer ontwikkeltools worden vervangen bij het verlaten van GitHub, wat de bestendigheid van het platform versterkt.

Waarom heeft gratis open source economische waarde voor GitHub?

Voor GitHub zijn gratis openbare repositories niet simpelweg een kostenpost. Zij vormen een kernactivum voor gebruikersverwerving en de vorming van het ecosysteem.

Ten eerste brengen open-sourceprojecten nieuwe gebruikers binnen. Ontwikkelaars die een specifieke bibliotheek willen gebruiken, een probleem willen melden of een patch willen indienen, maken GitHub-accounts aan. GitHub kan deze gebruikers verwerven zonder geld aan reclame uit te geven.

Ten tweede maakt open-sourceactiviteit GitHubs werkwijze tot een de-factostandaard in de sector. Ontwikkelaars leren forks, issues en pull requests op school of via persoonlijke projecten kennen en geven vervolgens op het werk de voorkeur aan dezelfde aanpak.

Ten derde zijn het openbare ecosysteem en private bedrijfsontwikkeling van elkaar afhankelijk. Ook private producten van bedrijven gebruiken talloze openbare bibliotheken en tools. In de gegevens van GitHub uit 2025 vond de meeste bijdrageactiviteit plaats in private repositories, terwijl openbare projecten in de meerderheid waren naar aantal repositories. Het gratis openbare ecosysteem vormt de basis voor betaald bedrijfswerk.

Ten vierde vergroten actievere openbare projecten de vraag naar beveiliging en automatisering. Updates van afhankelijkheden, detectie van kwaadwillende packages, licentiebeheer en grootschalig testen en implementeren worden allemaal noodzakelijk.

De ondersteuning van gratis open source door GitHub is daarom moeilijk uitsluitend als filantropie of uitsluitend als commerciële activiteit te verklaren. Zij levert echte waarde voor de ontwikkelaarsgemeenschap en dient tegelijk als langetermijnstrategie voor distributie naar de betaalde zakelijke markt.

Hoe verdienen open-sourcebedrijven doorgaans geld?

Het bedrijfsmodel van GitHub is een van meerdere verdienmodellen die open source gebruiken. Open-sourcebedrijven rekenen vaak niet voor de reproduceerbare code zelf, maar voor operationeel gemak, verantwoordelijkheid, beveiliging en expertise.

• Support en consultancy: Zij bieden software gratis aan en rekenen voor installatie, incidentrespons, training en langetermijnsupport.
• Beheerde cloud: Naast open source die klanten zelf kunnen installeren, verkopen zij SaaS die deze namens de klant beheert.
• Open core: Zij maken kernfuncties openbaar, terwijl zij functies voor bedrijfsbeheer, beveiliging en analytics aanbieden onder propriëtaire licenties.
• Dubbele licentiëring: Zij bieden dezelfde code aan onder zowel een open-sourcelicentie als een commerciële licentie, zodat gebruikers op basis van hun situatie kunnen kiezen.
• Hosting en gebruik: Zij rekenen op basis van gebruik van opslag, netwerk, computing en automatiseringsuitvoering.
• Sponsoring en donaties: Individuen, bedrijven en stichtingen ondersteunen maintainers of de werking van projecten.
• Certificering en training: Zij behalen inkomsten uit officiële opleidingen, examens, technische certificeringen of partnerprogramma's.

Deze modellen werken omdat softwarekosten niet beperkt zijn tot de licentieprijs. Bedrijven kijken naar de totale eigendomskosten, waaronder installatietijd, risico op uitval, beveiligingsincidenten, updates, naleving van regelgeving en tekorten aan gespecialiseerd personeel. Ook als zij de code gratis kunnen verkrijgen, kunnen zij bereid zijn te betalen voor betrouwbare operationele verantwoordelijkheid.

Wat zijn de beperkingen van open source en GitHub?

Open source wordt niet automatisch veilige en duurzame software alleen omdat veel mensen deelnemen.

Onderhoudslasten kunnen op enkele personen terechtkomen

Zelfs een veelgebruikte bibliotheek kan voor feitelijke reviews en releases van slechts enkele maintainers afhankelijk zijn. Naarmate het gebruik toeneemt, nemen de lasten voor issuemeldingen en beveiligingsrespons toe, terwijl de vergoeding van maintainers mogelijk niet evenredig stijgt.

Openbare review garandeert geen kwaliteit

Dat broncode openbaar is, verschilt van het feit dat iemand die voldoende heeft beoordeeld. Risico's in de supply chain omvatten kwetsbaarheden, kwaadwillende bijdragen, gecompromitteerde maintaineraccounts en besmette afhankelijkheden.

Licentieverplichtingen kunnen over het hoofd worden gezien

Open source is geen publiek goed zonder auteursrecht. De voorwaarden van iedere licentie moeten worden nageleefd, waaronder het behouden van auteursrechtvermeldingen, het beschikbaar stellen van broncode, het markeren van wijzigingen en het toepassen van dezelfde licentie. Vooral in commerciële producten die veel afhankelijkheden combineren, moet licentiecompatibiliteit worden beoordeeld.

Platformconcentratie creëert nieuwe afhankelijkheden

Omdat Git gedistribueerd is, kunnen repositories naar andere servers worden verplaatst. Maar issues, discussies bij pull requests, Actions-workflows, toegangsbeleid, Marketplace-apps en beveiligingsrecords volledig migreren is veel moeilijker.

Hoe handiger GitHub wordt, hoe meer ontwikkelgemeenschappen afhankelijk kunnen raken van de prijzen, het beleid, de incidentrespons en functiewijzigingen van één bedrijf. Het is noodzakelijk om code lokaal te klonen, releases en documentatie te back-uppen en afhankelijkheden van specifieke platformfuncties te begrijpen.

Wat zijn veelvoorkomende misvattingen?

„Het is openbaar op GitHub, dus het is open source”

Zonder licentie ontstaan de gebruikelijke gebruiksrechten voor open source niet. Zichtbaarheid en licentiëring zijn afzonderlijke instellingen.

„Alle open source is gratis”

Er kunnen geen kopieerkosten zijn, maar bedrijfsvoering, support, clouddiensten, training en beveiligingsfuncties kunnen kosten met zich meebrengen. Open-sourcelicenties verbieden betaalde verkoop niet.

„Iedereen kan de officiële code aanpassen zoals hij wil”

Het recht van iedereen om zijn eigen kopie aan te passen, verschilt van de bevoegdheid om wijzigingen in het officiële project op te nemen. Maintainers en governanceregels bepalen of wijzigingen officieel worden toegevoegd.

„GitHub zelf is open source”

GitHub host op grote schaal open-sourceprojecten en brengt verschillende open-sourcetools uit, maar de volledige GitHub-dienst is niet één open-sourceproduct. GitHub is een commercieel platform dat eigendom is van Microsoft.

„Omdat GitHub veel gebruikers heeft, zijn de meesten betalende gebruikers”

De door GitHub gerapporteerde aantallen ontwikkelaars omvatten gratis accounts. Het totale aantal geregistreerde ontwikkelaars, actieve ontwikkelaars, zakelijke klanten en betaalde seats zijn verschillende statistieken.

„Microsoft exploiteert GitHub gratis”

Hoewel gratis repositories ruim beschikbaar zijn, genereert GitHub inkomsten uit enterprise-seats, AI, beveiliging, automatisering, computing, opslag en de Marketplace. Gratis gebruikers bieden zowel mogelijke conversie naar betalende klanten als netwerkwaarde.

Hoe moet u een open-sourceproject beoordelen?

Kijk bij het invoeren van open source in een echt project niet alleen naar aantallen stars of GitHub-ranglijsten. Beoordeel de volgende punten samen:

• Het bestand LICENSE en de juridische compatibiliteit met het beoogde gebruik
• De frequentie van recente releases en beveiligingsupdates
• Het aantal kernmaintainers en de afhankelijkheid van specifieke personen
• De reviewsnelheid voor issues en pull requests
• De aanwezigheid van procedures voor testen, automatisering en kwetsbaarheidsmeldingen
• De volledigheid van documentatie en aanwijzingen voor upgrades
• Het personeel en de kosten die nodig zijn voor self-hosting
• De afhankelijkheid van GitHub of een specifieke clouddienst
• Beschikbare alternatieven en de haalbaarheid van migratie als het project wordt stopgezet

Dezelfde beginselen gelden bij het kiezen van GitHub als werkplatform. Beoordeel niet alleen gratis prijzen, maar ook vereist rechtenbeheer, auditing, beveiliging, automatiseringsgebruik, AI-gebruik, datalocatie, incidentrespons en migratiekosten als geheel.

Hoe moet de relatie tussen open source en GitHub worden begrepen?

Open source is een verzameling regels die rechten verdeelt om software gezamenlijk te gebruiken en te verbeteren. Git is een tool om de geschiedenis van die wijzigingen gedistribueerd te beheren, en GitHub is een platform dat samenwerking op basis van Git op grote schaal faciliteert.

GitHub heeft open source niet uitgevonden. In plaats daarvan vereenvoudigde het de processen voor ontdekken, kopiëren, bespreken, reviewen en samenvoegen die open-sourcegemeenschappen nodig hebben tot één uniforme workflow op het web. Openbare projecten creëerden een ontwikkelaarsnetwerk, en dat netwerk trok ook private bedrijfsontwikkeling naar GitHub.

GitHub bouwde daardoor niet een model dat toegang tot openbare code in rekening brengt, maar een model dat rekent voor de controle, beveiliging, automatisering, computing en AI die bedrijven nodig hebben om op grote schaal samen te werken. Het begon met een vroeg model van „openbaar is gratis en privé is betaald”, maar kan nu worden begrepen als een ontwikkelplatformbedrijf waarin „basissamenwerking gratis is en functies die organisatorische complexiteit oplossen betaald zijn”.