MauriceHendriks
commented
1 year ago Nog een paar feedback punten op de checklist:
Stap 2: Business strategie & plan
4. Bepaal welke deel van je project je wilt open sourcen (welke repositories, inclusief URLs)
Dit is een cirkelredenering. Repositories gaat namelijk al uit van een soort van inner sourcing en gebruik van (git) versie beheer. Dat is lang niet overal zo. Ook gaat het er teveel vanuit dat er al een soort van architectuur ten grondslag ligt aan de opzet van het project en daarmee de mogelijke verdeling in meerdere repositories. Dat is ook niet altijd.
5. Bepaal wie de kosten gaat dragen van voor maintainen van open source project (incl. infrastructuur, open source community support en open source activiteiten)
Ik zou hier gewoon het Nederlands beheer zeggen. Wat ik hier ook nog mis is al het polsen van de samenwerking met anderen.
Stap 3: Juridische beoordeling
1. Check of het open sourcen van je project impact heeft op het intellectueel eigendom van de organisatie
Dit is niet helemaal logisch verwoord. Er verandert niks aan het intellectueel eigendom. Het enige wat je aangeeft is dat je niet auteursrechtelijk gaat handhaven op IE-schendingen. Ik zou hier dus zeggen. Check of er geen auteursrechtelijke belemmeringen zijn voor het verbinden van een open source licentie aan de broncode
2. Bepaal onder welke open source licentie je de code wilt open sourcen.
Suggestie: bepaal welke open source licentie je aan je broncode wil verbinden.
3. Zorg er voor dat je de gekozen open source-licenties goed begrijpt en volledige naleeft
Hier gaat het over meervoudige licenties. Het lijkt me goed dan ook iets te zeggen over dual-licensing.
4. Overweeg of je ook non-software outputs van de community verwacht, zo ja: bepaal onder welke open source licentie je dat wilt open sourcen. Dit kan een andere licentie zijn dan waaronder je code open sourced.
Ik zou hier zeggen: Denk na over de licenties voor andere onderdelen van het project zoals je data, media, visuele elementen etc. Kijk daarin ook naar de licenties die passen bij die vormen zoals creative commons. Maak expliciet of je daar wel of geen bijdragen voor accepteert.
5. Bepaal je nog eventuele handelsmerk gerelateerde besluiten noodzakelijk zijn.
Hier zou dit ook juridischer verwoorden. Suggestie: "Controleer of het merkenrecht nog een belemmering is in het open source publiceren van de broncode."
Stap 4: Technische beoordeling
*1. Verwijder kritische afhankelijkheden met niet-publieke componenten."
Ik zou het hier ook compabiliteit van licenties hebben. Of er geen licentie conflicten zijn.
2. Zorg voor een goede README.MD met use-case voorbeelden.
Ik vind de README ook wel de plek om iets van de implementatie te beschrijven. Software architectuur keuzes.
8. Zorg ervoor dat coding style is consistent
Denglish. Ik vind het altijd prettig als de code stijl normen staan beschreven in de CONTRIBUTING.md
11. Voeg voor een kopie licentie tekst toe aan de root directory (LICENSE).
Ik zou hier nog iets zeggen over dual licensing.
Stap 5: Governance en processen
2. Bepaal wat de roadmap wordt
Ik zou zeggen dat als je voor 3 jaar gelden hebt verzameld je ook wel in een publieke roadmap moet kunnen zeggen wat je epics zijn voor die 3 jaar.
2. Zorg dat het geruik van Developer Certificate or Origin (DCO) wordt afgedwongen.
Typo
Aangepaste versie van lijst die intern in gebruik is bij Alliander. Later uit te breiden met diverse links naar andere pagina's.
Signed-off-by: Nico Rikken nico.rikken@alliander.com