Heel de overheid aan de Open Source (ambitie)

[oNNoZeLe]

Ik ben op zoek naar in welk topic we als tweakers met elkaar kunnen sparren over hoe de wereld er nu uit zou moeten zien als we binnen de overheid 'allemaal lekker aan de open source' gaan.

Ik werk bij de overheid en ken ons applicatielandschap goed, daarnaast heb ik 10 jaar voor een softwareboer gewerkt en weet dat er best wat handjes, processen en papier werk nodig zijn om van ontwerp naar 'in gebruikname' te gaan.

Deze hele OSS wending gaat nog veel stof doen opwaaien. Daar waar we nu soms een vendorlockin hebben gaan we dat straks wellicht krijgen op techniek?

Een alle communicatie tot nu toe mis ik de focus/tijdlijn in deze ambitie, we maken zoveel gebruik van software, waar start en stop je? Gaan we zelf mobiele OS ontwikkelen? Zelf Hypervisors maken? BI-tooling of de software die in onze verkeerlichten draait?

nogmaals, er draait hier zoveel software.

[ Voor 3% gewijzigd door oNNoZeLe op 15-03-2023 15:35 ]

[PageFault]

Eerst zul je dan in kaart moeten brengen welke tooling je allemaal in-house gebruikt. Dat is veel lastiger dan je denkt, vooral omdat soms bepaalde software niet via IT wordt aangeschaft binnen bepaalde organisaties....

Daarna kun je ernaast zetten welke vergelijkbare alternatieven zijn. Voor Excel heb je bijv. niet echt een goed alternatief, indien je complexe calculaties in sheets gebruikt, of erger nog: macros.

[Rolfie]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 15:35:
Ik ben op zoek naar in welk topic we als tweakers met elkaar kunnen sparren over hoe de wereld er nu uit zou moeten zien als we binnen de overheid 'allemaal lekker aan de open source' gaan.

Waarom zou men moeten overstappen op Open Source? Wat is echt de toegevoegde waarde?

Deze hele OSS wending gaat nog veel stof doen opwaaien.

Dat hoor ik ondertussen ook al 15 jaar.

Daar waar we nu soms een vendorlockin hebben gaan we dat straks wellicht krijgen op techniek?

Men kijkt meestal naar de beste applicatie die geschikt is voor de requirements.
Als je dit inhouse zou willen ontwikkelen, moet je ook de complete support hiervoor inrichten en toekomst visie hebben om dit daarna verder uit te breiden richting de toekomst.

Een alle communicatie tot nu toe mis ik de focus/tijdlijn in deze ambitie, we maken zoveel gebruik van software, waar start en stop je? Gaan we zelf mobiele OS ontwikkelen? Zelf Hypervisors maken? BI-tooling of de software die in onze verkeerlichten draait?

Je wilt dus eigenlijk het wiel zelf gaan uitvinden?

Zelf de ondersteuning volledig gaan bouwen en neerzetten?
Of ga je huidige opensource gebruiken en aanpassen, zodat je altijd je einde incompatible code hebt draaien die je moet aanpassen bij iedere aanpassen? En dus inhouse mensen hiervoor moet hebben en blijven houden?

nogmaals, er draait hier zoveel software.

Klopt. Meestal met een redenen.

Overheid staat nu ook niet bekend om zijn IT projecten en wat jij hier beschrijft, afhankelijk wat je gedachte is, klinkt als een niet te goede oplossing.

Opensource is zeker iets wat je kunt gebruiken, het hoeft echter niet het beste product te zijn of de beste oplossing. Het is geen holygreal. TOC technisch maakt het vaak onder de streep ook niet uit is mijn ervaring.

Maar mooi discussie topic.

[oNNoZeLe]

Rolfie schreef op woensdag 15 maart 2023 @ 16:58:
[...]

Waarom zou men moeten overstappen op Open Source? Wat is echt de toegevoegde waarde?

ik heb niet veel tijd nu maar onderbouwingen hoe ik kom tot dit topic:
1. nieuws: Nederlands ministerie van Binnenlandse Zaken krijgt opensourceofficer
2. https://www.digitaleoverh...ncode-digid-app-openbaar/
3. https://ibestuur.nl/partn...n-wat-houdt-ons-nog-tegen

er zijn nog meer artikelen waarbij open source als oplossing wordt gezien voor onder andere gemeenten.

[F_J_K]

Och er is altijd wel een 'de oplossing'. Zoals in die laatste common ground wordt genoemd. Dat heette 20 jaar geleden nog een dun midoffice

Open source: ik zie niet hoe een overstap op Linux+LibreOffice het makkelijker maakt t.o.v. Windows+MSOffice. Ook niet op de lange termijn. Licentiekosten? Dan heet het voortaan onderhoud- en ondersteuningskosten en verandert er weinig.

Het kan me niets schelen welk OS, welke hypervisor, welke browser, welk Office-pakket. Daar zit de complexiteit helemaal niet (wat dat betreft). Sociale dienst-systemen, burgerzaken, beheer openbare ruimte, vele andere 'niches'. Daar wel. En als die al 'free as in speech' worden dan met garantie tot de deur zodra je zelf een fork gaat maken.

Qua vendor-lockin zie ik een gang naar SaaS als meer een ding. Al vind ik het zelf wel prettig (zolang er goede afspraken zijn over toegang tot de data). "Simpelweg" de inrichting, beheer en gebruik is al genoeg werk.

[F_J_K]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 17:17:
2. https://www.digitaleoverh...ncode-digid-app-openbaar/

Code openbaar maken van zelf ontwikkelde software: daar sta ik helemaal achter ja, want betaald door ons allemaal. En goed qua openheid - al doet opensource-zijn daar niets voor, dat kan ook zonder GPL, en sowieso zit de logica niet in de code maar in de procesinrichting.

[Rolfie]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 17:17:
[...]


ik heb niet veel tijd nu maar onderbouwingen hoe ik kom tot dit topic:
1. nieuws: Nederlands ministerie van Binnenlandse Zaken krijgt opensourceofficer
2. https://www.digitaleoverh...ncode-digid-app-openbaar/
3. https://ibestuur.nl/partn...n-wat-houdt-ons-nog-tegen

er zijn nog meer artikelen waarbij open source als oplossing wordt gezien voor onder andere gemeenten.

Ik hoor het nodige al 15 jaar, zoals ik al aangaf.

Klinkt leuk zo'n oso, maar de meeste ministers krijgen hun ministerie vaak niet eens onder de knie. Grote IT projecten mislukken meestal of overschrijden vaak enorm het budget. Kosten zitten hem bijna altijd in de applicaties en logica. Opensource gaat daar niet heel veel aan veranderen, misschien maakt dit het alleen maar complexer, omdat support vaak een stuk lastiger te krijgen is.

Ik ben voorstander van OS, waar je dit kunt gebruiken. Als dit het beste product voor de oplossing is.

Maar de complexiteit bij de overheid zit hem voornamelijk in business intelligentie. Infrastructuur kosten zijn meestal goedkoop, maar daar is OS ook vaak best goed te gebruiken, zabbix, nagios en dit soort tooling is best heel geschikt hiervoor. Maar core infrastructuur, daar is opensource vaak gelimiteerd gebruikt.

[downtime]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 15:35:
Ik ben op zoek naar in welk topic we als tweakers met elkaar kunnen sparren over hoe de wereld er nu uit zou moeten zien als we binnen de overheid 'allemaal lekker aan de open source' gaan.

Ik werk bij de overheid en ken ons applicatielandschap goed, daarnaast heb ik 10 jaar voor een softwareboer gewerkt en weet dat er best wat handjes, processen en papier werk nodig zijn om van ontwerp naar 'in gebruikname' te gaan.

Deze hele OSS wending gaat nog veel stof doen opwaaien. Daar waar we nu soms een vendorlockin hebben gaan we dat straks wellicht krijgen op techniek?

Een alle communicatie tot nu toe mis ik de focus/tijdlijn in deze ambitie, we maken zoveel gebruik van software, waar start en stop je? Gaan we zelf mobiele OS ontwikkelen? Zelf Hypervisors maken? BI-tooling of de software die in onze verkeerlichten draait?

nogmaals, er draait hier zoveel software.

Persoonlijk denk ik niet dat de overheid persé voor OSS moet kiezen als het gewoon om standaard "off the shelf" software gaat. Dat levert niet zo gek veel op tenzij je denkt dat er enorme besparingen op licenties mogelijk zijn maar ik vrees dat dat tegenvalt. Als je niet voor licenties betaalt dan moet je wel weer voor support betalen.

De winst zit denk ik in software die als maatwerk wordt ontwikkeld. Het idee zou dan zijn dat:

• De burger inzicht krijgt in de algorithmes die de overheid gebruikt. Vanuit het oogpunt van een transparante overheid is dat interessant.
• De burger (onderdelen van) software die van zijn belastinggeld is ontwikkeld kan hergebruiken voor andere projecten.
• Overheden kunnen profiteren van OSS wat door andere onderdelen van die overheid is ontwikkeld (en betaald).
• Je niet meer afhankelijk bent van de oorspronkelijke vendor als er later aanpassingen aan bestaand maatwerk moet worden gedaan. Je kan dan gewoon een random partij inschakelen omdat je als overheid dan zelf eigenaar van de source code bent.

Denk dan bijvoorbeeld aan een pakket voor gemeenten wat dan door een grote gemeente wordt ontwikkeld waarna een andere gemeente het (of delen ervan) "gratis" kan gebruiken.
Betekent waarschijnlijk wel dat die eerste gemeente de hoofdprijs betaalt omdat de software vendors daarmee een makkelijke inkomstenbron verliezen.

[Jazzy]

Nieuwsberichtje van meer dan 20(!) jaar geleden: nieuws: Universiteit Maastricht: overheden naar open-source

Als bedrijven de broncode van hun software vrijgeven, kunnen andere bedrijven de software ook aanpassen. Overheden zijn dan niet meer afhankelijk van de kennis van één producent en kunnen makkelijker overstappen naar een andere. Dit leidt dan weer tot meer concurrentie op de markt en daardoor lagere prijzen.

Helder uitgangspunt, maar ik kan me niet herinneren dat we hier in de praktijk ooit bewijs van hebben gezien.

[downtime]

Jazzy schreef op woensdag 15 maart 2023 @ 17:42:
Nieuwsberichtje van meer dan 20(!) jaar geleden: nieuws: Universiteit Maastricht: overheden naar open-source

[...]

Helder uitgangspunt, maar ik kan me niet herinneren dat we hier in de praktijk ooit bewijs van hebben gezien.

Hebben we het ooit (serieus) geprobeerd dan?

[Jackxl]

Jazzy schreef op woensdag 15 maart 2023 @ 17:42:
Nieuwsberichtje van meer dan 20(!) jaar geleden: nieuws: Universiteit Maastricht: overheden naar open-source

[...]

Helder uitgangspunt, maar ik kan me niet herinneren dat we hier in de praktijk ooit bewijs van hebben gezien.

Ik denk dat bijvoorbeeld Android of Ubuntu heel wat hebben laten zien. Verder zijn er inmiddels talloze producten die gebruik maken van open source software en hardware. De ontwikkeling van deze producten is zeker weten goedkoper en sneller geworden door OSS.
Neem bijvoorbeeld git dat is toch gewoon geweldig.

[oNNoZeLe]

maar stel public money = public code voor software ontwikkeltrajecten?
Er zijn gemeenten die graag willen onderzoeken of we owncloud verder kunnen ontwikkelen om als vervanger van office365 te kunnen gebruiken. (ik zeg bewust o365 en m365 omdat dat meer is).

Dan gaan we dus COTS nabouwen met public money en concurreren met bestaande markten?

Maar even haalbaarheid en 'in het verleden behaalde resultaten geven garantie voor de toekomst' daargelaten.
Hoe dan?

[unezra]

Het wordt al meer dan 25 jaar geroepen en dé oorzaak van het continu falen, is dat OSS té versnipperd is, een hoog NIH gehalte kent en geen fatsoenlijke centrale sturing / marketing kent.

Het hele "bedrijfsmodel" van OSS maakt dat het vaak niet kan concurreren met CSS en zolang de OSS wereld dát niet snapt, zal het de positie houden die het heeft.

Daarbij vind ik dat je moet kiezen op de bruikbaarheid van een tool, waarbij licentiemodel een factor mag zijn, maar niet de enig bepalende.

(Saillant detail is dat de grootste OSS successen zijn geboekt dankzij commerciële partijen. RedHat was een van de eerste OSS partijen en is er groot mee geworden, maar juist een partij als RedHat heeft er voor gezorgd dat OSS nu die positie kent die het kent. Zonder partijen als RedHat, was het naar alle waarschijnlijkheid een hobbyproject van een zekere Fin gebleven.)

[oNNoZeLe]

unezra schreef op woensdag 15 maart 2023 @ 20:15:
Het wordt al meer dan 25 jaar geroepen en dé oorzaak van het continu falen, is dat OSS té versnipperd is, een hoog NIH gehalte kent en geen fatsoenlijke centrale sturing / marketing kent.

Het hele "bedrijfsmodel" van OSS maakt dat het vaak niet kan concurreren met CSS en zolang de OSS wereld dát niet snapt, zal het de positie houden die het heeft.

Daarbij vind ik dat je moet kiezen op de bruikbaarheid van een tool, waarbij licentiemodel een factor mag zijn, maar niet de enig bepalende.

(Saillant detail is dat de grootste OSS successen zijn geboekt dankzij commerciële partijen. RedHat was een van de eerste OSS partijen en is er groot mee geworden, maar juist een partij als RedHat heeft er voor gezorgd dat OSS nu die positie kent die het kent. Zonder partijen als RedHat, was het naar alle waarschijnlijkheid een hobbyproject van een zekere Fin gebleven.)

if you don't mind me asking, wat is NIH gehalte?

[downtime]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 20:21:
[...]


if you don't mind me asking, wat is NIH gehalte?

Not Invented Here, gok ik zo

[downtime]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 20:02:

Dan gaan we dus COTS nabouwen met public money en concurreren met bestaande markten?

Daarom vind ik juist dat de overheid gewoon off the shelve moet kopen waar het kan. De overheid moet niet zelf een marktpartij worden als het niet hoeft.
Maar er wordt bij de overheid (noodgedwongen) heel veel maatwerk ontwikkeld en dat kan best aanbesteed worden onder de voorwaarde dat de source code onder een open source licentie wordt gepubliceerd. Dan kunnen andere onderdelen van die overheid het ook kunnen gebruiken en betalen ze niet bij een vendor het volle pond voor code die allang bestaat.

Je moet er dan natuurlijk wel aanvullende eisen aan stellen zodat je niet via een omweg alsnog met een vendor lock-in zit (bijvoorbeeld door vendor-specifieke ontwikkeltools en -talen te gebruiken).

[Onbekend]

Ik denk dat er twee redenen zijn om open source te gebruiken:

1. Niet afhankelijk zijn van maar 1 leverancier of producent.
2. De volledige source code is voor iedereen inzichtelijk.

