Open sourcen in 3 stappen

2018-04-08

Je kunt broncode open en bloot in een Github gooien waar iedereen het kan downloaden en bewerken. Is dat open sourcen? In theorie, ja, in praktijk, nee. Er komt stiekem nog aardig wat bij kijken. Als iets voor iedereen zichtbaar op het internet komt te staan, wil je toch je beste beentje voort zetten.

Ik heb laatst een generiek stuk code 'geopensourced' (mooi woord). Dat is leuk/interessant om te doen, maar meer werk dan ik van tevoren dacht. In deze blog beschrijf ik in hoofdlijnen waar je in ieder geval aan moet denken bij het opensourcen van een project.

Stap 1: Breng je broncode op orde

Als je wilt dat mensen jouw code gaan gebruiken, dan kan het maar beter op orde zijn. Zorg dan ook dat je volledig achter je broncode durft te staan. Je plaatst het per slot van rekening voor iedereen zichtbaar op het internet. Vraag je dus af:

* Voldoet de code aan alle conventies?

* Is alles netjes voorzien van documentatie waar nodig?

* Is voldoende afgedekt met automatische tests? (En slagen de tests ook?)

Stap 2: Versiebeheer en continuous integration (CI)

De volgende stap is het plaatsen van de broncode. Github is een voor de hand liggende optie, maar Gitlab, Bitbucket of Sourceforge kunnen natuurlijk ook. Kies ook een CI tool. Voor open source is Travis een aardige optie. Bepaal ook de stappen voor CI: welke type tests draai je, moet er gelint worden, wordt er ook iets gecompileerd? Op een rijtje:

* Bepaal je versiebeheer platform, bijvoorbeeld Github;

* Bepaal je CI tool, bijvoorbeeld Travis;

* Bepaal je bouw-stappen (compile, test, lint, ...);

* Schrijf een goede README (hoe te installeren, hoe te bouwen, hoe te gebruiken, ...).

Stap 3: Publiceren in een package registry

Niet strikt noodzakelijk, maar wel aan te bevelen, is het publiceren naar een package registry. Onthoud: software engineers zijn lui, ze willen weinig moeite doen om met jouw project te kunnen werken. Packagemanagers zoals NPM, Pip, Maven of Gem verlagen de drempel om je project te gebruiken. Dus:

* Controleer of jouw project voldoet aan de projectstructuur van de beoogde package registry;

* Bepaal hoe je omgaat met versienummering (major en minor changes);

* Publiceer naar een package registry en controleer of het gelukt is.

 

Zo! Nu kun je achterover leunen. Toch? Nope, meestal vraagt een software project ook onderhoud. Als je pech hebt, wordt jouw project niet gebruikt. Met iets minder pech schieten mensen issues in. En als je geluk hebt, dan sluiten mensen zich bij jou project aan om mee te helpen.

Het gaf mij in elk geval een goed gevoel om te opensourcen. Je geeft ermee iets terug aan de software community waar je zoveel van ontvangen hebt. Daarnaast geeft het een kick als andere mensen van over de hele wereld jouw stukje code kunnen gebruiken. Ik heb met mijzelf afgesproken om vaker te open sourcen! Voor wie nieuwsgierig is, deze blog heb ik gebaseerd op geomodels, een NodeJs/frontend Javascript project.


Bekijk alle posts van Ramon