Hoe maakt u een open-source programma

  • 8 minuten

Hier bespreken we de belangrijkste aandachtspunten voor het maken van een opensource-programma.

Wat bedoelen we met 'opensource?'

Een opensource-programma is meer dan openbare toegang tot een codebasis. Het is een levend project waar u iedereen die eraan wilt werken toegang geeft. Wanneer het goed wordt uitgevoerd voor een geschikt project, kan een opensource-programma bijdragen aan aanzienlijke verbeteringen in de kwaliteit van uw product.

Een van de belangrijkste redenen waarom bedrijven kiezen voor opensource-projecten is dat ze de community willen betrekken. Populaire projecten ontvangen aanzienlijke bijdragen van de community en ze krijgen deze gratis.

De reden hiervoor is niet alleen liefdadigheid. Personen en organisaties gebruiken projecten omdat ze een persoonlijk of zakelijk voordeel bieden. Wanneer het project niet aan hun behoeften of verwachtingen voldoet, kunnen ze de mogelijkheid gebruiken om fouten op te lossen of functies toe te voegen. In plaats van deze verbeteringen terug te houden in privé forks, worden ze gedwongen om deze wijzigingen terug te leveren in de bronopslagplaats om deel uit te maken van de basislijn van het project. Deze waardevolle verbeteringscyclus is waarom veel bedrijven software maken met behulp van het opensource-model.

Opensource-doelstellingen

Kort samengevat zijn er drie dimensies voor deelname aan opensource-software:

  • Consumenten, die de opslagplaatsen van anderen bestuderen of gebruiken.
  • Inzenders, die actief betrokken zijn bij het verbeteren van de opslagplaatsen van anderen.
  • Producenten, die hun eigen opslagplaatsen bouwen en onderhouden die voor anderen openstaan.

Als organisaties dieper nadenken over wat ze van elke dimensie willen, is het een goed idee om te evalueren wat de huidige staat van deze dimensies zijn. Er zijn vijf procesniveaus binnen elke dimensie.

Diagram van opensource-procesniveaus.

  • Ad hoc, waarvoor geen proces is ingesteld. Success is afhankelijk van de afzonderlijke inspanningen.
  • Beheerd, die een gedeeltelijk gedocumenteerde procedure hebben. Success is afhankelijk van discipline.
  • Gedefinieerd, die een gedocumenteerd, gestandaardiseerd en geïntegreerd proces hebben. Success is afhankelijk van automatisering.
  • Gemeten, die een kwantitatief beheerd proces hebben. Succes is afhankelijk van de meting van metrische gegevens ten opzichte van de bedrijfsdoelen.
  • Geoptimaliseerd, die een proces hebben dat voortdurend en betrouwbaar wordt verbeterd door zowel incrementele als innovatieve wijzigingen. Success is afhankelijk van het verminderen van het risico van wijzigingen.

Als u een beter inzicht wilt krijgen in de staat van uw organisatie, raadpleegt u de Opensource-zelfevaluaties.

Wanneer moet u kiezen voor open source?

Veel projecten zijn niet bestemd voor opensource-grootheid. Hoewel uw criteria kunnen variëren op basis van de doelstellingen en het procesniveau van uw bedrijf, zijn hier enkele aanbevolen criteria om rekening mee te houden voordat u een project opent:

  • Bevat uw project intellectueel eigendom dat u wilt beveiligen? Als dit het geval is, kan open source ervoor zorgen dat anderen de waarde hiervan zien. Open source dergelijke projecten niet, tenzij u de voordelen opweegt tegen de risico's.

  • Is het project in een stabiele staat met goede codekwaliteit? Het project hoeft niet perfect te zijn, maar potentiële inzenders kunnen weglopen als het project een slechte vorm heeft om mee te beginnen.

  • Is uw project nuttig voor mensen buiten uw bedrijf? Als dat niet het geval is, krijgt u waarschijnlijk geen deelname.

  • Kunnen personen buiten uw bedrijf bijdragen? Ze hebben toegang nodig tot alle projectafhankelijkheden, buildprocessen en wat er ook nodig is om het project uit te voeren. Als ze het niet kunnen uitvoeren, kunnen ze geen bijdragen leveren.

  • Heeft uw team de bandbreedte voor de ondersteuning van een opensource-programma? Als dat niet zo is, wacht u totdat u dat doet. Als u een opensource-project opent en dit niet ondersteunt, verliest u mogelijk de kans om een vertrouwende community te bouwen.

Deze vragen zijn slechts enkele van de meest voorkomende overwegingen. Uw organisatie kan andere zakelijke of nalevingsproblemen hebben om rekening mee te houden.