Bij het eerste punt zou een leverancier met updates functionaliteiten kunnen aanpassen/verwijderen waardoor de update niet meer bruikbaar is. Als er meer leveranciers beschikbaar zijn, zou je kunnen overstappen. (Stel je voor dat Microsoft in Office 2025 een continue internetverbinding nodig heeft, dan zouden bijvoorbeeld pc's die niet aan het internet mogen hangen nooit deze update kunnen gebruiken.)

Bij het tweede punt kan de werking van de software onderhuids bekeken worden en eventueel met een aangepaste versie gecompileerd worden. En iedereen kan zien wat de code doet. (Ja, met contracten en wat geld zouden programmeurs wel inzicht mogen krijgen in closed source applicaties, maar alsnog mag niet iedereen de code bekijken.)


Een bijkomend voordeel van open source is vaak dat interfaces, imports en exports in een standaard formaat aangeboden kunnen worden zoals json of xml. Natuurlijk heeft elke applicatie een eigen formaat met een eigen datastructuur en is niet alles 1 op 1 compatibel, maar vanwege het open source is vrij eenvoudig te achterhalen hoe interfaces, exports en imports op elkaar moeten worden aangesloten.

Open source is overigens niet altijd gelijk aan gratis (maar vaak wel). En daarnaast heb je altijd ondersteuningskosten en onderhoudskosten aan een pakket. Immers, updates moeten worden getest en uitgerold worden.


Ik ben wel voor dat instanties ook het gebruik van open source pakketten onderzoeken, maar alleen om te voorkomen dat je afhankelijk bent van maar 1 partij. Mocht na onderzoek toch een closed source pakket als beste naar voren komen, dan is dat gewoon op dat moment de beste keuze. Financieel zie ik er niet direct een voordeel van open source of closed source. Het is gewoon de kosten tegen elkaar afwegen.


Hierboven heb ik het alleen gehad over het kiezen tussen open source en closed source. Maar in een organisatie zijn vaak verschillende softwarepakketten in gebruik die op elkaar zijn afgestemd. Bij elke verandering van software, of je nu voor open source of closed source kiest maakt niet uit, moet men er zeker van zijn dat het uiteindelijk goed op elkaar aansluit.
Soms is het veel goedkoper om een bestaand (slecht werkend) pakket te behouden, dan een ander (beter) pakket in gebruik te nemen om die daarna volledig in de organisatie te kunnen implementeren.

[JaQ]

Commercieel: geen voordeel, denk dat iedereen ondertussen wel weet (hopelijk?) dat open source niet perse goedkoper is dan closed source. “Even een stukje software downloaden” wordt OSS niet echt beter van hè.
Strategisch: De partijen die advies geven staan nou niet direct bekend vanwege het aanjagen van OSS (is ongetwijfeld ook geen criterium geweest bij de aanbesteding)
Mensen: het is al lastig genoeg voor de overheid om gekwalificeerde IT-ers te krijgen door het betalingsbeleid, OSS binnen een bedrijf onderhouden vereist toch net iets anders dan click-ops Maar ook qua besturing, de wat serieuzere IT manager moet wel heel principieel zijn om voor de overheid te kiezen.
Noodzaak: de huidige systemen voldoen min of meer, het staat niet zodanig in de brand dat er direct herbouw nodig is. Waar dat wel noodzakelijk is, is open sourcen van wat er gebouwd wordt eerder haalbaar dan implementeren van een bestaande OSS oplossing.

Kortom: kansloos.

Nieuwbouw wat herbruikbaar is, of vanuit security oogpunt open-sourcen is uiteraard prima (en verstandig). Dat is wel een route van de lange adem. Maar alle bestaande onderdelen zijn zeker niet direct een oplossing, tenzij we daar flink voor willen betalen met z’n allen. Wat zouden we niet meer moeten doen zodat er budget vrij komt om wel de overheid op OSS te krijgen? En is dat politiek haalbaar?

[F_J_K]

downtime schreef op woensdag 15 maart 2023 @ 20:55:
[...]

Daarom vind ik juist dat de overheid gewoon off the shelve moet kopen waar het kan. De overheid moet niet zelf een marktpartij worden als het niet hoeft.
Maar er wordt bij de overheid (noodgedwongen) heel veel maatwerk ontwikkeld en dat kan best aanbesteed worden onder de voorwaarde dat de source code onder een open source licentie wordt gepubliceerd. Dan kunnen andere onderdelen van die overheid het ook kunnen gebruiken en betalen ze niet bij een vendor het volle pond voor code die allang bestaat.

Je moet er dan natuurlijk wel aanvullende eisen aan stellen zodat je niet via een omweg alsnog met een vendor lock-in zit (bijvoorbeeld door vendor-specifieke ontwikkeltools en -talen te gebruiken).

En alle documentatie en zeker weten dat daadwerkelijk alle kennis is gedeeld.

Maar: meh. Als je bij een closed source bedrijf bestelt wordt de code ook gedeeld: als executable met alle andere klanten. Het enige verschil van open source is dat je kunt zeggen dat je kan dreigen zelf beter te doen met een fork. En dat gaat simpelweg niet gebeuren: er is geen overheid die meer betere devvers heeft om de komende decennia de software te onderhouden dan “de markt”.

Ik zie een pluspunt voor OS bij overheden zelf, maar geen hele grote eerlijk gezegd. Vooral in dat je bij ontsluiten van data de details van data en logica kunt bekijken of laten bekijken door een ander bedrijf.

TL;DR: aandeelhouders van Redhat willen evenveel geld zien als de aandeelhouders van Microsoft.

Edit: als privé-persoon ben ik er blij mee. Lekker gratis. Maar als organisatie kijk ik naar de total cost of ownership. Soms open source, soms niet.

[ Voor 4% gewijzigd door F_J_K op 15-03-2023 22:06 ]

[downtime]

F_J_K schreef op woensdag 15 maart 2023 @ 22:05:
[...]

Als je bij een closed source bedrijf bestelt wordt de code ook gedeeld: als executable met alle andere klanten. Het enige verschil van open source is dat je kunt zeggen dat je kan dreigen zelf beter te doen met een fork. En dat gaat simpelweg niet gebeuren: er is geen overheid die meer betere devvers heeft om de komende decennia de software te onderhouden dan “de markt”.

De overheid hoeft niet zelf devvers te hebben. Ze hebben op die manier gewoon de mogelijkheid om een leverancier te vervangen als de oude de hoofdprijs vraagt voor onderhoud. Daar hebben ze zelf niemand voor nodig.

En met welke “andere klanten” deelt een gemeente een stuk software waar niemand in de wereld iets mee kan behalve een handvol Nederlandse gemeenten die dezelfde wettelijke taken uitvoeren?

[F_J_K]

downtime schreef op woensdag 15 maart 2023 @ 22:33:
[...]

De overheid hoeft niet zelf devvers te hebben. Ze hebben op die manier gewoon de mogelijkheid om een leverancier te vervangen als de oude de hoofdprijs vraagt voor onderhoud. Daar hebben ze zelf niemand voor nodig.

Maar ook geen code: stap naar de concurrent met je data. Een fork per ontevreden klant gaat niet werken.

En met welke “andere klanten” deelt een gemeente een stuk software waar niemand in de wereld iets mee kan behalve een handvol Nederlandse gemeenten die dezelfde wettelijke taken uitvoeren?

De andere overheden. 1 pakket NL-breed is per definitie geen concurrentie en een paar jaar later geen fatsoenlijk systeem. Als het op dag 1 al werkt met 300 (gemeenten) a 1600 (overheden) kapiteins op 1 schip.

[thebeast12]

oNNoZeLe schreef op woensdag 15 maart 2023 @ 15:35:
Ik ben op zoek naar in welk topic we als tweakers met elkaar kunnen sparren over hoe de wereld er nu uit zou moeten zien als we binnen de overheid 'allemaal lekker aan de open source' gaan.

Ik werk bij de overheid en ken ons applicatielandschap goed, daarnaast heb ik 10 jaar voor een softwareboer gewerkt en weet dat er best wat handjes, processen en papier werk nodig zijn om van ontwerp naar 'in gebruikname' te gaan.

Deze hele OSS wending gaat nog veel stof doen opwaaien. Daar waar we nu soms een vendorlockin hebben gaan we dat straks wellicht krijgen op techniek?

Een alle communicatie tot nu toe mis ik de focus/tijdlijn in deze ambitie, we maken zoveel gebruik van software, waar start en stop je? Gaan we zelf mobiele OS ontwikkelen? Zelf Hypervisors maken? BI-tooling of de software die in onze verkeerlichten draait?

nogmaals, er draait hier zoveel software.

Ook ik werk voor de "Overheid" maar wat zie jij precies als de overheid?
De overheid is niet 1 grote IT leverancier maar zijn allemaal kleine organisaties die allemaal diensten leveren. Om deze organisaties nu al samen te laten werken is een hele uitdaging.
De overheid is gebaseerd op politiek. Deze politiek speelt ook binnen alle IT sectoren van de overheid.
Als organisatie A de werkplek aanbied en organisatie B moet daar een aplicatie op aanbieden is het nog geen probleem. Maar zodra dit niet meer werkt gaat organisatie B naar A wijzen en andersom. Er zijn best wel wat koppelingen van verschillende dienstverleners die met elkaar moeten werken.

Daarnaast alle legacy producten die er moeten blijven draaien omdat ministeries dit willen. Nee is geen antwoord. Een antwoord is hoeveel gaat het kosten?

Ik denk dat de uitdaging hierin veel dieper zit. Namelijk dat de IT sector ook gebaseerd is op politieke spelletjes. Zolang mijn straatje schoon blijft heb ik geen zorgen wordt er gedacht.

[Oogje]

downtime schreef op woensdag 15 maart 2023 @ 17:56:
[...]

Hebben we het ooit (serieus) geprobeerd dan?

Wij niet, een grote Duitse stad wel. München ging van MS naar OSS en jaren later weer naar MS en ondertussen willen ze toch weer OSS iirc.

[JJ Le Funk]

hebben ze bij de belastingdienst nog steeds van die gigantische server ruimtes waar elk project z'n eigen setje reduntant uitgevoerde hardware heeft hangen die 24/7 staat te idle'en maar niemand durft uit te zetten?
misschien kan dat probleem gelijk aangepakt worden bij een migratie naar open source.

[downtime]

Oogje schreef op woensdag 15 maart 2023 @ 23:55:
[...]

Wij niet, een grote Duitse stad wel. München ging van MS naar OSS en jaren later weer naar MS en ondertussen willen ze toch weer OSS iirc.

In mijn herinnering gingen ze daar best ver. Ook Windows vervangen door Linux, Office door OpenOffice, etc. Dat heeft impact op de hele organisatie. Alleen al Office vervangen heeft een enorme impact omdat zoveel andere software daaraan gekoppeld is. Dan zwijg ik nog over de gevolgen voor (de opleiding van) het personeel. Ik zeg bewust dat je je zou moeten beperken tot de software die toch al maatwerk is.

[oNNoZeLe]

thebeast12 schreef op woensdag 15 maart 2023 @ 23:50:
[...]


Ook ik werk voor de "Overheid" maar wat zie jij precies als de overheid?
De overheid is niet 1 grote IT leverancier maar zijn allemaal kleine organisaties die allemaal diensten leveren. Om deze organisaties nu al samen te laten werken is een hele uitdaging.
De overheid is gebaseerd op politiek. Deze politiek speelt ook binnen alle IT sectoren van de overheid.
Als organisatie A de werkplek aanbied en organisatie B moet daar een aplicatie op aanbieden is het nog geen probleem. Maar zodra dit niet meer werkt gaat organisatie B naar A wijzen en andersom. Er zijn best wel wat koppelingen van verschillende dienstverleners die met elkaar moeten werken.

Daarnaast alle legacy producten die er moeten blijven draaien omdat ministeries dit willen. Nee is geen antwoord. Een antwoord is hoeveel gaat het kosten?

Ik denk dat de uitdaging hierin veel dieper zit. Namelijk dat de IT sector ook gebaseerd is op politieke spelletjes. Zolang mijn straatje schoon blijft heb ik geen zorgen wordt er gedacht.

Ik werk bij 1 van de 340 gemeente, waarbij vanuit VNG deze hele opensource wending veel aandacht krijgt ook in relatie met “Common Ground” gedachte.

Ik acht de overstap naar OSS niet onmogelijk maar als we het echt willen dan gaat het wel lang duren om dat te bereiken.

[Jazzy]

oNNoZeLe schreef op donderdag 16 maart 2023 @ 09:05:
Ik acht de overstap naar OSS niet onmogelijk maar als we het echt willen dan gaat het wel lang duren om dat te bereiken.

We zijn al meer dan 20 jaar op weg. Hoe lang denk je dat het gaat duren dan?

[oNNoZeLe]

Jazzy schreef op donderdag 16 maart 2023 @ 09:10:
[...]
We zijn al meer dan 20 op weg. Hoe lang denk je dat het gaat duren dan?

Het start met 1.. en die is er al.
en op dit moment geeft men Signalen.org vooral als voorbeeld.
Maar in het AI spectrum hebben we ook odk.ai als voorbeeld..

[Bossie]

oNNoZeLe schreef op donderdag 16 maart 2023 @ 10:32:
[...]

Het start met 1.. en die is er al.
en op dit moment geeft men Signalen.org vooral als voorbeeld.
Maar in het AI spectrum hebben we ook odk.ai als voorbeeld..

En wat heeft dat te maken met een transitie van de overheid van closed source naar open source ?

Dit klinkt vooral als veranderen om te willen veranderen, dit is simpelweg te groot om op dit niveau te bekijken aangezien je per portfolio/application niveau eerst moeten kijken of er een opensource tegenhanger/fit is (en dan slaan we de migratie nog maar even over).

Maar dromen mag altijd en dat is in ieder geval goedkoper dan open source

[oNNoZeLe]

Hier nog eentje die bij moet dragen aan het meer opensource ontwikkelen binnen de overheid.

https://opensource.pleio.nl/

[SinergyX]

Bossie schreef op donderdag 16 maart 2023 @ 15:32:
[...]
Dit klinkt vooral als veranderen om te willen veranderen, dit is simpelweg te groot om op dit niveau te bekijken aangezien je per portfolio/application niveau eerst moeten kijken of er een opensource tegenhanger/fit is (en dan slaan we de migratie nog maar even over).

Maar dromen mag altijd en dat is in ieder geval goedkoper dan open source

Zo simpel is dat niet eens, als deze tegenhanger niet direct zou bestaan, dan maken we er toch gewoon eentje?

Sky is de limit blijft nog een toegepast principe bij de overheid, onderzoekje hier, onderzoekje daar, haalbaarheid hier, haalbaarheid daar, inmiddels duizenden euro's verder en elke 'adviseur' kan lullen als brugman.

[oNNoZeLe]

maar weinig mensen die geloven dat dit een haalbare ambitie is, aan de andere kant neemt de roep om transparantie toe. Ik geef toe, transparantie kan ook zonder opensource.

Maar we kunnen wel stellen dat opensource impliciet transparant is?

[downtime]

SinergyX schreef op maandag 20 maart 2023 @ 12:49:
[...]

Zo simpel is dat niet eens, als deze tegenhanger niet direct zou bestaan, dan maken we er toch gewoon eentje?

En dat gebeurt heel veel bij de overheid. Heel veel overheidstaken zijn specifiek voor Nederland (want wetgeving, taal, cultuur, historie, etc) en daar is geen standaard software voor want die markt is te klein. En dus gebruiken overheden veel maatwerk software.

Het is juist die maatwerk software die je makkelijk open source kunt maken. Daarvoor hoef je aan bestaande inkoopprocessen in principe maar één regeltje toe te voegen: De code die de leverancier produceert moet onder een OSS-licentie op Github gezet worden. Verder verandert er weinig aan het proces.

[downtime]

oNNoZeLe schreef op maandag 20 maart 2023 @ 13:09:

Maar we kunnen wel stellen dat opensource impliciet transparant is?

Nee. Het is expliciet transparant.

[TheDudez]

Is er al een goed alternatief voor Citrix/Vmware? En wat denk je van een Grafische omgeving met Autocad? En dan heb je het nog niet over all het maatwerk wat met office producten werkt. Nee het is zo goed als onmogelijk. Ik denk niet dat je verder komt dan wat webservers, Databases enzevoort.

En stel dat het lukt wat echt tientallen jaren gaat duren. Dan moet je alle gebruikers nog overtuigen om geen office producten te gebruiken. Succes!

[ Voor 20% gewijzigd door TheDudez op 20-03-2023 13:21 ]

[oNNoZeLe]

downtime schreef op maandag 20 maart 2023 @ 13:11:
[...]

En dat gebeurt heel veel bij de overheid. Heel veel overheidstaken zijn specifiek voor Nederland (want wetgeving, taal, cultuur, historie, etc) en daar is geen standaard software voor want die markt is te klein. En dus gebruiken overheden veel maatwerk software.

Het is juist die maatwerk software die je makkelijk open source kunt maken. Daarvoor hoef je aan bestaande inkoopprocessen in principe maar één regeltje toe te voegen: De code die de leverancier produceert moet onder een OSS-licentie op Github gezet worden. Verder verandert er weinig aan het proces.

maar dan verliest een leverancier zijn rechten op de software, die bedrijven zullen dan op zoek moeten gaan naar andere inkomsten bronnen. (build once, sell many)

Rondom de huidige overheids OSS initiatieven zie je het andersom ontstaan: Omdat er op sommige vlakken weinig leveranciers zijn die Commercial-of-the-Shelf leveren zijn ze zelf gaan ontwikkelen.

[Sissors]

Onbekend schreef op woensdag 15 maart 2023 @ 21:35:
Ik denk dat er twee redenen zijn om open source te gebruiken:

1. Niet afhankelijk zijn van maar 1 leverancier of producent.
2. De volledige source code is voor iedereen inzichtelijk.

En soms is dat tweede punt erg belangrijk. Als voorbeeld de COVID vaccinatie app, helemaal mee eens dat zoiets open source moet zijn. Tegelijk het IT ticketing systeem van gemeente Denekamp? Ik zie niet waarom transparantie hoe dat systeem werkt belangrijk is.

En dat zaken die betaald worden om ontwikkeld te worden door de overheid open source zijn, in principe niks mis mee. Maar ook daar is de vraag, wat valt daar precies onder?
Een programma vanaf scratch gemaakt is een makkelijke. Maar wat als het gebaseerd is op een bestaand iets van dat bedrijf? Of als het een aanpassing is van een bestaand programma? Of als het een plugin is voor een bestaand iets?

[downtime]

oNNoZeLe schreef op maandag 20 maart 2023 @ 13:32:
[...]

maar dan verliest een leverancier zijn rechten op de software, die bedrijven zullen dan op zoek moeten gaan naar andere inkomsten bronnen. (build once, sell many)

Klopt. Maar voor de klant betekent het 1 keer betalen, meerdere keren gebruiken. Software voor een gemeente zal voor de eerste gemeente, als opdrachtgever, duurder worden maar voor de tweede, derde en vierde gemeente juist een stuk goedkoper omdat ze veel kunnen hergebruiken. Het gebeurt nu niet omdat de eerste gemeente niet extra wil betalen maar gewoon de goedkoopste leverancier kiest, ook als dat betekent dat andere gemeentes later ook het volle pond betalen. Maar daarom moet je het juist verplichten.

De leverancier blijft overigens altijd in een gunstige concurrentiepositie. Als ontwikkelaar van de applicatie is hij ook degene met de meeste expertise ervan. Bij toekomstige aanbestedingen zal hij dus altijd een streepje voor hebben.

[pagani]

Vrijwel alle wereldwijde experimenten van (grote) gemeenten en overheidsinstanties om over te stappen naar open source lopen uit op dezelfde conclusie: TCO is minimaal gelijk maar vaak stukken hoger dan een niet-open source oplossing. Afhankelijkheid van de open source ondersteuningspartij is ook nog eens vergelijkbaar met de vendor lock in bij de niet-open source varianten. Daarnaast is vrijwel altijd de learning curve stijler, zijn gebruikerservaringen (UX) minder uniform met wat de gebruikers privé/werk gewend zijn etc.

Ik moet de eerste succesvolle volledig open source draaiende gemeente of instantie nog tegenkomen.

Uiteraard is dit business case gerelateerd, met oneindig budget zou ideologisch open source de betere oplossing zijn, maar dat budget he...

[ Voor 28% gewijzigd door pagani op 20-03-2023 14:39 ]

[Outerspace]

Dit past niet zo zeer binnen Tweakers Lounge, maar eerder in Softe goederen of Softwareontwikkeling. Ik verplaats hem iig naar Linux en overige clients, wat meer bij de ziel van deze gedachte ligt.

[downtime]

Sissors schreef op maandag 20 maart 2023 @ 14:14:
[...]

Tegelijk het IT ticketing systeem van gemeente Denekamp? Ik zie niet waarom transparantie hoe dat systeem werkt belangrijk is.

Ik mag hopen dat de gemeente Denekamp niet z'n eigen IT ticket systeem ontwikkelt want daarvan zijn er honderden in de markt waarvan er vast wel eentje aan alle eisen van de gemeente voldoet.
Om die reden zie ik open source ook niet zitten voor systemen die gewoon in de markt verkrijgbaar zijn. Het is onzin dat een gemeente het wiel opnieuw uitvindt als het niet echt hoeft.

[oNNoZeLe]

Outerspace schreef op maandag 20 maart 2023 @ 14:40:
Dit past niet zo zeer binnen Tweakers Lounge, maar eerder in Softe goederen of Softwareontwikkeling. Ik verplaats hem iig naar Linux en overige clients, wat meer bij de ziel van deze gedachte ligt.

Dit hoort helemaal niet bij dit onderwerp thuis en dan duw je hem wel meteen in een technisch software hoekje en "heel overheid_NL aan de OSS" is meer dan een technisch feestje.

Ik kon zelf ook geen passend hokje vinden overigens.

[oNNoZeLe]

downtime schreef op maandag 20 maart 2023 @ 14:29:
[...]

Klopt. Maar voor de klant betekent het 1 keer betalen, meerdere keren gebruiken. Software voor een gemeente zal voor de eerste gemeente, als opdrachtgever, duurder worden maar voor de tweede, derde en vierde gemeente juist een stuk goedkoper omdat ze veel kunnen hergebruiken. Het gebeurt nu niet omdat de eerste gemeente niet extra wil betalen maar gewoon de goedkoopste leverancier kiest, ook als dat betekent dat andere gemeentes later ook het volle pond betalen. Maar daarom moet je het juist verplichten.

De leverancier blijft overigens altijd in een gunstige concurrentiepositie. Als ontwikkelaar van de applicatie is hij ook degene met de meeste expertise ervan. Bij toekomstige aanbestedingen zal hij dus altijd een streepje voor hebben.

En dat verplichten is dus nu aan het gebeuren, daarnaast klopt het niet wat je schrijft over dat nu niet gebeurd. Er zijn al een paar projecten waarbij dit dus wel gedaan is en waarvan de adoptie binnen NL op gang komt. https://signalen.org en https://openstad.org/ zijn voorbeelden hiervan.

[oNNoZeLe]

downtime schreef op maandag 20 maart 2023 @ 14:41:
[...]

Ik mag hopen dat de gemeente Denekamp niet z'n eigen IT ticket systeem ontwikkelt want daarvan zijn er honderden in de markt waarvan er vast wel eentje aan alle eisen van de gemeente voldoet.
Om die reden zie ik open source ook niet zitten voor systemen die gewoon in de markt verkrijgbaar zijn. Het is onzin dat een gemeente het wiel opnieuw uitvindt als het niet echt hoeft.

wat hier grappig aan is, is dat een gemeente dit helemaal niet hoeft te ontwikkelen want dit soort open source tools zijn er al.
https://sourceforge.net/projects/bizitsm/ (slecht voorbeeld)
https://sourceforge.net/projects/i-doit/

En dit is dus waar het gewoon raar gaat worden.. Ik als adviseur bij een gemeente schrijf normaal bestek voor een aanbesteding en zorg dat wat er uit die aanbesteding komt matcht bij wat m'n gemeente wil.
Maar nu is er geen aanbesteding.. geen eisen en wensen lijstje, geen demo's, geen leveranciermanagement, geen ....

[ Voor 0% gewijzigd door oNNoZeLe op 20-03-2023 15:32 . Reden: bizitsm - update ]

[downtime]

oNNoZeLe schreef op maandag 20 maart 2023 @ 15:29:
[...]

wat hier grappig aan is, is dat een gemeente dit helemaal niet hoeft te ontwikkelen want dit soort open source tools zijn er al.
https://sourceforge.net/projects/bizitsm/
https://sourceforge.net/projects/i-doit/

En dit is dus waar het gewoon raar gaat worden.. Ik als adviseur bij een gemeente schrijf normaal bestek voor een aanbesteding en zorg dat wat er uit die aanbesteding komt matcht bij wat m'n gemeente wil.
Maar nu is er geen aanbesteding.. geen eisen en wensen lijstje, geen demo's, geen leveranciermanagement, geen ....

Ik weet dat er wel open source tools voor zijn. Maar ik weet niet hoe goed die zijn en of het echt een goed alternatief voor de commerciele software in die branch is. Als het gaat om standaard software is die afweging wel een lastige als een commercieel pakket gewoon beter aansluit bij de wensen van die organisatie.

[Shivs]

Het grootste probleem is volgens mij dat software is veel gevallen een commodity is geworden. Het moet gewoon werken en is verder niet bijzonder meer. En omdat het gewoon moet werken heb je support nodig. Veel OSS is niet supported voor een enterprise omgeving. RHEL is dat bijvoorbeeld wel, maar dat wordt volledig gefocust op servers. Daarom denk ik dat de gedachtegang om ondersteunde software te kopen ook prima is. Blijf lekker bij Microsoft voor je office software, dat doen praktische alle bedrijven in de wereld en is waarschijnlijk op alle vlakken de beste keuze.

Wat dan wel weer waarde heeft is dat maatwerk software ontwikkeld voor de overheid openbaar wordt gemaakt. Onder het mom van publiek geld = publieke code. Al was het maar voor de memes die ontstonden na het openbaren van de broncode van de DigiD app.

[unezra]

downtime schreef op maandag 20 maart 2023 @ 15:35:
[...]

Ik weet dat er wel open source tools voor zijn. Maar ik weet niet hoe goed die zijn en of het echt een goed alternatief voor de commerciele software in die branch is. Als het gaat om standaard software is die afweging wel een lastige als een commercieel pakket gewoon beter aansluit bij de wensen van die organisatie.

Als het puur gaat om ITSM tooling: iTop CMDB
https://www.combodo.com/itop-193

Persoonlijk vind ik het beter dan Topdesk en eigenlijk alle alternatieven die ik heb gezien.

[oNNoZeLe]

unezra schreef op woensdag 22 maart 2023 @ 07:39:
[...]


Als het puur gaat om ITSM tooling: iTop CMDB
https://www.combodo.com/itop-193

Persoonlijk vind ik het beter dan Topdesk en eigenlijk alle alternatieven die ik heb gezien.

bedankt voor je feedback..

Wat gewoon nu dus al zichtbaar wordt is dat je bij OSS een compleet ander proces moet bewandelen.
Geen leverancier = geen marktverkenning = geen aanbesteding = geen prijs/prestatie = geen leveranciersmanagement

Bij OSS is marktverkenning 'googlen naar systemen', omdat er geen leverancier is zul je bij wijzigingen op aanpassingen op zoek moeten naar een ontwikkelclub..

waar gaat dit heen..

[Jazzy]

Dat vind ik een eigenaardige conclusie. Waarom zou een partij die het implementeert en nadien ondersteunt geen onderdeel van de oplossing kunnen zijn?

[oNNoZeLe]

Jazzy schreef op woensdag 22 maart 2023 @ 09:31:
Dat vind ik een eigenaardige conclusie. Waarom zou een partij die het implementeert en nadien ondersteunt geen onderdeel van de oplossing kunnen zijn?

niet zo zeer bedoeld als conclusie maar ik probeer het proces te begrijpen als OSS verplicht gaat worden.
Je feedback is in die zin waardevol en zo had ik er nog niet tegenaan gekeken.

Dus een marktverkenning op OSS is gewoon mogelijk zeg je.

[P_de_B]

Ik geloof er niet in dat de overheid - of andere bedrijven - massaal over zullen stappen naar OSS voor bijvoorbeeld desktops en officepakketten. Die kosten zijn te hoog, en het helpt de productiviteit van medewerkers niet. Prima als je zelf fantastisch met Vim en Open office werkt, maar de meeste kunnen dat niet. Ik heb ook niet per sé behoefte om daarover in discussie te gaan

Wat ik wel mooi vond, en waar denk ik de overheid met ICT projecten veel meer gebruik van moet maken, is het ontwikkelproces rondom de Corona Check app. Dat is volledig open source onder regie van VWS maar met veel individuele externe experts ontwikkeld, tegen een fractie van de kosten en doorlooptijd wat het gekost zou hebben als een een van de grote ICT clubs het zou hebben ontwikkeld.

Zie hier bijvoorbeeld voor een korte evalutatie: https://www.agconnect.nl/...wikkelproces-coronamelder

[eric.1]

oNNoZeLe schreef op maandag 20 maart 2023 @ 13:09:
maar weinig mensen die geloven dat dit een haalbare ambitie is, aan de andere kant neemt de roep om transparantie toe. Ik geef toe, transparantie kan ook zonder opensource.

Maar we kunnen wel stellen dat opensource impliciet transparant is?

Open source software is transparant, maar het gebruik ervan maakt een organisatie dat nog niet.

Ik denk eerlijk gezegd dat een meer hybrid oplossing het beste is. Alles vervangen voor OSS gaat niet werken. Allereerst blijft een significante afhankelijkheid bestaan, alleen dan zonder garanties in de vorm van contracten. Daarnaast is het nog altijd een kosten-baten plaatje wat niet significant verbetert.

Maak delen open source waar het kan en waar het ook zinvol is. Alle Windows Clients omzetten? Niet doen. o365 uitfaseren voor een open-source variant? Niet doen. Nieuwe of hernieuwde projecten open source maken indien dit zinnig is? Zeker.

[unezra]

oNNoZeLe schreef op woensdag 22 maart 2023 @ 09:34:
[...]
niet zo zeer bedoeld als conclusie maar ik probeer het proces te begrijpen als OSS verplicht gaat worden.
Je feedback is in die zin waardevol en zo had ik er nog niet tegenaan gekeken.

Dus een marktverkenning op OSS is gewoon mogelijk zeg je.

Ja en OSS betekend niet "geen vendor".

Ook bij OSS heb je vaak alsnog te maken met een vendor, zoals in geval van iTop CMDB dat Combodo achter zich heeft staan (zij ontwikkelen die tool), of Zabbix, dat door Zabbix SIA/LLC wordt ontwikkeld.

Je kunt met OSS nagenoeg dezelfde processen gebruiken als bij niet-OSS en in fact, ik vind dat je *altijd* in geval van productkeuze, de breedte moet opzoeken. Dus ook als je verplicht OSS te onderzoeken, vind ik dat je het licentiemodel niet als uitgangspunt moet nemen, maar je onderzoek breed moet doen, waarbij het kan zijn dat je verplicht 1 of 2 OSS alternatieven mee neemt.

Productselectie wijkt niet af in dat geval.

(Ook vendorselectie niet, omdat je denk ik in veruit de meeste gevallen, moet zorgen voor commerciële backing. Dus altijd een partij die, betaald, onderhoud voor je kan doen en effectief supportpartij of zelfs vendor is van het product.)

[sam.vimes]

Wat ik als grootste probleem zie, is de vendor lock-in als je eenmaal voor een propriëtaire oplossing hebt gekozen.
Het is over het algemeen heel moeilijk om over te stappen op een product van een andere leverancier als je niet meer tevreden bent over de geleverde software of dienst. Dit geldt voor zowel OSS als propriëtair.
Een commerciële leverancier ziet zijn klanten natuurlijk liever niet verdwijnen en zal hiertegen drempels opwerpen (contractueel en/of technisch), tenzij je dit in je oorspronkelijke contract hebt afgedekt.
Bij OSS heb je het voordeel dat je niet de medewerking van de oorspronkelijke leverancier nodig hebt: je beschikt over alle broncode en kan een willekeurige softwareleverancier vragen om je te assisteren in de overgang.

[oNNoZeLe]

sam.vimes schreef op woensdag 22 maart 2023 @ 11:42:
Wat ik als grootste probleem zie, is de vendor lock-in als je eenmaal voor een propriëtaire oplossing hebt gekozen.
Het is over het algemeen heel moeilijk om over te stappen op een product van een andere leverancier als je niet meer tevreden bent over de geleverde software of dienst. Dit geldt voor zowel OSS als propriëtair.
Een commerciële leverancier ziet zijn klanten natuurlijk liever niet verdwijnen en zal hiertegen drempels opwerpen (contractueel en/of technisch), tenzij je dit in je oorspronkelijke contract hebt afgedekt.
Bij OSS heb je het voordeel dat je niet de medewerking van de oorspronkelijke leverancier nodig hebt: je beschikt over alle broncode en kan een willekeurige softwareleverancier vragen om je te assisteren in de overgang.

voor veel software in de overheid is dat "minder moeilijk".. tussen haakjes omdat het natuurlijk te licht uitgedrukt is.

De huidige software die we hebben moeten we aanbesteden. Dit proces zorgt er voor dat je vanzelf aan het einde van een contract komt en dus opnieuw moet beginnen en dit geeft de mogelijkheid om bij vervanging na te denken over een conversie of met een schone lei te beginnen.

Dit zal bij een overstap naar OSS natuurlijk net zo kunnen.

Een nadeel bij OSS en gemeenten is dat bijna geen enkele gemeente hetzelfde is waardoor 'one size fits all' voor proces ondersteunende applicaties niet overal goed zal gaan.

[F_J_K]

sam.vimes schreef op woensdag 22 maart 2023 @ 11:42:
Wat ik als grootste probleem zie, is de vendor lock-in als je eenmaal voor een propriëtaire oplossing hebt gekozen.
Het is over het algemeen heel moeilijk om over te stappen op een product van een andere leverancier als je niet meer tevreden bent over de geleverde software of dienst. Dit geldt voor zowel OSS als propriëtair.
Een commerciële leverancier ziet zijn klanten natuurlijk liever niet verdwijnen en zal hiertegen drempels opwerpen (contractueel en/of technisch), tenzij je dit in je oorspronkelijke contract hebt afgedekt.
Bij OSS heb je het voordeel dat je niet de medewerking van de oorspronkelijke leverancier nodig hebt: je beschikt over alle broncode en kan een willekeurige softwareleverancier vragen om je te assisteren in de overgang.

Is dat zo, voor minder kosten dan de data en processen migreren?

Even de slecht gedocumenteerde code leren kennen, plus de niet gedocumenteerde datamodellen. Die over de afgelopen 10 jaar aan onderhoud steeds wat zijn veranderd met een variëteit aan kwaliteit in documenteren. De code helpt, maar ik zou niet verwachten dat je er heel erg veel aan gaat hebben en dat migreren van data en processen makkelijker is.

Ik heb bij een grote complexe opdracht zoiets ooit getest: de huidige code & documentatie geven aan potentiële opdrachtnemers en zien of ze de boel draaiende krijgen en om te onderhouden. Bleek dat de originele devvers het zelf ook niet binnen redelijke termijnen konden op basis van alleen de beschikbare code & documentatie.

Sowieso is het wat migratie en lock-in betreft dan zaak om afspraken te hebben over altijd de data kunnen krijgen, vooral bij SaaS waar je niet zomaar in de database kunt duiken. De code hebben verandert daar weinig aan.

Open source kan zeker helpen om het zelf over te nemen, maar IMHO is migreren dan makkelijker als je niet zelf een kamer vol zichzelf vervelende devvers hebt.

[CAPSLOCK2000]

De focus op prijs en TCO is niet juist.
De overheid wil niet naar Open Source omdat dit op korte termijn financieel voordeel oplevert. Het gaat om macht, controle en afhankelijkheid (zowel van bedrijven als van andere landen, denk aan de positie waarin Rusland zit nu ze geen Amerikaanse en Europese software meer kunnen kopen). De enige rol die geld speelt in deze discussie is dat het wel betaalbaar moet zijn. Als je dit project benadert als bezuiniging dan mis je het punt.

Op korte termijn is het altijd goedkoper om iets kant-en-klaar van de plank te kopen.
Strategisch gezien gaat afhankelijkheid ook over kosten maar dat is meer iets voor de zeer lange termijn.


Natuurlijk is het niet de bedoeling om alle overheids IT in één klap om te zetten, zo werkt dat nooit. Als je wil veranderen dan stel je nú nieuwe regels en de volgende keer dat er software nodig is ga je de nieuwe regels volgen. Zo worden de nieuwe regels langzaam maar zeker ingevoerd. Daar zal ook software bij zitten die 25 jaar mee gaat en dus zal het altijd een langdurig proces zijn.

[CAPSLOCK2000]

eric.1 schreef op woensdag 22 maart 2023 @ 09:54:
Open source software is transparant, maar het gebruik ervan maakt een organisatie dat nog niet.

Dat klopt, ik zie het dus meer omgekeerd: Closed source software maakt je organisatie minder transparant.

[unezra]

CAPSLOCK2000 schreef op woensdag 22 maart 2023 @ 14:24:
De focus op prijs en TCO is niet juist.
De overheid wil niet naar Open Source omdat dit op korte termijn financieel voordeel oplevert. Het gaat om macht, controle en afhankelijkheid (zowel van bedrijven als van andere landen, denk aan de positie waarin Rusland zit nu ze geen Amerikaanse en Europese software meer kunnen kopen). De enige rol die geld speelt in deze discussie is dat het wel betaalbaar moet zijn. Als je dit project benadert als bezuiniging dan mis je het punt.

Waarom zou het de overheid niet gaan om TCO en er geen focus op prijs zijn?
De overheid werkt meestal met aanbestedingen en die gaan JUIST over prijs.

Zou het daar altijd over moeten gaan? Nee. Maar dat is een heel andere discussie.

Op korte termijn is het altijd goedkoper om iets kant-en-klaar van de plank te kopen.
Strategisch gezien gaat afhankelijkheid ook over kosten maar dat is meer iets voor de zeer lange termijn.

Off-the-shelf gaat niet enkel over kosten, maar ook over bedrijfszekerheid.
Ik snap dat in gevallen maatwerk nodig en onontkoombaar is, maar ik denk dat je, in iedere organisatie, maatwerk zo veel mogelijk moet voorkomen. Niet vanwege de hogere kosten, maar vanwege zaken als maintainability, toekomstbestendigheid, etc.

[Jazzy]

unezra schreef op woensdag 22 maart 2023 @ 17:22:
De overheid werkt meestal met aanbestedingen en die gaan JUIST over prijs.

Nee hoor. Aanbestedingen gaan over transparantie en een eerlijk speelveld. Prijs is slechts één van de vele, soms honderden, criteria waarop gegund wordt.

[oNNoZeLe]

Jazzy schreef op woensdag 22 maart 2023 @ 17:44:
[...]

Nee hoor. Aanbestedingen gaan over transparantie en een eerlijk speelveld. Prijs is slechts één van de vele, soms honderden, criteria waarop gegund wordt.

Soms gaat het inderdaad om prijs, soms kwaliteit, soms de balans tussen die twee..

[F_J_K]

offtopic:
Gunnen obv alleen laagste prijs is in principe verboden. Als laagste prijs al is te definiëren (TCO inclusief schatting interne kosten).

[oNNoZeLe]

F_J_K schreef op donderdag 23 maart 2023 @ 12:30:

offtopic:
Gunnen obv alleen laagste prijs is in principe verboden. Als laagste prijs al is te definiëren (TCO inclusief schatting interne kosten).

tja hoe reageer je op een offtopic reactie ;-)

