Beteenden runt öppen källkod

[Stefan Wallin]

Jag vill tipsa lite saker man kan tänka på när man har öppen-källkodsprojekt som kanske inte riktigt fångades i DIGGs policys runt öppen källkod.

Licenser:
Det är välkommet att i varje givet system där källkoden tillgängliggörs märka upp vilken licens som är den som gäller enligt det systemets praxis. Exvis på Github är det kutym med en LICENSE.txt samt att fylla i det i metadata-fältet för repositoriet. På paketsystem som NPM, RubyGems et.c. Så har även de ett metadatafält som ska fyllas i. Detta gör att projekt går att filtrera fram baserat på licenser

Förväntningar och känslor av ”entitlement”

• En bra podd på ämnet: https://kodsnack.se/488/
• Contributor guidelines, ett bra sätt att visa hur vi beter oss, även bra att referera till när man vill stänga issues som är irrelevanta eller otrevliga.
• I Readme’n högst upp skriva förväntningarna som kan has på repot. Hur underhålls det, hur snabbt svaras det i regel. Vilka system testas koden på.
• använda issue templates och där införa visdomen:

”Try to be nice, remember when writing that the maintainers are also human and they do this to best of their abilities”

[jamespether]

Hej,

Finns många aspekter att tänka på när man släppar öppen källkods projekt.

"Open Source Security Foundation (OpenSSF) Best Practices" har skapat kriterier FLOSS Best Practices Criteria (Passing Badge)

Täcker licenser, men även CI och releaser samt andra aspekter.

Exempel från mitt project lCIA best practice

Mvh

[Ainali]

Liknande FLOSS best practices criteria finns även Standard for Public Code, med mer fokus på att möjliggöra samarbete mellan myndigheter.
(För full transparens, jag arbetar med den.)