Dat betekent niet dat open software enkel ontstaat bij commerciële bedrijven, maar wel dat het een mythe is dat open source-projecten ontstaan omdat een brede community bij elkaar komt om iets te bouwen. De realiteit is heel anders dan die softwaremythe, maar nog steeds een heel positief alternatief voor commerciële software.

Waarom een paar door fabrikanten betaalde ontwikkelaars het meeste werk doen

Dertien jaar geleden dook ik in academische onderzoeken die lieten zien dat Mozilla's browser Firefox en de Apache HTTP Server beide werden ontwikkeld door een kleine groep kernbijdragers. De community was breder met mensen die onder meer bugs oplosten, maar het centrale ontwikkelen van deze en vrijwel alle andere projecten werd gedaan door een getalenteerde groep commiters.

Een recente analyse van Redmonks Finta Ryan van projecten onder de Cloud Native Computing Foundation (CNCF) laat zien dat dit niet is veranderd. Een van de beroemdste projecten van de stichting is Kubernetes. Google en Red Hat dragen het leeuwendeel van de code bij, maar ook kleinere, minder bekende projecten volgen dat patroon. De echte verrassing is eigenlijk dat dit al zo lang een constant patroon is.

Kijk naar een project van de CNCF, zoals Ryan deed, en je ziet dat bijna alle bijdrages van minder dan tien mensen komen. Sterker nog, als je dieper duikt, zie je dat het meeste werk van een willekeurig project wordt gedaan door slechts twee personen.

Hierna: Een balanspatroon dat je bij alle open source-projecten ziet - en dat is maar goed ook.

De onderzoeker schrijft:

Je kunt eerlijk stellen dat voor de meeste CNCF-projecten specifieke leveranciers verantwoordelijk zijn voor het meeste werk dat wordt gedaan. Dat is geen slechte zaak, maar een weergave van de realiteit: de brede community is groot, maar het aantal kernbijdragers relatief klein en het aandeel onafhankelijke bijdragers nog kleiner. Dit patroon zie je bij veel open source-projecten.

Niet alleen bij 'veel open source-projecten' - alle. Ik kan geen enkel voorbeeld bedenken waar dit niet het geval is. Voor grote, diverse projecten als Linux zie je als je dieper kijkt naar alle onderliggende projecten hetzelfde fenomeen: een handjevol ontwikkelaars, bijna allemaal in dienst bij leveranciers, die een enorm percentage van de kernbijdrages leveren.

Meer ontwikkelaars = inefficiënt

Maar als je een stapje terugneemt, besef je dat het ook niet anders zou kunnen zijn. Immers, hoe meer mensen je tegen een softwareproject aangooit, hoe inefficiënter het wordt, zoals we allemaal weten en is beschreven in het jaren 90-book The Mythical Man Month.

De vraag waarom de meeste developers betaald worden door commerciële softwareleveranciers heeft ook een simpel antwoord: bij ontwikkelaars moet ook brood op de plank komen; ze kunnen alleen groot bijdragen als ze daarvoor worden betaald. Bedrijven waarbij eigen gewin uiteraard voorop staat, nemen developers in dienst voor projecten waar ze zelf baat bij hebben.

Lees verder: Bedrijven kunnen van twee walletjes eten, maar dat pakt voor iedereen gunstig uit.

Slimme bedrijven weten hoe ze hier voordeel mee kunnen behalen. Red Hat bijvoorbeeld haalde in een recente telefoonvergadering naar aanleiding van zijn kwartaalcijfers de bijdrages aan Kubernetes aan (alleen Google is een grotere bijdrager). Volgens CEO Jim Whitehurst heeft Red Hat daarmee invloed op de roadmap van Kubernetes en kunnen klanten beter worden ondersteund. Kortom, met bijdrages hebben ze een competitief voordeel bij het aan de man brengen van Kubernetes.

Dus is community, het mythische idee dat open source wordt voortgedreven door een gemeenschap van gelijkgestemde ontwikkelaars, een illusie? Het simpele antwoord is 'nee'. Maar dat is ook het moeilijke antwoord, want open source heeft altijd al op deze manier gefunctioneerd.

Het interessante is hoe het spel van open source-engagement van ontwikkelaars behouden is gebleven, zelfs nadat open source de standaard werd voor grote delen van softwareontwikkeling, of het nu is gedaan door leveranciers of bedrijven die software voor eigen doeleinden bouwen.

Het lijkt misschien dat een open source-model dat afhankelijk is van slechts een paar hoofdbijdragers die zoveel van de code schrijven onhoudbaar is op langere termijn, maar niets is minder waar. Een leverancier kan bijvoorbeeld specifiek geïnteresseerd zijn in enkele projecten en meeliften op andere die van minder strategisch belang zijn. Zo wordt open source op meerdere niveaus gebruikt, ook al is het niet zo 'open' als sommige voorstanders soms zeggen.

Op de laatste pagina: Ondanks dit, functioneert open source wel fundamenteel anders en democratischer dan gesloten ontwikkeling.

Open source is wel een heel ander beestje dan andere interne ontwikkeling die leidt tot een propriëtair product. Daarbij wordt de hele ontwikkeling voorgeschreven door één leverancier. Maar bij een open source-project, vooral met een brede gebruikslicentie als Apache 2.0, is er altijd de optie dat een andere ontwikkelaar de balans verstoort of de leiding neemt.

Het is een democratischer proces. Kubernetes is een prima voorbeeld: Google begon als de enkele bijdrager en werd snel gevolgd door Red Hat en anderen. Een gemiddelde zakelijke ontwikkelaar die invloed wil hebben zonder code op te offeren is daar niet mee geholpen, maar je ziet dat je een impact kunt hebben op een open source-project die simpelweg niet mogelijk is bij propriëtaire ontwikkeling.

Er is dus weinig te vrezen van deze manier waarop open source werkt. In tegendeel, het is juist het eigenbelang van zakelijke of privéontwikkelaars dat ervoor zorgt dat open source-ontwikkeling met gemak nog vele decennia kan groeien.

FOSS-journalist Bryan Lunduke kijkt naar de invloed van een bekend bedrijf binnen een bekend open source-project, respectievelijk Microsoft en Linux.