In 1991 kondigde de Finse student Linus Torvalds aan dat hij was begonnen met de ontwikkeling van de Linux-kernel, en de rest is geschiedenis. Het was geen 'overnight succes', maar de Linux-kernel is nu precies dertig jaar later wel onderdeel van de meest gebruikte besturingssystemen ter wereld. Een terugblik.
Mijn eerste kennismaking met Linux was toen ik tijdens mijn afstuderen als bijbaan bij de computerwinkelketen Dynabyte werkte. Daar lagen dozen met Red Hat Linux in het schap, die ik na enige tijd toch eens mee naar huis heb genomen. Ik vond dat toen nog best ingewikkeld, maar bleef er mee experimenteren.
Later, toen ik bij de Universiteit van Leiden ging werken als Student Assistent voor professor Schmidt op de faculteit Recht en Informatica, leerde ik een andere kant van opensource kennen. Schmidt was een opensource-voorvechter en we spraken over de voor- en nadelen van Berkeley Software Distribution- (softwarelicenties voor opensourcesoftware) en GNU General Public License (GPL)-licenties. Ik vond toen al dat de GPL veel meer de samenwerking en het teruggeven aan de community promoot, en ik denk nog steeds dat dit de enige manier is om opensource op de lange termijn niet te laten versplinteren.
Ik ben toen besmet geraakt met de gedachte dat het mooi, interessant en leerzaam is om samen in de openbaarheid dingen te ontwikkelen. Dat is een ideologie waarin ik geloof.
Gehackt!
Voor het programmeerwerk dat ik deed, kreeg in die tijd ook een Windows-werkstation van de faculteit. Die liet ik ’s nachts gewoon aanstaan, want dat was heel normaal eind jaren negentig, onder andere door nieuwe tools als Napster. Op een ochtend merkte ik ineens dat mijn pc vreselijk langzaam was. Ik bleek gehackt te zijn. Toen dacht ik: dit gebeurt me één keer en nooit meer. Ik ga me nu écht verdiepen in dat Linux-spul. En dat is waar het voor mij begonnen is. Ik heb Red Hat Linux 6 of 7 op dat werkstation gezet, en daarna nooit meer teruggekeken.
Nooit wat
Sinds die tijd heb ik mijn juridische carrière opgegeven en ben ik me als hobby verder gaan ontwikkelen op het gebied van Linux en opensource, onder andere als Fedora-contributor, in de hoop dat ik er ooit mijn werk van kon maken. Dat bleek een paar jaar later mogelijk toen ik een baan kreeg als consultant voor ‘Linux-achtige dingen’. Uiteindelijk had ik vooral te maken met Unix, onder andere bij een grote bank, want ‘dat Linux wordt toch nooit wat’ en ‘alles blijft uiteindelijk op Unix en Solaris en dat is perfect’. Andere tijden.
De markt begon toen vanaf dat moment snel te veranderen, en Linux groeide in populariteit. Toen er een vacature bij Red Hat voorbijkwam (het bedrijf dat ooit mijn interesse in Linux had gewekt) bleek dit de ideale kans om van Linux en opensource mijn werk te maken. Want waar kan je dit nu beter leren, dan bij een bedrijf dat gebouwd is op opensource, de opensource-idealen en de GPL? Een bedrijf dat samenwerkt met alle partijen die iets met opensourcesoftware doen, van softwareleveranciers en technologiebedrijven, tot allerlei organisaties die opensourcesoftware gebruiken, en uiteraard de vele community’s rond talloze projecten.
Open samenwerking
Anno 2021 heeft bijna iedereen een computer op zak waar een Linux-kernel op draait, of in elk geval diverse opensource-hard- en softwarecomponenten. En ook bedrijven vertrouwen massaal op software en systemen die op Linux en opensource-tools zijn gebouwd. Ook daar heeft Linux de wereld veroverd. Weliswaar niet als vervanger van de Windows-desktop, maar wel als de motor achter de diensten waar bedrijven wereldwijd gebruik van maken.
Organisaties vragen tegenwoordig ook niet meer alleen om hulp bij opensource-implementaties, maar ook bij implementeren van een open manier van samenwerken. Je hebt daarvoor een bepaalde cultuur nodig, die je organisatie in staat stelt om te gaan met al die snelle technologische ontwikkelingen. Dat doe je niet door te zeggen: we hebben hier een Unix-platform dat al vijftig jaar draait. Steeds meer bedrijven willen tegenwoordig de slag maken naar een opensource-manier van samenwerking, ontwikkelen in community’s, zowel in- als extern, en wendbaarder worden als organisatie en daardoor sneller innoveren. Dat is waar de grootste winst te behalen is.
Naar de toekomst
Dertig jaar Linux heeft ons veel gebracht, en het mag helder zijn dat de GPL daar een belangrijke rol bij heeft gespeeld. De open manier van samenwerken en weer terug delen met de community was cruciaal voor dit succes. Door de GPL kunnen we voortbouwen op het werk van de pioniers die ons voorgingen. Technologieën als Kubernetes en serverless computing waren ook nooit ontstaan zonder Linux en alle opensource-projecten die eraan voorafgingen. Alles wat nu wordt ontwikkeld, hangt aan elkaar met opensource, met Linux als een belangrijke basis. Door samen te werken en te delen, zetten we makkelijker stappen vooruit, in plaats van iedereen het wiel te laten uitvinden.
Met de onstuitbare groei van Linux vindt ook het opensource-gedachtegoed zijn weg naar grote bedrijven. En het beperkt zich ook niet meer tot enkel technologie, maar ook tot allerlei vormen van open kennisdeling en samenwerking binnen de meest uiteenlopende vakgebieden.
Linux en de GPL staan garant voor nog dertig jaar succesvolle groei en innovatie wereldwijd. Linux wordt nu zelfs op Mars gebruikt in de vorm van Ingenuity, de eerste robothelikopter die op een andere planeet actief is. Voor Linux is dus zelfs de sky niet meer de limit.
Het is fantastisch om vanuit Red Hat bij te mogen dragen aan het succes van opensource in het algemeen en dat van Linux in het bijzonder, en bedrijven wereldwijd in aanraking te brengen met de technologie, maar ook met de opensource-cultuur. Ik ben ervan overtuigd dat de rol van Linux en opensource in onze maatschappij alleen nog maar zal toenemen de komende jaren.
(Auteur Maxim Burgerhout is principal solution architect bij Red Hat.)
@oudlid
gezien de patches, zero days en de ransomware ellende de afgelopen jaar zou ik bij het begrip “knutselen” aan een hele andere partij denken…
@SWA
De zero days komen evenveel – en misschien wel meer door de openheid van de code – voor bij open souces als de andere partij en ik moet daarom met grote regelmaat dus patchen waarbij één van de uitdagingen in de diversiteit zit want naast de kernel komen er vaak nog een heleboel andere projecten mee. Wat betreft het knutselen zijn m.n. de gratis community edities nogal innovatief en deze contractloze oplossingen vallen onder de noemer shadow IT door de nogal informele introductie binnen een architectuur. In 11 van de 10 gevallen is er sprake van achterstallig onderhoud als de engineer er niet meer is om de oplossing te knuffelen, knutselen wordt dan stuntelen. De ransomware ellende heeft veelal een andere oorzaak, zoals een lucratief verdienmodel als er verder niks meer te halen is.
@oudlid
stellige uitspraken hoor! geen onderbouwing / referenties en ik durf zelfs te stellen zelf dat je bewering zeer discutabel is: https://www.cvedetails.com/top-50-vendors.php?year=2021
ter verfijning (om minder appels en peren te vergelijken), neem eens:
https://www.cvedetails.com/product/32238/Microsoft-Windows-10.html?vendor_id=26
versus bijvoorbeeld:
https://www.cvedetails.com/product/78/Redhat-Enterprise-Linux.html?vendor_id=25
@SWA
Als eerste staan de zero days nog niet in de CVE database en als tweede betekent een bekende vulnerability niet dat iedereen de patch aangebracht heeft. Eén van de redenen waarom ik wijs op het fenomeen van shadow IT is omdat de papieren tijgers makkelijk te temmen zin want uitspraak over achterstallig onderhoud moet je op zijn merites beoordelen door een scan op de kwetsbaarheden te doen.
@SWA
Uiteraard hoef je mij niet te geloven en kun je andere artikelen lezen:
https://www.zdnet.com/article/a-call-to-improve-linuxs-security/
Leuk stukje ook over CVE database, het is cherry-picking. Maar let vooral even op de opmerkingen over gïntegreerde systemen, de hybride oplossing van product en dienst om de service tot achter de voordeur te leveren is natuurlijk een stukje uitbesteding wat de knutselaars liever zelf willen doen maar uiteindelijk blijft liggen omdat ze geen tijd hebben. En volgens Kees Cook is dit resource allocation probleem op te lossen met een grotere samenwerking buiten de gebruikelijke silo’s, academische (HPC) setting is tenslotte een niche want de meeste organisaties die open source gebruiken hebben niet de personele draagkracht om het te kunnen onderhouden.
Ik twijfel trouwens niet aan de innovativiteit van de knutselaars en begrijp daarom heel goed waarom open source gebruikt wordt maar vanuit een bestuurlijk perspectief zijn er nog andere gezichtspunten waar rekening mee gehouden moet worden.
Wat oudlid verkoopt is een professionele dienst, doet men het zelf dan wordt het ineeens shadow-it-geknutsel genoemd.
zuivere, onafhankelijke, goedkope oplossingen, effectief en efficient, waarover nagedacht is, door eigen professionals. oudlid vindt het maar nix want wat als de engineer er niet meer is.. Haha, over zuurpruimen gesproken 🙂
maar ik snap dat oudlid tegen contractloze oplosssingen is en dat hij me net als maxim graag uitlegt waarom ..
Dino, ik ben jarenlang weggezet als engineer op basis van het uurtje-factuurtje principe van detachering omdat een flexibele arbeidsschil populair was/is. Ik probeerde me daarin altijd zo snel mogelijk ‘weg te knutselen’ door kennisborging omdat ik voor die flexibiliteit gekozen had, het rendement van een constante contractverlenging is profijtelijker als ZZP-er. Denk dat ik de spijker wel op zijn kop sla als ik zeg dat sommigen bepaalde legacy knuffelen vanuit een eigenbelang. Jij natuurlijk niet maar denk dat een objectieve beoordeling van zuivere, onafhankelijke, goedkope oplossingen op basis van effectiviteit en efficiëntie een contradictio in terminis is als de slager zijn eigen vlees keurt.
Nu ik toch latijnse termen gebruik, quid pro quo principe van voor wat, hoort wat in het (grotendeels Romeinse) verbintenissenrecht betekent contractmanagement want contractloze oplosssingen in het verbintenissenrecht laten zich vertalen als een laisser-faire invulling van de activiteiten als het om de kosten-baten analyses gaat. Maxim is contractloos de support engineer voor zijn vader en wat betreft de community versies is het als een vereniging, vrijwilligheid is weliswaar geen vrijblijvendheid in de verbintenis maar er is geen dwang. Zelfs de statutaire drang kent zijn beperkingen maar dat is meer juridisch dan technisch dus wat de professionals betreft zitten we zeker niet op één lijn.
We kunnen terug gaan naar de andere discussie over kosten-baten analyses want zoals jezelf al zegt kunnen licenties veranderen waardoor beoordeling van de zuivere, onafhankelijke, goedkope oplossingen op basis van effectiviteit en efficiëntie opeens een heel andere uitkomst kan hebben. En wat betreft de eigen professionals die uiteindelijk ingehuurd zijn verwijs ik naar eerste alinea, de exit van de engineer is een realiteit bij een groot deel van het MKB. Neem nu Jan, de adviseur die eigenlijk net als Maxim de contractloze support engineer is voor zijn klanten. Voordat Jan in de kramp schiet, ik verkoop ook graag de ‘strippenkaart’ van een engineer die (quid pro quo) de klant helpt want de goedkope oplossing van gratis advies wordt als de prietpraat van een WC-eend gezien.
@oudlid
“vanuit een bestuurlijk perspectief zijn er nog andere gezichtspunten waar rekening mee gehouden moet worden.”
welke zijn dat dan?
“geknutsel”, IBM en Oracle die beide vell Linux inzetten als “knutselaars” betitelen zegt veel over de aktualiteit van je kennis in zake open source, tweederde de bijdragen worden van grote bedrijven gemaakt.
“contractloos”
wat je bedoelt is me een raadsel, natuurlijk wordt iedere opdacht kontraktueel vastgelegd welke prestaties, welke randvoorwaarden en welke vergoedingen komen.
Een tip, minder wollig formuleren en veel minderr kokketeren met latijn of andere dode talen.
Jan,
Je kokketeert altijd graag met een academische opleiding (voltooid?) waarin latijnse termen niet ongebruikelijk zijn waardoor ik mag aannemen dat je de reden kent voor het gebruik van een dode taal, het wollig formuleren in de semantische wereld van lange tenen en korte inzichten leidt namelijk nog weleens tot contextuele fouten in de aannames. Zo is het al fout dat bijdragen door grote bedrijven (rechtspersonen) gemaakt worden want het zijn vooral de natuurlijke personen die al dan niet met een contractuele verbintenis dit doen en eventueel het intellectuele eigendom als een verhandelbaar idee overdragen. En uiteraard kunnen ze het idee ook meenemen om een verbeterde versie te maken, mijn actualiteit aangaande code gaat dan ook iets verder dan alleen open source want de knutselaars die gisteren bij IBM werkten, vandaag bij Google en morgen bij Microsoft zijn natuurlijke personen die graag een beloning krijgen voor hun ideeën.
Klinkt wollig maar het Nederlands (continentaal) recht is incompatibel zijn met het Amerikaans (Angelsaksisch) recht omdat het quid pro quo principe niet mondiaal aanvaard is, als je de link niet gelezen hebt dan zul je de licentievoorwaarden ook wel niet gelezen hebben want net als de software kunnen ook licenties incompatibel met elkaar zijn. De juridische – alias de bestuurlijke – kant van de contractuele wederzijdse verplichtingen aangaande het patchen is daarom een leuke als we kijken naar de prestatieafspraken. En ik ben blij dat alles wat ik schrijf voor jouw een raadsel is want de prietpraat van een WC-eend is niet bedoeld als open kennisdeling en samenwerking binnen de meest uiteenlopende vakgebieden;-)