Het besturingssysteem Linux en de Netscape-browser zijn voorbeelden van ‘open source’ software. De broncode is vrijelijk beschikbaar en opdoemende problemen kunnen van meet af aan publiekelijk worden bediscussieerd. Een medewerker van Vertis over de grote voordelen van deze aanpak.
Er is een stille revolutie gaande, al is het misschien beter te spreken over de ‘coming-out’ van iets wat geleidelijk aan is geëvolueerd. De impact van wat gaande is zal groot zijn: er is een parallel te trekken met de opkomst van Internet. Ook daar zagen we dat een ontwikkeling van tientallen jaren plotsklaps ‘doorbrak’ naar de publieke sfeer. Met uiteindelijk significant succes, niettegenstaande alle scepsis en ongeloof. Het bleek ’the right thing’ te zijn. Of ‘open source’ dat ook is, moet nog blijken. Maar er zijn veel signalen die daar op wijzen. Zo heeft Oracle – toch niet de eerste de beste – recentelijk besloten om zijn commerciële software te poorten naar het besturingssysteem Linux. Oracle volgde daarmee Informix. Eerder had Sun al aangegeven ook een vinger in de Linux-pap te willen houden en sloot zich aan bij ‘Linux International’. En Marc Andreesen van Netscape spreekt enthousiast over de verbetering van de kwaliteit die ontstond toen de broncode van de Netscape browser beschikbaar kwam voor het publiek. Als u straks de URL’s volgt aan het eind van dit artikel, maakt u ook al gebruik van ‘horizontaal geprogrammeerde software’ – ook wel ‘open source’ of ‘free software’ (vrije software) genoemd. De broncode van deze software is vrijelijk beschikbaar.
Organisatiestructuren wijzigen meer en meer van een verticaal model naar een horizontaal model. Coöperatie en concurrentie blijken elkaar niet langer meer uit te sluiten. En de ontwikkelmethodieken veranderen mee: van verticale naar horizontale software. Kort en goed: de tijd is rijp. ‘open source’ heeft de toekomst.
De verticale ontwikkelmethode
De meeste software wordt van oudsher ‘verticaal’ gebouwd: een kleine groep programmeurs knutselt ijverig in opdracht van ‘een baas’ aan een product dat juist voldoende van kwaliteit is. Wat precies ‘voldoende kwaliteit’ is, wordt uiteraard gedefinieerd door de afnemer. Als deze niet in staat is om de kwaliteit zelf te bepalen – IT is nu eenmaal een complexe aangelegenheid – kan hij bijvoorbeeld een IT-deskundige in dienst nemen, die hem hierbij helpt. Bedrijven of personen die het zich niet kunnen veroorloven om een eigen expert in te huren en die verder de kennis niet (kunnen) hebben om de kwaliteit van software te beoordelen, hebben geen andere keus dan blind te varen op de optiek en de expertise van de softwarebouwer/leverancier, die uiteraard met flair de eigen standaard-producten adviseren. Het is een bekend fenomeen dat de bedrijfsprocessen in dat geval op de software worden aangepast in plaats van andersom. Het verticale ontwikkelmodel voldoet goed, zolang er door de leverancier voldoende kundige specialisten te werven zijn, er bij de afnemer voldoende geconcretiseerd kwaliteitsbesef aanwezig is en terugkoppeling naar de bouwer tot de mogelijkheden behoort. Kwaliteitssoftware is dus afhankelijk van – een fraaie open deur – de beschikbaarheid van specialisten. Als de markt aantrekt en de instroom van specialisten gering is, – een wereldwijd optredend fenomeen – is er structureel te weinig capaciteit beschikbaar om de kwaliteit van de software hoog te houden. Een sterk bepalende factor is daarbij ook dat elk bedrijf in zo’n situatie zijn uiterste best doet om goede mensen te werven die dan vervolgens slechts voor een beperkt doel worden ingezet. Dat is het heil van het bedrijf waar ze voor werken, wat op zijn best correspondeert met slechts een deel van het heil van de klanten van dat bedrijf.
Kwik, Kwek en Kwak
Maar met de toenemende complexiteit van software, de toenemende vraag naar producten en de toenemende schaarste op de markt lukt het de meeste bedrijven niet meer om voldoende kennis in huis te halen. De kwaliteit van de software neemt daardoor af. Gelukkig is de productiviteit van de ontwikkelaars dramatisch toegenomen, dankzij het gebruik van rad-toolsets. Maar die medaille heeft ook een keerzijde: de tools die bij ontwikkeling gebruikt worden, zijn vaak ook van ‘juist voldoende kwaliteit’ – dit ter beoordeling van de testteams van de leverancier, in plaats van de gebruiker. En een toolset kan structureel ‘minder goede’ applicaties genereren. De groeiende omvang en afnemende efficiëntie van onze programmacode geeft hiervan een goede indicatie. Een aanvullend probleem is dat commerciële bedrijven de broncode het liefst voor zichzelf houden – enerzijds om de voorsprong op de concurrent niet te verliezen, anderzijds om de klant te binden. Het is commercieel gezien prettig dat de fouten in een gesloten pakket van leverancier A zodoende niet door leverancier B opgelost kunnen worden. Als afnemer zit je dus vast aan je leverancier, of je moet al kunnen leven met een knappe kapitaalvernietiging. Maar vaak is dan het enige resultaat dat je nu niet meer gebonden bent aan A, maar aan B en begint het hele verhaal opnieuw. En de binding tussen leverancier en afnemer bestaat dan feitelijk niet meer omdat de leverancier de juiste kwaliteit levert, maar domweg omdat er geen weg terug bestaat zonder zeer forse investeringen. Een kwalijke zaak. Voor managementlagen binnen bedrijven is het juist in die situaties, waarbij je dus feitelijk een slechtere functionaliteit c.q. kwaliteit krijgt dan je zou willen, verleidelijk om zich met een beroep op het ‘Kwik-Kwek- en Kwak-effect’ vrij te pleiten. De typische redenatie luidt dan dat ‘het nog niet zo slecht kan zijn, want de anderen gebruiken het ook, dus is het standaard’. Kwik zegt het, dus Kwek en Kwak ook. Eindgebruikers van verticaal gebouwde software die massief wordt gebruikt, zijn de grootste slachtoffers van de verticale ontwikkelmethode. Enerzijds hebben zij geen mogelijkheid om hun individuele wensen en eisen op te leggen aan de producent – die luistert al lang niet meer naar het individu – anderzijds is de markt voor massa-software ook nog verworden tot een feitelijk monopolie, zodat je ‘wel mee moet doen’. De massale ‘reboot’-ziekte die ons al bijna tien jaar in de greep heeft, is een goede indicatie dat er ergens iets niet goed is gelopen. Het zou mooi zijn als de schaarse specialisten met elkaar zouden mogen overleggen, elkaars broncode konden controleren en elkaar konden helpen bij de voltooiing van projecten. Dat wordt door het management van bedrijven echter veelal nog gezien als een verraad aan de broodheer, waarna ontslag het gevolg kan zijn.
De horizontale ontwikkelmethode
Gelukkig is er in de laatste decennia toch een verschuiving ontstaan. Tegen de stroom in, en voornamelijk gevoed uit noodzaak, wordt meer en meer software ‘horizontaal’ gebouwd. Met name de beschikking over het wereldwijde Internet heeft een impuls gegeven aan het horizontale ontwikkelmodel. De horizontale ontwikkelmethodiek houdt in dat een probleem dat opdoemt van meet af aan publiekelijk – via Internet – wordt bediscussieerd. Onder ‘publiekelijk’ moet niet worden verstaan ‘door iedereen’: het zijn de ervaren specialisten die met elkaar de discussie voeren. Anderen, die het probleem ook herkennen en opgelost willen zien, participeren dan in het ‘project’, geven commentaar en dragen suggesties aan. Veelal wordt al de eerste dag een stukje code gepubliceerd dat althans een deel van het probleem oplost. Die code mag zelfs van slechte kwaliteit zijn, maar omdat er zoveel ogen van kundige heren en dames op worden gericht, evolueert zo’n kristallisatiepunt vaak heel snel tot software van uitstekende kwaliteit.
Typisch voor de horizontale benadering is dat zich vaak een coördinator (of team van coördinatoren) opwerpt – vaak degene die het probleem als eerste oppakte – die alle wijzigingen verzamelt en verwerkt in de broncode, waarna deze broncode opnieuw ter beschikking wordt gesteld. Linus Torvalds vervult deze rol bijvoorbeeld voor het besturingssysteem Linux, maar bij het (commerciële) Netscape is het een team van experts.
Wordt het dan niet al heel snel een warrige puinhoop? Gaat dan niet iedere hacker zijn eigen versie van de software maken? Het staat een ieder inderdaad vrij om ‘eigen’ afsplitsingen van de software te maken. Maar dat gebeurt niet vaak, omdat de coördinatoren veelal de strategie volgen om zoveel mogelijk van de gesuggereerde wijzigingen ook daadwerkelijk in de broncode op te nemen. Blijkt dat achteraf minder geslaagd, dan wordt dat door het veelal groeiende team van participerende experts gesignaleerd en alsnog ongedaan gemaakt. Om nu te voorkomen dat de gebruiker van de software met een soort permanente bèta-versie zou moeten werken – al is deze vaak al beter van kwaliteit dan de middels verticale methoden gebouwde gelijksoortige software – zorgt men bij het besturingssysteem Linux voor twee versies van de software.
Stabiel en experimenteel
Het betreft een experimentele lijn, die nog in ontwikkeling is en een iets oudere, stabiele lijn. Als de experimentele lijn stabiliseert, volgt een overgang naar de stabiele lijn en wordt een nieuwe experimentele lijn gestart. Iets soortgelijks zien we bij Netscape, waar we een ‘officiële’ versie van de browser hebben en een ontwikkellijn. Dit alles resulteert in softwaresystemen waarvan de broncode vrijelijk beschikbaar is en die voor een ieder die dat wil toegankelijk is. De meest recente naam voor dit soort software is ‘open source’. "Maar dat was er toch altijd al, zult u zeggen? Heette dat niet ‘free software’?" Inderdaad, ‘open source’ software is in feite hetzelfde, maar onder een nieuwe naam. Deze nieuwe naam werd op 5 februari 1998 gekozen door een klein team van experts, waarvan er een – Eric Raymond – was gevraagd om Netscape te helpen bij de planning van de vrijgave van de broncode van de Netscape browser. Dat werd door de daar aanwezigen gezien als een cruciale stap op weg naar massieve acceptatie van de horizontale software. De gelegenheid werd aangegrepen om nu ook eens marketing te bedrijven, een onderdeel waarin de horizontalen niet zo goed in zijn. En zo is het verband tussen ‘free software’ en ‘open source’ als volgt te schetsen: ‘open source’ is het marketinginstrument van ‘free software’. ‘Free’ moet je dan wel lezen als ‘in vrijheid geschreven’ en niet per se als ‘gratis verkrijgbaar’. De schaarste aan specialisten kan niet zo maar worden opgelost door een andere ontwikkelmethode. Maar de specialisten die werken volgens het ‘open source’-model kunnen wel veel efficiënter werken: ze maken uitputtend gebruik van elkaars broncode en kennis. Omdat er geen restricties zijn om ‘open source’ software ook commercieel in te zetten – mits de modificaties op het origineel maar worden teruggekoppeld aan de ‘open source’ gemeenschap – kan een bedrijf zeker geld verdienen met de inzet van ‘open source’. Het bedrijf kan dan niet meer profiteren van het unieke bezit van de broncode, maar de kwaliteit van de software wordt wel een stuk beter en de klant zal minstens even graag betalen voor goede ondersteuning als voor software. Een voordeel van ‘open source’ is ook dat in eerste instantie de experts zelf de afnemers van de producten zijn. Zij worden dus zelf het eerst geconfronteerd met de ellende die gebricoleer oplevert, waardoor de impuls om ‘er iets aan te doen’ veel groter is. "
Niet meer te stuiten
‘Maar is die software dan niet vooral gericht op programmeurs en ingenieurs? En hoe zit het met eindgebruikers-software?’.Ik citeer uit de FAQ van de internationale ‘open source’ site.
Vijftien jaar geleden zeiden de mensen: "Die lui van de ‘free software’-beweging hebben een paar mooie speeltjes en demo’s gebouwd, maar ze hebben de capaciteit niet om echte tools te bouwen". De FSF bewees dat ze het bij het verkeerde eind hadden.
Vijf jaar geleden zeiden dezelfde mensen: "Nou goed, de GNU-toolkit is een prachtige toolkit voor programmeurs, maar ze zullen nooit een waardevol besturingssysteem bouwen".
Linux bewees opnieuw dat ze het bij het verkeerde eind hadden. Nu zegt men: "OK, Linux is een leuke speeltuin voor hackers en is aardig goed in Internet-toepassingen, maar ze zullen nooit nette toepassingen voor eindgebruikers schrijven."
Als de nee-zeggers het deze keer bij het goede eind zouden hebben, zou dat de eerste keer zijn. Er zijn inmiddels ‘open source’ kantooromgevingen (Star Office), ‘open source’ grafische pakketten van hoogstaande kwaliteit (Gimp), en er is natuurlijk de Netscape-browser. Maar er kondigt zich nu ook een golf van meer op de eindgebruiker gerichte toepassingen aan. Verder is de tendens te zien dat ook commerciële bedrijven hun producten poorten naar ‘open source’ of zelfs ‘open source’ maken (Oracle, Corel, Netscape, Red Hat, Caldera). ‘Open source’ software vormt nu al de basis van het wereldwijde Internet. TCP/IP, DNS, Sendmail en bijvoorbeeld de Apache webserver zijn daarbij onmisbare pijlers. Maar ‘open source’ manifesteert zich nu ook op de massa-markt en helpt zo mee om de monopolies die we daar zien te verbreken. Met name het besturingssysteem Linux [1] mag zich verheugen in de belangstelling van honderdduizenden hooggeschoolde specialisten. In deze laatste observatie ligt ook het succes van Linux besloten: het zijn de ingenieurs, de techneuten, die uit liefde voor hun vak en uit onvrede met de ‘standaard’-oplossingen de oude wetten van de commercie met voeten treden. Dezelfde specialisten worden namelijk dagelijks geconfronteerd met de slechte kwaliteit van het verkrijgbare. En het is een gegeven dat, wanneer de technologen een keuze hebben gemaakt, deze binnen een paar jaar ook doordringt op de werkplekken van de niet-technologen. De golf is niet meer te stuiten.
Kruispunt of puzzle?
De vraag kan terecht worden gesteld of de ‘open source’ benadering de oplossing is voor alle kwaliteitsproblemen. Moet alle software nu dus ‘horizontaal’ worden gebouwd? Wie betaalt dan de salarissen van de ontwikkelaars, bijvoorbeeld? Welnu, zeker 75 procent van het werk van bijvoorbeeld programmeurs bestaat uit het onderhouden van verticale software. Die taak blijft bestaan. Verder zijn er veel gebieden die zich (nog?) niet goed lenen voor een volledig horizontale benadering. Denk maar eens aan de programmering van hardware-besturingen, zoals de injectiemotor in de auto, of aan software die de bedrijfsprocessen van banken en verzekeringsmaatschappijen ondersteunt – het overgrote deel van het werk in onze branche. Wel verwacht ik dat commerciële bedrijven meer en meer hun experts de vrijheid zullen geven om een deel van hun werktijd betaald door te brengen met het schrijven van ‘software in het algemeen belang’. Niet omdat men aan liefdadigheid wil doen, maar gewoon omdat het algemeen belang ook het belang van het bedrijf blijkt te zijn. Bedrijven als Vertis, Netscape en Oracle hebben dit ingezien – het is een kwestie van tijd en dan volgt ook uw bedrijf.
Maar zoals mensen met een vooruitziende blik jaren geleden hun bedrijf nu een vooraanstaande rol laten spelen in de Internetmarkt, zo kunnen zij nu diensten bewijzen door het inzetten van meer ‘open source’ software.
Henk Klöpping, is werkzaam bij Vertis en lid van de European Fortean Foundation
Literatuur
[1]. Donkers, A.: Zij zijn groot en ik is klein, Computable, 21 augustus 1998. p.30
Nuttige URL’s
Een goede beschrijving van het ‘open source’ model kan worden gevonden in Erik Raymonds geschrift ‘De kathedraal en de bazaar’. Zie http://www.opensource.nl/bazaar.html voor een Nederlandse vertaling van zijn artikel. De internationale ‘open source’ site is te vinden onder http://www.opensource.org. Het artikel van Arthur Donkers is ook op de Nederlandse ‘open source’ pagina’s op te vragen: http://www.opensource.nl/artlinux.html. Zie voor meer uitleg over de diverse gangbare benamingen van vrije software, maar ook voor het commentaar van Richard Stallman, de vader van free software, op de marketingnaam ‘Open Source’: http://www.gnu.org/philosophy/categories.html, of raadpleeg de generieke ‘free software’ site http://www.fsf.org. Omdat het in het belang is van Internet dat er altijd voldoende ‘open source’ beschikbaar blijft om Internet onafhankelijk van verticalisten operationeel te kunnen houden, is er een werkgroep Open Source in oprichting van de Internet Society Nederland. Als u wilt participeren, kunt u mij een email sturen: henk@fortean.org. Zie verder ook http://www.isoc.nl. De Nluug heeft een ‘special interest’ groep opgezet voor Linux en ‘open source’. U kunt informatie opvragen over deze werkgroep via e-mail: buro@nluug.nl. Zie ook http://www.nluug.nl, en verder: http://www.mozilla.org, http://www.oracle.com/html/linux.html, http://www.li.org, http://www.linux.org en http://www.vertis.nl.
