Het “wat” en “waarom” van open source

Dus je denkt erover om aan de slag te gaan met open source? Gefeliciteerd! De wereld waardeert uw bijdrage. Laten we het hebben over wat open source is en waarom mensen het doen.

Wat betekent “open source”?

Als een project open source is, betekent dit dat iedereen vrij is om uw project voor elk doel te gebruiken, bestuderen, wijzigen en distribueren. Deze machtigingen worden afgedwongen via een open source-licentie.

Open source is krachtig omdat het de barrières voor acceptatie en samenwerking verlaagt, waardoor mensen projecten snel kunnen verspreiden en verbeteren. Ook omdat het gebruikers de mogelijkheid geeft om hun eigen computergebruik te beheersen, in vergelijking met closed source. Een bedrijf dat open source software gebruikt, heeft bijvoorbeeld de mogelijkheid om iemand in te huren om aangepaste verbeteringen aan de software aan te brengen, in plaats van uitsluitend te vertrouwen op de productbeslissingen van een closed source-leverancier.

Vrije software (Free software) verwijst naar dezelfde reeks projecten als open source. Soms zie je ook deze termen gecombineerd als “free en open source software” (FOSS) of “free, libre en open source software” (FLOSS). Free en libre verwijzen naar vrijheid, niet de prijs.

Waarom stellen mensen hun werk als open source beschikbaar?

Er zijn veel redenen waarom een persoon of organisatie een project zou willen open source maken. Enkele voorbeelden zijn:

  • Samenwerking: Open source-projecten kunnen wijzigingen van iedereen ter wereld accepteren. Exercism is bijvoorbeeld een oefenplatform voor programmeren met meer dan 350 medewerkers.

  • Adoptie en remixen: Open source-projecten kunnen door iedereen voor bijna elk doel worden gebruikt. Mensen kunnen er zelfs andere dingen mee bouwen. WordPress is bijvoorbeeld begonnen als een splitsing van een bestaand project met de naam b2.

  • Transparantie: Iedereen kan een open source-project inspecteren op fouten of inconsistenties. Transparantie is belangrijk voor regeringen zoals Bulgarije of de Verenigde Staten, gereguleerde industrieën zoals het bankwezen of de gezondheidszorg, en beveiligingssoftware zoals Let’s Encrypt.

Open source is niet alleen voor software. U kunt alles openen, van datasets tot boeken. Bekijk GitHub Explore voor ideeën over wat je nog meer kunt open source.

Betekend open source gratis?

Een van de grootste voordelen van open source is dat het geen geld kost. “Gratis” is echter een bijproduct van de totale waarde van open source.

Omdat een open source-licentie vereist dat iedereen uw project voor bijna elk doel kan gebruiken, wijzigen en delen, zijn projecten zelf meestal gratis. Als het project geld kost om te gebruiken, kan iedereen legaal een kopie maken en in plaats daarvan de gratis versie gebruiken.

Als gevolg hiervan zijn de meeste open source-projecten gratis, maar ‘gratis’ maakt geen deel uit van de open source-definitie. Er zijn manieren om indirect kosten in rekening te brengen voor open source-projecten via dubbele licenties of beperkte functies, terwijl ze toch voldoen aan de officiële definitie van open source.

Moet ik mijn eigen open source-project lanceren?

Het korte antwoord is ja, want wat de uitkomst ook is, het starten van je eigen project is een geweldige manier om te leren hoe open source werkt.

Als je nog nooit een project hebt geopend, ben je misschien zenuwachtig over wat mensen zullen zeggen, of dat iemand het überhaupt zal opmerken. Als dit klinkt zoals jij, ben je niet de enige!

Open source werken is net als elke andere creatieve activiteit, of het nu gaat om schrijven of schilderen. Het kan eng aanvoelen om je werk met de wereld te delen, maar de enige manier om beter te worden, is door te oefenen - zelfs als je geen publiek hebt.

Als u nog niet overtuigd bent, neem dan even de tijd om na te denken over uw doelen.

Je doelen stellen

Doelen kunnen u helpen erachter te komen waaraan u moet werken, waar u nee tegen moet zeggen en waar u hulp van anderen nodig heeft. Begin met jezelf af te vragen: waarom ben ik open source voor dit project?