Het mag wel volgens pianoo als je het maar motiveert.

https://www.pianoo.nl/nl/...van%20subgunningscriteria.

Ontopic,
Boeiend aspect is dat je wellicht bij OSS systemen alleen diensten gaat aanbesteden en geen software.
Dat is een totaal ander bestek en een andere performance.

[oNNoZeLe]

nieuws: Kiesraad: nieuwe verkiezingssoftware wordt dit jaar opgeleverd

Dit had toch mooi opensource kunnen zijn?

[F_J_K]

Yep, schoolvoorbeeld van waar je dat wel zou verwachten: het is uniek genoeg om er niet een markt voor te kunnen zien ontstaan.

Het lijkt ook te gebeuren (of tenminste free as in speech):

Het plan is om de broncode van het Digitaal Hulpmiddel Verkiezingen openbaar beschikbaar te maken.

-

hoe staan jullie tegenover gebruik van niet-opensource maar wel op de markt toegankelijke componenten? Een of andere algemene library gebruiken in code die een andere devver ook kan gebruiken, of bijv. open source op een closed source SQL Server. Ik ben daar wel voorstander van: het vermindert op geen manier de mogelijkheid om naar andere partijen te kunnen stappen.

[downtime]

F_J_K schreef op zaterdag 25 maart 2023 @ 14:33:

