Nederlands ministerie van Binnenlandse Zaken krijgt opensourceofficer

Het Nederlandse ministerie van Binnenlandse Zaken en Koninkrijksrelaties krijgt een Open Source Program Officer. Deze OSPO moet ervoor zorgen dat opensourcewerken binnen het ministerie wordt gestimuleerd.

De OSPO gaat onder de chief information officer van het ministerie vallen en samenwerken met verschillende beleids- en stafdirecties. Daarbij gaat de opensourceofficer afspraken maken met verschillende onderdelen binnen het ministerie over het uitvoeren van pilots of het open sourcen van bestaande apps.

De opensourceofficer gaat onder meer werken op het gebied van openbaring van overheidsinformatie en de Europese Digital Identity-wallet. De OSPO is onderdeel van het 'open, tenzij'-beleid van het ministerie, waarbij zoveel mogelijk apps en software open source beschikbaar gesteld moeten worden. In dat kader bracht het ministerie bijvoorbeeld al de broncode van de DigiD-app open source uit.

In onderstaande video legt staatssecretaris Digitalisering Alexandra van Huffelen uit dat hoewel ambtenaren wel open source willen werken, dit een nieuwe werkwijze en nieuwe manier van werken vraagt. De OSPO moet bij die omschakeling helpen. Andere EU-lidstaten en de Europese Commissie hebben al een OSPO. Van Huffelen hoopt dat andere delen van de overheid ook met OSPO's gaan werken.

Door Hayte Hugo

Redacteur

14-03-2023 • 14:42

89

Reacties (89)

Sorteer op:

Weergave:

Public money, public code. Het zou eigenlijk vanzelfsprekend moeten zijn. Hoe eerder we daarmee beginnen des te sneller die projecten beter worden. In plaats van elke keer maar gaan voor de grote Amerikaanse (cloud) producten, die niet eens zoveel malen beter zijn dan dat ze kosten.
Aan de ene kant wel, maar er zijn legio voorbeelden van geplande migraties naar OO die toch uiteindelijk niet uitgevoerd wordt of dat men toch weer terug gaat naar MO omdat de compatibiliteit gewoon niet goed is.
Los van dat je je eigen mensen opnieuw moet trainen, als burgers dingen met Word of bijvoorbeeld Excel aanleveren, dan ga je het jezelf erg moeilijk maken door naar een platform te gaan dat niet native hetzelfde is.
Trainen? Wanneer heb je voor het laatst een MS-Office training gehad? Ik zie ze niet regelmatig iig. tenzij het geavanceerde Excel VLOOKUPs zijn. Maar dat doet vrijwel niemand. Dan compatibiliteit: dat is deels relevant als het gaat om complexe sheets/documenten. Een aantal zaken hierbij:
1) Complexe sheets : dan zit er dus logica in die je moet vertalen. Waarom zit dat in een sheet? Hoe leg je vast hoe de logica tot stand is gekomen? Hoe leg je vast wie er aan gewerkt heeft? Zaken die Excel niet ondersteund. De vraag is dus of deze sheets mogen bestaan in een open-overheid en niet zowiezo al aangepast moeten worden.
2) Opmaak: de opmaak van Overheidsdocumenten is vaak niet zo heel spannend. Kun je ook projectmatig omzetten.

En als burgers zaken aanleveren in formaten die niet ondersteunt worden dan meld je dat aan je gebruikers? En laat je ze PDF sturen.

Zachte heelmeesters maken stinkende wonden denk ik altijd bij dit soort halfzacht migraties.
tenzij het geavanceerde Excel VLOOKUPs zijn. Maar dat doet vrijwel niemand.
Ik denk dat dit ook een van de redenen is dat mensen moeite hebben met compatibiliteit. De persoon die de het magische spreadsheet onderhoudt is op vakantie of al tien jaar geleden uit het bedrijf gestapt maar zie maar dat spreadsheet is wel mooi een kritiek bedrijfsonderdeel. Iemand inhuren om een spreadsheet om te zetten is duur (en staat ook niet heel slim) en niemand heeft zin om de Excel-handleiding uit zijn hoofd te leren om de boel om te zetten.

Ik heb zelf niet meer problemen met compatibiliteit meegemaakt dan dat Microsoft zelf ook heeft als je verschillende versies naast elkaar gebruikt. Aan de andere kant heb ik hele applicaties weggestopt zien worden in Excel-spreadsheets op een netwerkschijf waarvan ik zelf ook zou vrezen dat hele bedrijfstakken zouden instorten als je te hard klikt.

Gewenning van personeel. slechte UI en "Loes van financiën heeft over de jaren heen een SaaS-applicatie gebouwd in Excel-formules" zijn de grote redenen die ik zie waarom mensen niet met open office-alternatieven om kunnen gaan. Gewenning valt te trainen, we hebben de menu-naar-lint transitie van Office tenslotte ook doorstaan, maar qua UI en compatibiliteit snap ik wel dat men het lastig vindt om volledig over te gaan als je de hele dag in Office moet werken.
de persoon die de het magische spreadsheet onderhoudt is op vakantie of al tien jaar geleden uit het bedrijf gestapt
person to blame: de manager die dit heeft toegestaan. Als trainee, eeuwen geleden, kreeg ik al mee dat processen (software of iets anders) nóóit van één persoon afhankelijk mochten zijn. Zelfs de board members mochten niet in hetzelfde vliegtuig/auto naar een meeting.
Mooie statement maar kleine bedrijven gaan toch echt niet elk process bij meerdere personen neerleggen. Willen ze misschien wel maar om voor sommige taken meer dan 1 persoon in te huren is toch soms te kostbaar.
voor een deel heb je gelijk en het hoeft ook niet voor alle processen. Toch is het handig om e.e.a. in kaart te brengen. Vaak is een echt bedrijfskritisch deel makkelijk over te nemen door een aanpalende functie. Zo hadden we maar 1 persoon voor de QC van een proces, maar een andere lab medewerker kreeg wel scholing en kon bij gelegenheid het QC proces overnemen.
Theorie is altijd leuk, maar de praktijk is simpelweg anders. Uiteindelijk heb je met de praktijk (en mensen!) te maken, en niet de theorie.
En daar is die theorie dan ook voor zodat je die praktijk kan gaan sturen naar een robuuster proces, i.p.v. stil te blijven zitten. Natuurlijk zijn er veel situaties waarin de praktijk weerbarstig is, maar een rondje bewustwording van de mensen om je heen doet al heel veel. Nadat we dit thema op de agenda hadden gezet bleken er ineens veel medewerkers met hele goede ideeën te zijn die met simpele ingrepen (zonder kosten dus) het hele proces al 1) inzichtelijker maakten en 2) een stuk robuuster.
100%, maar vingers wijzen lost het probleem helaas niet op; het spreadsheet is er doorgaans al.

Een goede oplossing is ook niet altijd te behalen. Je kunt moeilijke spreadsheets verbieden, maar dat gaat ten koste van productiviteit. Je kunt proberen om mensen bij te leren over Excel, maar een schokkend aandeel van de mensen die dagelijks Excel gebruikt heeft hun vaardigheden zwaar overschat en raak je nu niet meer kwijt. Je kunt de functie officieel maken en het spreadsheet documenteren (of zelfs omzetten naar een echte applicatie) maar daar is vaak geen budget voor.