Er is geen goed antwoord op deze vraag. Mogelijk hebt u meerdere doelen voor een enkel project, of verschillende projecten met verschillende doelen.

Als het je enige doel is om met je werk te pronken, wil je misschien niet eens bijdragen, en dat zeg je zelfs in je README. Aan de andere kant, als u donateurs wilt, investeert u tijd in duidelijke documentatie en zorgt u ervoor dat nieuwkomers zich welkom voelen.

Naarmate uw project groeit, heeft uw gemeenschap mogelijk meer nodig dan alleen code van u. Reageren op problemen, code herzien en uw project promoten, zijn allemaal belangrijke taken in een open source-project.

Hoewel de hoeveelheid tijd die u aan niet-coderende taken besteedt, afhangt van de omvang en reikwijdte van uw project, moet u als onderhouder erop voorbereid zijn om ze zelf aan te pakken of iemand te zoeken om u te helpen.

Als u deel uitmaakt van een bedrijf dat een project opent, zorg ervoor dat uw project over de interne middelen beschikt die het nodig heeft om te gedijen. U wilt weten wie verantwoordelijk is voor het onderhoud van het project na de lancering, en hoe u die taken met uw community deelt.

Als u een specifiek budget of personeel nodig heeft voor promotie, operaties en het onderhouden van het project, begin die gesprekken dan vroeg.

Bijdragen aan andere projecten

Als het uw doel is om te leren samenwerken met anderen of om te begrijpen hoe open source werkt, overweeg dan om bij te dragen aan een bestaand project. Begin met een project dat je al gebruikt en waar je van houdt. Bijdragen aan een project kan zo simpel zijn als het corrigeren van typefouten of het bijwerken van documentatie.

Als u niet zeker weet hoe u als bijdrager aan de slag kunt gaan, bekijk dan onze Hoe u kunt bijdragen aan Open Source-gids.

Uw eigen open source-project lanceren

Er is geen perfect moment om uw werk open source te maken. U kunt een idee openen, een werk in uitvoering of na jarenlang closed source te zijn geweest.

Over het algemeen moet u uw project openen als u zich op uw gemak voelt als anderen uw werk bekijken en er feedback op geven.

Ongeacht in welke fase u besluit uw project te openen, elk project moet de volgende documentatie bevatten:

Als open source-onderhouder helpen deze componenten u bij het communiceren van verwachtingen, het beheren van bijdragen en het beschermen van ieders wettelijke rechten (inclusief die van uzelf). Ze vergroten uw kansen op een positieve ervaring aanzienlijk.

Als je project op GitHub staat, zal het plaatsen van deze bestanden in je root-directory met de aanbevolen bestandsnamen GitHub helpen ze te herkennen en automatisch aan je lezers te laten zien.

Een licentie kiezen

Een open source-licentie garandeert dat anderen uw project zonder repercussies kunnen gebruiken, kopiëren, wijzigen en eraan kunnen bijdragen. Het beschermt je ook tegen plakkerige juridische situaties. U moet een licentie toevoegen wanneer u een open source-project start.

Juridisch werk is niet leuk. Het goede nieuws is dat u een bestaande licentie kunt kopiëren en in uw repository kunt plakken. Het duurt maar een minuut om uw harde werk te beschermen.

MIT, Apache 2.0 en GPLv3 zijn de meest populaire open source licenties, maar er zijn andere opties om uit te kiezen.

Wanneer u een nieuw project op GitHub maakt, krijgt u de mogelijkheid om een ​​licentie te selecteren. Als u een open source-licentie opneemt, wordt uw GitHub-project open source.

Kies een licentie

Als u andere vragen of opmerkingen heeft over de juridische aspecten van het beheren van een open source-project, wij hebben u gedekt.

Een README schrijven

README’s doen meer dan alleen uitleggen hoe u uw project kunt gebruiken. Ze leggen ook uit waarom uw project ertoe doet en wat uw gebruikers ermee kunnen doen.

Probeer in je README de volgende vragen te beantwoorden:

  • Wat doet dit project?
  • Waarom is dit project nuttig?
  • Hoe begin ik eraan?
  • Waar kan ik meer hulp krijgen als ik die nodig heb?