hoe staan jullie tegenover gebruik van niet-opensource maar wel op de markt toegankelijke componenten? Een of andere algemene library gebruiken in code die een andere devver ook kan gebruiken, of bijv. open source op een closed source SQL Server. Ik ben daar wel voorstander van: het vermindert op geen manier de mogelijkheid om naar andere partijen te kunnen stappen.

Je zegt dat gebruik van een closed source SQL Server de mogelijkheid om over te stappen niet vermindert. Dat is niet waar. Elke database pakket heeft unieke functionaliteit die concurrenten niet hebben. Tenzij je expliciet als eis stelt dat het product geen vendor-specifieke functionaliteit mag gebruiken (en ook daadwerkelijk ontwikkelt en test met meerdere platformen) is portabiliteit niet gegarandeerd. Daarmee riskeer je een vendor lock-in.

Daarmee wil ik niet zeggen dat closed source verboden moet zijn. Maar je zult expliciet moeten afbakenen. Je kunt bijvoorbeeld specificeren dat minstens 2 of 3 populaire database servers ondersteund moeten worden. Daarmee voorkom je vendor lock-in en maak je de kans een stuk groter dat de code ook in de toekomst voor nieuwe database servers aangepast kan worden. Maar het levert ook extra complexiteit voor de ontwikkelaars op want je zult het allemaal moeten testen. En iemand gaat daar een factuur voor krijgen.

Maar het blijft lastig. Hoe ver wil je gaan? Moet de programmeertaal open source zijn? De ontwikkeltools? Het OS waar de servers op draaien? Libraries?

[F_J_K]

Waarom daar? X86 is geen ARM. Of nog meer lower level? De grens leggen bij DB server of het OS is IMHO arbitrair.

Iedereen kan SQL server-licenties kopen, kan bepaalde libraries gebruiken. Je kunt zonder probleem naar vele andere partijen stappen. Dat is, wat betreft de 99,9% organisaties zonder vele devvers in huis, m.i. reden OS te willen gebruiken.

[downtime]

F_J_K schreef op zaterdag 25 maart 2023 @ 18:12:

Iedereen kan SQL server-licenties kopen, kan bepaalde libraries gebruiken. Je kunt zonder probleem naar vele andere partijen stappen.

Als jij over SQL Server spreekt neem ik aan dat je Microsoft SQL Server bedoelt. En niet een ander RDBMS die SQL als query-taal gebruikt.

Kiezen voor SQL Server levert jou een vendor lock-in op. Leuk dat je zelf een retailer kunt kiezen waar je een SQL Server licentie kan kopen maar dat lost de vendor lock-in niet op. Je zit toch aan Microsoft vast.

En mocht je niet specifiek Microsoft SQL Server bedoelen: Elk SQL RDBMS kent z’n eigen dialect en extra functionaliteit die juist bedoeld is om een vendor lock-in te creëren. Denk in SQL Server bijvoorbeeld aan SSIS en SSAS. Je hoeft IMHO absoluut niet een OSS database pakket te gebruiken maar dan moet je wel goed nadenken hoe je vendor lock-in voorkomt.

[Dido]

CAPSLOCK2000 schreef op woensdag 22 maart 2023 @ 14:26:
Dat klopt, ik zie het dus meer omgekeerd: Closed source software maakt je organisatie minder transparant.

Maar nuttige transparantie zit hem in de data en de processen. En die zitten niet in code. De data is sowieso afgeschermd (en terecht) en de processen zijn voor organisaties zelf al dusdanig transparant dat ze hele legers aan procesanalisten voltijd bezig houden.

Vlekken op je raam maken het raam minder transparant, maar met OS lap je niet de ramen maar spuit je hooguit de blinde muur schoon. Dan zijn er wel een hoop vlekken weg,maar heb je geen iota extra transparantie.

downtime schreef op zaterdag 25 maart 2023 @ 17:22:
Maar het blijft lastig. Hoe ver wil je gaan? Moet de programmeertaal open source zijn? De ontwikkeltools? Het OS waar de servers op draaien? Libraries?

En dan blijft de vraag bij elk van die opties, wat levert het op? En niet alleen financieel, maar zeker ook wat betreft onderhoudbaarheid, toekomstbestendigheid, flexibiliteit, en verantwoording. Met name dat laatste weegt heel erg zwaar bij de overheid, en kan heel makkelijk roet in het eten gooien zodra je van de gebaande paden afwijkt.

Ik denk dat de bestaande slechte relatie tussen overheid en IT(-projecten) heel andere en veel diepere oorzaken kent dan het al dan niet gebruiken van OS. En ik denk dat, als je erin slaagt om die echte problemen aan te pakken, met OS erg weinig nuttigs gaat toevoegen.

Er wordt een aantal keer geopperd dat OS met name voor maatwerk nuttig zou zijn, maar ten eerste is maatwerk welhaast vloeken bij overheids-IT (het lijkt soms wel religieus!), daarnaast vraag ik me serieus af wat voor OS-ontwikkeltools en platformen je voor zulk maatwerk zou kunnen inzetten die ook in de markt nog eens breed ondersteund zijn (anders zit je met een OS vendor lock-in, en dat is niets beter dan elke andere vendor lock-in).

[downtime]

Dido schreef op zondag 26 maart 2023 @ 13:59:
[...]

Maar nuttige transparantie zit hem in de data en de processen. En die zitten niet in code. De data is sowieso afgeschermd (en terecht) en de processen zijn voor organisaties zelf al dusdanig transparant dat ze hele legers aan procesanalisten voltijd bezig houden.

Transparantie zit zeker ook in algorithmes. Je moet niet de kost geven aan organisaties die hun bestaande software niet (of alleen met veel moeite) kunnen vervangen omdat ze zelf niet meer weten hoe die processen in elkaar zitten (en vooral: waarom ze zo in elkaar zitten). Dat probleem los je weliswaar niet op met OSS maar gewoon ter illustratie hoe belangrijk de source code kan zijn.

Daarnaast mag de puinhoop bij de Belastingdienst ook als illustratie dienen dat processen soms helemaal niet transparant zijn. Nog steeds kan (of wil) niemand uitleggen hoe die puinhoop tot stand is gekomen omdat belangrijke beslissingen nooit vastgelegd zijn. Zonder inzicht in de software is ook het enige bewijs dat bepaalde algorithmes uberhaupt bestaan weg.

Ik denk dat de bestaande slechte relatie tussen overheid en IT(-projecten) heel andere en veel diepere oorzaken kent dan het al dan niet gebruiken van OS. En ik denk dat, als je erin slaagt om die echte problemen aan te pakken, met OS erg weinig nuttigs gaat toevoegen.

Klopt. Die slechte relatie heeft andere oorzaken. En kan daarom ook geen argument zijn om niet met OSS te beginnen. Het gaat hier (mede) om de relatie tussen burger en overheid.

Er wordt een aantal keer geopperd dat OS met name voor maatwerk nuttig zou zijn, maar ten eerste is maatwerk welhaast vloeken bij overheids-IT (het lijkt soms wel religieus!)

En terecht. Maar onherroepelijk zal er altijd maatwerk bij de overheid zijn omdat je nu eenmaal niet voor elke overheidstaak standaard software kunt kopen. En voor die maatwerk is OSS prima.

, daarnaast vraag ik me serieus af wat voor OS-ontwikkeltools en platformen je voor zulk maatwerk zou kunnen inzetten die ook in de markt nog eens breed ondersteund zijn (anders zit je met een OS vendor lock-in, en dat is niets beter dan elke andere vendor lock-in).

Dat hangt er vanaf hoever je wilt gaan. Java is een behoorlijk ondersteunt ecosysteem wat niet volledig op Oracle leunt. Met .NET Core gaat Microsoft aardig die kant op al is dat misschien te afhankelijk van Visual Studio. PHP en Python gaan nog wat verder. Zelfs in C/C++ kun je platformonafhankelijk ontwikkelen mits je dat vanaf de eerste regel code als expliciet doel stelt.

[oNNoZeLe]

Dido schreef op zondag 26 maart 2023 @ 13:59:
[...]

Maar nuttige transparantie zit hem in de data en de processen. En die zitten niet in code. De data is sowieso afgeschermd (en terecht) en de processen zijn voor organisaties zelf al dusdanig transparant dat ze hele legers aan procesanalisten voltijd bezig houden.

Vlekken op je raam maken het raam minder transparant, maar met OS lap je niet de ramen maar spuit je hooguit de blinde muur schoon. Dan zijn er wel een hoop vlekken weg,maar heb je geen iota extra transparantie.


[...]

En dan blijft de vraag bij elk van die opties, wat levert het op? En niet alleen financieel, maar zeker ook wat betreft onderhoudbaarheid, toekomstbestendigheid, flexibiliteit, en verantwoording. Met name dat laatste weegt heel erg zwaar bij de overheid, en kan heel makkelijk roet in het eten gooien zodra je van de gebaande paden afwijkt.

