Ik ben betrokken bij veel projecten waar een afweging wordt gemaakt tussen het gebruik van closed en open source. Er zijn vele artikelen verschenen over het maken van deze keuze. Ik wilde nu eens belichten hoe het er uit ziet een jaar nadat de keuze is gemaakt tussen een open source- en een closed source-product. Gemakshalve spreek ik alleen over product, dit kan echter net zo goed een library of component zijn.
Bij de start van het project is er gekozen voor een of meerdere open source-producten. In het type projecten dat ik doe, custom java development, zijn dit vaak vele verschillende producten. Normaal kies je voor de laatste stabiele release van een product, soms voor een bèta- of release-kandidaat. Tijdens het project moet je dan een upgrade doen, dit is meestal echter geen probleem. Na een jaar (of korter) wordt de eerste release opgeleverd van je eigen project en gaat het project in productie. Soms gaat het project verder met release 2, anders komen we meer in een beheermodus. Vaak is het een combinatie.
Binnen deze context zijn er niet echt verschillen tussen closed source en open source. Nu we in productie zijn en misschien gaan werken aan release 2, zullen er nieuwe features gebouwd en bugs opgelost moeten worden. Ook komen er van de producten die we gebruiken nieuwe versies, en bugfix releases uit. Hier kan een duidelijk verschil ontstaan tussen open source-producten en closed source. Hier kom ik later nog op terug. We moeten de verschillende producten goed in de gaten houden. Komen er handige nieuwe features uit? Wellicht moeten we de producten updaten.
Afhankelijk van het open source-product kan de handelswijze sterk verschillen. Sommige open source-projecten maken gebruik van heel goed release management, stabiele versies zijn ook daadwerkelijk stabiel en minor/patch releases bevatten geen nieuwe bugs door toch nieuwe features toe te voegen. Zo heb ik goede ervaring met bijvoorbeeld WordPress en Spring Famework. Minder goede ervaring heb ik met bijvoorbeeld Maven. Hier moet je altijd erg oppassen als je een nieuwe minor release download en kun je rare dingen verwachten. Veel problemen ontstaan bij projecten die veel gebruik maken van plug-ins, deze worden vaak niet goed meegenomen in de upgrade-cyclus. Iets waar je dus tijdens het ontwikkelen ook heel erg goed rekening mee moet houden en veel moet testen.
Een ander facet van open source waar je bij stil moet staan is de api van het product. Als een closed source-product de mogelijkheid heeft om er tegen aan te programmeren, gebeurt dit vaak tegen een gedefinieerde api. Deze api wordt goed getest op backwards compatibiliteit. Omdat bij een open source-product alles beschikbaar is wordt de api-grens veelal met voeten getreden. Hierbij loop je met het upgraden een groter risico dat code kapot gaat.
Goed release management van producten heeft ook een nadeel. Het is vaak lastiger om nieuwe features toe te voegen aan releases. De major releases met nieuwe features vinden vaak maar maximaal een paar keer per jaar plaats. Dit is wel het moment dat open source je redding kan zijn. Doordat je de codes hebt en deze vaak zo beschikbaar worden gesteld, is het goed mogelijk om zelf nieuwe features toe te voegen en hoef je niet te wachten op de echte release.
Een mooi voorbeeld hiervan waar we binnen het bedrijf waar ik werk regelmatig mee in contact komen is Solr. Dit is een product dat we bij veel enterprise search-projecten gebruiken. Solr is zo'n open source-project dat niet vaak met nieuwe releases komt maar wel een hele levendige community heeft. Er zijn vele uitbreidingen beschikbaar die je zelf moet bouwen door de code te 'patchen'. Uiteraard is het mogelijk om dit door andere bedrijven te laten doen die daar dan weer support op leveren. Uiteraard brengt dit wel wat risico met zich mee en later wellicht wat meer werk om de patch te vervangen door een echte release die wellicht toch net iets anders is, maar om voorop te lopen moet je soms een beetje pijn accepteren. Dus extra tijd of geld opzij leggen als je dit wilt.
Het teruggeven van uitbreidingen en verbeteringen aan de community kan je helpen bij het verzachten van de pijn bij nieuwe releases. Als je tijdens het project zinvolle dingen hebt gebouwd die voor anderen ook zinvol kunnen zijn, denk er dan aan om deze terug te geven aan de community. Op die manier hoef je zelf minder tijd te besteden aan beheer en wordt je onderdeel van het project.
Aan het eind van een project is het ook tijd voor bezinning. Er zijn een aantal dingen die je na kunt gaan om te leren van beslissingen die je hebt genomen bij de start of gedurende het project. Er zijn een aantal vragen die je moet stellen. Zijn de kosten van het open source-gebruik nu minder geweest dan de licentiekosten die ik anders had moeten betalen? Kan ik nu iemand bellen als ik problemen heb met een product? Ben ik echt flexibeler geweest door gebruik van open source of had het andere product toch alle features die ik nodig had?