Een opensource-programma ontwerpen

Het uitvoeren van een opensource-programma is vergelijkbaar met het uitvoeren van een InnerSource-programma, maar voor een openbare doelgroep. Als gevolg hiervan zijn er nog enkele overwegingen.

Verwachtingen van de community beheren

Bestanden zoals README.md en CONTRIBUTING.md zijn nog belangrijker omdat ze worden blootgesteld aan personen die niet over uw organisatiecontext beschikken. Ze moeten vanuit het perspectief van iemand buiten het bedrijf worden geëvalueerd om duidelijkheid te garanderen.

Daarnaast is uw Gedragscode een belangrijk beleid om te communiceren. De standaardinstelling is om een CODE_OF_CONDUCT.md bestand toe te voegen aan de hoofdmap van uw opslagplaats en dit te gebruiken om het gedrag uit te leggen dat wordt verwacht van deelnemers in uw community. Meerdere groepen in uw organisatie moeten dit document bekijken, inclusief uw juridische team. Gelukkig zijn er veel standaard gedragscodes beschikbaar om te beginnen. Veel projecten gebruiken deze codes ongewijzigd, zonder aanpassingen. Meer informatie in de Gids voor opensource-gedragscodes.

Werknemers voorbereiden voor het onderhouden van een opslagplaats

Werknemers hebben mogelijk geen ervaring met het werken met de opensource-community. Om ze voor te bereiden, raden we aan dat het bedrijf een set handleidingen biedt die de belangrijkste dingen behandelen die iedereen moet weten voordat ze aan de slag gaan. Deze handleidingen moeten worden geplaatst in een interne opslagplaats of portal die regelmatig wordt onderhouden en alleen toegankelijk is voor werknemers van het bedrijf. De volgende handleidingen zijn enkele van de belangrijkste:

  • Een ‘Moet we dit project open source maken?'-hulplijn die een raamwerk biedt voor de beslissing of een kandidaatproject geschikt is voor open source of niet. Deze hulplijn kan worden gestructureerd als een stroomdiagram, een set met vragen of een lijst met overwegingen.

  • Een controlelijst voor installatie met alle werkitems die een team moet voltooien voor en na het starten van een opensource-project. Deze lijst moet bestaan uit het verkrijgen van goedkeuring om het project open source te maken, codebeoordelingen om ervoor te zorgen dat gevoelige gegevens worden verwijderd voordat het project live gaat, een zoekopdracht over het opensource-project of handelsmerk om er zeker van te zijn dat er geen naamconflict is, enzovoort.

  • Een lijst met contactpersonen voor belangrijke personen in uw organisatie die mogelijk contact moeten opnemen als directe ondersteuning van de onderhouders vereist is. Deze lijst moet personen bevatten uit softwarebeveiliging, sitebeveiliging, juridisch, public relations, enzovoort.

  • Een koppeling naar een startopslagplaats die kan worden gekloond als uitgangspunt. Deze opslagplaats moet een voorbeeld-README, licentie, gedragscode, inzendershulplijn en andere ondersteunende bestanden bevatten die elk opensource-project van uw bedrijf moet hebben. Het mag geen items bevatten die u niet per ongeluk naar een openbare doelgroep zou willen pushen.

  • Een hulplijn voor onderhoud waarin de verantwoordelijkheden worden uitgelegd die een beheerder heeft om de opslagplaats in orde te houden. Deze verantwoordelijkheden omvatten het up-to-date houden van opslagplaatsdocumentatie, ervoor zorgen dat problemen en pull-aanvragen tijdig de aandacht krijgen van de juiste personen, enzovoort.

  • Een communicatiehandleiding met richtlijnen voor het onderhouden van opslagplaatsen voor een aantal onderwerpen die u liever niet wilt opnemen in openbare bestanden, zoals README.md, CONTRIBUTING.mdof CODE_OF_CONDUCT.md. Deze onderwerpen kunnen gevoelige zakelijke onderwerpen zijn, zoals het niet bespreken van concurrenten; of meer algemene onderwerpen, zoals het op de juiste manier herkennen van de belangrijkste inzenders.

  • Een interne veelgestelde vragen die goedgekeurde antwoorden biedt op veelgestelde vragen. Deze lijst is vooral handig als er juridische subtiliteiten zijn voor de onderwerpen die uw bedrijf kan bespreken tijdens het onderhouden van een opensource-programma.

  • Een licentiebeleid dat vermeldt welke licenties zijn goedgekeurd of afgekeurd door de juridische afdeling voor opensource-verbruik of -bijdragen.