Ik denk dat de bestaande slechte relatie tussen overheid en IT(-projecten) heel andere en veel diepere oorzaken kent dan het al dan niet gebruiken van OS. En ik denk dat, als je erin slaagt om die echte problemen aan te pakken, met OS erg weinig nuttigs gaat toevoegen.

Er wordt een aantal keer geopperd dat OS met name voor maatwerk nuttig zou zijn, maar ten eerste is maatwerk welhaast vloeken bij overheids-IT (het lijkt soms wel religieus!), daarnaast vraag ik me serieus af wat voor OS-ontwikkeltools en platformen je voor zulk maatwerk zou kunnen inzetten die ook in de markt nog eens breed ondersteund zijn (anders zit je met een OS vendor lock-in, en dat is niets beter dan elke andere vendor lock-in).

Voor gemeenten zijn er mensen die daarvoor het commonground gedachte ontwikkeld hebben. opslag, logica etc allemaal in gescheiden lagen. https://commonground.nl/
Ook dit moet zich allemaal nog goed bewijzen.

Als laatste, ik ben dit draadje gestart juist omdat overheid ZELF deze ambitie aan zichzelf opgelegd heeft. De VNG/Gemeenten hebben zich hier 'gewoon' bij aangesloten, waarbij ik mijzelf echt afvraag wat het moet opleveren, wat het kan opleveren en tegen welke prijs..

[CptKemel]

Ik heb dit ook al eens onder een frontpage-artikel gepost: het grootste voordeel wat ik zie voor doorsnee gebruikers is de enorme hoeveelheid aan artikelen, YouTube videos, blogposts, en andere vormen van "informele support" die met bijvoorbeeld MS Office verbonden is.

Als ik iets moet doen in Excel maar ik weet niet hoe, dan is een zoekopdracht meestal voldoende om het probleem op te lossen danwel een flink eind te komen, bijvoorbeeld omdat een of andere forumuser in 2015 het ook al eens geprobeerd heeft, of iets vergelijkbaars, en werkend heeft gekregen. Zelfs de beruchte topics-zonder-terugmelding/-oplossingsbevestiging hebben heel veel nuttige informatie in hun posts.

Dat is voor veel gebruikers, mijzelf incluis, een echt enorm voordeel van de vendor lock-in die MIcrosoft heeft bewerkstelligd.

Vast en zeker wordt dit inmiddels door Microsoft flink in stand gehouden door kanalen en influencers te sponsoren (een soort "astroturfing" van deze vorm van support) - ook iets wat ik bij een open-source pakket minder verwacht.

[CAPSLOCK2000]

F_J_K schreef op zaterdag 25 maart 2023 @ 14:33:
hoe staan jullie tegenover gebruik van niet-opensource maar wel op de markt toegankelijke componenten? Een of andere algemene library gebruiken in code die een andere devver ook kan gebruiken, of bijv. open source op een closed source SQL Server. Ik ben daar wel voorstander van: het vermindert op geen manier de mogelijkheid om naar andere partijen te kunnen stappen.

Daar sta ik negatief tegenover omdat het maar één van de aspecten van Open Source verzorgt (beschikbaarheid) en niet eens heel erg goed. Alleen al rond het thema beschikbaarheid blijven een hoop problemen onopgelost. Met name hoe je zorgt dat zo'n component toegankelijk blijft.

Vragen die dan bij me opkomen zijn:
Hoe voorkom je dat de prijs omhoog vliegt zodra je er van afhankelijk bent?
Mag de leverancier nieuwe features toevoegen (waardoor je niet meer naar een alternatief kan overstappen)?
Wat doe je als de leverancier geen onderhoud meer kan of wil geven?
Wat als er een handelsverbod komt waardoor de leverancier het niet meer mag verkopen?
Mag de leverancier nieuwe features toevoegen (waardoor je niet meer naar een alternatief kan overstappen)?

Die laatste vragen gaan misschien wat ver maar als we het specifiek over overheids-IT hebben vind ik het er wel bij horen.

Er zijn wel oplossingen te bedenken maar die moeten er wel bij om het een eerlijke vergelijking te maken en ik denk dat een deel van de oplossingen in praktijk onacceptabel zou zijn.

Zowel China en Rusland hebben besloten dat ze een eigen OS en software-industrie nodig hebben om niet afhankelijk te zijn van de VS. Nu wil ik niet zeggen dat het allemaal heel vlotjes gaat maar dat laat alleen maar zien dat die afhankelijkheid een echt probleem is.

downtime schreef op zaterdag 25 maart 2023 @ 17:22:
Maar het blijft lastig. Hoe ver wil je gaan? Moet de programmeertaal open source zijn? De ontwikkeltools? Het OS waar de servers op draaien? Libraries?

Daarom wil ik geen "Open Source" maar "Free Software". Die twee worden vaak door elkaar gehaald maar er is verschil. "Open Source" betekent strict genomen alleen dat de source "open" is. "Free Software" gaat verder en is meer een filosofie rond het onderwerp "Vrijheid". De Free Software Foundation heeft al een paar decennia nagedacht over de vragen die je stelt.

FSF stelt dat alles open moet zijn tot aan de hardware toe. De insteek van de FSF is ongeveer: Alles moet beschikbaar zijn om hetzelfde resultaat te krijgen (bv dezelfde binary) en daarbij moeten alle hulpmiddelen beschikbaar zijn hun 'voorkeursvorm'. Daarmee wordt in de eerste plaats broncode bedoelt maar het kan ook over andere data gaan, bv de ongecomprimeerde versie van plaatjes en alle gebruikte lettertypes.
Het gaat ook over compilers, assemblers, packagers, libraries en al het andere wat nodig is om software te bouwen en te gebruiken. En als er een digitale handtekening nodig is om iets te laten werken moet daar ook een oplossing voor zijn.

F_J_K schreef op zaterdag 25 maart 2023 @ 18:12:
Waarom daar? X86 is geen ARM. Of nog meer lower level? De grens leggen bij DB server of het OS is IMHO arbitrair.

Eens. Hardware hoort er ook bij en dat X86 en ARM niet open zijn is problematisch. RISC-V is (wat dat betreft) beter.

Iedereen kan SQL server-licenties kopen, kan bepaalde libraries gebruiken. Je kunt zonder probleem naar vele andere partijen stappen. Dat is, wat betreft de 99,9% organisaties zonder vele devvers in huis, m.i. reden OS te willen gebruiken.

Nu zit ik toevallig midden in een groot database-migratie project. We hebben licenties voor een bekende database maar dat is niet meer houdbaar in de huidige vorm. De leverancier weet dat we afhankelijk zijn en de prijs vliegt om hoog op een manier die voelt als chantage. We moeten overstappen voordat het hele budget opgaat aan dat ene product. Bij iedere stap die we willen doen blijken er echter nieuwe afhankelijkheden te zijn waardoor er meer geld moet naar de leverancier waar we van af willen voor extra licenties en consultants.

Om even terug te gaan naar de eerdere vraag:

hoe staan jullie tegenover gebruik van niet-opensource maar wel op de markt toegankelijke componenten?

Ik zie het een beetje als "a la carte" vs "het menu" of een "samenlevingscontract" vs "trouwen onder huwelijkse voorwaarden". Bij het menu/huwelijk krijg je een standaard pakket waar lang en goed over is nagedacht zodat en er geen grote problemen zijn. De Free Sotware filosofie is ook zo'n standaard pakket.

Je hoeft dat pakket niet te gebruiken om een bepaalde uitkomst te krijgen, maar dan zal je zelf beter moeten opletten en antwoorden bedenken op vragen zoals die ik hierboven stelde. Dat is bepaald niet makkelijk en volgens mij is de Free Software filosofie de beste oplossing die we hebben.


Dat zowel Rusland als China als India er voor hebben gekozen om hun nationale software te baseren op een (van oorsprong) Europees OS dat (tegenwoordig) voor door Amerikanen wordt ontwikkelt zegt wat mij betreft wel iets over het vertrouwen in het model.

Misschien moet ik nog even toevoegen dat je nog steeds afhankelijk kan raken van bepaalde software, dat wordt niet voorkomen. Het verschil zit in de gevolgen van de afhankelijkheid en wat je er aan kan doen. De FSF heeft heel hard geprobeerd om te zorgen dat er nooit een doodlopende weg is.

[Dido]

downtime schreef op zondag 26 maart 2023 @ 14:36:
Klopt. Die slechte relatie heeft andere oorzaken. En kan daarom ook geen argument zijn om niet met OSS te beginnen. Het gaat hier (mede) om de relatie tussen burger en overheid.

Een simpel argument tegen elke verandering is de investering die nodig is. Zolang er geen ROI lijkt te zijn is dat een heel valide reden om niet te veranderen.

Als je gaat veranderen omdat je geen reden ziet om het niet te doen, ben je aan het veranderen om hjet veranderen. Dan kun j enu 20 jaar investeren in een transitie naar OS, en daarna, met dezelfde zwakker argumenten weer een transitie beginnen de andere kant op.

En hoewel dit belachelijk klinkt is dit helaas wel wat ik van dichtbij zie gebeuren.

En terecht. Maar onherroepelijk zal er altijd maatwerk bij de overheid zijn omdat je nu eenmaal niet voor elke overheidstaak standaard software kunt kopen. En voor die maatwerk is OSS prima.

Maar ik heb nog steeds geen enkel daadwerkelijk voordeel gezien om voor dat maatwerk OSS te gaan gebruiken.

Dat hangt er vanaf hoever je wilt gaan. Java is een behoorlijk ondersteunt ecosysteem wat niet volledig op Oracle leunt. Met .NET Core gaat Microsoft aardig die kant op al is dat misschien te afhankelijk van Visual Studio. PHP en Python gaan nog wat verder. Zelfs in C/C++ kun je platformonafhankelijk ontwikkelen mits je dat vanaf de eerste regel code als expliciet doel stelt.

Maar dan ga je OS werken om OS te werken. Ik zie nog steeds geen onderliggende motivatie behalve "OSS is gaaf!"
Sowieso zit je nog met de hobbel dat de overheid, net als elk bedrijf, een enorme shitload aan de facto legacy-software gebruikt (de BD adverteerde een paar jaar terug nog met het feit dat je als mainframe-programmeur aan de slag kon bij ze )en dat voor het volledig herschrijven daarvan op welk nieuw platform dan ook geen realistische business case (of politieke wil) bestaat.

oNNoZeLe schreef op zondag 26 maart 2023 @ 14:42:
Voor gemeenten zijn er mensen die daarvoor het commonground gedachte ontwikkeld hebben. opslag, logica etc allemaal in gescheiden lagen. https://commonground.nl/
Ook dit moet zich allemaal nog goed bewijzen.

In het geval van gemeenten heb je het stomtoevallig over een dikke driehonderd vrijwel identieke instanties die allemaal vrijwel dezelfde taken uitvoeren. Daar heb je heel snel voordeel van processtandaardisering en hergebruik van software.

Maar ondanks het feit dat de VNG vindt dat zij het belangrijkste deel van de overheid zijn (zoals elke overheidsinstantie ) zijn er nog onnoemelijk veel andere onderdelen van de overheid en semi-overheid waar dergelijke standaardisering een utopie is.

Als laatste, ik ben dit draadje gestart juist omdat overheid ZELF deze ambitie aan zichzelf opgelegd heeft.

"De overheid" legt zichzelf wel vaker dingen op, maar dat betekent nog niet dat het verstandig is. Hell, we zitten al tijden met opeenvolgende kabinetten die zichzelf regels opleggen om ze vervolgens zelf met voeten te treden

De VNG/Gemeenten hebben zich hier 'gewoon' bij aangesloten, waarbij ik mijzelf echt afvraag wat het moet opleveren, wat het kan opleveren en tegen welke prijs.

Ik denk dat het idee van hergebruik en processtandaardisering juist bij gemeenten wel winst op kan leveren, maar daarmee heb je maar een miniem deel van "de overheid" te pakken. Los van het feit dat ik niet zie hoe OS per se beter helpt bij die zaken dan proprietary software of platformen.
Standaardisering klinkt leuk, maar een van de meest voor de hand liggende kandidaten daarvoor (de GBA vervangen door een gecentraliseerde BRP) bleek te moeilijk en ingewikkeld waardoor het project na ettelijke miljoenen investering werd afgeblazen.

Intussen blijven we zitten met een enorm ingewikkeld landschap van welhaast ontelbare (semi-)overheidsinstellingen die, overspoeld met projectmanagers, architecten, adviseurs, consultants, kwartiermakers, businessanalisten en meer van dat soort baantjescarrouseltijgers proberen hun software aan de wijzigende wetgeving, normering en constant veranderende buitenwereld te laten voldoen.
Dan kan de zoveelste club dikbetaalde advisuers in Den Haag wel roepen dat alles OS moet worden, maar dat komt echt niet automagisch boven aan de proriteitenlijst te staan. Daar staan wettelijke juistheid, tijdigheid en verantwoording. Die laatste neemt soms al een heel kwartaal van een hele IT-afdeling in beslag , helaas.

Ik vermoed dat er heel weinig beslisbevoegden bij overheidsinstellingen zitten te wachten op derden die vragen gaan stellen of commentaar gaan leveren op sourcecode van hun instelling, ze liggen al genoeg onder de loep vanuit Den Haag en de pers om bij elke beslissing zeven kleuren te schijten uit angst voor mogelijke fouten. Openheid en transparantie klinkt heel leuk, maar niet voor organisaties die een angstcultuur hebben ontwikkeld waar menig dictator nog een puntje aan kan zuigen.

Daar wordt trouwens ook wat aan gedaan hoor, ook voor dat probleem worden werkgroepen, commissies en afdelingen volgepropt met carrouselrijders die na tonnen, zo niet miljoenen, met klinkende adviezen komen zoals "de angstcultuur moet worden aangepakt". Maar intussen durft een overheidsinstelling het verantwoordelijke ministerie niet eerlijk te informeren over falende projecten, gemaakte fouten of ontstane problemen. En daar zit soms nog een laag politiek belang tussen waar ik liever geen weet van had gehad.

[downtime]

Dido schreef op maandag 27 maart 2023 @ 11:31:
[...]

Een simpel argument tegen elke verandering is de investering die nodig is. Zolang er geen ROI lijkt te zijn is dat een heel valide reden om niet te veranderen.

Als je gaat veranderen omdat je geen reden ziet om het niet te doen, ben je aan het veranderen om hjet veranderen. Dan kun j enu 20 jaar investeren in een transitie naar OS, en daarna, met dezelfde zwakker argumenten weer een transitie beginnen de andere kant op.

Je redeneert volledig vanuit je eigen perspectief: Ik zie een probleem, OSS lost het niet op, dus OSS invoeren is zinloos. Misschien moet je gewoon het topic lezen en even kijken waarom andere mensen wel voordelen in OSS zien.

Maar ik heb nog steeds geen enkel daadwerkelijk voordeel gezien om voor dat maatwerk OSS te gaan gebruiken.

Transparantie. Hergebruik van zaken die met belastinggeld zijn gemaakt. Potentieel lagere kosten op langere termijn. Verminderen van vendor lock-in en afhankelijkheid van leveranciers. Allemaal eerder in dit topic genoemd.

Maar dan ga je OS werken om OS te werken. Ik zie nog steeds geen onderliggende motivatie behalve "OSS is gaaf!"

Je ziet het niet omdat je alles wat al gezegd is negeert. Letterlijk helemaal niemand heeft het over "OSS is gaaf" gehad. Dat is de stroman die je zelf opzet. Want dat is makkelijker dan argumenten lezen en daarop reageren.

Sowieso zit je nog met de hobbel dat de overheid, net als elk bedrijf, een enorme shitload aan de facto legacy-software gebruikt (de BD adverteerde een paar jaar terug nog met het feit dat je als mainframe-programmeur aan de slag kon bij ze )en dat voor het volledig herschrijven daarvan op welk nieuw platform dan ook geen realistische business case (of politieke wil) bestaat.

Niemand heeft gezegd dat alles herschreven moet worden. Niemand wil voor tientallen miljarden aan maatwerk software herschrijven "omdat het kan". Maar voor nieuwe projecten kan OSS prima. Je moet ergens beginnen.