Ik denk dat dat laatste de beste kans van slagen heeft, maar ik hoor vaak de eerste optie vaak voorbij komen. Dat, of het probleem negeren totdat een upgrade naar de nieuwe Office problemen veroorzaakt. Zelfs kan kun je nog jaren op Windows XP/7 met Office 2003/2012 en Exchange 2007 draaien, zoals meer dan genoeg bedrijven en ook onze eigen overheid ons al heeft laten zien. De rekening komt pas zodra het misgaat, dus gewoon niet aan zitten!

[Reactie gewijzigd door GertMenkel op 22 juli 2024 14:54]

hier heb je zeker een punt. Helaas is het laatste veel te vaak het geval
Trainen? Wanneer heb je voor het laatst een MS-Office training gehad?
Nooit, in het algemeen kunnen mensen die training gehad hebben minder goed overweg met Excel dan ik, uitgezonderd als het draaitabellen betreft. Ook gebruik ik slechts een heel klein deel van de functies. Sum-of-the-years-digits heb ik wel eens geprobeerd, maar de afschrijvingsmethode ben ik in de praktijk nog niet tegen gekomen (wel destijds gehad op school). Voor andere afschrijvingsmethodes bouw ik liever mijn eigen formules.
Ik zie ze niet regelmatig iig. tenzij het geavanceerde Excel VLOOKUPs zijn. Maar dat doet vrijwel niemand.
Die heb ik veel gebruikt vroeger, de HLookups nog meer.
Dan compatibiliteit: dat is deels relevant als het gaat om complexe sheets/documenten. Een aantal zaken hierbij:
1) Complexe sheets : dan zit er dus logica in die je moet vertalen. Waarom zit dat in een sheet? Hoe leg je vast hoe de logica tot stand is gekomen? Hoe leg je vast wie er aan gewerkt heeft? Zaken die Excel niet ondersteund.
Dat kun je prima op een andere sheet vastleggen of in een bijbehorend tekstdocument. Procedures hebben standaard op het einde een versiegeschiedenis, dan kan in Excel ook op een aparte worksheet.
De vraag is dus of deze sheets mogen bestaan in een open-overheid en niet zowiezo al aangepast moeten worden.
In een open-source spreadheet is beter, tenzij dat vanwege bepaalde functionaliteit (VBA) niet kan maar als je het in een web-app verwerkt ziet men al snel helemaal niet meer wat er op de achtergrond gebeurd.
En als burgers zaken aanleveren in formaten die niet ondersteunt worden dan meld je dat aan je gebruikers? En laat je ze PDF sturen.
Dus alle burgers moeten dan in Adobe Acrobat Pro DC gaan tekstverwerken?
Zachte heelmeesters maken stinkende wonden denk ik altijd bij dit soort halfzacht migraties.
Vaak wilt de top eigenlijk zelf ook niet, meestal vanwege lobbies.
"Dat kun je prima op een andere sheet vastleggen of in een bijbehorend tekstdocument. Procedures hebben standaard op het einde een versiegeschiedenis, dan kan in Excel ook op een aparte worksheet" probleem is dat er geen enkele vorm van source-code management in Excel (of Office in het algemeen) zit. Dus wie heeft welke cell of formule om welke reden aangepast is mensenwerk qua vastlegging. Daar kom je niet mee weg als je beslissingen eraan opknoopt (althans: ik kom er niet mee weg als ik een klodder software aflever die zegt dat er een miljoen naar rekening X overgemaakt moet worden. Helaas zijn de controles op Excel sheets vaak zo dermate droevig, dat dit daar wel geaccepteerd wordt om reden : "het kan niet anders"). Een versiegeschiedenis met de hand vastleggen is puur indicatief en heeft geen enkele formele waarde (in andere woorden: is waardeloos als er een auditor langskomt)

En PDF: doe eens "save as PDF in Word" of maak een PDF printer aan in Windows... Acrobat Pro heb je alleen nodig als je formulieren maakt.
Procedures hebben standaard op het einde een versiegeschiedenis, dan kan in Excel ook op een aparte worksheet" probleem is dat er geen enkele vorm van source-code management in Excel (of Office in het algemeen) zit. Dus wie heeft welke cell of formule om welke reden aangepast is mensenwerk qua vastlegging.
Klopt. Als je source-code management moet doen, zul je die discipline zelf moeten opbrengen. Voor een aangepaste formule in een cel of reeks cellen is dat nog doenbaar, voor VBA niet, al zijn er daarvoor wel add-on versiebeheer-systemen, of dat fatsoenlijk werkt weet ik niet, ik heb ze nog niet geprobeerd. VBA-code kun je ook ondertekenen, dus ook daar zit een stukje zekerheid, al heb ik geen idee of dat veel gebruikt wordt. Registreer die ondertekening in je versiebeheer (geen idee of dat al kan) en je bent een heel eind.

Voor waarden die in cellen ingevoerd worden, die zijn zo volatiel dat daar ook geen beginnen aan is. Wat er in Excel gemaakt wordt zijn vaak rekenmodellen, die worden bv toegepast om te kijken wat de kosten of de opbrengsten zijn als voor een grondstof of eindproduct een bepaalde prijs wordt toegepast of als die prijs naar een andere waarde gaat.

