OS2/ai-heatcontrol

Fork 0

Afklare budgetmæssige og strategiske konsekvenser af digital suverænitet, maintainer-rolle og proprietære løsninger #55

New issue

Open

opened 2026-08-19 09:35:22 +00:00 by JakobNoerby · 1 comment

JakobNoerby commented

2026-08-19 09:35:22 +00:00

(Migrated from github.com)

Kilde: Projektmøde 18.08.2026

Ansvarlig: Styregruppen

Deadline: Uafklaret

Baggrund

På projektmødet den 18.08.2026 blev det opdaterede budget gennemgået med særligt fokus på vedligeholdelse, teknisk forvaltning og maintainer-rolle.

Der er flyttet budget fra ekstern projektleder til maintainer-rolle for at sikre en mere effektiv teknisk forvaltning af projektet, og få kompetencer ind i projektet der er uafhængige og i højere grad kan sikre digital suverænitet.

Samtidig er der behov for, at styregruppen drøfter de budgetmæssige og strategiske konsekvenser af forskellige løsningsmodeller for OS2 AI Heat Control. Det gælder særligt balancen mellem:

Digital suverænitet
Open source-governance
Leverandøruafhængighed
Drift og vedligehold
Eventuel anvendelse af proprietære løsninger
Mulighed for senere flerleverandørsetup

Hvis projektet vælger en samlet løsning hos én leverandør eller en løsning, der bygger tæt oven på eksisterende platforme eller leverandørspecifik infrastruktur, kan det have betydning for projektets fremtidige ejerskab, fleksibilitet og exit-muligheder.

Styregruppen skal derfor afklare, hvilket ambitionsniveau projektet skal have i forhold til digital suverænitet, open source, teknisk ejerskab og eventuel binding til proprietære løsninger.

Opgave

Styregruppen skal drøfte og afklare de budgetmæssige og strategiske konsekvenser af projektets tekniske og organisatoriske valg.

Drøftelsen bør som minimum omfatte:

Hvilket ambitionsniveau projektet skal have for digital suverænitet?
Om projektet ønsker at eje og kunne videreudvikle centrale dele af løsningen selv
Om projektet accepterer binding til én leverandør og/eller én bestemt driftsplatform
Om en væg-til-væg-løsning er forenelig med projektets open source-ambition
Om løsningen senere kan understøtte flere leverandører, algoritmer og integrationer
Hvilke omkostninger der realistisk skal afsættes til drift, vedligehold, governance og teknisk kvalitetssikring
Om budgettet afspejler de reelle omkostninger ved open source-forvaltning
Om projektet skal udarbejde scenarier for lav, middel og høj grad af digital suverænitet

Centrale afklaringsspørgsmål

1. Leverandørbinding

Hvis projektet vælger en samlet løsning hos én leverandør, skal det afklares, om løsningen reelt kan drives, vedligeholdes og videreudvikles af andre leverandører senere.

2. Driftsmodel

Det skal afklares, om budgettet til drift og vedligeholdelse skal indeholde antagelser om bestemt cloudplatform, infrastruktur, afhængighed til eksisterende platforme eller leverandørspecifikke komponenter.

3. Flerleverandørsetup

Det skal vurderes, om den ønskede arkitektur skal kunne understøtte, at andre leverandører senere kan udvikle algoritmer, integrationer eller driftskomponenter.

4. Digital suverænitet

Styregruppen skal tage stilling til, om digital suverænitet er et centralt projektmål, eller om projektet accepterer en højere grad af afhængighed af proprietære løsninger for at reducere kortsigtede omkostninger og kompleksitet.

5. Vedligehold og teknisk forvaltning

Styregruppen skal drøfte, hvor stor en del af projektets økonomi der bør reserveres til vedligehold, governance, dokumentation og teknisk forvaltning frem for alene nyudvikling.

Foreslåede scenarier til drøftelse

Scenarie 1: Lav grad af digital suverænitet

Projektet vælger en væg-til-væg-løsning hos én leverandør og accepterer i højere grad binding til leverandørens arkitektur, infrastruktur og driftsmodel.

Mulige fordele

Hurtigere etablering
Lavere kompleksitet på kort sigt
Én tydelig leverandør med samlet ansvar

Mulige ulemper

Risiko for leverandørbinding
Svagere exit-strategi
Mindre fleksibilitet for senere algoritmer og integrationer
Mindre reel open source-governance