U kunt uw README gebruiken om andere vragen te beantwoorden, zoals hoe u omgaat met bijdragen, wat de doelen van het project zijn en informatie over licenties en attributie. Als u geen bijdragen wilt accepteren, of uw project is nog niet klaar voor productie, schrijf deze informatie dan op.

Soms vermijden mensen het schrijven van een README omdat ze het gevoel hebben dat het project niet af is, of omdat ze geen bijdragen willen. Dit zijn allemaal hele goede redenen om er een te schrijven.

Voor meer inspiratie, probeer @dguo’s “Maak een README”-gids of @PurpleBooth’s README-sjabloon om een volledige README te schrijven.

Als je een README-bestand opneemt in de root-directory, zal GitHub het automatisch op de startpagina van de repository weergeven.

Schrijven van uw bijdrage richtlijnen

Een CONTRIBUTING-bestand vertelt uw publiek hoe ze aan uw project kunnen deelnemen. U kunt bijvoorbeeld informatie opnemen over:

Naast technische details is een CONTRIBUTING-bestand een gelegenheid om uw verwachtingen voor bijdragen te communiceren, zoals:

  • De soorten bijdragen die u zoekt
  • Uw roadmap of visie voor het project
  • Hoe bijdragers wel of niet contact met u moeten opnemen

Het gebruik van een warme, vriendelijke toon en het aanbieden van specifieke suggesties voor bijdragen (zoals het schrijven van documentatie of het maken van een website) kan ertoe bijdragen dat nieuwkomers zich welkom en enthousiast voelen om deel te nemen.

Bijvoorbeeld: Active Admin start zijn bijdragende gids met:

Allereerst bedankt dat u overweegt om bij te dragen aan Active Admin. Het zijn mensen zoals jij die Active Admin tot zo’n geweldig hulpmiddel maken.

In de vroegste stadia van uw project kan uw CONTRIBUTING-bestand eenvoudig zijn. U moet altijd uitleggen hoe u bugs of problemen met bestanden meldt, en welke technische vereisten (zoals tests) u heeft om een bijdrage te leveren.

Na verloop van tijd kunt u andere veelgestelde vragen aan uw CONTRIBUTING-bestand toevoegen. Als u deze informatie opschrijft, zullen minder mensen u keer op keer dezelfde vragen stellen.

Voor meer hulp bij het schrijven van je CONTRIBUTING-bestand, ga je naar @nayafia’s sjabloon voor bijdrage gids of @mozilla’s “Bouw een CONTRIBUTING.md workshop”.

Link naar uw BIJDRAGEN-bestand vanuit uw README, zodat meer mensen het kunnen zien. Als je het CONTRIBUTING-bestand in de repository van je project plaatst, zal GitHub automatisch naar je bestand linken wanneer een bijdrager een issue maakt of opent een pull-verzoek.

Contributing guidelines

Opstellen van een gedragscode

Ten slotte helpt een gedragscode om basisregels vast te stellen voor het gedrag van de deelnemers aan uw project. Dit is vooral waardevol als u een open source-project start voor een gemeenschap of bedrijf. Een gedragscode stelt je in staat om gezond, constructief gemeenschapsgedrag te faciliteren, wat je stress als onderhouder zal verminderen.

Raadpleeg voor meer informatie onze Gedragscode-gids.

Naast het communiceren van hoe je verwacht dat deelnemers zich gedragen, beschrijft een gedragscode ook vaak op wie deze verwachtingen van toepassing zijn, wanneer ze van toepassing zijn en wat te doen bij een overtreding.

Net als bij open source-licenties, zijn er ook nieuwe normen voor gedragscodes, zodat u deze niet zelf hoeft te schrijven. De Bijdrager Covenant is een drop-in gedragscode die wordt gebruikt door meer dan 40.000 open source-projecten, inclusief Kubernetes, Rails en Swift. Welke tekst u ook gebruikt, u moet bereid zijn om uw gedragscode waar nodig af te dwingen.

Plak de tekst rechtstreeks in een CODE_OF_CONDUCT-bestand in uw repository. Bewaar het bestand in de root-directory van je project zodat het gemakkelijk te vinden is, en link ernaar vanuit je README.

Geef uw project een naam en branding

Branding is meer dan een flitsend logo of pakkende projectnaam. Het gaat erom hoe u over uw project praat en wie u bereikt met uw bericht.