Maar er zijn dus ook boekhoudsystemen die werken op Excel, niet iets wat ik aan zou raden, een database is daar veel geschikter voor, afhankelijk van de grootte van het bedrijf zou dat misschien in sommige gevallen zelfs in Access kunnen, al loop je daarmee ook weer snel tegen beheersproblemen aan. Dat Excel vaak verkeerd gebruikt wordt is niet mijn schuld.
Daar kom je niet mee weg als je beslissingen eraan opknoopt (althans: ik kom er niet mee weg als ik een klodder software aflever die zegt dat er een miljoen naar rekening X overgemaakt moet worden.
Als jij een tikfout maakt die van die één miljoen 100.000 of 10 miljoen maakt, dan gaat dat versiebeheer je ook niet redden.
Helaas zijn de controles op Excel sheets vaak zo dermate droevig, dat dit daar wel geaccepteerd wordt om reden : "het kan niet anders"). Een versiegeschiedenis met de hand vastleggen is puur indicatief en heeft geen enkele formele waarde (in andere woorden: is waardeloos als er een auditor langskomt)
Zoals boven aangegeven, het kan wel anders maar het is veelal niet nodig. En als het wel nodig is, kijkt men meestal toch vooral naar de input en de output.
En PDF: doe eens "save as PDF in Word" of maak een PDF printer aan in Windows...
Dan heb je ook geen controle op de kwaliteit van het document, laat staan op de mogelijkheid om de inhoud, de gegevens er in digitaal te verwerken. PDF draait om lay-out.
Ik heb geprobeerd een .odt document aan de gemeente te sturen. Kreeg terug dat 'ze 't niet konden lezen'. Ze gebruiken dus geen open source offic pakket (libre office, open office, enz.) en ook niet een recente versie van ms-word.
Hoezo open standaarden..
Ik schaar dat onder gebruikers fouten. Volgens mij opent word al sinds 2013 gewoon odt maar wel met een melding waarschijnlijk waar een gebruiker van schrikt. Of beheer heeft de odt import niet geïnstalleerd (zou me ook niet verbazen).
Verwijderd @r_j15 maart 2023 10:00
Ik heb geprobeerd een .odt document aan de gemeente te sturen. Kreeg terug dat 'ze 't niet konden lezen'. Ze gebruiken dus geen open source offic pakket (libre office, open office, enz.) en ook niet een recente versie van ms-word.
Hoezo open standaarden..
Daar zou de omslag moeten beginnen, op gemeente, provincie, waterschappen niveau, deze gewoon verplichten om uitsluitend .odt bestanden te accepteren.
Hoe moeilijk kan het zijn om simpele formulieren als .odt bestand te verwerken, in eender welk Office programma.
Maar het is veel blabla, moeilijk, nooit mee gewerkt, open source, commerciële belangen, alle redenen blijken goed om maar niet met de .odt standaarden te hoeven werken.
Compatibiliteit is meestal onzin. Het heeft te maken met het gebruik van software op een manier waarvoor het eigenlijk nooit bedoeld is (complete administraties waarbij 10-tallen Excel sheets naar elkaar verwijzen en daar informatie uit halen, bijvoorbeeld of Word documenten van 100-den pagina's).

Vaak groeit het zo. Het begint met een "leuk en handig idee" omgezet in beschikbare software. Dat blijft maar groeien en wordt een gedrocht waar je niet meer vanaf kunt komen ("compatibel").

Er is dan eigenlijk geen sprake van niet "compatibel" zijn, maar van oneigenlijk gebruik van software waarvoor een andere oplossing gezocht had moeten worden.

Hier komt dan ook nog bij kijken dat het mogelijk een risico is om op deze manier te werken (door niet weten wat er precies allemaal gebeurd, gaan gegevens de verkeerde kant op).

Ook bij bijvoorbeeld Adobe-software is het veel gehoord. Het "compatibel" moeten zijn met de industriestandaard. 15 tot 20 jaar geleden wellicht nog waar, maar nu zeker niet meer.
men toch weer terug gaat naar MO omdat de compatibiliteit gewoon niet goed is.
Het klopt dat LO en MO niet heel erg compatible zijn maar het is een beetje zuur om daar LO de schuld van te geven als het MO is dat zich niet aan de standaarden houdt (die nota bene door MS zelf zijn geschreven).

Het is haast niet te geloven dat LO zich beter aan de standaard voor Office documenten houdt dan MO en toch is het zo (te lang verhaal voor hier en nu, zie https://nl.wikipedia.org/...tandaarden_door_MS_Office).

We zijn inmiddels 15 jaar verder en MS is nog steeds niet compatible met z'n eigen voorgestelde bestandsformaat. Dan kunnen we nog speculeren of dat incompetentie of onwil is maar feit is dat het probleem nog steeds niet is opgelost, ondanks alle mooie beloftes en suggesties waarmee MS het standaardisatieproces van de EU heeft ondermijnd.

Ik snap heel goed dat bedrijven daar niet aan willen beginnen. Die zijn meer pragmatisch dan principieel en geen enkel bedrijf is machtig genoeg om MS te negeren, wat je er verder ook van denkt.
Voor principiele beslissingen moet je bij de overheid zijn. De overheid heeft veel macht om moeilijke beslissingen te nemen en consequent uit te voeren, ook als dat niet de makkelijkste of goedkoopste korte termijn oplossing is.
Los van dat je je eigen mensen opnieuw moet trainen, als burgers dingen met Word of bijvoorbeeld Excel aanleveren, dan ga je het jezelf erg moeilijk maken door naar een platform te gaan dat niet native hetzelfde is.
Ik ben vast te veel nerd om het probleem te zien maar grote meerderheid van de documenten die ik zie gebruikt alleen de meest basale features en bestaan uit een stukje tekst met wat kopjes, misschien wat vet en cursief gedrukte stukjes en heel misschien een tabel of een plaatje. Al die functionaliteit is altijd al standaard geweest in ieder "office" pakket van voor de tijd dat we het "office" noemde.
De enige veelgebruikte feature die de afgelopen 25 jaar is toegevoegd is de mogelijkheid om inline commentaar in documenten te plakken.

Ik kan me geen enkel geval in de afgelopen 10 jaar herinneren waarin ik LO niet voldeed voor mij (met die aantekening dat ik niet geef om pixel perfecte layouts, maar als je dat wil moet je toch niet bij Office zijn).
Aan de ene kant wel, maar er zijn legio voorbeelden van geplande migraties naar OO die toch uiteindelijk niet uitgevoerd wordt of dat men toch weer terug gaat naar MO omdat de compatibiliteit gewoon niet goed is.
Uit de tekst:
Daarbij gaat de opensourceofficer afspraken maken met verschillende onderdelen binnen het ministerie over het uitvoeren van pilots of het open sourcen van bestaande apps.
Het gaat ook over programmatuur van/voor/door de Nederlandse overheid, dat die 'publiek' (open source) wordt uitgebracht. Dat vind ik zelf een stuk belangrijker.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 14:54]

Hier aan zou ik willen toevoegen dat onderdelen zoals bijvoorbeeld de belastingdienst, meer zijn dan alleen een Excel documentje met de gegevens die Henk en Ingrid inleveren. Het gaat ook over de achtergrondprocessen de algoritmes en soortgelijke hard-en software.

Publiek geld publieke code gaat veel meer over niet twee maal het wiel opnieuw moeten uitvoeren. Als je ziet dat er door veranderen de regels een keer geïnvesteerd moet worden om veranderingen door te voeren dan ben je meestal niet de enige die die veranderingen door moet voeren dan wil je dus ook dat andere mensen daar eventueel op hun manier ook van kunnen profiteren zodat zij niet alsnog het werk dubbel moeten laten uitvoeren. We betalen immers allemaal belasting en met dat geld proberen we zo efficiënt mogelijk de problemen in onze samenleving op te lossen het zouden ze gek zijn als de overheid vervolgens tegen ons, de burger, op Prijs of beschikbaarheid van software gaat concurreren.
Ik zie het nu ook, de titel is ietwat ongelukkig gekozen want ik dacht dat het specifiek over Open Office ging en niet een algeheel programma om een Open Source programma op te zetten.
Ik denk dat iets als Microsoft Office vervangen door Open Office niet behoort tot de meest efficiënte Open Source projecten. Ik denk dat je meer naar de backend zal moeten kijken, waar toch al techneuten zitten, daar zijn meer punten te scoren dan een OS oplossing voor het kantoorpersoneel.

En vergeet niet dat OS niet direct betekend gratis, zeker als je bij grote organisaties als de overheid zit, wil je support en voor support zal je moeten betalen! Linksom of rechtsom, of je betaald het bedrijf die de support levert of je zal het zelf moeten inrichten (en betalen). Leveranciers die support leveren voor OS producten kunnen failliet gaan en/of de support prijzen drastisch omhoog gooien, dus daar moet je ook rekening mee houden...

Waar je ook mee zit, is dat verschillende betaalde enterprise versies van OS software ook weer proprietory software (bevatten), denk aan bv. Red Hat, Chocolatey of Terraform...
Ik denk dat iets als Microsoft Office vervangen door Open Office niet behoort tot de meest efficiënte Open Source projecten.
@GertMenkel @Fab1Man Daar ben ik het grondig mee eens. Open Office is de naam van het project waarvan vrijwel alle ontwikkelaars het achter zich hebben gelaten: omzetten naar LibreOffice is de enige verstandige keus.
Als van zijn hele stukje alleen het stukje Apache open Office vs Libre Office bij je blijft hangen

Kom aan als je daar ons zuurverdiende belastinggeld aan wilt verkwisten
Tja, nu wordt het geld verkwist aan dure Microsoft producten en ondersteuning daarop. Grootste probleem dat overheden daarmee hebben is het privacy vraagstuk. Terecht punt mijn inziens. Wat bedrijven doen moeten ze natuurlijk zelf weten, maar het geeft wel te denken.

LibreOffice zal niet als losstaand producten worden ingezet, maar bijvoorbeeld als onderdeel van Nextcloud waar het geïntegreerd is als Nextcloud Office.
Rhel is voor het grootste deel gewoon foss en voor de rest zijn er prima alternatieven het is zeker niet zo dat centos geen opvolging kent

Maar om eerlijk te zijn onze overheid heeft veel problemen (lees casussen) waarvoor oplossinging bestaan die ook elders nuttig zijn als je al dat maatwerk publiceert kunnen anderen er ook gebruik van maken, van leren of controle op uitoefenen
Echter zit je met support. Sommige bedrijven verplichten/vereisen gewoon dat je een support contract hebt. Maar mooie is dat die voor heel veel OS projecten zijn. Soms zelfs meerdere. Denk aan RHEL dan wel CloudLinux/tuxcare en hun derivaten.

zijn inderdaad erg goede opvolgers van CentOS, die we ook gebruiken. Maar sommige “servers” hebben vanwege vereisten nu eenmaal een support contract nodig en daarvoor gebruiken wij de ondersteuning van cloudlinux/tuxcare.
Los van dat je je eigen mensen opnieuw moet trainen, als burgers dingen met Word of bijvoorbeeld Excel aanleveren, dan ga je het jezelf erg moeilijk maken door naar een platform te gaan dat niet native hetzelfde is.
En daar sla je de plank al mis.


Word en excel zijn het laatste waar ik aandacht aan zou besteden.

*appen (whatsapp)
*browser
*standaard search engine

Andere messenger zorgt ervoor dat Mark Zuckerberg en priscilla chan minder winsten gaan maken.
Andere browser zorgt voor betere integratie van opensource-modules
Standaard search engine zorgt ervoor dat binnen de EU serieuze alternatieven financiert (zonder woekerwinsten).

Ben je nog steeds niet waar je wilt zijn maar je slaat wel serieuze slagen en je hebt een betere basis ipv afhankelijk te zijn/blijven.


En al die drie factoren kun je binnen 3 maanden uitrollen zonder dat je serieuze issues gaat tegenkomen.
Lijkt me sterk dat ze deze opensourceofficer enkel aan nemen voor hun tekst, mail en spreadsheet verwerker. Er zijn vele complexere cusussen zoals het omzetten van ERP systemen naar opensource pakketten.
OpenOffice is al een jaar of tien een dood project. LibreOffice is de opvolger, wordt actief onderhouden en heeft een ecosysteem van partners waar je migratie, implementatie en ondersteuning diensten van afnemen in combinatie met Long-Term-Support builds van LibreOffice (Collabora Office, LibreOffice by Allotropia, en anderen). Daarnaast zijn er diepe integraties met derde partijen, zoals Collabora Office Online in Nextcloud/OwnCloud/Filr/Moodle en vele andere oplossingen welke in verschillende cloud oplossing worden aangeboden of beschikbaar zijn.

"dan ga je het jezelf erg moeilijk maken door naar een platform te gaan dat niet native hetzelfde is. "
Microsoft is nauwelijks compatibel met z'n eigen document formaat door de verschillende office versies heen, nog afgezien van de discutabele status van hun document formaat (zie ook opmerkingen van anderen omtrent dit punt).
Je gaat er van uit dat iedereen Windows en MS Office gebruikt, maar relaliteit is dat de groep die MacOS+Android+IOS+Chromebook gebruiken wellicht veel groter is. Op die platformen heb je een verscheidenheid aan document editors. Wat je aangeleverd krijgt kan dan wellicht een docx bestand zijn, maar zou er niet vanuit gaan dat dit met MS Office is opgesteld. Om die reden is het dus ook van beland om open document standaarden te hanteren. Overheid heeft zichzelf Open Document Formaat opgelegd, maar gebruikt dit in de praktijk nauwelijks, is mijn ervaring. Dan schiet je je als overheid dus in je voet wanneer je van oplossing wil veranderen. Dat wat je 10 jaar geleden had moeten doen, moet dan nu alsnog... klink met de huidige uitdagingen waar onze overheid mee te kampen heeft wel als bekend, afstel door uitstel:)
De code van overheid applicaties wordt voornamelijk in Nederland geschreven niet in de VS. En het wordt gehost wordt op en een eigen,nederlandse hosting partijen,AWS, Azure,GC,etc.

