♻️ Genbrugs-kriterier for Open Source

✅ Hvordan du gør dit projekt nemt at finde, forstå og genbruge – 3 hurtige trin

1️⃣ Strategi og rammer

• Afklar behov og mål (DIGST Vejledning om open source)
• Vælg åben licens og delingsstrategi (DIGST Tjekliste til Standard for Offentlig Kode (PDF))
• Lav markedsafdækning og TCO‑vurdering (DIGST Strategier for genbrug og fællesudvikling)

2️⃣ Design og governance

• Etabler governance og roller (OS2 Governance-model)
• Planlæg brugerinddragelse og tilgængelighed (FAIR-USE4OS Guidelines)
• Garanter bæredygtighed og finansiering over tid (OS2 Governance-rapport skabelon)

3️⃣ Leverance og genbrug

• Byg åbent med åbne standarder (Standard for Public Code)
• Dokumentér kode, test og review (GitHub Open Source Guide)
• Gør løsningen findbar og inviter bidrag (opensource.guide – Building welcoming communities)
• Vedligehold roadmap og community (OS2 GitHub)

Spørgsmål og svar

❓ Hvad skal man tjekke for, når man offentliggør koden?

✅ Hold koden ren for adgangsoplysninger og miljøspecifikke filer
Inden I offentliggør koden, skal I sikre, at der ikke ligger nogen form for data i repoet, som kan være følsomme, miljøspecifikke eller irrelevante for andre brugere.

📌 Best practice:
  - Brug miljøvariabler til konfiguration – ingen adgangsoplysninger i koden
  - Tilføj en eksempelfil som `config.example.env` og dokumenter hvordan den anvendes
  - Brug `.gitignore` til at udelukke `.env`, `config.*`, `*.log`, `.pem` osv.
  - Dokumentér i `README.md`, hvordan man opsætter miljøet lokalt

🚫 Undgå:
  - Følsomme oplysninger og credentials: API-nøgler, tokens, brugernavne, adgangskoder
  - Miljøspecifikke filer: Produktionskonfigurationer, interne URL’er, IP-adresser
  - Data og logfiler: Produktionsdata, testdata med rigtige oplysninger
  - Intern kontekst: Referencer til interne systemer eller dokumentation
  - Midlertidige filer: Lokale udviklingsfiler, cache, build-artifacts

✅ Men inkluder gerne:
  - Syntetiske eller anonymiserede data til eksempler og tests
  - Eksempelfiler til konfiguration, f.eks. `config.example.env`
  - Dokumentation for hvordan man selv tilføjer konfiguration
  

❓ Hvilke tests skal man lave?

✅ Automatiske tests og dokumenteret testmiljø øger kvaliteten
For at sikre at softwaren fungerer som forventet – både nu og i fremtiden – bør der være automatiske tests og en klar beskrivelse af testmiljøet.

📌 Best practice:
  - Automatiske tests med CI-værktøjer som GitHub Actions eller GitLab CI
  - Linting og formattering med IDE eller CI
  - Enhedstests og integrationstests – gerne med input fra brugere
  - Dokumentér teststrategi og testdata i `tests/` eller `README.md`
  - Inkluder eksempelfiler til testmiljøopsætning

🚫 Undgå:
  - Tests der afhænger af interne systemer eller netværk

✅ Men inkluder gerne:
  - CI-konfiguration: f.eks. `.github/workflows/test.yml`
  - Eksempler på testkommandoer i `README.md` eller `CONTRIBUTING.md`
  - Syntetiske testdata til realistiske scenarier
  

❓ Hvilken dokumentation skal man tilknytte?

✅ God dokumentation gør projektet lettere at forstå og genbruge
Dokumentation er en nøglekomponent i open source-projekter – både for nye brugere og for genbrug.

📌 Best practice:
  - Inkluder altid en README.md med introduktion og brug
  - Vis konkrete eksempler på anvendelse
  - Beskriv miljøopsætning og nødvendige variabler
  - Tilføj templates til udrulning med åbne værktøjer

🚫 Undgå:
  - Ufuldstændig eller forældet dokumentation
  - Antagelser om intern viden
  - Dokumentation i lukkede systemer eller proprietære formater

✅ Men inkluder gerne:
  - Diagrammer og arkitekturtegninger (f.eks. Mermaid)
  - Links til relevante issues eller diskussioner
  - En `CONTRIBUTING.md` med bidragsvejledning
  

❓ Hvor skal man offentliggøre det?

✅ Brug åbne og tilgængelige platforme
For at sikre at din kode er nem at finde og bidrage til, bør du bruge en platform med versionsstyring og samarbejdsværktøjer.

📌 Best practice:
  - Brug GitHub, GitLab, Codeberg eller SourceHut
  - Gør projektet offentligt
  - Tilføj en open source-licens (MIT, Apache 2.0, GPL)
  - Brug README.md som landing page

🚫 Undgå:
  - Lukkede platforme eller interne systemer
  - At offentliggøre uden README, licens eller dokumentation
  - Platforme uden versionsstyring (f.eks. Google Drive)

✅ Men inkluder gerne:
  - Link til repoet i artikler, præsentationer eller dokumenter
  - `CONTRIBUTING.md` og `CODE_OF_CONDUCT.md` for bidrag
  

---

Baggrundsmateriale

🏛 DIGST	🤝 OS2	🫶 FAIR-USE4OS	📖 Foundation for Public Code	🌍 Open Source Guide
📖 DIGST Vejledning om open source	📋 OS2-Governancemodel	💓 FAIR-USE4OS Guidelines	🥇 Standard for Public Code	🧑‍🤝‍🧑 Community-drevet guide til open source