Opensourcesoftware is al jaren onderdeel van de mainstream van enterprise-it. Uit onderzoek van Red Hat blijkt hoe snel opensource zich in twintig jaar ontwikkelde: 95 procent van de gebruikers vindt het strategisch belangrijk. Ook IDC zegt dat opensource is doorgedrongen tot vrijwel elk niveau van de softwarestack. De populariteit is te danken de kant-en-klare goed gebouwde, veilige en hoogwaardige tools die opensource biedt.
En dat alles ook nog eens tegen lage kosten: niet alleen de afwezigheid van licentiekosten, maar de kwaliteit en beschikbaarheid van opensource betekende dat ontwikkelaars beter konden werken, waardoor de kosten en de tijd die met de ontwikkeling en levering van software gepaard gaan, werden verminderd.
En twintig jaar later is opensourcesoftware nog steeds populair. Tegelijkertijd is het kostenaspect actueler dan ooit. Door de huidige krapte op de arbeidsmarkt is het lastig vaste it-talenten aan te trekken, waardoor veel bedrijven gebruik maken van flexibele arbeidskrachten. Zij hebben vaak kennis van opensource en weten hoe ze het moeten inzetten binnen organisaties. Veel bedrijven zien dit als een manier om nieuwe en bestaande digitaliseringsinitiatieven te leveren met minder mensen. Tegelijkertijd brengt het inhuren van deze flexibele arbeidskrachten extra kosten met zich mee.
Onderhouden van opensource
Volgens onderzoek van Tidelift zijn de kwaliteit en betrouwbaarheid van code factoren die ontwikkelaars helpen snel te werken, maar één ding sprong er in het bijzonder uit. ‘Ontwikkelaars profiteren van het feit dat code wordt gebruikt en onderhouden door een grotere community buiten hun eigen organisatie’, aldus Tidelift. Dit is belangrijk omdat ‘onderhouden’ implicaties heeft, afhankelijk van de setting.
Van oudsher worden opensourceprojecten onderhouden door middel van regelmatige releases of fixes. In de enterprise-wereld is dat niet meer van deze tijd. Onderhouden in enterprise-it voegt extra operationele vereisten toe op het gebied van compliance, regelgeving en samenwerking. Deze bedrijfsgerichte operationele aspecten vallen buiten het projectwerk van de community, maar komen wel voor in betaalde enterprise versies. Bedrijven geven met het grootste gemak geld uit aan softwaremakers van gesloten software, maar vinden het moeilijk om de portemonnee te trekken voor opensource.
Beslissen wanneer over te stappen op een betaalde versie is volgens Gartner een dilemma voor twiintig procent van de organisaties. Wat ironisch is omdat het runnen van niet-ondersteunde code in strategisch belangrijke systemen iedereen zou moeten verontrusten.
Adoptie-cyclus
De adoptie-cyclus van bedrijfssoftware verloopt in drie fasen – ontwikkeling, stabilisatie en standaardisatie. En betalen voor onderhoud tijdens elk van deze fases heeft geen zin. Maar wat is dan wel het juiste moment om hierop over te gaan?
Tijdens de eerste fase experimenteren ontwikkelaars met de code. Het zal geëvalueerd en gebruikt worden door slechts een handjevol personen om de proof-of-concept en initiële interne software af te leveren. Niet-ondersteunde opensource is in dit stadium vaak goed genoeg.
Als de code stabiliseert en in productie gaat, worden de enterprise-extra’s belangrijk. Dit is het moment waarop operationele teams betrokken raken bij de implementatie en lifecycle én dus tools nodig hebben om te communiceren en samen te werken. Als de code in contact komt met klanten, komen beveiliging en privacy in beeld, met de behoefte aan compliance, auditing en tracking. Tenslotte worden performance en betrouwbaarheid belangrijk, dus zijn er tools nodig voor real-time administratie en monitoring.
Wanneer de software uitgerold wordt, zal het een standaard worden voor de hele organisatie. Daarom is het belangrijk dat de code gemakkelijk te implementeren en te integreren is met de gebruikelijke processen en systemen. Om dit te bereiken moet gebruik worden gemaakt van best practices en sjablonen. De lange termijn conditie van de software is cruciaal, dus betaalde ondersteuning moet zorgen voor beveiligingsupdates, fixes en upgrades.
Succes en mislukking
De kracht van opensourcesoftware is dat het verankerd is in de community. Historisch gezien zijn tools, templates, integraties en dashboards voor samenwerking, monitoring en compliance die buiten de ontwikkelingsfase worden gebruikt organisch ontstaan. Hiervoor zijn specialisten nodig die ervaring hebben met enterprise-klanten. Zij hebben deze factoren meegenomen in hun werk aan opensource-projecten, en zullen dat blijven doen.
De aanwezigheid van deze deskundigen biedt nog een ander voordeel. De overgang naar een digitale infrastructuur vraagt om een grondige herziening van de systeemarchitectuur en werkwijzen rond gedistribueerde en flexibele cloud computing en storage.
Betaalde partners kunnen het verschil maken tussen succes en mislukking: het betekent dat een partner helpt bij de veranderingen qua technologie en architectuur en kan adviseren over het ontwerp en het beheer van grote en gedistribueerde systemen. Zij kunnen adviseren over migratie en implementatie, best practices delen en benchmarking, en teams opleiden. En als er problemen zijn waarvoor ondersteuning nodig is, kunnen deze deskundigen snel voor oplossingen zorgen. Vertragingen en uitval zijn pijnlijk voor digitale bedrijven: investeren in ondersteuning kan helpen de pijn te beperken.
Mondiger
Opensource heeft ontwikkelaars mondiger gemaakt en organisaties opgebouwd, maar terwijl cfo’s misschien de voorkeur geven aan de kostenvoordelen van ‘gratis’ om op korte termijn de klus te klaren, moet er rekening worden gehouden met de gezondheid van de code – en van uw operationele systemen – op lange termijn.
Dat betekent investeren in de tools en best practices die de opensourcesoftware in staat stelt te werken als onderdeel van een volwaardig systeem van enterprise-operaties.
Wat een verhaal, je zal maar klant zijn.
Support van je closed source software provider of van je opensource “betaalde partners”
Kies maar..
“De kracht van opensourcesoftware is dat het verankerd is in de community.” maar ja, daar koop 🙂 je weinig voor.
Blijkbaar is het niet genoeg.
Code zou vaker aangepast moeten worden en natuurlijk specifiek voor de klant en context: compliance, regelgeving en samenwerking. Wat zou er met die code gebeuren ? Ook terug naar de gemeenschap ? Of dat juridisch moet verschilt vast per licentie model en dus per applicatie, of je het wilt is nog de vraag.
Verwijzingen naar onderzoek van Tidelift en RedHat. Follow the money en betaalde partners klinkt ineens niet meer zo gek.
Natuurlijk is het grotendeels wij van WC-eend adviseren WC-eend door een regional manager solutions engineering maar open source heeft een enorme opmars gemaakt doordat het steeds vaker onderdeel is van een oplossing. Wel een dingetje hierin zijn de bedrijfsgerichte operationele aspecten die buiten het projectwerk van de community vallen want een schrikbarend veel voorkomend euvel hierin ls dat bedrijfsgerichte aspecten meer op het functionele vlak dan het technische liggen waardoor er niet alleen doorgewerkt wordt met niet-ondersteunde code maar ook vaak code waarin fouten zitten die misbruikt kunnen worden. Ik twijfel daardoor of het verhaal de titel dekt want de uitrol van software is niet het probleem.
Volgens mij is er tussen opensource en closed source geen verschil qua codering. Ik kan me niet voorstellen dat je een stukje software schrijft of reeds bestaande componenten bij elkaar klikt die NIET voldoen aan de gestelde eisen (welke deze ook zijn). Zo zou ik ook een betoog kunnen houden over veel closed software waarbij men zich ook niet heeft gehouden aan allerlei eisen die de klant wil (en daar zijn er legio van).
In mijn optiek is het meest essentiële verschil tussen open source en closed source het enkele feit dat je de broncode niet krijgt te zien die de manifeste software tot uiting brengt. Veel mensen denken dat open source niet betaald hoeft te worden. Dat is niet waar; ik kan prima een partij opdracht geven om software te laten bouwen waarvoor ik vrolijk betaal. Dat ik vooraf afspraken maak over de licentiestructuur van de code is een onderdeel van de eisen. Zo zou ik er ook prima een partij kunnen zijn die gratis en voor niets iets bouwt en dat wel closed source houdt. Waarom ze dat doen, zodat alle add-ons en dergelijke wel betaald dienen te worden.
Voor partijen die iets bouwen heeft te maken met het gekozen businessmodel waarop zij hun diensten hebben gebaseerd. Voor klanten heeft het te maken, met sturing op de interne werking en informatiekundige visie waarop men de software gebouwd wil hebben.