[Reactie gewijzigd door Cobalt op 22 juli 2024 14:54]

Heb je hier een bron voor? Eind januari meldde Lubach bijvoorbeeld dat er 1800 overheidssites zijn, gemeenten niet meegerekend. Dan hebben we het alleen over web applicaties, dus dat zullen er nog veel meer zijn. Het lijkt me dat je uitspraak dus op een onderzoek gebaseerd is, en ik ben erg benieuwd naar de details!
De code van overheid applicaties wordt voornamelijk in Nederland geschreven niet in de VS. En het wordt gehost wordt op en een eigen,nederlandse hosting partijen,AWS, Azure,GC,etc.
Waar host de Nederlandse Overheid eigenlijk al zijn (of moet ik beter zeggen, onze) data? Hebben ze hun eigen datacenter? Of maken ze gebruik van giganten als Amazon en Microsoft?

Ik neem aan dat informatie van ons als burger wel in Nederland bij een Nederlandse onderneming wordt opgeslagen?
Een snelle zoektocht levert in ieder geval deze vacature op die spreekt over een local cloud (op openshift?):

https://www.werkenvoorned...te&utm_source=shortcode#0
Ik denk dat uit het volgende artikel te concluderen is dat het momenteel, of tenminste tot eind 2022, op eigen cloud diensten werd bewaard.

nieuws: Nederlandse overheidsinstanties mogen straks commerciële clouddienste...
Er zijn 4 overheidsdatacenters (ODC), eentje in rijswijk, eentje in groningen. Kortweg: Haagse Kern Km
en ODC Noord.

Die andere weet ik niet 1-2-3, maar dat kun je makkelijk vinden. Toch gaan er ook stemmen op om deels het werk naar de giganten te laten sturen. Dit bijvoorbeeld met de migratie naar SAP Hana.
Apeldoorn (Belastingdienst), en 2 gehuurde locaties bij Equinix in Amsterdam :)
Ik kan je helaas nu even geen bronnen bij vinden maar voor zover ik weet wordt alle Nederlandse data van bijvoorbeeld belastingdienst maar ook justitie in een eigen datacenter gehaast of eigenlijk heeft onze overheid dus zijn eigen Cloud provider in het leven geroepen waar vervolgens door verschillende partijen gebruik van wordt gemaakt
Mijn vorige werkgever sloeg veel burger data op in azure private cloud. Maar dan specifiek in de azure data centra in Nederland.

edit: private cloud was de commerciele term, het zat gewoon in AKS, blob storage en mssql

[Reactie gewijzigd door Kriekel op 22 juli 2024 14:54]

En het wordt gehost wordt op en een eigen,nederlandse hosting partijen,AWS, Azure,GC,etc.
Dat zijn alle drie Amerikaanse bedrijven.

Dat ze ook een datacentre in NL hebben maakt het nog geen Nederlandse bedrijven. Uiteindelijk gaan de centen naar de VS en zitten de mensen die beslissen over voorwaarden, prijzen en andere belangrijke zaken ook in de VS. Die houden zich in de eerste plaats aan Amerikaanse wetten en normen. Daarmee wil ik niet zeggen dat ze dus Europese wetten negeren of breken, maar bij conflicten moet je er van uitgaan dat de Amerikaanse kant wint, zo gaat dat.