Scenarie 2: Balanceret model

Projektet anvender åbne standarder, open source-principper og en maintainer-rolle, men accepterer proprietære komponenter eller én primær driftsleverandør, hvor det er praktisk og økonomisk hensigtsmæssigt.

Mulige fordele

Balance mellem fremdrift og ejerskab
Mulighed for gradvis modning af open source-governance
Reduceret risiko for overkompleksitet

Mulige ulemper

Kræver tydelige arkitekturbeslutninger
Risiko for uklar grænse mellem fælles OS2-produkt og leverandørspecifik løsning
Kræver aktiv teknisk forvaltning

Scenarie 3: Høj grad af digital suverænitet

Projektet prioriterer åben arkitektur, flerleverandørsetup, uafhængig maintainer, dokumentation, governance og tydelig exit-strategi.

Mulige fordele

Større leverandøruafhængighed
Bedre langsigtet ejerskab
Stærkere open source-produkt
Bedre mulighed for genbrug på tværs af kommuner og leverandører

Mulige ulemper

Højere omkostninger til teknisk forvaltning
Større behov for governance og kompetencer
Kan give langsommere fremdrift i opstartsfasen

**Kilde**: [Projektmøde 18.08.2026](https://github.com/OS2sandbox/ai-heatcontrol/blob/JakobNoerby-patch-23/projektadministration/m%C3%B8der/pm8.md) **Ansvarlig**: Styregruppen **Deadline**: Uafklaret ### Baggrund På projektmødet den 18.08.2026 blev det opdaterede budget gennemgået med særligt fokus på vedligeholdelse, teknisk forvaltning og maintainer-rolle. Der er flyttet budget fra ekstern projektleder til maintainer-rolle for at sikre en mere effektiv teknisk forvaltning af projektet, og få kompetencer ind i projektet der er uafhængige og i højere grad kan sikre digital suverænitet. Samtidig er der behov for, at styregruppen drøfter de budgetmæssige og strategiske konsekvenser af forskellige løsningsmodeller for OS2 AI Heat Control. Det gælder særligt balancen mellem: - Digital suverænitet - Open source-governance - Leverandøruafhængighed - Drift og vedligehold - Eventuel anvendelse af proprietære løsninger - Mulighed for senere flerleverandørsetup Hvis projektet vælger en samlet løsning hos én leverandør eller en løsning, der bygger tæt oven på eksisterende platforme eller leverandørspecifik infrastruktur, kan det have betydning for projektets fremtidige ejerskab, fleksibilitet og exit-muligheder. Styregruppen skal derfor afklare, hvilket ambitionsniveau projektet skal have i forhold til digital suverænitet, open source, teknisk ejerskab og eventuel binding til proprietære løsninger. ### Opgave Styregruppen skal drøfte og afklare de budgetmæssige og strategiske konsekvenser af projektets tekniske og organisatoriske valg. Drøftelsen bør som minimum omfatte: - Hvilket ambitionsniveau projektet skal have for digital suverænitet? - Om projektet ønsker at eje og kunne videreudvikle centrale dele af løsningen selv - Om projektet accepterer binding til én leverandør og/eller én bestemt driftsplatform - Om en væg-til-væg-løsning er forenelig med projektets open source-ambition - Om løsningen senere kan understøtte flere leverandører, algoritmer og integrationer - Hvilke omkostninger der realistisk skal afsættes til drift, vedligehold, governance og teknisk kvalitetssikring - Om budgettet afspejler de reelle omkostninger ved open source-forvaltning - Om projektet skal udarbejde scenarier for lav, middel og høj grad af digital suverænitet ### Centrale afklaringsspørgsmål #### 1. Leverandørbinding Hvis projektet vælger en samlet løsning hos én leverandør, skal det afklares, om løsningen reelt kan drives, vedligeholdes og videreudvikles af andre leverandører senere. #### 2. Driftsmodel Det skal afklares, om budgettet til drift og vedligeholdelse skal indeholde antagelser om bestemt cloudplatform, infrastruktur, afhængighed til eksisterende platforme eller leverandørspecifikke komponenter. #### 3. Flerleverandørsetup Det skal vurderes, om den ønskede arkitektur skal kunne understøtte, at andre leverandører senere kan udvikle algoritmer, integrationer eller driftskomponenter. #### 4. Digital suverænitet Styregruppen skal tage stilling til, om digital suverænitet er et centralt projektmål, eller om projektet accepterer en højere grad af afhængighed af proprietære løsninger for at reducere kortsigtede omkostninger og kompleksitet. #### 5. Vedligehold og teknisk forvaltning Styregruppen skal drøfte, hvor stor en del af projektets økonomi der bør reserveres til vedligehold, governance, dokumentation og teknisk forvaltning frem for alene nyudvikling. ### Foreslåede scenarier til drøftelse #### Scenarie 1: Lav grad af digital suverænitet Projektet vælger en væg-til-væg-løsning hos én leverandør og accepterer i højere grad binding til leverandørens arkitektur, infrastruktur og driftsmodel. **Mulige fordele** - Hurtigere etablering - Lavere kompleksitet på kort sigt - Én tydelig leverandør med samlet ansvar **Mulige ulemper** - Risiko for leverandørbinding - Svagere exit-strategi - Mindre fleksibilitet for senere algoritmer og integrationer - Mindre reel open source-governance #### Scenarie 2: Balanceret model Projektet anvender åbne standarder, open source-principper og en maintainer-rolle, men accepterer proprietære komponenter eller én primær driftsleverandør, hvor det er praktisk og økonomisk hensigtsmæssigt. **Mulige fordele** - Balance mellem fremdrift og ejerskab - Mulighed for gradvis modning af open source-governance - Reduceret risiko for overkompleksitet **Mulige ulemper** - Kræver tydelige arkitekturbeslutninger - Risiko for uklar grænse mellem fælles OS2-produkt og leverandørspecifik løsning - Kræver aktiv teknisk forvaltning #### Scenarie 3: Høj grad af digital suverænitet Projektet prioriterer åben arkitektur, flerleverandørsetup, uafhængig maintainer, dokumentation, governance og tydelig exit-strategi. **Mulige fordele** - Større leverandøruafhængighed - Bedre langsigtet ejerskab - Stærkere open source-produkt - Bedre mulighed for genbrug på tværs af kommuner og leverandører **Mulige ulemper** - Højere omkostninger til teknisk forvaltning - Større behov for governance og kompetencer - Kan give langsommere fremdrift i opstartsfasen

👀 1

JakobNoerby commented

2026-10-05 15:10:51 +00:00

(Migrated from github.com)

Status fra projektmøde 05.09.2026

Risikologgen blev gennemgået, og særligt risikoen om budgetsikkerhed og graden af leverandøruafhængighed blev drøftet.

Det blev aftalt, at næste møde dedikeres til en uddybende drøftelse af dette punkt, da det både relaterer sig til:

Projektets budgetsikkerhed
Grad af leverandøruafhængighed
Digital suverænitet
Open source-governance
Kravspecifikation til udbud
Fremtidig drift og vedligehold

Næste møde afholdes i Kolding den 03.11.2026 kl. 9.00-11.00.

Henrik fra LibreLab inviteres til mødet for at bidrage med erfaring og faglighed om open source softwareudvikling og open source-forvaltning.

Næste skridt

Forberede scenarier for budgetsikkerhed og leverandøruafhængighed
Invitere Henrik fra LibreLab
Afklare hvilke konsekvenser forskellige grader af digital suverænitet har for kravspecifikation og udbud

### Status fra projektmøde 05.09.2026 Risikologgen blev gennemgået, og særligt risikoen om budgetsikkerhed og graden af leverandøruafhængighed blev drøftet. Det blev aftalt, at næste møde dedikeres til en uddybende drøftelse af dette punkt, da det både relaterer sig til: - Projektets budgetsikkerhed - Grad af leverandøruafhængighed - Digital suverænitet - Open source-governance - Kravspecifikation til udbud - Fremtidig drift og vedligehold Næste møde afholdes i Kolding den 03.11.2026 kl. 9.00-11.00. Henrik fra LibreLab inviteres til mødet for at bidrage med erfaring og faglighed om open source softwareudvikling og open source-forvaltning. ### Næste skridt - [ ] Forberede scenarier for budgetsikkerhed og leverandøruafhængighed - [x] Invitere Henrik fra LibreLab - [ ] Afklare hvilke konsekvenser forskellige grader af digital suverænitet har for kravspecifikation og udbud