Slim balanceren tussen open en closed source

Bij Otherside at Work ontwikkelen we de Xpert Suite om organisaties te ondersteunen bij verzuimmanagement, duurzame inzetbaarheid en sociale zekerheid. De Xpert Suite is een SaaS-oplossing die werknemers ondersteunt, organisaties grip geeft en ketenpartners verbindt. Het selecteren van de juiste technologieën voor onze tech stack is essentieel voor het succes en de betrouwbaarheid van ons bedrijf. Bij deze keuzes geloven we in een pragmatische benadering: we kiezen de technologie die het meest geschikt is voor de specifieke taak. In dit blog bespreekt Stef Roskam, VP Engineering bij Otherside at Work, onze visie op het opbouwen van deze tech stack. Hierbij staan de keuze voor open source en closed source software en de overwegingen die hieraan ten grondslag liggen centraal.

Life cycle management: de kern van onze keuzes

“Onze codebase is waar ons hele bedrijf op draait. Gezien de omvang van de codebase is het niet realistisch dat deze in één keer volledig vervangen kan worden. Dat betekent dat we hoge eisen stellen aan de kerncomponenten binnen onze infrastructuur”, legt Stef uit. Deze componenten moeten:

• Een betrouwbare update-strategie hebben.
• Een minimaal risico op vendor lock-in bieden, bijvoorbeeld door voorspelbare prijsmodellen.
• Een bewezen staat van dienst hebben op het gebied van security updates en life cycle management.

Stef vervolgt: “Vanwege deze eisen kiezen we voor open source software voor cruciale onderdelen. Open source biedt ons de vrijheid en flexibiliteit om adequaat te reageren op wijzigingen van leveranciers of maintainers, waardoor afhankelijkheid van één enkele partij wordt geminimaliseerd.”

Vendor lock-in: een belangrijk aandachtspunt voor core componenten

Bij open source (met de juiste licenties) voorkom je ook het risico van de Vendor lock-in. Vendor lock-in kan aanzienlijke risico’s met zich meebrengen, vooral wanneer het gaat om software die lastig te vervangen is. Stef geeft een voorbeeld: “Stel bijvoorbeeld dat een van onze leveranciers plotseling de licentiekosten verhoogt met een substantieel bedrag. Als we dan niet kunnen overstappen naar een ander systeem vanwege het hoge aantal manjaren om de codebase (deels) te vervangen, dan zitten we mogelijk jarenlang vast aan hoge kosten. Om deze risico’s te beheersen, gebruiken we open source met goede licenties voor alles wat veel effort nodig heeft om te vervangen.” De belangrijkste voorbeelden zijn:

• .NET voor de backend.
• JavaScript libraries voor de frontend.

Voor alle overige componenten geldt: kijk wat het beste past

“Voor onderdelen in onze tech stack die minder tijd kosten om te vervangen hanteren we andere afwegingen. Denk hierbij aan componenten zoals backupsoftware, lokaal gebruikte componenten in ons SaaS-platform, firewalls, proxies en hostingplatforms”, aldus Stef. Voor deze toepassingen wordt beoordeeld:

• De mate waarin de oplossing aansluit bij onze functionele behoeften.
• De inspanning om de componenten te implementeren.
• Veiligheid die de leverancier kan garanderen.
• Reputatie van de leverancier.
• Ondersteuning die de leverancier kan bieden en tegen welk tarief.

Veiligheid: open source versus closed source

“Er wordt vaak aangenomen dat open source software veiliger is, omdat de code publiek toegankelijk is en door een brede community kan worden beoordeeld. In de praktijk blijkt deze aanname echter niet altijd op te gaan”, zegt Stef. Hij vervolgt: “Veel open source projecten worden onderhouden door kleine teams, of zelfs door één enkele ontwikkelaar, wat de mate van controle en doorontwikkeling kan beperken. Daarbij zijn er genoeg voorbeelden van open source waaruit is gebleken dat ze kwetsbaarheden hadden. Daarbij moet wel gesteld worden dat closed source software niet per definitie veiliger is.” Om een beoordeling te maken hoe veilig een samenwerking met een leverancier is, wordt onder andere gekeken naar:

• De expertise van het ontwikkelteam.
• De beschikbare middelen voor onderhoud en doorontwikkeling.
• De kwaliteit van de bestaande codebase.

“Bij onze beslissingen hechten we daarom veel waarde aan de reputatie en betrouwbaarheid van de leverancier of community, ongeacht of de software open of closed source is.”

Overige evaluatiecriteria voor softwarekeuze

Stef legt uit hoe onze aanpak bij de selectie van open source of closed source wordt gekenmerkt door een kritische evaluatie van onder andere:

• De stabiliteit en toekomstbestendigheid van doorontwikkeling.
• De kwaliteit van de code en de ondersteuning van de ontwikkelgemeenschap of leverancier.
• Het risico dat we lopen als een leverancier stopt met ondersteuning of wijzigingen doorvoert.

“Een goed voorbeeld is onze keuze voor .NET. Hoewel dit framework open source is, biedt het dankzij de ondersteuning van Microsoft en een breed gebruikersnetwerk een sterke garantie voor continuïteit. Bij kleinere leveranciers of minder bekende technologieën voeren we vaker en intensiever evaluaties uit om zekerheid te krijgen over de kwaliteit en toekomstbestendigheid.”

Conclusie: een gebalanceerde aanpak werkt het beste voor Otherside at Work

Stef concludeert: “Onze tech stack is een zorgvuldig samengestelde mix van open source en closed source oplossingen. Voor kernsystemen kiezen we open source technologieën vanwege de grotere flexibiliteit en lagere risico’s op vendor lock-in. Voor andere onderdelen kiezen we de oplossing die het beste aansluit bij onze behoeften. Deze pragmatische aanpak stelt ons in staat om een software-infrastructuur te onderhouden die niet alleen betrouwbaar en veilig is, maar ook goed is voorbereid op toekomstige ontwikkelingen.”

Heb je vragen over onze visie op open source of closed source? Of wil je meer weten over hoe we denken over onze techstrategie? Lees hier bijvoorbeeld onze visie op incrementeel doorontwikkelen versus herbouwen.

En neem gerust contact met ons op.