Soms wordt er nog een Nederlandse dochteronderneming tussen gezet zodat het op papier geen Amerikaans bedrijf is maar dat is vooral een schijnconstructie. Als puntje bij paaltje komt doen die dochters gewoon precies wat het Amerikaanse moederbedrijf wil. Er zijn wel een paar gevallen bekend waarin het niet zo is gegaan (zoals het geval waarin MS geen Europese data aan Amerikaanse onderzoekers wilde geven) maar dat is typisch omdat het moederbedrijf het eigenlijk niet eens is met de Amerikaanse wet en zich dus achter een Europese dochter verschuilt. Nu kan je dat in dit voorbeeld misschien toejuichen maar in het algemeen wil (kun) je daar niet op vertrouwen.
Je wordt gemint omdat wat je aangeeft een reëel probleem is, maar mensen nog steeds niet geloven dat dit het geval is;) Amerikaanse overheid mag zich toegang verschaffen tot jouw data en deze bedrijven moeten daar aan meewerken en mogen jouw daarvan niet op de hoogte stellen; Cloudact. Zou een rode vlag voor de overheid moeten zijn.
Public money, public code.
Waar ik me over verbaas is dat dit principe ook op andere gebieden totaal niet wordt gedaan.

Zelf werk ik in het onderwijs. Met gemeenschapsgeld wordt op een school onderwijs ontworpen (denk aan projecten, lessenseries, uitlegfilmpjes, toetsing). Maar al dat met gemeenschapsgeld ontwikkelde materiaal blijft vervolgens op die school en wordt in 99,99% van de gevallen niet gedeeld met andere scholen. Dus wat je krijgt is dat er in Nederland op 645 middelbare scholen telkens opnieuw het wiel wordt uitgevonden, men niets deelt en niet van elkaar leert 8)7 Ondertussen gaat er ook een grote geldstroom van al die scholen naar commerciële ontwikkelaars van lesmateriaal, tegenwoordig jaarlijks met de leuke licentiemodellen met online methodes..

Waarom stelt de overheid niet verplicht dat je een groot deel van je ontworpen materiaal online moet delen? In een soort github-achtig systeem, zodat anderen ook weer voorstellen kunnen doen om het verder te verbeteren. En waar materiaal geranked kan worden op basis van kwaliteit? Daar kom je toch veel verder mee dan nog tientallen jaren elke school weer op z'n eigen eilandje dingen laten maken?

Is ook nog eens werkdruk verlagend, als je als docent kunt putten uit een grote database waarin de creativiteit, denkkracht en evaluaties/verbeteringen van honderden/duizenden collega's is verwerkt.

[Reactie gewijzigd door Gizz op 22 juli 2024 14:54]

Enerzijds inderdaad een zeer goed initiatief.
De enige zaken waar ik mij vraagtekens bij zet is:

-SLA’s bij problemen (public money blijft dus uitgegeven worden)

-kennis en adoptie van medewerkers (zeker nieuwe medewerkers). Als ik nu al zie hoe vaak er al vragen komen over de Microsoft Office pakketen, waar de meeste al gewend aan zijn. Dan maak ik best zorgen over het gebruik van deze software.

-compatibiliteit met bestanden die door derden worden aangeleverd

-ondersteuning voor plug-ins van andere software (ja deze zijn ook hier voor te ontwerpen, maar dan zit je vaak weer tegen maatwerk aan, dat ook onderhouden moet worden)
Ook met open source kan geld verdiend worden, dat gaat vaak via de support en dus SLAs. Hoe moeilijk kan een tekstverwerker zijn? LibreOffice heeft zeker een opfrisbeurt nodig. Templating is niet geweldig, UI kan ook wel wat beter. En dan zijn er nog cloud oplossingen zoals OnlyOffice en Nextcloud Office. Het punt dat ik probeer te maken is dat er kansen liggen om die alternatieven te verbeteren. En in de zin van compatibiliteit, als je juist gaat voor Microsoft dan kies je voor incompatibiliteit. Zij gaan bewust tegen de open standaarden in. Dat hebben ze gelukkig verloren in de browser oorlog met IE, maar met documenten maken ze het leven van anderen nog steeds lekker lastig.
Microsoft files are still based on the proprietary format deprecated by ISO in 2008, and not on the ISO approved standard, so they hide a large amount of artificial complexity,” the blog post states. “This causes handling issues with LibreOffice, which defaults to a true open standard format (the OpenDocument Format).”
Bron: https://www.techradar.com...ng-microsoft-365-for-good
Ik heb al gebruikers gehad met vragen over Notepad. Ik denk dat je moet beginnen met te erkennen dat de meeste mensen, ook al staat er office op het CV, het verschil tussen een body-stijl en een kop-stijl in een word document niet weten en gewoon alles met Bold/Italics met het handje doen. Om dan te zeggen dat de stap naar een andere pakket zo lastig is.

Compatibiliteit met bestanden: Word documenten van derden mag je op veel plekken al niet openen (want virusgevaar) dus ik zie niet wat hier het probleem is. Daar is PDF voor.

Plugins: ja, dat is een ding. Maar dat is een beetje hetzelfde probleem als je website in Silverlight of Flash maken: gedoemd om te sterven.

Hier geld ook voor: 80/20: 80% is met een poep en een scheet over te zetten en er zitten een aantal lastiger vraagstukken bij.

Persoonlijk zou ik het op prijs stellen als mijn belastinggeld niet gebruikt wordt om nutteloze SLAs bij firma's in de USA te spekken, maar uitgegeven wordt aan lokale partijen.
Als iemand Office op zijn CV heeft staan dan verwacht ik ook dat die persoon daar een "Wizard" of iets dergelijks in is; anders beschouw ik het gewoon als nutteloze cv opvulling.

Helemaal mee eens dat compatibiliteit geen probleem hoeft te zijn gezien PDF's voor die reden er zijn. Als iemand Office op zijn blaadje heeft staan maar niet in staat is om een PDF aan te leveren dan weet je genoeg :P.
Je moet ze de kost geven die het aanmaken van een stijl in Word als hogere wiskunde zien en zichzelf daarmee office expert noemen. Als iemand word/vba neerzet dan denk ik: ok, dat is iets meer dan secretarieel werk.
Klinkt makkelijk, maar ik loop hier nu zelf tegenaan mbt Databricks. Om een fatsoenlijk data lakehouse te kunnen bouwen heb je databricks nodig. Als je puur Spark gebruikt mis je de belangrijkste features waardoor je allerlei lelijke hacks moet bouwen die er voor zorgen dat je product gewoon niet meer goed werkt en waardoor de ontwikkeltijd veel langer is. Het is een beetje de vraag of het zinnig is om véél meer tijd (en dus geld) in iets te stoppen om hetzelfde te ontwikkelen, puur omdat je per sé open source producten wil gebruiken.
Tja, ga er maar aan staan, voor minder dan 45 euro per gebruiker (commercieel) een
- client-OS deployen en onderhouden (Windows)
- een Office pakket deployen en onderhouden (Office365)
- een mailserver hebben met wettelijke compliance opties zoals legal hold en AVG-compliant mailboxen doorzoeken (ExchangeOnline)
- 1TB per user cloud storage (OneDrive)
- een (hosted) video conferencing/chat/telefonie/colaboration storage (Teams)

En voor scholen en ziekenhuizen zijn de licentie kosten bij MS zelfs nihil.