In het geval van gemeenten heb je het stomtoevallig over een dikke driehonderd vrijwel identieke instanties die allemaal vrijwel dezelfde taken uitvoeren. Daar heb je heel snel voordeel van processtandaardisering en hergebruik van software.

Juist. Dus wat is jouw bezwaar?

Maar ondanks het feit dat de VNG vindt dat zij het belangrijkste deel van de overheid zijn (zoals elke overheidsinstantie ) zijn er nog onnoemelijk veel andere onderdelen van de overheid en semi-overheid waar dergelijke standaardisering een utopie is.

Ongetwijfeld. Maatwerk wordt meestal niet ontwikkeld omdat "het gaaf is" maar omdat het niet anders kan. Maar standaardisering is niet de enige reden voor OSS.

Ik denk dat het idee van hergebruik en processtandaardisering juist bij gemeenten wel winst op kan leveren, maar daarmee heb je maar een miniem deel van "de overheid" te pakken. Los van het feit dat ik niet zie hoe OS per se beter helpt bij die zaken dan proprietary software of platformen.

Je bent aan het navelstaren. Je denkt dat OSS alleen goed is als het de overheid helpt. Maar de overheid is er voor de burger. En transparantie is een essentieel onderdeel van democratie. Closed source software staat op gespannen voet met transparantie.

Dan kan de zoveelste club dikbetaalde advisuers in Den Haag wel roepen dat alles OS moet worden, maar dat komt echt niet automagisch boven aan de proriteitenlijst te staan. Daar staan wettelijke juistheid, tijdigheid en verantwoording. Die laatste neemt soms al een heel kwartaal van een hele IT-afdeling in beslag , helaas.

Daarom zou de rijksoverheid het op de prioriteitenlijst erbij moeten zetten. Niet denken dat het vanzelf wel gebeurt.

Ik vermoed dat er heel weinig beslisbevoegden bij overheidsinstellingen zitten te wachten op derden die vragen gaan stellen of commentaar gaan leveren op sourcecode van hun instelling, ze liggen al genoeg onder de loep vanuit Den Haag en de pers om bij elke beslissing zeven kleuren te schijten uit angst voor mogelijke fouten. Openheid en transparantie klinkt heel leuk, maar niet voor organisaties die een angstcultuur hebben ontwikkeld waar menig dictator nog een puntje aan kan zuigen.

De beste manier om problemen bij de overheid aan te pakken is niet door die organisaties te helpen om nog meer onder de mat te schuiven. De beste manier is door toezicht en transparantie af te dwingen. Denk jij dat de toeslagenaffaire was gebeurd als de BD een open en transparante organisatie met afdoende toezicht was geweest?

En ja, het is vervelend werken als elk foutje in de pers en de politiek wordt opgeblazen, en het is geen gezonde manier om met elkaar om te gaan. Maar dat kan nooit een reden zijn om maar voor geheimhouding te kiezen. Want dat leidt op lange termijn alleen maar tot meer problemen.

[Falcon]

Mijn mening is vrij simpel:

OSS is in dit geval een politieke keuze en geen technische, implementatie of architecturale keuze.

Vandaar uit zou ik dit topic niet onder "Linux en overige clients" laten vallen, want dan ga je te snel zitten in oplossingen en inventarisatie van wat er dan allemaal OSS zou kunnen. Maar meer onder een politiek forum.

Politiek technisch zou je dit misschien kunnen laten vallen onder partijen die transparantie rondom bijv. Algoritmes vanuit de overheid belangrijk vinden, maar dit gaat nog veel verder dan dat.

In mijn optiek gebeurt erop dit vlak helemaal niks, als men niet eerst in Den Haag een kabinet heeft zitten die daar een beslissing over (durft) te nemen. En heel misschien komt er dan ooit "ambitie" voor OSS (zie topic titel).

[ Voor 3% gewijzigd door Falcon op 27-03-2023 12:43 ]

[Dido]

downtime schreef op maandag 27 maart 2023 @ 12:21:
Misschien moet je gewoon het topic lezen en even kijken waarom andere mensen wel voordelen in OSS zien.

Misschien wel, maar de eerste drie keer hebben niets opgeleverd.
kijken.

Transparantie.

Heel weinig tot niets, dus. Dat is je muur schoonspuiten omdat je raam vies is.

Hergebruik van zaken die met belastinggeld zijn gemaakt.

Dat is ook al meerdere keren weerlegd. En dan wordt de scope opeens verkleind tot maatwerk, dat dus niet herbruikbaar is.

Potentieel lagere kosten op langere termijn.

Alleen bij herbruik, wat dus niet of nauwelijks opgaat.

Verminderen van vendor lock-in en afhankelijkheid van leveranciers.

Daar heb ik ook nog steeds geen overtuigend argument voor gezien. Het is een utopie om te denken dat je een bestaand complex stuk maatwerk eenvoudig overdraagt aan een nieuwe toko voor onderhoud. Ontwikkeling, ondersteuning en uitbreiding van software is meer dan alleen een code-base. Je echte lock-in zit op een gegeven moment in de domeinkennis die een leverancier opbouwt. En dat is 100% onafhankelijk van een framework, platform, licentiemodel of taal.

Allemaal eerder in dit topic genoemd.

En allemaal al eerder in dit topic weerlegd.

Je ziet het niet omdat je alles wat al gezegd is negeert. Letterlijk helemaal niemand heeft het over "OSS is gaaf" gehad. Dat is de stroman die je zelf opzet. Want dat is makkelijker dan argumenten lezen en daarop reageren.

Ik zou nu iets heel flauws kunenn zeggen over het negeren van de weerleggingen van de genoemde "argumenten", maar ik zal het maar niet doen

Niemand heeft gezegd dat alles herschreven moet worden. Niemand wil voor tientallen miljarden aan maatwerk software herschrijven "omdat het kan". Maar voor nieuwe projecten kan OSS prima. Je moet ergens beginnen.