De juiste naam kiezen

Kies een naam die gemakkelijk te onthouden is en idealiter een idee geeft van wat het project doet. Bijvoorbeeld:

  • Sentry controleert apps op crashrapportage
  • Thin is een snelle en eenvoudige Ruby-webserver

Als u voortbouwt op een bestaand project, kan het gebruik van hun naam als voorvoegsel helpen verduidelijken wat uw project doet (bijvoorbeeld node-fetch brengt window.fetch naar Node.js).

Overweeg vooral duidelijkheid. Woordspelingen zijn leuk, maar onthoud dat sommige grappen mogelijk niet vertalen naar andere culturen of mensen met andere ervaringen dan jij. Sommige van uw potentiële gebruikers kunnen werknemers van het bedrijf zijn: u wilt ze niet ongemakkelijk maken als ze uw project op het werk moeten uitleggen!

Naamconflicten vermijden

Controleer op open source-projecten met een vergelijkbare naam, vooral als je dezelfde taal of hetzelfde ecosysteem deelt. Als uw naam overlapt met een populair bestaand project, kunt u uw publiek in verwarring brengen.

Als u wilt dat een website, Twitter-handle of andere eigenschappen uw project vertegenwoordigen, zorg er dan voor dat u de gewenste namen krijgt. Idealiter reserveer deze namen nu voor gemoedsrust, zelfs als u ze nog niet wilt gebruiken.

Zorg ervoor dat de naam van uw project geen inbreuk maakt op handelsmerken. Een bedrijf kan u vragen om uw project later stop te zetten, of zelfs juridische stappen tegen u ondernemen. Het is het risico gewoon niet waard.

U kunt de WIPO Global Brand Database raadplegen voor handelsmerkconflicten. Als u bij een bedrijf werkt, is dit een van de dingen waarmee uw juridische team u kan helpen.

Voer tot slot een snelle Google-zoekopdracht uit naar uw projectnaam. Zullen mensen uw project gemakkelijk kunnen vinden? Verschijnt er iets anders in de zoekresultaten waarvan u niet wilt dat ze het zien?

Hoe u schrijft (en codeert), heeft ook invloed op uw merk!

Gedurende de levensduur van uw project zult u veel schrijven: README’s, tutorials, gemeenschapsdocumenten, reageren op problemen, misschien zelfs nieuwsbrieven en mailinglijsten.

Of het nu gaat om officiële documentatie of een informele e-mail, uw schrijfstijl maakt deel uit van het merk van uw project. Bedenk hoe u op uw publiek zou kunnen overkomen en of dat de toon is die u wilt overbrengen.

Het gebruik van warme, inclusieve taal (zoals ‘zij’, zelfs als je naar de enige persoon verwijst), kan er voor zorgen dat je project een welkom gevoel krijgt bij nieuwe bijdragers. Blijf bij eenvoudige taal, aangezien veel van uw lezers mogelijk geen moedertaalsprekers Engels zijn.

Naast hoe u woorden schrijft, kan uw codeerstijl ook onderdeel worden van het merk van uw project. Angular en jQuery zijn twee voorbeelden van projecten met rigoureuze coderingsstijlen en richtlijnen.

Het is niet nodig om een stijlgids voor je project te schrijven als je net begint, en het kan zijn dat je het toch leuk vindt om verschillende codeerstijlen in je project op te nemen. Maar u moet anticiperen op hoe uw schrijf- en coderingsstijl verschillende soorten mensen zou kunnen aantrekken of ontmoedigen. De vroegste stadia van uw project zijn uw kans om het precedent te scheppen dat u wenst te zien.

Uw checklist vóór de lancering

Klaar om uw project te openen? Hier is een checklist om te helpen. Alle vakjes aanvinken? Je bent klaar om te gaan! Klik op “publiceren” en geef jezelf een schouderklopje.

Documentatie

Code

Mensen

Als je een individu bent:

Als u een bedrijf of organisatie bent:

Je hebt het gedaan!

Gefeliciteerd met het openen van uw eerste project. Ongeacht de uitkomst, werken in het openbaar is een geschenk voor de gemeenschap. Met elk commit-, commentaar- en pull-verzoek creëer je kansen voor jezelf en voor anderen om te leren en te groeien.