Ik zeg niet dat het onmogelijk is, maar met (hosted) alternatieven bij commerciele bedrijven gaat het toch al gauw meer kosten.
En dan zit je nog altijd met een client OS waar je geen software voor kan kopen zoals bijv AutoDesk, een Office pakket waarvan niemand precies weet hoe het werkt en waarvan het fileformat in praktijk toch niet compliant blijkt met import-jobs van andere software leveranciers. Over invoegtoepassingen voor Office (yek) nog maar te zwijgen.
Het verdienmodel van RedHat is immers dat het product gratis, maar je vet betaalt voor de support (bugfixes) op het product. Bij MS betaal je voor het product, waardoor je recht hebt op gratis garantie/bugfixes (al moet je geen eisen stellen aan de doorlooptijd). Beide bedrijven pakken hun winst wel.

Helaas leidt deze standaardisatie niet alleen tot kostenreductie maar ook tot armoe in het product-landschap. Dat moet ik dan wel weer nageven.

Software ontwikkelaars vergissen zich vaak hierin: zij hosten/beheren met hun collega's maar 1 softwarepakket waar ze zich volledig in kunnen verdiepen. Een beetje bedrijf/overheidsinstelling heeft 100 tot 200 softwareproducten hoog te houden die allemaal (samen) moeten werken. Als je geen gestandaardiseerde buildingblocks gebruikt, maar met de wanen van dag infra gaat bouwen CentOS, nee voortaan Debian, nee voortaan Debian dockers, nee voortaan moeten die Dockers in kubernetis staan...
Tja, voor bedrijven die 'many of one' moeten hosten werkt dat prima, maar als je 'one of many' in de lucht moet houden, dan is dat niet te doen.

[Reactie gewijzigd door Vogel666 op 22 juli 2024 14:54]

Een beetje bedrijf/overheidsinstelling heeft 100 tot 200 softwareproducten hoog te houden die allemaal (samen) moeten werken.
Is dat echt wel zo? Dan lijkt me dat ze daar al een probleem hebben - OpenSource of niet. En eigenlijk geloof ik ook niet dat het aantal zo hoog is.

Maar goed - dan nog, niet elke overheids instelling hoeft een office pakket te onderhouden. Dat kan wel degelijk centraal geregeld worden.
Punt blijft: maatwerk software is vast wel duurder dan een standaard pakket. Open Source valt daar een beetje tussen in denk ik (tussen maatwerk en standaard). Maar dat zijn kosten die je zou moeten maken om de afhankelijkheid (en mogelijke negatieve side-effects) tegen te gaan.

Met een OS ligt het misschien wel anders. Maar sinds MS het 'phone-home' gedrag nog verder heeft aangedikt valt dat ook inmiddels in de category 'moeten we dan wel willen?'.
Lijkt een goed initiatief maar ik snap alleen niet zo goed waarom dit beter zou zijn dan closed source. In sommige omgevingen zou je graag juist closed source willen zodat derden het niet zo gauw kunnen penetreren.
Ah ja, security through obscurity. Dat werkt altijd goed :P
Security through obscurity kan een prima aanvulling zijn in een bredere beveiligingsstrategie.
En uiteindelijk, als je er goed over nadenkt, gaat alle security over het beschermen van een stukje geheime (niet voor iedereen beschikbare) informatie. Dat kan een paspoort zijn, een geheime sleutel in een telefoon, je iris, etc.
Security through obscurity hoeft niet per se een issue te zijn net zoals open source niet per se veilig is (iedereen kan het aanpassen/checken argument).

Als 'security through obscurity' een onderdeel is van de oplossing en er daarnaast de security best practices worden gevolgd kan het in ieder geval de casual 'hackers' tegenhouden. (Denk aan SSH op een andere poort draaien, met alleen mogelijkheid om in te loggen met een public key en een IDS als fail2ban). Het is een heel bescheiden maatregel maar niet per se fout.

De illusie dat open source software open is en daarom veilig is ook gevaarlijk. Er zijn veel projecten, ook veel gebruikt, die maar weinig actieve maintainers hebben. Laat staan mensen die volledige audits uitvoeren. Wil natuurlijk niet zeggen dat open source niet veilig kan zijn.
Dat is nogal een dooddoener altijd. Die vlieger gaat natuurlijk alleen op als je het hebt over gehardcode wachtwoorden of extreem gebrekkige code waarvan men weet dat het kwetsbaar is maar niks aan wordt gedaan.

Security through obscurity werkt prima als middel om cybercriminelen harder te laten werken. Kijk naar Denuvo, een prachtvoorbeeld van "simpele code zo moeilijk mogelijk maken zodat niemand weet hoe het precies werkt". Voorkomt het dat games gecrackt worden? Nee, natuurlijk niet. Aan de andere kant is de cracktijd wel van "dagen" naar "maanden" gegaan en zijn hele piracy-groepen opgehouden omdat DRM tegenwoordig te moeilijk is voor een clubje hobbyisten. Momenteel zijn de enigen die deze tool verslaan nog gekke genieën (de persoon die het HP-spel heeft gekraakt) en professionele bedrijven die cheats verkopen voor heel veel geld.

Als er nog eens probleem van logjam-schaal wordt gevonden, ben je gewoon een stuk veiliger als criminelen niet weten welke stukken software je precies gebruikt die de kwetsbare bibliotheek gebruiken en hoe ze de aanval lokaal kunnen simuleren om hun succes te garanderen. Je moet nog steeds je shit patchen, maar de luiste hackers haken af en de slimmere hackers doen er een stuk langer over, en dat geeft je tijd om je patches goed uit te rollen.

Ik ben persoonlijk groot voorstander van open source en "publiek geld, publieke code" maar het gesloten houden van software heeft wel degelijk voordelen als het aankomt op hackbestendigheid. De firewallconfiguratie van de Belastingdienst hoeft van mij echter niet op Github en de tooling van de AIVD geef ik ook liever niet weg aan kwaadaardige landen die nóg verder gaan als het aankomt op burgers bespioneren.
Maar dat voordeel van gesloten software ben je kwijt als het standaard software betreft. Dan heeft de hele wereld toegang tot diezelfde software en wordt de groep van mensen met expertise vele malen groter. Tel daarbij op dat dan ook andere 'belanghebbenden' dus met minder effort een veel grotere reikwijdte hebben als ze kosten en moeite steken in het hacken van veel gebruikte standaard software.

OpenSource heeft dat nadeel ook wel maar daar zijn dan weer (vermoedelijk) ook weer meer mensen geneigd/bereid om zaken juist te fixen (die gebruikt zouden kunnen worden als 'hacker entry-point').

Anders gezegd: bij standaard software werken de ontwikkelaars van de leverancier aan verbetering (misschien ook niet als het een buitenlands produkt betreft...maar dat is een beetje complot-denken) en de rest van de ontwikkelaars probeert nu juist lekken te vinden en uit te buiten. Soms wordt er nog tegen betaling door externe gezocht naar lekken.

Bij OpenSource is de groep van externe ontwikkelaars onderverdeeld in mensen die juist proberen de lekken te vinden en zo te houden en anderen die juist die lekken willen fixen. Hoe die verdeling is, weet ik niet en zal per produkt verschillen. Maar ze zijn er in ieder geval.
Daar heb je grotendeels gelijk in (Denuvo blijft een mooi voorbeeld). Ook is vaak de configuratie erg belangrijk, want veel standaardsoftware is erg modulair. Zo kun je Office helemaal dichttimmeren en Windows beperken tot executables op een whitelist en daarmee de meeste standaardexploits ontzettend moeilijk maken, waar een bedrijf dat de boel gewoon met fabrieksinstellingen draait in één klap geransomwared zou zijn.

