Deel 3 van 8. Deel 2 zette uiteen wat afhankelijkheid je kost.
Wat deze post behandelt
- De jaren waarin open source bevochten werd.
- Waarom de strijd stopte.
- Wie de software vandaag draaiende houdt.
- Wat er gebeurde toen de makers probeerden te rekenen.
- Wat er met bedrijven gebeurt nadat ze gekocht zijn.
- Wat het voor jou betekent.
De jaren waarin open source bevochten werd
Open source is software waarvan iedereen de code kan lezen, gebruiken en veranderen.
Het is nu gewoon. Ongeveer 15 jaar lang werd het als een bedreiging behandeld.
In oktober 1998 lekte een intern Microsoft-memo. Eric Raymond publiceerde het met aantekeningen, en het werd bekend als de Halloween-documenten.
Het memo was eerlijk over de kwaliteit van open source. Het noemde de manier waarop duizenden mensen er samen aan werken opmerkelijk.
Toen zette het uiteen wat eraan te doen. Eén regel verklaart een heleboel:
By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.
Een protocol is een afgesproken manier voor 2 systemen om met elkaar te praten.
Dus het plan was niet om een beter product te bouwen. Het plan was om de verbindingen tussen producten te veranderen, zodat een concurrent er niet in gedropt kon worden.
Verscheidene andere stappen volgden over de volgende 10 jaar.
In 2003 beweerde een bedrijf genaamd SCO dat Linux code bevatte die het bezat. De zaak sleepte jaren aan en SCO won niet. Terwijl het liep, waren heel wat organisaties onzeker of het veilig was om Linux over te nemen.
Microsoft tekende ook octrooiovereenkomsten met mobiele-telefoonmakers. Verscheidene jaren nam het een betaling op elke verkochte telefoon die Android draaide, een besturingssysteem dat het niet had geschreven.
In 2008 werden Microsofts documentformaten goedgekeurd als een internationale standaard. Verscheidene nationale standaardeninstanties maakten bezwaar tegen hoe dat werd afgehandeld.
Europa duwde tegen een deel ervan terug. De Europese Commissie beboette Microsoft met €497 miljoen in 2004 over informatie die concurrenten nodig hadden om met zijn producten te werken.
Het beboette het bedrijf in 2013 opnieuw met €561 miljoen, omdat een afgesproken oplossing niet was ingevoerd.
Die tweede boete is een moment waard. Het probleem was geen nieuw probleem. De afgesproken oplossing was simpelweg niet gedaan.
Waarom de strijd stopte
Het stopte rond 2014, omdat het niet had gewerkt.
Linux was de software geworden waar de meeste servers op draaien. Het draait ook de meeste clouddiensten en de meeste mobiele telefoons.
Je kunt iets niet via de rechtbank eruit halen zodra alles erbovenop gebouwd is.
Dus de aanpak draaide helemaal om.
Microsoft trad toe tot de Linux Foundation. Het bracht een deel van zijn eigen gereedschap als open source uit. In 2018 kocht het GitHub, de site waar veel van ’s werelds open source geschreven wordt.
Amazon en Google bouwden heel grote bedrijven op open source, en alle 3 de bedrijven steken er nu veel werk in terug.
Dat werk is echt, en de software is er beter door. Het zou dwaas zijn te doen alsof het anders is.
Maar 1 ding veranderde niet.
De bedrijven die ooit probeerden open source te vertragen behoren nu tot zijn grootste financiers. Ze zijn ook nog steeds de grootste bedrijven in de markt.
Open source won het technische argument. Het veranderde niet wie de sterkste hand houdt.
Wie de software vandaag draaiende houdt
Hier is het stukje dat mensen buiten software verrast.
Heel veel veelgebruikte open source wordt draaiende gehouden door heel kleine teams. Een deel ervan door 1 persoon, in eigen tijd, voor niks.
Diezelfde stukken zitten dan binnen producten die door heel grote bedrijven verkocht worden.
In december 2021 dook een fout op in Log4j, een klein gereedschap dat Java-programma’s gebruiken om vast te leggen wat ze aan het doen zijn.
De fout liet aanvallers hun eigen code op getroffen systemen draaien. Het trof een enorm aantal organisaties tegelijk. Het Britse National Cyber Security Centre bracht er richtlijnen over uit.
Het gereedschap werd onderhouden door een kleine groep vrijwilligers.
De les is niet dat open source riskant is. Het meeste ervan is heel goed, en open voor inspectie op een manier die gesloten software nooit is.
De les gaat over voor dingen betalen. Gedeeld werk waar veel bedrijven op leunen heeft financiering nodig, en krijgt dat vaak niet.
Deze is te repareren, en sommige organisaties repareren het wel. Een onderhouder betalen, of een stichting financieren, is meestal een heel kleine kost naast wat de software je bespaart.
Wat er gebeurde toen de makers probeerden te rekenen
Sommige bedrijven bouwen open source en verkopen er een betaalde dienst omheen. Dat werkte een hele tijd goed genoeg.
Het werd moeilijker toen cloudproviders dezelfde software als een eigen dienst begonnen aan te bieden.
De provider nam de inkomsten. Het bedrijf dat de software schreef niet.
Verscheidene ervan reageerden door hun licentie te veranderen, zodat anderen hun software niet als concurrerende dienst konden aanbieden.
- MongoDB veranderde zijn licentie in 2018.
- Elastic volgde in 2021.
- HashiCorp veranderde in 2023.
- Redis veranderde in 2024.
Het Open Source Initiative stelt de geaccepteerde definitie van open source. Het oordeelde dat 1 van deze nieuwe licenties er niet aan voldeed.
Heel wat Linux-distributies lieten toen de getroffen software vallen.
De bredere gemeenschap nam kopieën van de laatste open versies en zette die apart voort. Zo’n kopie heet een fork.
- OpenSearch zet de eerdere Elasticsearch-code voort.
- OpenTofu zet de eerdere Terraform-code voort.
- Valkey zet de eerdere Redis-code voort.
Elastic en Redis zijn beide sindsdien teruggegaan naar open licenties.
Het is de moeite waard te kijken hoe dat eindigde, want niemand die erbij betrokken was kreeg waar hij op uit was.
Een bedrijf bouwde nuttige software. Een groter bedrijf verdiende er meer aan dan de maker. De maker beperkte de licentie om te overleven. De gemeenschap maakte bezwaar, terecht, dat dit geen open source meer was. Een fork verscheen, vaak gesteund door de grotere bedrijven.
Aan het eind ervan is de software nog steeds gratis te gebruiken. De forks worden meestal gestuurd door de grootste spelers. Het bedrijf dat voor het oorspronkelijke werk betaalde is zwakker dan toen het begon.
Wat er met bedrijven gebeurt nadat ze gekocht zijn
De tweede manier waarop waarde een bedrijf verlaat heeft niks met softwarelicenties te maken.
Het gaat over hoe een bedrijf gekocht wordt.
Hier is het patroon, ronduit.
Een koper leent het grootste deel van de koopprijs. De lening wordt dan gedekt tegen het bedrijf dat gekocht wordt. Dus het bedrijf eindigt met de schuld die gebruikt werd om het te kopen.
De koper kan dan de gebouwen van het bedrijf verkopen en ze terughuren. Het opgehaalde geld kan aan de nieuwe eigenaren worden uitgekeerd. Het bedrijf betaalt nu huur op panden die het vroeger bezat.
Kosten die dit jaar niet opduiken worden gesneden. Dat betekent meestal onderhoud, personeelsaantallen, onderzoek en productontwikkeling.
Dan wordt het bedrijf doorverkocht.
De Bank of England heeft de financiële-stabiliteitskant hiervan bekeken. Zijn review van private equity merkt op dat zware leningen bij buyouts die bedrijven waarschijnlijker in gebreke doen blijven, en hun kredietverstrekkers blootstelt aan verliezen. Het is de sector blijven volgen sindsdien.
Niet elke buyout werkt zo, en heel wat eigenaren investeren in plaats van te strippen. Dit is een patroon om te herkennen, geen beschrijving van alle kopers.
Maar waar het wel gebeurt, is de uitkomst elke keer hetzelfde.
Het bedrijf werkte meestal prima. Wat niet werkte was het bedrijf plus de schuld die aangegaan werd om het te kopen.
Hetzelfde patroon in software
Dit bereikte software enkele jaren terug.
Het bezit dat bewerkt wordt is geen gebouw. Het zijn de klanten die niet makkelijk weg kunnen.
Een volwassen product met langdurige klanten kan opnieuw geprijsd worden. Die klanten kunnen niet snel verhuizen, en als zodanig betaalt het merendeel van hen.
Tegelijkertijd kan de uitgave aan engineering gesneden worden. Dat kost jaren om te tonen, en tegen dan is de verkoop doorgegaan.
Deel 2 behandelde hoe dit eruitzag voor VMware-klanten.
Er is ook een versie gefinancierd door investeerders in plaats van schuld. Het is vaak genoeg beschreven om een naam te verdienen: enshittification, een woord gebruikt door de Canadese schrijver Cory Doctorow vanaf 2022.
Het loopt in 3 fases.
- De dienst wordt verkocht onder wat het kost om te draaien, betaald door investeerders. Het is goedkoop en goed, dus mensen stappen erop over.
- Zodra mensen niet makkelijk weg kunnen, wordt het aangepast om in plaats daarvan de betalende zakelijke klanten te passen.
- Zodra beide kanten vastzitten, veranderen de voorwaarden weer om winst te verhogen.
Fase 1 is degene die telt voor deze serie.
Een bedrijf dat jarenlang onder de kostprijs verkoopt wint niet omdat het beter is. Het wordt gefinancierd om de markt te nemen.
Kleinere bedrijven die hun eigen kosten moeten dekken kunnen die prijs niet evenaren. Heel wat gaan dicht.
Wanneer prijzen later klimmen naar iets houdbaars, is de keuze die vroeger bestond vaak weg.
Wat het voor jou betekent
Twee praktische dingen komen hieruit, en beide zijn makkelijk genoeg te doen.
Controleer hoeveel mensen je afhankelijkheden draaiende houden.
Kijk naar het gereedschap waar je systemen niet zonder zouden kunnen draaien. Zoek uit hoeveel mensen elk ervan actief onderhouden.
Als het antwoord 1 of 2 is, is dat de moeite waard te weten. Je wilt misschien dat werk financieren, je eigen kopie van de broncode houden, of plannen wat je zou doen als het stopte.
Let op wie je leveranciers bezit.
Je voorwaarden volgen de eigenaar, niet het product. Een eigendomswisseling kan je verlenging meer verschuiven dan welke verandering in de software ook.
Wanneer je tekent, controleer wat je houdt als je stopt met betalen. Controleer of je nog steeds kunt draaien wat je al geïnstalleerd hebt, en of je nog steeds beveiligingsupdates krijgt.
Geen van beide kost lang. Beide zijn veel makkelijker vóór een verlenging dan tijdens een.
Deel 4 kijkt naar wat rechtbanken en toezichthouders al beslist hebben.
Eerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.