Hoe maak je een open source cms?

Open Source CMS

De meeste mensen gebruiken er één. Maar hoe werkt dat nou achter de schermen, zo’n open source? Hoe ontwikkel je nieuwe versies? Hoe manage je de mensen die er vrijwillig aan bijdragen? En betekent open ook dat iedereen die wil er maar aan kan gaan klussen?

Laten wij nou niet alleen bouwen met Bolt, we klussen ook mee aan Bolt. Kunnen we mooi een tipje van de sluier oplichten. Inclusief wat mooie kleurrijke uitdrukkingen!

2021-01/dummies

Waarom kiezen mensen voor open source?

Vaak omdat het gratis is. Of juist omdat bij de grotere open source CMS-en er veel mensen zijn die de kennis hebben om ermee te werken. Bij (semi-)overheidsinstellingen is het gebruik van open source materiaal tegenwoordig zelfs een vereiste: zo blijft het beheersbaar.  

Bovendien is het risico vrij laag dat plotseling ‘de stekker eruit gaat’. Bijvoorbeeld vanwege de overname door een concurrent. Of simpelweg omdat een commercieel bedrijf besluit dat het niet rendabel genoeg meer is en stopt met ondersteunen. Als jij dan net een bak geld aan je site hebt uitgegeven ben je op zijn zachtst gezegd niet blij dat je met een ander CMS opnieuw moet beginnen.  

En als er dingen stuk gaan na bijvoorbeeld een browserupdate of de beveiligingsgaten erin vallen zit je helemaal met de gebakken peren.  

Maar het gebeurt ook bij open source dat de site herbouwd moet worden omdat er een nieuwe versie komt.

Klopt. Dat heet ‘End Of Life’ (EOL) van een versie. Klinkt heftig (ook developers kunnen zich heel dramatisch en poëtisch uitdrukken), maar het betekent gewoon dat het team op een gegeven moment ophoudt met het updaten van een oudere versie. Het is onvermijdelijk, alleen al omdat de techniek en de apparatuur zo razendsnel veranderen. Je kan niet pleisters blijven plakken.

Maar EOL kondigen ze doorgaans ruimschoots van tevoren aan. Van Drupal kreeg je bijvoorbeeld meer dan 3 jaar de tijd om afscheid te nemen van Drupal 7. Dat is riant, toch? En er staat dan al minstens één volgende versie voor je klaar. Zo niet twee.

Wie werken er dan aan zo’n nieuwe versie?

Een flink team vrijwilligers. Vaak bieden mensen aan om mee te helpen omdat ze of al met Bolt werken, of ermee willen gaan werken. Aan de ene kant is dat prettig: vele handen maken licht werk. Aan de andere kant maakt dat het ook lastig. Omdat je aangewezen bent op de goodwill van mensen, je kan ze niet dwingen om iets af te maken, zich aan deadlines te houden of überhaupt iets op te pakken.

Hoe houd je zoiets in bedwang met zoveel mensen?

Er is een kernteam: mensen die al langere tijd regelmatig bijdragen leveren. En iemand moet toch een beetje de kartrekker zijn: binnen het kernteam draagt onze Bob de ietwat dubieuze eretitel BDFL. Benevolent Dictator For Life.

Daarnaast heb je een roadmap (https://roadmap.boltcms.io/) waarop alle klussen staan. In principe kan iedereen zijn hand opsteken en aangeven wat hij of zij daarvan kan en wil oppakken.

Werk je dan allemaal tegelijk aan het systeem?

Ja en nee. Er wordt door meerdere mensen tegelijk aan verschillende features gewerkt, maar dat kan natuurlijk niet allemaal tegelijk direct in de code. Je maakt eerst een kopie van Bolt op de eigen werkomgeving en daar ga je in werken. Heb je een brokje code af, dan maak je een ‘pull request’, een verzoek aan de eigenaar van de code om jouw stukje van de code op te nemen in het totaalpakket. Daar gebruiken we github voor. Dat geeft het kernteam meteen de kans om na te kijken of alles wel goed aansluit en helpt om bij te houden wat er van de roadmap al is gemaakt.

Wordt alles from scratch gemaakt?

Als het aan veel developers ligt wel, ja! Dat heet het ‘Not Invented Here syndroom’: zelf maken is leuker (en ze denken altijd dat het beter kan), dus ze gaan liever het wiel opnieuw uitvinden. Aan het kernteam om de al te enthousiaste doe-het-zelvers terug te fluiten en te kijken of er al iets bestaat dat prima functioneert.  

Bestaande componenten hebben namelijk een veel groter draagvlak. Dus als een developer om welke reden dan ook stopt met bijdragen aan de ontwikkeling van het open source product, is het veel makkelijker over te nemen.

Stel: je bent een website aan het maken. Een klant wil iets dat niet binnen het CMS bestaat. Kan je dat zomaar maken?

Dat kan. Zeker vanaf Bolt 4 omdat dat echt een pure Symfony applicatie is: iedereen die Symfony beheerst kan er een extensie voor bouwen. Wil je dat andere mensen daar ook gebruik van kunnen maken dan kan dat op twee manieren.

  1. Je kan dat als een open source extensie aanbieden op de marktplaats van Bolt, https://extensions.boltcms.io/.
  2. Of je kan jouw werk via een pull request laten opnemen in de volgende versie van Bolt.

Maar niet alles wordt zomaar geaccepteerd. Wat jij maakt moet wel aansluiten bij de kernwaarden van Bolt. Bovendien wil je ‘feature creep’ voorkomen: een wildgroei aan uitbreidingen. Voor iedere naar wens gemaakte feature die je toevoegt zijn er ook mensen die het niet nodig hebben. Dat maakt iedere volgende versie onnodig gecompliceerd voor een steeds grotere groep mensen.

Daarom hebben we er expliciet voor gekozen om van Bolt4 een Symfony app te maken zodat je binnen elk project eigen code kan gebruiken. Zo kan je met maatwerk je klant bedienen, en blijft de basis eenvoudig en schoon.

Tot slot: Verdient het nou iets?

Nou… Nee. Niet echt. Bolt heeft weliswaar nu een sponsordeal in Github, maar er zijn echt maar een paar mensen die daarvan kunnen rondkomen. Het komt erop neer dat mensen ons een maandelijkse bijdrage kunnen geven als ze vinden dat we harder moeten werken. Dat gaat deels op een hele ludieke manier. Je kan bijvoorbeeld brandstof kopen voor de developers – dat is koffie of bier, afhankelijk van het tijdstip. Voor de grotere abonnementen plaatsen we je bedrijfslogo /sponsorship op de "about" of voorpagina van de Bolt site.

Het betaalt de treinkaartjes naar de presentaties praatjes. En de stickers. En de server waar de Bolt site op staat. Maar als begin is het erg leuk! Wie het kleine niet eert…

Andere blogs