Echter gaat het bij de software die dit artikel benoemt vooral om speciale Belastingdienst-software. Wellicht zijn er proprietary-pakketten die de belastingdienst gebruikt waar open pakketten ook voldoen, maar ik denk dat dat maar een beperkte subset is.
Hogwarts legacy was anders binnen 2 weken gekraakt, dus ik weet niet of je de vergelijking met Denuvo kan maken. Natuurlijk gebruikt zoiets ook obscurity, maar bijna zeker ook een vorm van encryptie.
Soms is closed source toch slimmer. OpenSSL is een super veel gebruikt stuk software. Toch kwamen we er indertijd achter dat het nooit fatsoenlijk ge-audit was. Dat werd een wereldwijd probleem.
Denk je dat een obscuur administratief pakket wat een Nederlandse gemeente heeft laten ontwikkelen dan ooit een audit krijgt? Wie gaat dat doen? Als niemand met verstand van zaken ooit een audit van die code doet, levert open source alleen maar extra risico op, omdat kwaadwillenden dan als enige naar die code kijken.
Closed source maakt dat een overheid afhankelijk is van een partij. Als die partij besluit zich uit te laten kopen door [willekeurig land hier], dan blijkt dat die afhankelijkheid toch niet zo fijn is. Met open source kan je een project forken zodat je zelf de baas blijft over de applicatie.

Closed source is niet veiliger dan open source. Obscurity != security. En het is maar de vraag hoe closed source applicaties echt zijn anno 2023. Een lek/hack en de broncode ligt bij een dubieuze partij, en er is (buiten het originele bedrijf) niemand op de wereld die je kan helpen. Bij open source heb je dan nog ten minste de community die je kan helpen (niet redden).
Een stukje binaire code disassemblen en decompilen of terug brengen tot ~ leesbare code ligt ook volledig binnen de mogelijkheden van vandaag. Dit vraagt misschien wel wat werk. Maar iemand die securityfouten wil vinden in overheidssoftware heeft dat daar zeker voor over.

Vaak hoef je (of wil je) voor bepaalde securityfouten ook niet echt alles te decompilen / disassemblen maar wel enkel het stukje dat er toe doet (het stukje dat de authenticatie doet, dat de encryptie doet). Debuggers en andere tools kunnen heel fijn en goed in de binary code identificeren waar en welke code dat is. Bij wijze van spreke zet je een breakpoint op een gekend punt, en een typische debugger laat al een scherm aan assembler zien (rondom dat punt). Copy-paste dat in een decompiler en hup dat was alles. Of lees gewoon de assembler. Assembler is helemaal niet moeilijk te begrijpen.

Mensen die denken dat binaire code veilig is omdat zij het zelf niet of weinig begrijpen, begrijpen ook niets of weinig van security in software code.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:54]

Het grote misverstand dat veel mensen hebben is dat je de broncode nodig hebt om fouten te vinden en dat klopt inderdaad niet.

Je hebt de broncode nodig om de fouten op te lossen. Strict genomen is ook dat niet helemaal waar maar in praktijk zal je niet meer dan minimale veranderingen kunnen doorvoeren zonder de broncode en het is een stuk moeilijker.

Het klopt op zich wel dat aanvallers ook voordeel hebben van het kunnen inzien van de broncode. maar het voordeel voor de verdediging is veel groter. De aanvaller hoeft immers maar één fout te vinden en te misbruiken en soms kan een aanval bestaan uit een aanpassing van niet meer dan 1 bit, de verdediging moet álle fouten vinden en dichten voordat de aanvaller er misbruik van maakt. Daarbij moet de verdediging ook nog eens zorgen dat de software wel blijft werken terwijl de aanvaller daar veel minder om zal geven (als het doel al niet is om uitval te veroorzaken).
Mensen die denken dat binaire code veilig is omdat zij het zelf niet of weinig begrijpen, begrijpen ook niets of weinig van security in software code.
Yup, vinger op de zere plek. Dit is een van de waarschuwingssignalen die ik gebruik om de technische kennis van anderen te beoordelen. Hoe harder er op geheimhouding wordt gehamerd hoe minder kennis er is. En nee, ik zeg niet dat álles openbaar moet, sommige dingen moet je wél geheim houden (en dat heeft niks met 'security through obscurity' te maken). Maar mensen die er genoeg van snappen om er logisch over te redeneren zijn helaas vrij zeldzaam.
Dat is gebaseerd op de (foutieve) aanname van "security through obscurity": het feit dat iets closed source is, wil niet zeggen dat het minder makkelijk te penetreren is. En andersom: open source code is niet inherent minder veilig dan closed source, sterker nog: omdat iedereen er naar kan kijken, is de kans in principe groter dat security bugs gezien en opgelost worden c.q. dat goede security-principes als 'zero trust' worden toegepast. (natuurlijk zijn er ook tegenvoorbeelden, van beide kanten)

En nog even los van security: open source heeft nog wel meer voordelen, bijvoorbeeld m.b.t. vendor lock-in. Zie ook https://opensource.com/resources/what-open-source
Ik leg mensen wel eens de vraag voor of ze zich comfortabel zouden voelen in een auto waarvan de fabrikant weigert om uit te leggen hoe de remmen werken, welke materialen er gebruikt worden en wat daar de sterke en zwakke punten van zijn. Tevens is het verboden om iets aan de remmen te veranderen. Je moet er mee rijden zoals ze uit de fabriek zijn gekomen.

Als je merkt dat je auto niet goed remt en je dat op internet zet wordt je aangeklaagd door de autofabrikant die je beschuldigt van "hacken".

Als ze dan over Tesla beginnen te ranten (op de een of andere manier doen de meesten dat) voeg ik nog even toe dat Elon Musk zelf de remmen heeft ontworpen en gemonteerd. (Dat is misschien een beetje makkelijk maar niet onderbouwde onderbuikgevoelens zijn haast niet met logica te veranderen. Zeker als de andere kant eerst moet toegeven er eigenlijk niks van te wten. Soms is het eenvoudiger om ze dan maar te laten struikelen over andere onderbuikgevoelens.)
Dan heb je security through obscurity en dat is ook niet altijd goed. Kijk bijvoorbeeld naar Windows vs Linux of LastPass vs Bitwarden.

Door de source code open source te maken kunnen meerdere partijen kijken of er problemen zijn, en in combinatie met een bug-bounty programma ook nog belonen voor gevonden problemen.
Hoewel ik het op zich eens ben met je veronderstelling dat gesloten broncode niet per definitie veiliger is dan open broncode, zijn de door jou aangehaalde voorbeelden gewoon pertinent onwaar. Microsoft Windows is alles behalve minder veilig dan bijvoorbeeld red hat Linux

En ondanks dat lastpass Onlangs negatief in het nieuws kwam kun je eigenlijk niet zeggen dat de problemen kwamen doordat hun software niet open source was sterker nog hij lag in dit geval een organisatorisch probleem aan ten grondslag