Het "kan", maar wat is dan het voordeel?
Software gaat decennia mee, dus als er al voordelen aan OSS zijn ga je die pas op heel lange termijn merken. Een termijn die veel langer is dan de strategische planningstermijn bij overheidsinstanties (die veelal een softwarelandschap hebben waar nu al 20 vernieuwende ideeen en paradigma's in staat van oorlog naast elkaar leven.)

Juist. Dus wat is jouw bezwaar?

Dat het feit dat er een case te maken is om bij gemeenten het e.e.a. te standaardiseren (al dan niet met OS, daar zie ik nog steeds niet direct een enorm voordeel van) niet betekent dat het dus een goed idee is om overal maar OS te willen implementeren.

Ik ben enorm voorstander van hamers om spijkers in hout te meppen. Ik ben fervent tegenstander van het gebruik van hamers om alle bevestigingsmaterialen aan te brengen. En dat laatste is het onderwerp van dit topic (dat is een pleonasme, sorry.)

Ongetwijfeld. Maatwerk wordt meestal niet ontwikkeld omdat "het gaaf is" maar omdat het niet anders kan. Maar standaardisering is niet de enige reden voor OSS.

Ik heb nog geen andere redenen gezien die mij overtuigen. (Wel genoeg die mij niet overtuigen, ondanks je aanname dat ik niet kan of wil lezen.)

Je bent aan het navelstaren. Je denkt dat OSS alleen goed is als het de overheid helpt. Maar de overheid is er voor de burger. En transparantie is een essentieel onderdeel van democratie. Closed source software staat op gespannen voet met transparantie.

Hoe verhoogt het openbaar maken van sourcecode de transparantie van een overheidsorganisatie?
De enige voorbeelden die bij me opkomen zijn zeer uitzonderlijke gevallen:
Ten eerste de corona-chack app, een use-case die (hoop ik) redelijk uniek te noemen is.
Ten tweede noemde iemand de "vlag-algoritmes" bij de belastingdienst die mensen automatisch als fraudeur wegzetten.

Van die laatste zou je terecht kunnen beargumenteren dat het de burger voordeel had opgeleverd als die meuk eerder aan het licht was gekomen. Ik betwijfel echter dat de kans substantieel is dat dergelijke zaken (op tijd) opgemerkt worden als er opeens de sourcecode van duizenden hoogspecialistische applicaties on-line komt. Ik vermoed dat er niet een enorme overlap zit tussen degenen die die sourcecode kunnen lezen en begrijpen, en degenen die voeldoende domeinkennis van de betreffende materie hebben.
Ik zie wel een risico in (welwillende!) oplettende burgers die de media en socials gaan overspoelen met bakken aan al dan niet terechte enorme fouten in overheidssoftware, en daarmee het toch al wankele vertrouwen in die overheid nog verder vernaggelen.

Daarom zou de rijksoverheid het op de prioriteitenlijst erbij moeten zetten. Niet denken dat het vanzelf wel gebeurt.

Heb je enig idee wat er gebeurt met iets dat op nummer 4 staat op de prioriteitenlijst bij een overheidsinstelling?

De beste manier om problemen bij de overheid aan te pakken is niet door die organisaties te helpen om nog meer onder de mat te schuiven. De beste manier is door toezicht en transparantie af te dwingen. Denk jij dat de toeslagenaffaire was gebeurd als de BD een open en transparante organisatie met afdoende toezicht was geweest?

En door transparantie af te dwingen denk jij dat je de angstcultuur in die organisaties gaat veranderen? Ik zou wel twee keer nadenken voordat ik een regel code zou durven schrijven en inchecken bij of voor een overheidsorganisatie.
Hooguit een aanroep naar een functie in een stuk closed-source code (en ga maar aantonen dat dat stuk closed-cource code onterecht closed source is )

En ja, het is vervelend werken als elk foutje in de pers en de politiek wordt opgeblazen, en het is geen gezonde manier om met elkaar om te gaan. Maar dat kan nooit een reden zijn om maar voor geheimhouding te kiezen. Want dat leidt op lange termijn alleen maar tot meer problemen.

Het is niet alleen "vervelend". Ik kan je uit ervaring vertellen dat het een manier van werken is die dusdanig giftig is dat het de gezondheid van mensen direct in gevaar brengt.
De overheid heeft nu al moeite om goede IT-ers te vinden en te behouden, dat gaat er niet op vooruit als je jezelf moet gaan adverteren met "we laten heel Nederland je sourcecode reviewen op Twitter!"

Ik wil trouwens ook je valse tegenstelling nuanceren. Het niet publiceren van alle sourcode staat niet gelijk aan alles geheimhouden. Sterker nog, als je transparantie wilt (en daar ben ik echt niet op tegen) dan moet je dat op procesniveau doen, daar is veel meer winst te behalen.

Maar zelfs als die transparantie er is lost dat niet alles op. Ik heb gezien dat iemand pas na lange tijd een (tegen die tijd heel hoge!) factuur kreeg van een overheidsinstantie. Lag dat aan die instantie? Nee, het bleek dat een gemeente verzuimd had een wijziging door te voeren in de GBA.
Hier werd een burger benadeeld, terwijl diezelfde burger op ieder moment had kunnen zien dat er gegevens niet correct waren in de GBA (want die is transparant toegankelijk voor je eigen gegevens).

Dan kan de betreffende organisatie die de factuur stuurde wel de sourcecode online zetten van de applicaties die de GBA-gegevens ontvangen, verwerken, de te betalen bedragen berekend, de facturen aanmaakt, de facturen opmaakt, de verzending van die facturen verzorgt en de 300 andere applicaties die ergens in de stroom zitten, maar daar was de betreffende burger geen fluit mee opgeschoten.

Transparantie? Helemaal voor, maar het sec publiceren van sourcecode is niet alleen een druppel op een gloeiende plaat, het vergroot de druk op overheidsinstanties nog veel meer, waar de kwaliteit van de dienstverlening aan de burger alleen maar onder lijdt.

Moet het anders? Jazeker! Maar niet met een hamer, en al helemaal niet omdat iemand ooit ergens met enige mate van succes een hamer geprobeerd heeft.

[Dido]

Falcon schreef op maandag 27 maart 2023 @ 12:42:
Politiek technisch zou je dit misschien kunnen laten vallen onder partijen die transparantie rondom bijv. Algoritmes vanuit de overheid belangrijk vinden, maar dit gaat nog veel verder dan dat.

In mijn optiek gebeurt erop dit vlak helemaal niks, als men niet eerst in Den Haag een kabinet heeft zitten die daar een beslissing over (durft) te nemen. En heel misschien komt er dan ooit "ambitie" voor OSS (zie topic titel).

Precies, eerst maar eens wat doen aan de angstcultuur binnen de overheid (die zorgt voor verzwijgen van dingen), gevolgd door meer openheid over processen en algoritmes.

Als dat allemaal op de rails is, kun je wellicht de nieuwe situatie verder verbeteren door ook inzage te geven in hoe die processen en algoritmes geimplemteerd zijn.

Als je in de huidige situatie opeens implementaties op straat gooit wordt er niet veel transparant, en weet je zeker dat je de angstcultuur alleen maar aanwakkert.

[i-chat]

wat @Dido hierboven zegt snap ik wel en het klopt zeker weten wat hij/zij zegt, maar toch moet ik het ermee oneens zijn.

public money public domain / public code, het kan maar niet vaak genoeg worden gezegd dat in beginsel alles waar gemeenschapsgeld in moet, ook gemeenschappelijk belang moet worden gevonden.

of dat nu controle is of publieke samenwerking, (zoals bij de covid app),
of dat gemeentes uiteindelijk allemaal (op termijn) samenwerken aan een stukje software om het GBA goed en stabiel te laten werken, en dat afwijkende wensen dus als individuele modules kunnen worden ontwikkeld.
of dat overheden comuniceren (zowel onderling als met de burger) in een vastgesteld formaat, waarin van vendor-lockin geen sprake kan zijn. Ja nu gebeurt dat nog steevast in word en pdf maar dat kan vast anders.

bij mij op school is het zelfs zo erg dat we verslagen alleen in mogen leveren in office word documenten tussen 2016 en huidig omdat anders de anti-plagiaat-software niet werkt. pdf en odt zijn dus letterlijk uitgesloten omdat een overheids-instelling gebruik maakt van een closed-source-oplossing die geen zin heeft om zich te beteren zonder een volledig nieuwe licentieovereenkomst aan te moeten gaan... en kom op dan praten we dus letterlijk over het toevoegen van enkele bestandsformaten.

verder zijn er op velerlei vlakken zoveel software pakketen dermate verouderd dat het wellicht raadzaam is om aan de slag te gaan richting een migratie-traject.. volgens de belastingdienst zijn hun systemen zo verouderd dat ze binnen enkele jaren simpelweg niets meer kunnen.

wat belemmerd ons dan om in zo'n migratiet-traject af te dwingen dat de software onder een bepaalde licentie moet worden afgegeven.

[ Voor 13% gewijzigd door i-chat op 27-03-2023 17:33 ]

[Dido]

i-chat schreef op maandag 27 maart 2023 @ 17:30:
public money public domain / public code, het kan maar niet vaak genoeg worden gezegd dat in beginsel alles waar gemeenschapsgeld in moet, ook gemeenschappelijk belang moet worden gevonden.

In beginsel, daar ben ik het mee eens. Maar de huidige (niet al te beste) uitgangssituatie in ogenschouw nemend, kun je niet opeens een principe (dat op zich heel lovenswaardig is) 100% gaan afdwingen.

of dat overheden comuniceren (zowel onderling als met de burger) in een vastgesteld formaat, waarin van vendor-lockin geen sprake kan zijn. Ja nu gebeurt dat nog steevast in word en pdf maar dat kan vast anders.

Dat kan zeker anders, gewoon kilo's boom versturen - gebeurt ook gewoon

bij mij op school is het zelfs zo erg dat we verslagen alleen in mogen leveren in office word documenten tussen 2016 en huidig omdat anders de anti-plagiaat-software niet werkt. pdf en odt zijn dus letterlijk uitgesloten omdat een overheids-instelling gebruik maakt van een closed-source-oplossing die geen zin heeft om zich te beteren zonder een volledig nieuwe licentieovereenkomst aan te moeten gaan... en kom op dan praten we dus letterlijk over het toevoegen van enkele bestandsformaten.

Ik ben betrokken bij een Europees samenwerkingsverband om sociale zekerheidsgegevens uit te wisselen. Denk je dat binnen zo'n Europees kader nieuwlichterij als odt geaccepteerd wordt? Hell, buitenlandse partijen krijgen het al niet voor elkaar een mime-type (correct of ueberhaupt) te vullen, een paar bestandsformaten toevoegen is dan geen sinecure.
Dus de Nederlandse overheid zit ook nog eens met de uitdaging dat ze helemaal niet zomaar zelfstandig en onafhankelijk van alles kunnen en mogen bepalen.

verder zijn er op velerlei vlakken zoveel software pakketen dermate verouderd dat het wellicht raadzaam is om aan de slag te gaan richting een migratie-traject.. volgens de belastingdienst zijn hun systemen zo verouderd dat ze binnen enkele jaren simpelweg niets meer kunnen.

Dat is niet alleen bij de belastingdienst zo. En niet eens alleen bij overheidsinstanties Maar een migratietraject komt de facto meestal neer op volledige nieuwbouw van systemen waarvan de specs nog slechts te vinden zijn als fossiele afdrukken in de sourcecode. "Migratie" wordt helaas vaak gebruikt als een eufemisme voor "vanaf de grond opnieuw beginnen". En dat is in veel gevallen de beste, zo niet enige oplossing, maar het klinkt zo eng, groot en onvoorspelbaar dat de politieke wil veelal ontbreekt om eraan te beginnen. Plus het prijskaartje. Je hebt archeologen nodig in de vorm van techneuten die vloeiend ASM, COBOL en/of RPG praten, en bereid zijn om dergelijke systemen te reverse-engineeren. Als je die al kunt vinden zijn ze per hoofd duurder dan een werkgroepje met experts die het probleem weer even de toekomst in kunnen adviseren.

wat belemmerd ons dan om in zo'n migratiet-traject af te dwingen dat de software onder een bepaalde licentie moet worden afgegeven.

Om te beginnen dat je dat migratietraject niet van de grond krijgt.
Daarnaast weet niemand precies wat er allemaal aan het licht komt als een oud lijk uit elkaar gesneden wordt om vervolgens als nieuwe gestructureerde code het public domain in te gaan. Dus de politieke wil om de deuren open te gooien zal niet heel hoog zijn.
En dat is niet zo gek. Mijn schoonmoeder is welkom bij mij thuis, maar ik wil wel van te voren tijd hebben om het huis aan kant te krijgen voordat ze binnen komt. En waar ik mijn huis in een dag wel schoonmoeder-proof heb, heb je het bij d eoverheid niet over dagen, weken of maanden die nodig zijn om op te ruimen. Dat gaat jaren, zo niet decennia duren, en daar zou eerst eens echt druk op gezet moeten worden.
Maar ja, overheid en prioriteiten. Er wordt zoveel tijd besteed (verspild?) aan het blussen van brandjes dat er geen tijd is om het pand brandveilig te herbouwen. Dus wachten we af tot een van die brandjes niet te blussen is en toch het hele pand in de as legt, want dan kan er opeens wel herbouwd worden. Het jammere is wel dat de bouwtekeningen de brand niet gaan overleven, want die zijn al jaren geleden weggerot.

[i-chat]

Om te beginnen dat je dat migratietraject niet van de grond krijgt.
Daarnaast weet niemand precies wat er allemaal aan het licht komt als een oud lijk uit elkaar gesneden wordt om vervolgens als nieuwe gestructureerde code het public domain in te gaan. Dus de politieke wil om de deuren open te gooien zal niet heel hoog zijn.

misschien was ik dan niet heel duidelijk, in wat ik bedoelde te zeggen,

Ik zeg niet, morgen (of over 5 tot 10 jaar moet de hele overheid opensource of openfileformat zijn.

wat ik wél zeg is, vroeg of laat zie je dat de situatie onhoudbaar wordt (zoals kennelijk nu bij de belasting, waar kennelijk experts hebben geconcludeerd dat de zaak binnen een jaar of 10 compleet in elkaar zakt en er dus iets nieuws moet komen.

DAT zijn volgens mij de momenten waarop je kunt zeggen, ja is goed, en verplicht in het open. waar je interfaces nodig hebt naar oude systemen die niet open zijn, kun je prima zorgen dat het nieuwe systeem zo ontwikkeld wordt dat zo'n module op termijn relatief eenvoudig te vervangen is door een module naar een ander systeem die wel aan de nieuwe regels voldoet.

verandering om verandering is nagenoeg nooit te rechtvaardigen (dont fix what isn't broken), tegelijkertijd kun je wel kijken naar die economische driehoek... tijd geld kwaliteit. als de kwaliteit hoog moet zijn, en het geld laag, dan zul je simpelweg HEEL veel tijd moeten spenderen in een nieuw systeem. dus misschien kunnen we beginnen te plannen (in een open model) hoe in 2035 alle overheidssystemen een stukje beter kunnen zijn. want als je dat niet doet, zitten we straks OF weer met rotzooi, of wordt het onnoemelijk duur (waarschijnlijk beiden)

[oNNoZeLe]

Iemand hier met ambitie?

Had ik maar een tijdmachine, waar zou dit over 10 jaar staan..

https://www.werkenvoorned...bij-cio-bzk-BZK-2023-0330

[Verwijderd]

Waar vroeger monolith werdt gebouwd wordt dat nu vaker met microservices opgelost. De een is goed in het geheel. De ander vaak in 1 of meerdere dingen. Vroeger was dat ook niet mogelijk, microservices nu de hardware goedkoop is geworden. Waar de software duur blijft. Zo'n monolith ombouwen kost gewoon heel veel tijd. Als er al 10 a 20 jaar aan wordt gebouwd kom je ook heel specifieke regels tegen. De documentatie is vaak niet up to date, of aanwezig. Zelfde geldt voor unit tests. Dit komt vaak door tijdgebrek en gebrek aan fatsoenlijke deadlines. Php laatst gecompileerd en hebben 17000 tests. Ben benieuwd hoeveel dat er zijn bij de overheid. Doordat de documentatie niet op orde is, falen er vaak projecten. En dit komt dan ook uit bij wie moet de test / documentatie maken. Zo wordt je als developer minimaal een factor 3 trager, bent niet productief genoeg etc. Als je ook nog tests moet schrijven in die aantallen dat bv. Php doet. Documentatie moet onderhouden. En dan ook nog dure maatwerksystemen ontwikkelen Waar geen markt voor is. Het wordt dan ook een factor 3 duurder. Waarom zou je opensource moeten willen en inleveren op kwaliteit, met hoger risico op bugs. De closed software is vaak beter te integreren, beter te bedienen, heeft meer gebruikers (vacature vullen) zaken over te vinden en een prijs. Goede software schrijven kost gewoon veel tijd en dus geld. Open source is niet goedkoper dan closed software. Daarnaast zit je ook nog met patenten zoals Adobe, etcetera. Flash is bijvoorbeeld gestopt omdat het niet veilig te krijgen was.

[unezra]

i-chat schreef op dinsdag 28 maart 2023 @ 19:54:
[...]
misschien was ik dan niet heel duidelijk, in wat ik bedoelde te zeggen,

Ik zeg niet, morgen (of over 5 tot 10 jaar moet de hele overheid opensource of openfileformat zijn.

wat ik wél zeg is, vroeg of laat zie je dat de situatie onhoudbaar wordt (zoals kennelijk nu bij de belasting, waar kennelijk experts hebben geconcludeerd dat de zaak binnen een jaar of 10 compleet in elkaar zakt en er dus iets nieuws moet komen.

DAT zijn volgens mij de momenten waarop je kunt zeggen, ja is goed, en verplicht in het open. waar je interfaces nodig hebt naar oude systemen die niet open zijn, kun je prima zorgen dat het nieuwe systeem zo ontwikkeld wordt dat zo'n module op termijn relatief eenvoudig te vervangen is door een module naar een ander systeem die wel aan de nieuwe regels voldoet.

verandering om verandering is nagenoeg nooit te rechtvaardigen (dont fix what isn't broken), tegelijkertijd kun je wel kijken naar die economische driehoek... tijd geld kwaliteit. als de kwaliteit hoog moet zijn, en het geld laag, dan zul je simpelweg HEEL veel tijd moeten spenderen in een nieuw systeem. dus misschien kunnen we beginnen te plannen (in een open model) hoe in 2035 alle overheidssystemen een stukje beter kunnen zijn. want als je dat niet doet, zitten we straks OF weer met rotzooi, of wordt het onnoemelijk duur (waarschijnlijk beiden)

Tijd = geld.
Als je ergens heel veel tijd aan spendeert, kost het automatisch veel geld.

Verder begrijp ik niet helemaal hoe OSS dé oplossing gaat zijn in de huidige ellende met oa de systemen van de belastingdienst. Cruciaal kenmerk van OSS is namelijk niet dat het gratis is, maar dat de broncode vrij beschikbaar is. (Met de nodige restricties.)

[i-chat]

Tijd = geld is echt zo’n grote BS

Natuurlijk willen de mensen die ergens aan werken gewoon hun boterham eten en hun hypotheek betalen

Maar dat zijn kosten die in het niet vallen bij de kosten die je maakt om je BE op te ruimen

Kijk naar ee hoeveelheid ellende en uiteindelijk geld die nodig gaat zijn om de toeslag affaire op te lossen en al die gezinnen schadeloos te stellen dat kost eindeloos veel meer tijd en zelfs NÓG veel meer geld

En ik denk dat je me verkeerd begrijpt, OSS Ga niet het verschil maken tussen een goede of een slechte Overheid.

Het punt is simpel gezegt Dat bepaalde software niet meer mee kan en dat er al over duidelijke signalen zijn en wetenschappelijke rapporten dat de huidige software de toenemende complexiteit niet aankan. Open source gaat hij in niets meer of minder veranderen dan closed source. Wel is het zo dat de overheid nu dus moet gaan investeren in een geheel nieuwe set tools en programmatuur. Mijn punt was nu juist dat dat dus het moment zou kunnen zijn om de overstap te maken, als je immers toch al kosten moet maken voor nieuwe software kun je net zo goed gelijk je andere doelstellingen proberen te verwezenlijken

Dat heeft dus niets te maken met de vraag of open source beter is, dat heeft te maken met het met het vraagstuk hoe je met je geld omgaat hoe je wilt zorgen dat je een open en transparante overheid bent.

Mensen denken vaak alleen maar in termen van A is beter dan B want A is 0,1 seconde sneller dan A

Dat is misschien leuk in het bedrijfsleven maar alles competitie is en winst het allergrootste doel, In andere situaties spelen er echter andere belangen zoals controleerbaarheid vertrouwen en in grote maten ook waarde voor je geld. Dat laatste wil vooral zeggen dat als je werk hebt verzet waar anderen ook gebruik van kunnen maken dat je jouw werk openbaar moet maken ten gunste van de maatschappij ze hebben er immers al voor betaald

Zoals je ziet komt in deze gehele casus het stukje beter zijn dan helemaal niet aan bod want open source kan net zo goed buggs en het feit dat iedereen de broncode kan controleren maakt weliswaar verschil maar zeker niet op het niveau dat het ineens onoverwinnelijk zou zijn

[Verwijderd]

Ik wou nog even kwijt. Stel de broncode is 1 MB groot. Je hebt specifieke domeinkennis nodig om die broncode te begrijpen. Bugs vinden als buitenstaander is hetzelfde als phpstan draaien op de code. (Voorbeeld)

Als er 300 gemeente zijn en 300 applicaties nu, ga je dat ook niet oplossen met 1 applicatie. De wil is er niet om samen te werken dan. Daarnaast is bij 300 applicaties vaak de data ook zo gescheiden. Prima ipv 1 grote db.

Hergebruik van code voor 300 gemeenten zal dan vaak inhouden dat je je beperkt tot 1 taal, 1 framework etc.
Nu zal er wel het een en ander mogelijk zijn, maar je gaat je beperken.
Als je dan toch wil samenwerken zul je de programmeurs moeten samenvoegen en die structuur laten aanbrengen bij de gemeenten.
300 gemeenten hebben ook weer veel meer geld te besteden aan software.
Hoeveel gemeenten heeft de eu?
moeten die wel allemaal dezelfde systemen? Krijg je dan niet de data op 1 hoop van alle gemeenten omdat dat onderhoud technisch veel beter gaat. Ipv 300 db upgrades heb je er maar 1.
Dat scheelt dus ook in de kosten, verminderd complexiteit etc. Hoe ga je om met specifieke gemeente regels in zo'n systeem en hoe kun je dat als buitenstaander controleren want dat is data en geen code.

[i-chat]

@Verwijderd ik denk dat je vooral niet moet vergeten dat die 300 (volgens mij zijn het er tegenwoordig eerder iets rond 200 (door gem herindelingen), gemeenten eigenlijk allemal dezelfde of gelijkwaardige taken hebben en dus in grote lijnen ook dezelfde behoefte.

1 een systeem voor het verwerken van GBA-gegevens.
2 een systeem voor het verwerken van belasting en heffingen
3 een systeem voor het aanvragen en verlenen van verguningen.
4 een burger service portaal.
5 een tool voor digitaal overleg

heel misschien moet je gemeenten juist wel bewegen richting een bepaalde keuze. zolang dergelijke systemen maar vrij zijn om zelf voor de juiste rekenmodellen te kiezen of om door middel van een plugin interface eigen keuzes te laten maken kun je dus redelijk efficiënt zorgen dat de kwaliteit en par blijft en dat bepaalde knowhow kan worden doorontwikkeld - dit alles heeft natuurlijk niets met open- of closed- source software te maken

maar als je kijkt naar de gemiddelde know-how binnen lokale overheden dan zou ik enige standaardisering zeker toejuichen (op termijn althans).

[oNNoZeLe]

1 van de key aspecten die door de OSS promoters aangehaald worden is dat we dan af zijn van 'de grote vendor lockin', wat ik dan wel weer grappig vind is dat @Verwijderd hier ook al aanhaalt je met efficiënt ontwikkelen je dus een keuze moet gaan maken waarin je gaat ontwikkelen. Volgens mij ligt hier dan weer een lockin op de loer, echter geen vendor lock maar een technische lock..

verder haalt @i-chat een heel goed onderwerp aan, overigens eerder ook al aangehaald, we mogen dan wel 340 gemeenten in NL hebben en ze mogen dan deels dezelfde taken hebben, maar dit gaat echt niet allemaal op dezelfde manier.

Je zou zeggen dat gemeente nu al zo lang bestaan, dat zal vast allemaal gestandaardiseerd zijn.. -> nope!

Ongeachte de waarde van OSS ontwikkelen moeten we het aan de voorkant eerst eens worden over HOE we iets nu doen.

en dit standaardisatie gaat dan ook richting frameworks, talen, etc..

[Verwijderd]

oNNoZeLe schreef op dinsdag 11 april 2023 @ 17:44:
1 van de key aspecten die door de OSS promoters aangehaald worden is dat we dan af zijn van 'de grote vendor lockin', wat ik dan wel weer grappig vind is dat @Verwijderd hier ook al aanhaalt je met efficiënt ontwikkelen je dus een keuze moet gaan maken waarin je gaat ontwikkelen. Volgens mij ligt hier dan weer een lockin op de loer, echter geen vendor lock maar een technische lock..

verder haalt @i-chat een heel goed onderwerp aan, overigens eerder ook al aangehaald, we mogen dan wel 340 gemeenten in NL hebben en ze mogen dan deels dezelfde taken hebben, maar dit gaat echt niet allemaal op dezelfde manier.

Je zou zeggen dat gemeente nu al zo lang bestaan, dat zal vast allemaal gestandaardiseerd zijn.. -> nope!

Ongeachte de waarde van OSS ontwikkelen moeten we het aan de voorkant eerst eens worden over HOE we iets nu doen.

en dit standaardisatie gaat dan ook richting frameworks, talen, etc..

de technische lock valt op zich ook wel mee, maar je kunt niet programmeertalen echt door elkaar gebruiken. dat zal per microservice bepaald moeten worden welke taal het gewenste resultaat biedt. je kunt wel api's maken om de verschillende programmeertalen met elkaar te laten praten. het zou ook een zooitje worden voor programeurs (welke taal kiezen we vandaag en we over blijven met allemaal smileys als code en dan (what does this smiley do...)

voor OSS ontwikkelen kan gewoon gekozen worden en verplicht worden door de opdrachtgever.
Maar de vraag is, wat heeft iemand eraan als de data ontbreekt. het lezen van code is niet moelijk, wat wel moeilijk is, die 200 gemeenten en de code daarover. Daarnaast als je toch eenmaal bezig bent, zou ik gelijk alle gemeenten van de eu erbij halen (is het ook een beter verdien model voor de partij in kwestie die moet gaan bouwen). Als je een uniform programma wilt maken die helemaal in te richten is voor elke gemeente in kwestie moet je niet vergeten hoe er met data omgegaan wordt. Als je een europees systeem krijgt zou ik niet 1 grote database willen, maar een lokale gemeente database. onderhoud op deze manier (updates) gaat gigantisch veel meer kosten en zul je moeten updaten zoals microsoft dat bijvoorbeeld doet (2x per jaar een grote update) de wetten wijzigen continue daar moeten de systemen ook mee overweg kunnen. database wijzigingen ook, het is soms makkelijker om een nieuwe database in te richten dan de bestaande te onderhouden. wat je bijvoorbeeld kan doen is een migratie systeem laten bouwen die van de oude database een nieuwe kan maken (ongeacht de wijzigingen en vendor). Bij zo'n project komen vele systemen erbij om dan alle gemeenten te bedienen. tuurlijk krijg je programma's, maar je krijgt ook services (achtergrond programma's (bijvoorbeeld email). Heel veel frameworks zijn al open source en gratis te gebruiken ook voor overheden.

Ik zou als overheid bijvoorbeeld kiezen voor wellicht een aantal backends. sommige zouden elkaar kunnen overlappen (in doen hetzelfde, maar ander domein). wat je dan wel kan doen is benchmarken om zo naar de beste / snelste / goedkoopste oplossing te gaan. In iedergeval geen exotische programma's gebruiken of oude meuk die technisch voor die tijd mischien prima was (zie bijvoorbeeld alle password schandalen) voor die tijd.

stel een backend heeft een vulnerability dan zou je die ook nog kunnen uitzetten, redirecten naar dat andere domein waar het ook kan). zo ligt de service er niet uit bijvoorbeeld.

Daarnaast zou ik in ieder geval gaan voor php als basis backend (versie 8.2) node er wellicht bij, maar dat is waarschijnlijk een vulnerabilty op den duur (ligt er ook aan wat je er van gebruikt).

De reden van php is het marktaandeel. python, rust zal ook gebruikt worden samen met c en dergelijke.
En een browser als applicatie. (Alles verplaatst zich naar de browser wordt er gezegd) maar CTRL-w voor een shooter killed echt je browser en kun je niet kruipend naar voren. (Helaas ALT-F4 is te herprogrammeren maar CTRL-w niet...)

Als je voor php gaat zou ik ook gaan voor Doctrine, daarmee heb je bijna geen vendor lockin op de database keuze. (kan connecten naar veel verschillende type databases) maar er zullen er voor andere talen (Java bijvoorbeeld dat wordt / werdt (geen idee) op de HBO gebruikt). Maar Java gaat samen met Oracle dus dan zit je vendor lockin aan oracle.

Je moet ook een team grootte gaan aangeven voor allerlei systemen die je kan bedenken en wat je denkt te halen in een bepaalde tijd, roadmaps gaan schrijven etc...

[oNNoZeLe]

Afgelopen weekend zag ik een sheet op LinkedIn voorbij komen waarin een deel van het “programma common ground” geschetst wordt.

Common Ground gaat in principe over gemeente IV en wordt onder andere door VNG getrokken en heeft Open Source als een richtlijn..

Zie de sheet om een beeld te krijgen waarvan wij, VNG en Gemeente, denken nodig te hebben om deze transitie van de grond af te krijgen.




Credits van VNG denk ik.
Of https://commonground.nl/

[Cergorach]

Wat ik nog steeds niet snap is dat als we het hebben over de overheid naar open source software (oss) de discussie veel te vaak uitkomt op Windows en Office vervangen door Linux+OpenOffice/LibreOffice terwijl dat imho het minste oplevert en verre uit het meeste kost om over te stappen.

Ik zie veel meer winst in de backend! Zo zie ik in het Enterprise landschap nu veel meer Linux gebruikt worden dan 15-20 jaar geleden. Die dingen worden gebruikt/beheert door techneuten die een stuk minder last hebben van UI veranderingen in hun werk, dat is immers hun werk.

Maar zelfs als je Linux gebruikt, wat voor smaakje gebruik je dan? Voorheen riep iedereen CentOS! Nu? Ik zie een hoop zakelijke CentOS gebruikers nu toch overstappen op Red Hat... Kosten? Ga je ook hun gesloten software gebruiken? Of stap je over op Ubuntu of Debian? Wat als er iets dergelijks ook ontstaat bij die distributies? Weer als een kip zonder kop rondrennen naar the best next thing en bergen geld uitgeven voor migratie?

En is de overheid capabel om zelf het gehele support te regelen zonder third party waar ze op terug kunnen vallen? Ik gok van niet, die mensen hebben ze immers nu ook niet en ook die mensen kosten geld, zullen moeten ontwikkelen voor dat OSS project, etc. Als je het uitbesteed zit je weer verbonden aan een thirdparty, als die ermee ophoud of opeens schandalig hoge tarieven gaat hanteren (seen that happen before), wie gaat dan het support regelen?

Waarom je met OSS niet eens eerst concentreren op al die oplossingen die zelf zijn ontwikkeld of in opdracht van de overheid voor de overheid. Geef dat uit als OSS en/of bouw de volgende versie als OSS. Er zullen vast mensen de code onderhanden nemen en dat geeft de rest van de wereld ook de mogelijkheid om het te gebruiken. Dit is imho al zo een diep gat dat je decennia werk hier aan heb en de Nederlandse overheid hoeft het echt niet allemaal alleen te trekken, als andere (EU) landen de voordelen zien, zullen er wellicht meer volgen. Het zou ook mogelijk Nederland weer wat meer kenniseconomie kunnen geven, mensen die hier hebben geholpen aan de ontwikkeling en implementatie kunnen in een ander land aan de slag om het te implementeren en/of daar personeel op te leiden (ivm. kennis/ervaring)...

Op het moment dat je hele backen OSS is (en de applicaties gewoon bruikbaar zijn via de browser) zal uiteindelijk een verplaatsing van de werkplek naar geheel OSS ook makkelijker mogelijk gaan worden en hopelijk is tegen die tijd er al veel meer tijd/geld/moeite gestoken in de desktop Linux distributies.

[downtime]

Cergorach schreef op woensdag 19 april 2023 @ 20:33:
Wat ik nog steeds niet snap is dat als we het hebben over de overheid naar open source software (oss) de discussie veel te vaak uitkomt op Windows en Office vervangen door Linux+OpenOffice/LibreOffice terwijl dat imho het minste oplevert en verre uit het meeste kost om over te stappen.

Ik zie veel meer winst in de backend! Zo zie ik in het Enterprise landschap nu veel meer Linux gebruikt worden dan 15-20 jaar geleden. Die dingen worden gebruikt/beheert door techneuten die een stuk minder last hebben van UI veranderingen in hun werk, dat is immers hun werk.

Dat is mijn denkwijze ook. We kunnen de wereld niet in ons eentje veranderen maar we kunnen wel de dingen veranderen die we zelf (laten) maken. Daarom vind ik dat we eerst naar de maatwerksystemen moeten kijken. Het is maatwerk dus je kunt eigenlijk elke eis stellen zolang je er ook maar voor betaalt.

[oNNoZeLe]

Geen idee of dit mee speelt maar ik kon geen geschikt topic vinden voor om deze ambitie in onder te brengen..

Uiteindelijk heeft 1 van de modz hem hier naartoe geplaatst en ik vind hem hier ook niet thuis horen omdat het veeeel meer is dan besturingssysteem of Office applicaties of hypervisor..

Dit gaat mogelijk over alle van de iso/osi lagen en dan inclusief dat wat het common ground plaatje schetst..

In welk topic zouden jullie dit onderbrengen?

[i-chat]

Op het moment dat je hele backen OSS is (en de applicaties gewoon bruikbaar zijn via de browser) zal uiteindelijk een verplaatsing van de werkplek naar geheel OSS ook makkelijker mogelijk gaan worden en hopelijk is tegen die tijd er al veel meer tijd/geld/moeite gestoken in de desktop Linux distributies.

Dit is letterlijk wat ik de afgelopten 10+ jaar al tegen iedereen predik...

begin met het vervangen van custom made (vaak nog in een oudere versie van MS EXEL of ACCESS gebouwd prularia of een in delphi ofzo geschreven broddelwerkje dat via een samba-share gedeeld wordt met alle collega's. Door een fatsoenlijk en door moderne technieken goed stukje software met een webinterface. kijk naar wat er mogelijk is in mederne cloud-oplossingen en hoe je met compute -achtige systemen (voor een overheid natuurlijk wel op eigen infra gehost), je prachtige berekeningen invulvelden dynjamische workflows en ga maar zo door..

gewoon lekker beginnen met het opruimen van je legacy meuk en steeds een beetje beter aansluiten een open structuur. bovendien zegt men wel, dat open broncode geen open bedrijfscultuur maakt maar om maar eens met een slechte vergelijking te komen, hoe ga jij ooit nog te hard rijden als er een dikke begrenzer in je auto is ingebouwd. ja hooguit zullen er 1 of 2 zijn die zo'n ding weten te hacken en dus weer kunnen hardrijden maar voor het gros betekent het gewoon da ze zich aan de limieten moeten houden.

nieuwe software (dat zelfde geld overigens ook voor closed-source (maar dan is het misschien wel een beetje hypocriet), kan zeker weten nieuw gedrag afdwingen.

[oNNoZeLe]

i-chat schreef op woensdag 19 april 2023 @ 22:31:
[...]

gewoon lekker beginnen met het opruimen van je legacy meuk en steeds een beetje beter aansluiten een open structuur. bovendien zegt men wel, dat open broncode geen open bedrijfscultuur maakt maar om maar eens met een slechte vergelijking te komen, hoe ga jij ooit nog te hard rijden als er een dikke begrenzer in je auto is ingebouwd. ja hooguit zullen er 1 of 2 zijn die zo'n ding weten te hacken en dus weer kunnen hardrijden maar voor het gros betekent het gewoon da ze zich aan de limieten moeten houden.

nieuwe software (dat zelfde geld overigens ook voor closed-source (maar dan is het misschien wel een beetje hypocriet), kan zeker weten nieuw gedrag afdwingen.

Gewoon lekker beginnen?
Zonder structuur en begeleiding wordt dat de zoveelste overheid en ict drama..

[downtime]

oNNoZeLe schreef op woensdag 19 april 2023 @ 22:25:
Geen idee of dit mee speelt maar ik kon geen geschikt topic vinden voor om deze ambitie in onder te brengen..

Uiteindelijk heeft 1 van de modz hem hier naartoe geplaatst en ik vind hem hier ook niet thuis horen omdat het veeeel meer is dan besturingssysteem of Office applicaties of hypervisor..

Dit gaat mogelijk over alle van de iso/osi lagen en dan inclusief dat wat het common ground plaatje schetst..

In welk topic zouden jullie dit onderbrengen?

In mijn ogen zou het hier horen: Actualiteit, wetenschap en maatschappij

Het gaat niet om software in technische zin maar om keuzes die onze overheid maakt.

[oNNoZeLe]

Dan wordt er een stukje geschreven en start het met Red Hat. ;-)

https://ibestuur.nl/partn...h-unconference-maart-2023

[oNNoZeLe]

Kijk dit stukje software zou dus echt mooi open source gemaakt kunnen worden..

De vraag is dan wel nog of het goedkoper of duurder wordt en wat we als inwoners daar dan van vinden.

nieuws: Kiesraad ontbindt contract leverancier verkiezingssoftware na gemiste...

[CAPSLOCK2000]

Verwijderd schreef op dinsdag 11 april 2023 @ 13:17:
Als er 300 gemeente zijn en 300 applicaties nu, ga je dat ook niet oplossen met 1 applicatie. De wil is er niet om samen te werken dan. Daarnaast is bij 300 applicaties vaak de data ook zo gescheiden. Prima ipv 1 grote db.

Ik zou ook niet willen dat al die gemeentes overal exact dezelfde software voor gebruiken. Zo'n monocultuur heeft allerlei nadelen. Verschillenden applicaties gebruiken voorkomt dat een enkele bug het hele land plat legt.

Dat heeft verder weinig met open of gesloten te maken, monoculturen zijn niet goed.

In de tijd dat ik voor een gemeente werkte was er op een hoop punten eigenlijk niks te kiezen. De facto was er voor een hoop zaken maar één leverancier ("C") en die ene leverancier levert aan alle gemeentes. Iedere gemeente betaalde daarbij fors om aanpassingen te laten doen om die applicaties aan te laten passen aan de lokale inzichten. Ik sprak wel eens met collega's van andere gemeenten en die bleken vaak precies dezelfde aanpassingen te willen als wij. Allemaal moesten we de volle mep betalen voor maatwerk bovenop de toch al forse licentiekosten.

Soms waren er twee mogelijkheden. Regelmatig heb ik me verbaasd dat we dan vaak beide applicaties in huis hadden. Dat bleek ook weer een gevolg van vendor lockin waardoor de grote leveranciers weigerden om hun eigen poduct te laten samenwerken met dat van de concurrent.

Als je dat ziet gebeuren dringt zich heel sterk het gevoel op dat je wordt opgelicht en dat het beter zou zijn om met een tiental gemeentes samen zelf een paar programmeurs in te huren om een applicatie te laten ontwikkelen en die dan aan te passen aan ieders behoefte. Volgens mij is er later ook zo iets gebeurd maar toen was ik daar al weer weg.

<edit>

Ik keek net even op de website van die gemeente en het lijkt er op dat ze het een paar jaar gelden echt hebben gedaan. Er is een aparte IT-club opgericht met geld van verschillende gemeentes. Toevallig staat er een nieuwsbericht dat ze net afscheid hebben genomen van de systemen waar ik 20 jaar geleden mee werkte. Zo moeilijk was het dus om daar vanaf te komen. De naam van de leverancier van toen komt ook weer terug in dat nieuwsbericht, die is blijkbaar nog steeds betrokken.
Blijkbaar is het in 5 jaar gelukt om dat product te vervangen waar ze eerst (minstens) 20 jaar aan vast hebben gezeten. Daarnaast zie ik ook nog nieuwsberichtjes dat ze moderne en innovatieve dingen met IT doen (nou ja, voor een gemeente dan )

[jbhc]

Grappig deze discussie.


Vanuit een iets ander perspectief gezien wil ik het volgende meegeven:

Op mijn werk hebben we veel liften waarvan de hardware gesloten is. Dit heeft tot gevolg dat je voor bepaalde reparaties alleen bij de fabrikant van die lift terecht kunt.

Dit heeft vrij grote gevolgen omdat, wanneer je een andere firma het onderhoud uit laat voeren, ze niet alles kunnen doen en regelmatig de fabrikant in moeten huren, uiteraard voor de hoofdprijs en bijbehorende wachttijden.

Wij laten dus, wanneer een lift toe is aan groot onderhoud, of wanneer de besturing defect gaat, deze bewust ombouwen naar open besturingen zodat elke partij hier onderhoud aan uit kan voeren.

Hetzelfde geldt voor UPS-en. Wij hadden standaard een bepaald merk. Helaas heeft dat merk besloten dat de besturing van hun UPS-en voor niemand meer toegankelijk is, ook niet meer voor onze leverancier en tevens onderhoudspartij waardoor er nu telkens iemand van de fabrikant bij moet komen als we wat gewijzigd willen hebben aan bepaalde parameters. Ondertussen schaffen we dat merk dus niet meer aan.

Open systemen, zowel in hard en software, zijn van groot belang om de onderhoudskosten op de lange termijn binnen de perken te houden. Wanneer alles alleen toegankelijk is voor de fabrikant zit je daaraan vast en kunnen ze zowel kwa prijsstelling als klantvriendelijkheid doen wat ze willen. Dat is iets waar je je als afnemer van gesloten producten zeer bewust van moet zijn.

Alles natuurlijk nog even afgezien van de problemen die er ontstaan wanneer een fabrikant verdwijnt. Zie dan je producten nog maar eens onderhouden en of gerepareerd te krijgen.

Bovenstaande verhaal gaat net zo goed op voor software. Gesloten software geeft automatisch een "vendor lock in" iets wat je, imho, zeker bij de overheid zoveel mogelijk moet voorkomen.