De werkelijke verschillen in veiligheid van software zitten hem uiteindelijk ook niet alleen in de toegang tot broncode maar eerder in de mate waarin de software op veiligheid wordt getest Het zal dus duidelijk zijn dat kleine foutjes in de broncode bij open source wellicht iets sneller zullen worden gevonden omdat er meerdere mensen naar kijken maar naarmate software ingewikkelder wordt en er dus meer expertise nodig is kun je ervan uitgaan dat het aantal personen die er naar kijkt significant kleiner wordt als het gebruik meer verspreid ligt. Je kunt dan dus beter hebben dat iedereen op Windows it dan dat Jantje bij Ubuntu zit pietje red hat een Klaasje bij gento
Je haalt iets door elkaar. Standaarden moeten open zijn. Dat je ze vervolgens met encryptie afsluit voor ongure partijen staat daar los van, maar sluit elkaar niet uit. Idealiter is ook je encryptie open source, wat dus niet betekend dat iedereen die encryptie kan kraken, maar dat de encryptie inherent goed in elkaar zit zodat echt alleen de geheime sleutel de encryptie ongedaan maakt.
Hee daar heb je mevrouwtje die ongeacht motie van de tweede kamer alsnog in EU top heeft ingestemd met de digitale munt.
Ook lekker geruststellend dat de officier van open source het grote open source event van Europa skipt en een remote berichtje inbeld. Voor zo ver dit plan. Heb meer vertrouwen in de impact van het OFE dan in Van Huffelen in dit geval. Met het bestaan van de rol is er in ieder geval vast ruimte voor het volgende kabinet om dit wellicht wel serieus te gaan nemen...
Eindelijk een stap naar de juiste richting!
En het heeft niets 100% met veiligheid te maken, maar met ethiek.
Opensource op alle levels please.. hardware, software, networking, procedures & security governance.
Open Source (Program) Office is wel een slechte naam zeg. Maakt de titel hier ook niet duidelijker van. Maar ze krijgen dus een 'commissie open source' zou ik zeggen.
Alleen als je niet kan lezen, een officer is heel wat anders dan office
Het begrip programma betekent niet per definitie dat het een applicatie betreft. Vervang de IT van de overheid is een programma. Vervang de IT van Financiën is dan een sub-project en tevens voor Financiën een programma. (Bestaande uit IT Afdelingen BTW, Loonbelasting, Onroerend goed etc.)

Iemand die dergelijke activiteiten ontplooit noem je een Programma-manager. In het nederlands:
Open Broncode Programma Manager, wat vertaald kan worden naar exact de term Open Source Program Officer.

Die Officer (Manager) kan dan één persoon zijn of leiding geven aan een hele afdeling die onder die naam valt (in het nederlands spreek je dan wellicht van Projectbureau).

Dus afgezien van de discussie waarom in het Engels is de naam prima gekozen.
Ik had niet goed gelezen zoals @Gerton ook aangeeft. Verder haal ik programma en applicatie niet door elkaar. Wel een goeie onderbouwing dat het een goeie naam is, maar in de titel wordt dus de naam zonder spaties gehanteerd, wat dus bij mij de verwarring veroorzaakte.
Overheids "Opensource" zou wellicht nog zoveel waarde hebben als dat de overheid met hun nieuw bestuurscultuur te koop zit te lopen met hun zogenaamde transparantie :+

[Reactie gewijzigd door deniz280 op 22 juli 2024 14:54]

"Wa zeggie? Commissie open office? Heet da nie libreoffice tegenwoordig ofzo?"
Op haar linked in zie ik letterlijk niets wat ook maar iets te maken heeft met software. Waarom hebben we ministers die over zaken gaan waar ze zelf geen ervaring in hebben?
Op haar linked in zie ik letterlijk niets wat ook maar iets te maken heeft met software. Waarom hebben we ministers die over zaken gaan waar ze zelf geen ervaring in hebben?
Omdat in de hedendaagse politiek de achtergrond niet meer zo zwaar weegt als we zelf zouden willen misschien. Ik heb liever ook iemand met een militair verleden als Minister van Defensie, maarja... kennelijk is dat geen eis als je minister wilt zijn.

Ergens denk ik ook niet dat het noodzakelijk moet zijn mits een Minister zich goed laat informeren en op basis van de infromatie goede besluiten neemt. Maar toch merk je in de praktijk dat he vooral de burger doet twijfelen aan de bekwaamheid van een minister, en dat vind ik wel een ding. Bovendien zien we ook met onze Minsters van Buitenlandse Zaken en Financiën dat ze duidelijk op de verkeerde plek zitten.
De minister van defensie is als enige een slecht voorbeeld, omdat de militaire kennis bij de commandant der strijdkrachten ligt. De minister maakt niet eenzijdig beleid, maar dat doet in samenwerking. Dat geldt in mindere mate natuurlijk ook voor andere ministers. Die winnen advies in.
Omdat het ministerie een bedrijf is. Daar zet je geen ICT persoon neer maar een goede ondernemer/manager.
Voor inhoudelijke vragen heb je met kennis om je heen dwarrelen.
Helaas is die goede ondernemer/manager het dus ook niet geworden.
Op haar linked in zie ik letterlijk niets wat ook maar iets te maken heeft met software. Waarom hebben we ministers die over zaken gaan waar ze zelf geen ervaring in hebben?
Ik verkondig graag dat iedereen tegenwoordig iets te maken heeft met software en dat alle bedrijven inmiddels softwarebedrijven zijn, de meesten weten het alleen zelf nog niet.

Zo'n beetje ieder apparaat heeft tegenwoodig een chip en wat software.

Vanuit dat standpunt zou iedereen dus ook geschikt moeten zijn om iets over software te zeggen of denken.

Maar ja, als dat de praktijk was dan hoefde ik mijn stelling niet te verkondigen. Vaak beseffen mensen gewoon hoeveel IT er om ze heen gebeurt. De meeste mensen beseffen bijvoorbeeld niet echt dat iedere "slimme" lamp een chip aan boord heeft waar een besturingsyssteem op draait en een applicatie. Ze beseffen al helemaal niet dat zo'n lamp meer rekenkracht heeft dan de raketten waarmee we op de maan zijn geland.

Het is lastig uit te leggen dat de concierge niet gewoon een nieuwe lamp van de bouwmarkt mag inschroeven.
True

[Reactie gewijzigd door deniz280 op 22 juli 2024 14:54]

Ik ben ergens wel benieuwd wat voor functie profiel hier bij zit. Wat voor iemand zoekt men hiervoor en wat heeft een dergelijke OSPO in zijn Mars nodig om deze functie te kunnen bekleden? :)
Waarschijnlijk is wie je kent en/of van welke partij je lid bent belangrijker dan kennis van zaken (zie de betreffende staatssecretaris).

[Reactie gewijzigd door Meessen op 22 juli 2024 14:54]

Mooi idee.

Alleen verwacht ik dat er voor opensource omgevingen binnen de overheid veel kennis en specialisten nodig zijn. Je kan het inkopen als support bij een derde partij, maar wat heeft dat voor nut als het inkopen van close support bij een andere partij exact hetzelfde opleverd?
Ik werk bij de overheid en ken ons applicatielandschap goed..

Ik heb 10 jaar voor een softwareboer gewerkt en weet dat er best wat handjes, processen nodig zijn om van ontwerp naar in gebruikname door gebruikers 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?

Verder mis ik de focus/tijdlijn in dit initiatief, 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.
Heel goed dat er naar Opensource gekeken wordt. bespaard handen met geld aan Licentiekosten aan Apple en M$. Ook wordt je zo minder afhankelijk. en kun je de regie weer een beetje in eigen handen nemen. Goed voorbeeld. Al neem ik alleen maar Open Office , Libre Office in vergelijking met MS Office m.b.t. de Portemonnee. prijs en kwaliteit verhoudingen.

[Reactie gewijzigd door Whdr op 22 juli 2024 14:54]

Op dit item kan niet meer gereageerd worden.