Overheid gaat opzet ontwikkeling corona-app wellicht in toekomst vaker gebruiken

Staatssecretaris Raymond Knops van Binnenlandse Zaken gaat kijken of het ontwikkelproces van de CoronaMelder-app in de toekomst kan werken voor andere ict-projecten van de overheid. De overheid ontwikkelde de corona-app in het semi-openbaar.

Knops schrijft in een brief aan de Tweede Kamer dat hij het ontwikkeltraject rondom de Nederlandse corona-app gaat evalueren. Hij doet dat in opdracht van het ministerie van Volksgezondheid, na vragen van SP-Kamerlid Maarten Hijink. Die laatste vroeg tijdens een debat uit te zoeken wat er allemaal goed ging op het gebied van transparantie en het betrekken van vrijwilligers en experts. Knops gaat daarin mee, zegt hij.

De staatssecretaris schakelt het Bureau ICT Toetsing of BIT in voor de evaluatie. "Met het BIT en mijn ambtsgenoot van VWS ga ik in gesprek over de wijze waarop de evaluatie vorm kan krijgen en het geschikte moment om deze te starten", schrijft hij. Knops denkt dat de evaluatie veel kan betekenen voor toekomstige ict-projecten van de overheid. "Ik zie net als uw Kamer de meerwaarde van zo’n evaluatie ten behoeve van het lerend vermogen binnen het stelsel en zeg u hierbij toe dat te zullen doen."

De ontwikkeling van de corona-app kreeg na een wat moeizame start veel lof van experts. Bij de ontwikkeling werden externe experts betrokken die zowel over het ontwerp als de privacyaspecten nadachten. In totaal kostte de ontwikkeling van CoronaMelder rond de vijf miljoen euro.

Reacties (131)

[wifikabelhuren]

In totaal kostte de ontwikkeling van CoronaMelder rond de vijf miljoen euro.
Waar halen ze al die kosten vandaan. Snap dat er heel wat handjes aan werken en koppelingen gemaakt moet worden met ggd.. maar 5 miljoen? Ik snap niet dat er zoveel geld in om gaat.
De ontwikkeling van een boekhoud pakket als e-boekhouden/twinfield is nog goedkoper. En dat zijn complexere dingen dan zo'n app.

[robinvw1]

Waar halen ze al die kosten vandaan. Snap dat er heel wat handjes aan werken en koppelingen gemaakt moet worden met ggd.. maar 5 miljoen? Ik snap niet dat er zoveel geld in om gaat.

Die 5 miljoen euro voor dat 'appie' bevat onder andere:
- testen van de toegankelijkheid voor een hele grote doelgroep zoals blinden
- niet alleen 'simpelweg' een design, maar heel veel gedragsonderzoeken
- de portal waar de GGD op in kan loggen en het testen met de GGD's
- penetratietesten
- de back-end (coronamelder-api.nl en https://productie.coronam...l/v1/exposurekeyset/:uuid waar de keys worden opgehaald)
- poging tot 'reproducible builds' door middel van de Landsadvocaat de builds op GitHub met de App Store verifiëren

Eigenlijk alles wat je op https://github.com/minvws ziet, was er nog niet. Er is echt heel veel werk verzet.

[GrooV]

Zou je kunnen toelichten wat de Landsadvocaat precies heeft gedaan? Heeft hij gecontroleerd of de zelfde code die op Github staat ook in de Appstore stond?

[robvanwijk]

De theorie is dat, als een stuk software open source is, iedereen de code kan onderzoeken om bugs en backdoors op te sporen. Het probleem is dat je daarmee alleen kunt laten zien dat de source "schoon" is. Blijft de vraag, is die openbaar beschikbare code ook echt de source die gebruikt is voor het bouwen van de object code ("het echte programma")?
In theorie zou je de source zelf kunnen compileren en kijken of het resultaat hetzelfde is als het programma dat je downloadt uit de app store. Maar moderne software (het "programma zelf", alle gebruikte libraries, de compiler, linker en assembler, ...) is zo complex dat het antwoord op die vraag eigenlijk altijd "nee" zal zijn. Zelfs als je uit dezelfde source, met dezelfde ontwikkelomgeving, op dezelfde computer twee keer de hele applicatie bouwt, dan zullen daar normaal gesproken flink wat verschillen tussen zitten (al was het maar omdat er net iets andere beslissingen zijn genomen bij het optimaliseren). Als je een build op jouw computer vergelijkt met de binary die gebouwd is door het ministerie (andere computer, niet alleen een andere versie van de compiler maar misschien zelfs een compleet andere ontwikkelomgeving), dan zijn die verschillen nog heel veel groter.
Als je die verschillen met de hand gaat analyseren dan kun je elk verschil wel verklaren, maar dat is gruwelijk veel werk wat alleen door specialisten gedaan kan worden. Wat je eigenlijk wil is dat iedereen die enigszins kennis van programmeren heeft de exacte ontwikkelomgeving na kan bouwen: niet alleen weten dat je GCC moet installeren, maar ook het exacte versienummer van de compiler en van elke gebruikte library en ... tot en met welke flags je moet meegeven. Als je dat allemaal gedaan hebt, dan heb je een reproducible build gemaakt en kun je keer op keer exact dezelfde binary produceren (met hooguit andere timestamps in de header). Daarmee kun je er vertrouwen in hebben dat de (object) code die je draait ook echt overeen komt met de (source) code die je onderzocht hebt.

[Reactie gewijzigd door robvanwijk op 23 juli 2024 17:09]

[dsdevries]

Is dit niet gewoon het idee achter een checksum? De landsadvocaat geeft een public key uit waarmee een checksum opgemaakt en versleuteld kan worden tijdens het compileren. De landsadvocaat is als enige in bezit van een private key waarmee de checksum gelezen kan worden. De checksum moet vervolgens overeenkomen met de bits van de gecompileerde code.

[SpiceWorm]

Met een checksum zal je alsnog die landsadvocaat moeten vertrouwen. Ondertekend die de juiste binary?

Met een reproducible build kan iedereen met de juiste kennis het checken. Ook het build proces open source en verifyable dus.

[GrooV]

Thnx voor de uitleg maar wat was de rol van de landsadvocaat hier in? Ik neem aan dat die niet zelf in de code is gedoken

[robvanwijk]

Thnx voor de uitleg maar wat was de rol van de landsadvocaat hier in? Ik neem aan dat die niet zelf in de code is gedoken

Ik heb werkelijk geen idee, misschien kan @robinvw1 daar antwoord op geven? Als ik Google vraag naar "landsadvocaat coronamelder reproducible build" dan is de eerste treffer dit artikel... Da's niet heel handig. Mijn post was vooral bedoeld om uit te leggen wat een reproducible build is, want ik heb het gevoel dat dat begrip niet algemeen bekend is.

Als ik een gokje zou moeten wagen, dan zou ik verwachten dat het een methode is om niet-programmeurs ook vertrouwenn te geven in CoronaMelder. Jij en ik hebben op zich de kennis om de source van CoronaMelder uit te checken, de stappen te volgen, onze eigen build te maken en die te vergelijken met de APK die in de store staat, maar er zijn heel veel mensen die die kennis gewoon niet hebben. (Plus, om heel eerlijk te zijn... ik heb wel de kennis, maar helemaal geen zin om dat te moeten doen.) Het zou voor iedereen veel makkelijker zijn als een klein aantal personen (onafhankelijk van elkaar!) controleert dat de code op GitHub inderdaad overeenkomt met de APK. Als er dan ook nog even iemand is die hun verklaringen naast elkaar legt (al lijkt me dat niet de taak van de landsadvocaat, is dat niet meer iets voor een notaris...!?) dan kan heel Nederlands (nou ja, behalve de alu-hoedjes) erop vertrouwen dat het afdoende gecontroleerd is dat de source code overeenkomt met de object code.

[SpiceWorm]

Goede uitleg, maar dit:

Zelfs als je uit dezelfde source, met dezelfde ontwikkelomgeving, op dezelfde computer twee keer de hele applicatie bouwt, dan zullen daar normaal gesproken flink wat verschillen tussen zitten (al was het maar omdat er net iets andere beslissingen zijn genomen bij het optimaliseren).

Lijkt mij sterk. Het zou echt dezelfde code op moeten leveren. De compiler maakt geen andere beslissingen 's avonds dan 's middags om een voorbeeld te geven.

[robvanwijk]

Het zou echt dezelfde code op moeten leveren. De compiler maakt geen andere beslissingen 's avonds dan 's middags om een voorbeeld te geven.

Dat dacht ik ook ooit, maar dat blijkt tegen te vallen. Praktijkvoorbeeld: https://alioth-lists.debi...-Mon-20150209/000933.html

Ik denk dat de kern van het probleem is dat we heel lang compilers geschreven hebben met het idee "zolang de executable correct werkt is het goed", zodat overal en nergens "ach, het maakt niet uit, dus doe maar wat" beslissingen worden genomen. Bijvoorbeeld:

quote: https://reproducible-builds.org/docs/stable-inputs/

Stable order for inputs

If building your software requires processing several inputs at once, make sure the order is stable across builds.

A typical example is creating an archive from the content of a directory. Most filesystems do not guarantee that listing files in a directory will always result in the same order.

Als je doorklikt staat er een voorbeeld van een Makefile die een niet-reproduceerbare build veroorzaakt. Er staan ook meteen twee mogelijke oplossingen bij; niet alle problemen zijn moeilijk, maar als niemand in een project hier ooit naar gekeken heeft, dan is er een goede kans dat er wel heel erg veel problemen zijn. En ze moeten allemaal opgelost worden voordat je een reproducible build hebt.

[JosWo]

En dat is dus precies wat Nix(OS) als sinds 2003 doet, https://nixos.org/
Een idee van NL bodem dat naar mijn idee sindsdien veel te weinig aandacht krijgt:
Reproducible builds and deployments.
Nix
A powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible. Share your development and build environments across different machines.

NixOS
A Linux distribution with a unique approach to package and configuration management. Built on top of the Nix package manager, it is completely declarative, makes upgrading systems reliable, and has many other advantages.

[zeno4ever]

Iemand van Landsadvocaat die kennis heeft van het compileren kijkt mee als van de broncode gecompileerd word en zet een stempel hierop dat het volgens de regels gebeurt is. Wat hieronder ook staat in principe zou je denken dat dit eenvoudig zou moeten zijn maar door verschillen in libaries etc kan het gecompileerde product er toch anders uitzien als je het zelf zou doen. Het is dus een soort accountantsverklaring dat het allemaal op de goede manier is gedaan.

[Sorcerer8472]

Idd, ik moet het hier mee eens zijn. Het is niet overdreven duur voor het werk wat er is verricht. Deze werkwijze kan in de toekomst erg veel geld besparen én garandeert waarschijnlijk een beter eindresultaat.

[aileron]

Als je het zo brengt wordt ik bijna enhousiast van een IT project van de overheid. Het moet niet gekker worden

[actionInvoke]

Ik werk als een lead bij de overheid. Een software engineer in dienst verdient ongeveer 65-120k excl. extra's. Reken dat ruwweg keer 2/3 voor de totale kosten. Diverse project management aspecten, zoals PO's en natuurlijk management. Een leger aan ops personeel is ook nodig. Consultants kosten met gemak 60-250€ per uur. Testers voor alle aspecten. Je hebt in een klein software team al gauw 15-20 man rond lopen.

En dan komen de echte kosten. Uptime en redundante servers die aan veel hogere eisen moeten voldoen dan wat een vps toko om de hoek levert. Dat pakket waar jij het over hebt is simpel als je gaat kijken naar de robuustheidseisen van kritieke overheids infra.

Daarbovenop moet je nog kijken naar alle niet direct berekenbare overhead. Reken maar uit aan kosten. 5 miljoen is kleingeld.

[SPee]

Dit project heeft toch geen jaar geduurd qua ontwikkeling?
Of is dat salaris per maand, want dan wil ik wel overstappen

[BlueSpirit]

Vergeet niet dat de overheid niet blind een API kan gebruiken, maar ook de nodige aanvullende testen moet doen. Immers ze gaan beleid maken waar mensen de overheid voor aansprakelijk zullen stellen. Denk aan https://magazines.defensie.nl/specials/2020/02/02_corona-app of het onderzoeken van meldingen of uitgebreide rapporten die derden insturen. Allemaal verborgen kosten die verder gaan dan wat code kloppen

[Mellow Jack]

Sinds maart/ april dus het is echt niet overdreven veel geld. Personeelskosten zijn 1 maar dan heb je nog niet zoveel. Het team heeft tools nodig. Dat kost geld en FTE's. Een team heeft een hosting platform nodig. Kost ook weer geld en FTE's. De applicatie zelf gebruik vaak middleware en runtimes. Kost ook weer geld en FTE's. Omdat het een high profile project is moet ook alles nog een extern gevalideerd worden (security, accountancy, juridisch) Enz enz enz

Noem nadrukkelijk ook het verschil tussen FTE's en geld Het is altijd een belans tussen outsourching, licenties en werknemers binnen de kaders van de wetgeving, opdracht en het budget.

5 miljoen is echt heel netjes binnen de context waarin het project is uitgevoerd. Wat ik wel lastig vind aan belaalde software projecten is dat er tegenwoordig bijv. een beeld ontstaat dat je dmv webshosting of de public cloud ineens heel makkelijk en goedkoop websites en apps kan hosten. Helaas is dat niet altijd het geval wanneer je een bepaalde schaalgrootte, redundantie en security vereisten moet kunnen afvangen.

[actionInvoke]

[...] Wat ik wel lastig vind aan belaalde software projecten is dat er tegenwoordig bijv. een beeld ontstaat dat je dmv webshosting of de public cloud ineens heel makkelijk en goedkoop websites en apps kan hosten. Helaas is dat niet altijd het geval wanneer je een bepaalde schaalgrootte, redundantie en security vereisten moet kunnen afvangen.

Dit is zeker waar en ervaren wij ook. Mensen denken dat applicatie ontwikkeling tegenwoordig makkelijk is. Daarnaast wordt de markt overspoeld door bedrijven en mensen..... van mindere vak kwaliteit. Dat maakt goede mensen vinden zeer moeilijk.

Er komt zo. enorm. veel. veel. veel. meer bij kijken om een applicatie te ontwikkelen dan wat mensen denken. De processen, de organisaties, bestuursrechtelijke zaken, wet gerelateerde zaken, etc. etc. Voordat er ook maar een regel code is geschreven zijn er vaak al veel meer dan een dozijn mensen bezig.

De daadwerkelijke ontwikkeling van een applicatie is maar een heel klein element en de gehele trein.

[actionInvoke]

Infra puur qua metaal kost al richting wat hier boven wordt genoemd. Als je op extreem hoge eisen stelt dan kosten dingen ook wat. Dit soort zaken zijn niet zo maar een webshopje oid die op een kubernetes/aws/etc platform yolo gedropt kunnen worden.

Dit project zit er waarschijnlijk wat anders in dan wij maar punt blijft, ze hebben in extreem versneld traject iets moeten bouwen van null naar 100. Ik ben verder niet bekend met dit project maar dan komt er wel iets bij kijken.

De fout die ik mensen altijd zie maken is dat ze een bedrag als 5 miljoen zien, ze redeneren vanuit hun eigen perspectief als persoon. Dan is het veel geld.
Voor een overheid, die bijna 300 miljard aan inkomsten heeft en nu een oplossing voor een bepaald probleem nodig heeft, is 5 miljoen zakgeld. Er wordt een berekening gedaan hoeveel corona aan schade aan richt en hoeveel zo'n tool dat in kosten reduceert. Dat bedrag zal een stuk hoger zijn dan 5 miljoen.


Salaris bij 0.8-1 fte/y.

[K-aroq]

5 miljoen is echt niet zo veel voor zo'n project. De vergelijking met een boekhoudpakket is niet terecht, dat is immers slechts een geautomatiseerd kasboekje waarvan de principes al jaren hetzelfde zijn. Je pakt ene boek over financieel management en je weet alle requirements. Verder is er geen back-end integratie nodig en geen nieuwe bedrijfsprocessen.

Maar ik zou zeggen: bewijs dat het veel goedkoper kan door een eigen variant te maken die net zo goed werkt.

[Bor]

De complexiteit zit hem in dit geval mede in de relatieve eenvoud waarmee een antwoord op een complex vraagstuk is gegeven. Een boekhoud pakket is niets nieuws en bovendien iets van waar de spelregels aardig uitgekauwd zijn. Een vergelijkbare App als deze was er volgens mij nog niet. Hierbij komen nog de privacy en beveikigingseisen die hoog liggen. Het is, ondanks beide software, appels en peren vergelijken.

[Moartn]

Onderschat ook niet hoe veel tijd in toegankelijkheid en gebruiksvriendelijkheid is gaat zitten bij zo'n app. Het ontwerp en de teksten zijn zo gemaakt en geschreven dat elke nitwit het moet kunnen begrijpen. En dat ook nog eens in veel verschillende talen. En het moet ook werken voor kleurenblinden, volledig blinden en andere mensen met handicaps. En ze hebben uitgebreid gebruikerstests gedaan met allerlei groepen (potentiële) gebruikers om te zorgen dat het duidelijk genoeg was.

Heeft allemaal niks met programmeerwerk te maken, maar hoort wel bij de kosten die horen bij "het onwikkelen van de app".

[iAR]

Volgens mij doet Apple daarin al veel voor je (net als Google wellicht)., in API’s en frameworks. Toegankelijkheid is al jaren een groot ding op iPhones. De teksten zijn in 9 talen plus Nederlands.
Waarschijnlijk is het wél wat je zegt: testen, support, bugfixes die ook in die 5 miljoen zitten.

[Reactie gewijzigd door iAR op 23 juli 2024 17:09]

[AmazingDreams]

Apple zal hoogstens een oppervlakkige toegankelijkheid controle uitvoeren, maar ze zullen je echt niet helpen om dit te verbeteren.

[iAR]

Ik bedoel niet dat Apple naast je gaat zitten, eerder dat er een grote collectie api’s is om toegankelijkheid in je apps te bouwen.

[GrooV]

Klopt, Apple levert API's maar dan moet je nog steeds je app daar voor beschikbaar maken en bedenken wat waar getoond moet worden. Een API doet niets automatisch

[CodeGuy]

Goedkoper dan de Duitse variant. Die heeft naar schatting 20 miljoen gekost https://9to5mac.com/2020/06/16/germanys-contact-tracing-app/.

[arianvp]

In Belgie hebben ze de Duitse code geforkt. In iedergeval de frontend. Want de apps zien er identiek uit voor mij.

Er is wel gediscussierd in de CodeForNL-community of forken een goeie strategie was.

Een probleem is dat de zorgprocessen in Duitsland en Nederland heel anders zijn ingericht. de "Achterkant" van de app zou dus sowieso opnieuw moeten; en ook hoe de app resultaten terugkoppeld naar zorgsystemen.

Verder is aan de voorkant ontzettend veel gebruikersonderzoek gedaan om hem zo gebruiksvriendelijk mogelijk te maken. Iets was ik erg vond missen bij de Duitse app. De Duitse app is wat vaag en onduidelijk naar mijn mening. Door die gebruikersonderzoeken zijn er ontzettend veel pijnpunten gevonden die we anders pas veel later (na de launch) tegen waren gekomen (https://github.com/minvws/nl-covid19-notification-app-design click maar beetje rond).

[ApexAlpha]

Hoe koppelt de app die terug dan? Is dat niet gewoon een losse API weer waar alle zorgsystemen het uit halen?

[Nyarlathotep]

Ik denk dat dit misschien wel het meest succesvolle én goedkoopste IT overheidsproject is in de Nederlandse geschiedenis...

[CivLord]

In ieder geval voor een project dat zo in de openbaarheid staat.
De meeste ICT-projecten bij de overheid verlopen volgens verwachting, maar totaal buiten beeld van het publiek.

[isomis]

Het is niet alleen maar happy happy joy joy werken voor de overheid. Overigens boekhoudprogramma's zijn erg ingewikkeld. Dat ga je niet redden met 5 miljoen.

Ik kan je vertellen dat de maatschappelijke druk en eisen van deze opdracht zo hoog waren, dat je als bedrijf geen risico wilt lopen. Kortom, dat kost geld en ik vind 5 miljoen daarom een net bedrag.

[Reactie gewijzigd door isomis op 23 juli 2024 17:09]

[Cergorach]

5 miljoen?
De ontwikkeling van een boekhoud pakket als e-boekhouden/twinfield is nog goedkoper.

Waar haal jij vandaan dat de ontwikkeling van Twinfield minder dan €5 miljoen heeft gekost? Dat is imho een heel misplaatste aanname...

[scholtnp]

De ontwikkeling van een boekhoud pakket als e-boekhouden/twinfield is nog goedkoper.

Dat hangt natuurlijk ook van de features af, maar ter vergelijking, gnucash heeft 652 manjaar gekost volgens de schatting van deze site.

[stefanhendriks]

5 miljoen... als je van 100eur per uur uitgaat dus 50.000 manuren.

Een enorm bedrag inderdaad en heel veel uren.

Natuurlijk is de opzet geheel anders. Anders dan het bedrijfsleven heeft de overheid manieren om dit te financieren.

Als ik kijk naar de functionaliteit van de app zal het m daar niet in zitten. Ik vermoed dat het geld vooral zit in de verdere integratie met andere systemen. Vast ook de nodige overhead, gezien de hoeveelheid afstemming en schijven waarover dit gaat.

[CivLord]

Die tijd is lang niet allemaal in het programmeren gaan zitten.
De meeste kosten zullen gemaakt zijn in de overhead, administratie, documentatie, testen. onderzoeken, evalueren etc.

[PolarBear]

De ontwikkeling van een boekhoud pakket als e-boekhouden/twinfield is nog goedkoper. En dat zijn complexere dingen dan zo'n app.

Twinfield, is daar de nieuwe interface al af?

[MacD]

-2 android devs
-2 ios devs
-1 mobile lead
-2 backend devs
-2 interne frontend/dashboard devs
-2 cloud devs
-minimaal 2 QA
-2 sysadmin/infra
-2 managers/product owners
-1 lead

minimaal al 18 x 90.000 loon voor een half jaar = 80k/2, maar weer maal 2 omdat kosten werkgever (een werknemer kost al snel 2x salaris) = (160k x 16) /2 (halfjaar) = 1.620.000.

En dat is absoluut minimaal.

Maar dan komen er de advocaten, de andere beheerders, de tech, de frontend/backend kosten, apparatuur, compliance, pentesters en andere security audits, de financiele mensen, etc etc etc bovenop. En wat dacht je van overuren (want die draaien ze!)?

En mijn schatting vd eerste orde (18 man dev team) is nog klein.

5 mil. klinkt heel reeel voor een dergelijk project in een dergelijk tijdsframe met topmensen (sterker nog, je zou tegenwoordig makkelijk een ton kunnen rekenen voor een aantal van die lui, maar weer minder voor de QA, dus gemiddeld, swah).

[Reactie gewijzigd door MacD op 23 juli 2024 17:09]

[kevinvz]

Ik wou alleen maar even zeggen dat ik dit echt een hele goede zaak vind. De boel open gooien is echt het beste medicijn tegen wanpraktijken die we veel met overheids ICT aanbestedingen gezien hebben. Bovendien, als het met publiek geld betaald wordt, waarom zou de code dan niet publiek zijn. Laat dat de regel zijn ipv de uitzondering, en laat iedereen het resultaat van de aanbesteding zien. Zo kunnen er ook in een vroeg stadium fouten uitgehaald worden die het publiek belang schaden, en heeft de overheid minder lock-in met enkele commerciële partijen die het vervolgens voor het zeggen hebben en veel geld voor weinig kwaliteit kunnen vragen.

[WhatsappHack]

Not gonna happen, want de bedrijven die de aanbestedingen vaak winnen hebben daar vast geen zin in (en dat blijven vaak “vriendjes van”); het loont immers immens om er een potje van te maken... Dat gaat moeilijker als t openbaar is en men op je vingers mee kan kijken en commentaar kan geven.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 17:09]

[Moartn]

Als je het op deze manier aanpakt hoeft het ook niet aanbesteed te worden De regie ligt in dit geval bij de overheid zelf, en die huurt specialisten (vaak ZZP'ers) in om delen van het werk uit te voeren. Dat is behoorlijk anders dan zo'n klus in z'n geheel bij een grote automatiseerder neer te leggen.

Dat gezegd hebbende, ik vraag me af of dat gaat werken. De Coronamelder is natuurlijk een mooi voorbeeld, maar de meeste ICT-projecten in overheidsland zitten veel meer aan de "backend" en hebben te maken met allerlei legacy.

[CEx]

En dan hebben we het nog niet over schaalgrootte. Zonder oneerbiedig te zijn maar dit is slechts een app met een heel specifiek doel met een beperkte set aan ontwikkelaars en (waarschijnlijk) messcherpe requirements.

Overigens als je bij de leverancier van die specialisten (wat je echt niet droog houdt met alleen ZZP'ers) boven de aanbestedingsgrens komt zal je alsnog moeten aanbesteden. Voor lange periodes (meer dan een jaar) zit je daar ook vrij snel op met 1 ZZP'er.

[Reactie gewijzigd door CEx op 23 juli 2024 17:09]

[Xiz]

Misschien is dit dan een goed leermoment voor de overheid. Met een heel specifiek doel en messcherpe requirements heb je maar een beperkte set aan ontwikkelaars nodig en kan je snel een resultaat behalen.

Zeg maar het tegenovergesteld van wat ze normaliter doen :-).

[Mellow Jack]

het punt is dat je deze app niet kan vergelijken met bijv. een wet of applicatie implementeren bij de belastingdienst. Dit is een opzichzelfstaand project en dat kan je makkelijk opvangen door een project team wat bijv grotendeels zzp'er is.

Bij de belastingdienst kan 1 wet of 1 applicatie een berg van applicaties raken waarbij sommige van die applicaties net nieuw zijn en sommige 20+ jaar oud. Al die applicaties gezamenlijk vormen ons belasting systeem. Nu hebben belastingdiensten wereldwijd wel gemenedelers, zeker binnen Europa. Toch blijft onze situatie uniek en veranderd het ook continue telkens omdat mensen in den haag weer een nieuw ficaal voordeeltje of nadeeltje hebben verzonnen

[J_van_Ekris]

Dat gezegd hebbende, ik vraag me af of dat gaat werken. De Coronamelder is natuurlijk een mooi voorbeeld, maar de meeste ICT-projecten in overheidsland zitten veel meer aan de "backend" en hebben te maken met allerlei legacy.

Mijn ervaring met overheidsprojecten is dat ze vaak op de klippen lopen omdat er allerlei ongemanagde stakeholders zijn die het project voorzien van zijsturing. Ik denk dat dit project uitblonk in het formuleren van een heeeeeel helder doel, dat heel doelgericht bouwen en stakeholders op de juiste momenten erbij betrekken. Helaas zijn al die andere overheidsprojecten niet zo helder...

[TheVivaldi]

Mag dat eigenlijk wel? Ik dacht alles moest worden aanbesteed van de EU...

[Moartn]

Alles? Nee, dat ligt er toch echt aan hoe je het insteekt. Als je "het ontwerpen en bouwen van een app" in z'n geheel bij 1 partij wil neerleggen, dan valt dat zeker boven de aanbestedingsgrens. Maar dat is niet wat ze in dit geval hebben gedaan. Zoals ik al zei: de regie ligt bij mensen van het ministerie zelf. Wat ze vervolgens hebben gedaan is mensen ingehuurd die kennis en ervaring hebben op specifieke vlakken, zoals "het ontwikkelen van een iOS app", "het onwikkelen van een Android app", "het ontwikkelen van een backend", "grafisch ontwerp", "gebruiksvriendelijke teksten schrijven", etc etc. Dat zijn allemaal kleine dingetjes waar je (in dit geval) ZZP'ers voor kunt inhuren, voor de duur van een paar maanden. Dan blijft het onder de aanbestedingsgrens.

Maar zoals hierboven terecht wordt opgemerkt, bij grotere projecten gaat dit niet op. Dan heb je meer mensen nodig, voor langere tijd en dan kom je zelfs bij zo'n constructie boven de aanbestedingsgrenzen uit.

[Reactie gewijzigd door Moartn op 23 juli 2024 17:09]

[batjes]

Ook daar kan de overheid afdwingen dat de ontwikkeling op een bepaalde manier uitgevoerd moet worden. Zo'n aanbesteding is natuurlijk niet zonder eisenpakket. Al is het maar dat er een eis tussen zit dat de broncode openbaar beschikbaar moet komen op een soort rijksbroncode.nl oid.

[supersnathan94]

Dat zijn allemaal kleine dingetjes waar je (in dit geval) ZZP'ers voor kunt inhuren, voor de duur van een paar maanden. Dan blijft het onder de aanbestedingsgrens.

Probleem is dan wel tweeledig.

A) je moet onder de €50K oid blijven dus afhnakelijk van uurtarief is het ook echt maximaal een paar maanden
kennis komt en gaat dus ook met de ingehuurde mensen. Hier moet je heel goed op anticiperen om die kennis binnen te houden. Intern dus vooral veel mensen mee laten werken om kennis op te doen. Anders weet niemand straks hoe het werk en waarom.

[mddd]

Boven een bepaald bedrag wel ja. Maar een enkele developer zit wel onder dat bedrag.
In theorie zou het goed zijn. Maar ik denk niet dat de overheid voorbereid is om zoveel werk en coördinatie binnenshuis te halen.

[THA_ErAsEr]

En privacy

[CivLord]

Aanbesteding heeft de bekende minpunten. maar het is niet voor niets verplicht.

De aanpak zoals jij hem beschrijft, zal snel resulteren in een kleine pool van bekende ZZP-ers. Daar kunnen met de beste wil ter wereld één of meerdere favorieten van de opdrachtgevers tussen komen te zitten. Voor buitenstaanders is het dan erg moeilijk om overheidsopdrachten te krijgen. Ook wanneer zij daar misschien beter in zijn, omdat zij bekend zijn met nieuwere technieken, terwijl de vaste pool het bijhouden van kennis laat verslappen. En dan hebben we het nog niet over vriendjespolitiek en omkoping.

Het aanbesteden van grotere opdrachten is verre van ideaal, maar in een niet ideale wereld kunnen andere methodes vaak nog minder ideaal worden.

[Eonfge]

Klopt, hier zie je ook een duidelijk precedent voor:
nieuws: Tweede Kamer hoeft broncode van Debat Direct-app niet openbaar te maken

Dat de Corona App open source is, is meer de uitzondering die de regel bevestigd.

[Daoka]

Uiteindelijk was de eerste open source programma ook een uitzondering. Soms zijn uitzonderingen nodig om te zien dat het ook anders kan.

[Eonfge]

O, maar als je ziet om welke drogredenen de Debat Direct app niet openbaar gemaakt is, dan kan je wel op je klompen aanvoelen dat ze dat excuus vaker van stal gaan halen.

[Hatsjoe]

Als overheid zijnde ben je opdrachtgever en bepaal je hoe de aannemer van de aanbesteding de uitvoering moet doen. Als de eis daarbij is dat al het werk geschiedt binnen publieke git repositories, dan is dat zo. Kunnen ze hoog of laag springen maar als ze het niet doen plegen ze contractbreuk.

Ook zou je kunnen stellen dat door meer zaken op deze manier aan te pakken je helemaal geen aanbestedingen meer nodig hebt zoals @Moartn aangeeft.

[CEx]

Dit werkt niet, ook voor het inhuren van externen geldt een aanbestedingsplicht als deze de opdrachtwaarde overschrijdt. Met enkele ZZP'ers is dat in de boeken nog wel te voorkomen en kan je je beroepen op specifieke (technische/business) kennis. Voor 50+ man wordt dat een lastiger verhaal, vaak ook omdat er intern ook afdelingen zijn (control) die willen weten waar het geld aan uitgegeven wordt.

[CivLord]

Natuurlijk bepaal je als opdrachtgever hoe een aannemer de aanbesteding uitvoert.
Geen enkele aannemer zal problemen hebben met het openbaar maken van de code. Maar daar hangt dan wel een prijskaartje aan.
De overheid wordt eigenaar van de code. De aannemer kan geen reeds bestaande niet-openbare code gebruiken en zal dus meer tijd en energie moeten besteden aan het schrijven van compleet nieuwe code. Die nieuwe code zal meer fouten en problemen bevatten dan de reeds bestaande code die gebruikt kan worden.
De aannemer kan toekomstige klanten niet laten betalen voor het gebruik van de openbaar gemaakte code, dus kan er bij de calculatie geen rekening gehouden worden met toekomstige inkomsten van de geschreven code. Dat moet dus ook in het huidige project verwerkt worden.
Wanneer het vaak genoeg gebeurd is, zal een aannemer terug kunnen vallen op gedeeltes van code die eerder openbaar gemaakt zijn en dus ontwikkelkosten kunnen besparen. Maar voordat het zover is zal de ontwikkeling van software door de overheid flink duurder worden.

[K-aroq]

Je suggereert nu nogal wat. Ik neem aan dat je kunt onderbouwen dat het allemaal vriendjespolitiek is.

[SqyD]

Dat is precies wat er hier nu wel goed gegaan is. Aanvankelijk zaten alle "vriendjes" aan tafel tijdens de hackathon en toen hebben we met zijn allen kunnen zien dat ze gebakken lucht zaten te verkopen. Ik blijf hoopvol.

[WhatsappHack]

Ja ik dacht toen ook al: de wonderen zijn de wereld nog niet uit... Misschien dat een paar ook gedacht hebben "dit is te belangrijk om weer miljarden tegenaan te smijten zonder resultaat". *kuch*defensie*kuch*

Ik help het je mee hopen, maar ik vrees het ergste en dat men gewoon overgaat tot "de orde van de dag" bij nieuwe projecten. Maar misschien leren ze er inderdaad toch van.

[kodak]

Als het loont om er een potje van te maken en er vriendjes zijn, hoe verklaar je dan dat er bij de overheid wel vaker open source projecten bestaan?

Wat je noemt zijn de ongewenste kanten die belangrijker zouden worden gevonden. Maar het lijkt me niet dat dat zich standaard voor doet. Daarbij is nu aantoonbaar gemaakt dat een project dat open is en niet bij maar een gesloten partij ligt wel degelijk een succes in het ontwikkelen en opleveren kan zijn. Dat werkt niet zomaar in het voordeel van bedrijven of vrienden die iets anders willen voorspiegelen om er zelf beter van te worden.

[oef!]

het loont immers immens om er een potje van te maken

Er een potje van maken resulteert in heibel met ministeries, ggz's en heeft een grote impact op de maatschappij. Niemand zit in die modus en de app wordt niet ontwikkeld door een club als Atos of Cap.

[WillySis]

Dan is dit een hele goede manier om te voorkomen dat men er geen potje meer van maakt.
Volledig openbaar zal het nooit worden, maar dat is de CoronaMelder ook niet. De api van Apple en Google is bijvoorbeeld niet openbaar.
Als de grote ICT bedrijven niet inschrijven is er voldoende concurrentie van kleinere bedrijven die een bak zzp-ers open kunnen trekken of samenwerkingen aan kunnen gaan. Hier op Tweakers wordt al veel vaker geroepen dat de overheid eigenlijk alleen open-source zou moeten gebruiken.
Als de overheid deze methode doorzet wordt het veel lastiger om overal lekker een potje van te maken en is die vijf miljoen in no time terugverdiend.

[Woefdramcx]

Dat lijkt me erg kort door de bocht. Bovendien zou dat eenvoudig op te vangen zijn door in de aanbesteding te formuleren dat de broncode openbaar moet, zoals bij de huidige app. En als potentiële ontwikkelaars daar geen zin in hebben omdat ze de boel dan niet kunnen verstieren, filtert dat precies die rotte appels eruit die je niet wilt hebben. Lijkt me een win-winsituatie.

[LittleKiller]

Je kunt zeggen wat je wilt. Dit is een ICT project wat niet gefaald is

[wifikabelhuren]

Dit ICT project is wel in het begin wel enorm gefaald door eerst allemaal bedrijven een pitch te laten doen. Dat hadden ze beter niet kunnen doen want hier is ontzettend veel kritiek ontstaan.

[Mic2000]

Maar van die kritiek hebben ze toch juist geleerd? Wat als ze nooit van de kritiek hadden gehoord...

[jip_86]

Het is niet gefaald omdat ze tijdig hebben ingezien dat dit niet de manier was. Het had zeker wel gefaald als ze zich aan een van die partijen hadden gecommitteerd.

[Cerberus_tm]

Maar, als die zgn. pitches openbaar zijn, en allerlei deskundigen er kritiek op hebben, dan zal de overheid zich minder snel aan zoiets committeren: als er al meteen vanaf het begin bekend is dat iets een slecht idee is, doe je dat niet zo snel. Daarom denk ik dat maximale transparantie heel goed kan werken.

[Bor]

Volgens mij bepaald niet de weg ergens heen maar het eindresultaat of iets gefaald is of niet. Kortom; is het binnen budget, scope, kwaliteitseisen (etc) gebleven.

[K-aroq]

Wat is daar mis mee? Er is toch niks mis mee om eerst een hoop partijen hun mening te laten geven voordat je verder gaat. Je weet dan in ieder geval hoe het niet moet. Beter aan het begin een paar van dat soort sessie dan vanaf het begin het verkeerde pad in slaan.

[CivLord]

Ze hebben het juist eel slim gedaan.
Wanneer ze meteen met een partij aan het bouwen waren geslagen, dan was er weer een hoop kritiek geweest dat ze niet eerst anderen de kans gegeven hadden om iets voor te stellen.
Dat hebben ze nu in één of twee weken afgetikt op een manier waarop het bereikte eindresultaat alleen maar mee kan vallen.

[kodak]

Een succes of falen hangt niet alleen af van het maken en opleveren maar ook of het geschikt blijkt voor het doel. Dat moet het nog bewijzen. Het is zeker een succes te noemen hoe hier in redelijke openheid is samengewerkt en iets is opgeleverd wat veel waarde kan hebben.

[LittleKiller]

Nou ja. Ik ben het niet met je eens. Linksom of rechtsom, het ICT project is gelukt. Of de app effect heeft is een heel ander project.

[kodak]

Je weet dat het een achterhaald concept is om een product op te leveren en dan net te doen alsof het dan klaar is? Het bestaansrecht van het project van deze app is namelijk dat het doel bereikt kan worden, niet alleen om een app op te leveren. Ontwikkeling is slechts een deel van het hele project. Als deelproject kan je het natuurlijk prima een succes noemen.

[CivLord]

Dat is toch de norm voor softwarebouwers? Je levert iets af dat voldoet aan de opdracht, maar dat zeer tekort schiet in de praktijk, zodat het echte verdienen pas gebeurt bij het aanpassen.

[Freekers]

Het grote voordeel van de ontwikkeling van de corona-app/CoronaMelder-app is dat deze greenfield is opgezet. Je hebt (nagenoeg) geen last van legacy systemen, waardoor ontwikkeling een stuk vlotter kan verlopen. Dat is wat vaak de das omdoet voor de gigaprojecten binnen instanties als een Belastingdienst of RDW.

[i-chat]

wat dus suggereert dat het misschien tijd word om op zo'n zelfde manier de systemen bij de belastingdienst of de RDW te he implementeren als zo'n traject straks kan worden ingezet hebben we over 10 jaar een heel nieuw systeem wat dan 'wel schaalbaar en veranderbaar is' dat wel rekening houdt met de toekomst en dat wel geschikt voor de 21ste eeuw.

ik kan alleen maar raden hoe bijvoorbeeld het stopzetten van KEI (digitalisering in de rechtspraak) voorkomen had kunnen worden als er op deze manier wat ontwikkeld.

[K-aroq]

Precies. Dat laatste is iets wat alle betweters altijd vreselijk onderschatten. Als we nu ons land opnieuw zouden ontwerpen dan wordt alle regelgeving, en dus alle ICT, een stuk eenvoudiger. Maar we kunnen nu eenmaal niet zomaar allerlei bestaande regels veranderen. Er bestaat immers zoiets als verworden rechten die je niet zomaar kunt schenden.

[michielRB]

Als ze het principe van "publiek geld, publieke code" onvoorwaardelijk gaan omarmen dan wordt het wellicht nog wat. En dit zou dan ook voor ingekochte diensten moeten gelden zodat de Cap Gemini's, IBM's, KPMG's en Deloitte's alle voor de overheid geschreven code ook als opensource beschikbaar stellen.

[CivLord]

En welk probleem lost dat op?

Maakt dat dat alle legacy problemen op magische wijze in rook op gaan? Nee, want de bestaande systemen blijven bestaan zolang ze niet vervangen zijn.

Maakt dat de ontwikkeling van software goedkoper? Nee. Softwareleveranciers kunnen niet meer terugvallen op bestaande, propriëtaire code. Ze moeten dus vanaf scratch nieuwe overal nieuwe code voor schrijven die eigendom wordt van de overheid. Lijkt leuk (is het misschien ook wel), maar ook verschrikkelijk duur.

Maakt het de software veiliger? Nee. Je geeft iedereen de kans om de code te bekijken en fouten te vinden. Leuk wanneer die geconstateerde fouten meteen gemeld worden, maar minder leuk wanneer die fouten gebruikt worden om het systeem te hacken. Het is een feit dat organisaties die misbruik willen maken van fouten in (overheids)software veel meer middelen en recourses hebben om die fouten actief op te sporen, dan individuen en organisaties die die fouten willen melden om ze te laten patchen.

Open source levert heel veel mooie, gevatte one-liners op, maar het is niet op magische wijze beter. In een ideale wereld, is het zeker een ideaal model. Helaas is de wereld niet ideaal dus blijft open source alleen voor een beperkt aanal toepassingen ideaal.

[michielRB]

Maakt dat dat alle legacy problemen op magische wijze in rook op gaan? Nee, want de bestaande systemen blijven bestaan zolang ze niet vervangen zijn.

Nee dat lost het niet automagisch op. Dat kost heel veel ellebogenstoom en geld. Maar dan ben je uiteindelijk wel af van de legacy zooi die al jaren als een molensteen om de nek van de overheid ict hangt.
Eenmaal begonnen met een echt modulaire opbouw, die open is, zodat iedere codeklopper er op verder kan, maakt dat je van de wurgcontracten afkomt van de grootgrutters in ICT land.

Maakt dat de ontwikkeling van software goedkoper? Nee. Softwareleveranciers kunnen niet meer terugvallen op bestaande, propriëtaire code. Ze moeten dus vanaf scratch nieuwe overal nieuwe code voor schrijven die eigendom wordt van de overheid. Lijkt leuk (is het misschien ook wel), maar ook verschrikkelijk duur.

Oneens. Juist doordat er op propriëtaire code wordt teruggevallen ontstaan situaties dat je als overheid in vendor lock-ins terecht komt.

Maakt het de software veiliger? Nee. Je geeft iedereen de kans om de code te bekijken en fouten te vinden. Leuk wanneer die geconstateerde fouten meteen gemeld worden, maar minder leuk wanneer die fouten gebruikt worden om het systeem te hacken. Het is een feit dat organisaties die misbruik willen maken van fouten in (overheids)software veel meer middelen en recourses hebben om die fouten actief op te sporen, dan individuen en organisaties die die fouten willen melden om ze te laten patchen.

Drogreden. Security door obscurity is geen veiligheid. Doordat er veel meer ogen zijn die meekijken worden de fouten eerder opgemerkt en sneller gepatched.

Open source levert heel veel mooie, gevatte one-liners op, maar het is niet op magische wijze beter. In een ideale wereld, is het zeker een ideaal model. Helaas is de wereld niet ideaal dus blijft open source alleen voor een beperkt aanal toepassingen ideaal.

Daar zet je potverdikkeme toch een paar mooie oneliners tegenover... /s

[Malarky]

Toch wel, 5 miljoen is redelijk goedkoop voor een werkende app met zo'n grote adoptie. Alleen.... we kopen er niets voor: er is ondertussen al in binnen- en buitenland bewezen door zowel Nederlands als Internationaal onderzoek dat mensen bitter weinig doen met de informatie dat ze waarschijnlijk of zelfs geheel zeker besmet zijn.

Daarom is ook niet gek dat alles behalve geblekenis dat landen met een fancy app het beter doen op corona gebied dan landen zonder app.

Mooi app, veel gebruikers, maar dan heb je ook niks behaald van de originele echte doelstellingen.

Het is al ironisch genoeg dat in de week van de 2e lockdown, de succeseen van de corona app overal besproken worden (alsin, goedkoop en veel gebruikers) en iedereen lijkt vergeten te zijn waarom we ook alweer zo een app wilden: inderdaad, strengere maatregelen voorkomen.

Helemaal niemand, maar dan ook de grootste optimist niet, heeft nog de opinie dat we straks dankzij die app ons leven een tikje beter kunnen oppakken.

[Reactie gewijzigd door Malarky op 23 juli 2024 17:09]

[Luchtbakker]

Je kunt zeggen wat je wilt. Dit is een ICT project wat niet gefaald is

Roep het nog niet te hard... We zijn er nog niet

[himlims_]

opensource betekend niet direct dat de datasets ook toegankelijk zijn; https://github.com/minvws

dat gezegd hebben; 5 miljoen is toch serieus geld voor een appie

[robinvw1]

dat gezegd hebben; 5 miljoen is toch serieus geld voor een appie

Die 5 miljoen euro voor dat 'appie' bevat onder andere:
- testen van de toegankelijkheid voor een hele grote doelgroep zoals blinden
- niet alleen 'simpelweg' een design, maar heel veel gedragsonderzoeken
- de portal waar de GGD op in kan loggen en het testen met de GGD's
- penetratietesten
- de back-end (coronamelder-api.nl en https://productie.coronam...l/v1/exposurekeyset/:uuid waar de keys worden opgehaald)
- poging tot 'reproducible builds' door middel van de Landsadvocaat de builds op GitHub met de App Store verifiëren

Eigenlijk alles wat je op https://github.com/minvws ziet, was er nog niet. Er is echt heel veel werk verzet.

[LittleKiller]

Denk dat de tijd daarin vooral een ding is. Als er niet zoveel druk op had gestaan dan was het waarschijnlijk wel goedkoper uitgevallen

[CivLord]

Ik denk dat het meeste daarvan in administratieve zaken zit. Documentatie en test/ onderzoeken tijdens het hele proces.

[wifikabelhuren]

als er data op straat komt te liggen dan zijn dit hashes van hashes? je kunt er niks mee.

[LittleKiller]

Hoe en welke data kan er op straat komen te liggen dan?

[FvdM]

Ik kan erg weinig vinden over de code implementatie van de API in het OS. Wel al die mooie marketingverhaaltjes over de werking en de allerhoogste privacy in het universum. Je hebt echter geen garantie dat Apple en Google verder niets met de data doen. Als ik een evil Google was had ik wel brood gezien in al die contact traces, zeker icm de geolocatie van diezelfde smartphones. Die gedachte is vast wel in hun op gekomen, maar ze hebben beloofd de privacy te waarborgen dus daar houden ze zich gewoon aan... yeah right.

[K-aroq]

Google is extreem transparant over wat ze met de data doen die ze hebben. Daar is eigenlijk niks evils aan. Ik denk dat de meeste bedrijven waar wij werken daar best nog wel wat van kunnen leren. Je kunt het hoogstens niet eens zijn met hoe zij hun geld verdienen. En ook dat maakt het nog niet evil.

[FvdM]

Extreem transparant is als je in de totale administratie, deals en broncode van het bedrijf kan. Heb jij die toegang?

[LittleKiller]

Oke. Dan stel ik de vraag nog een keer met een toevoeging.

Hoe en welke data kan er op straat komen te liggen, die google/apple niet al in het bezit heeft, dan?

[i-chat]

dan stel ik de vraag nóg een keer en nú góéd ...

welke data verzameld die corona app nou priecies op een manier dat er commerciëël gewin in zit.

met een goede packet-sniffer weet je al dat locatiegebonden dat niet via de corona api naar google gaat daar gebruiken ze apps als google.maps voor.

maar de feitelijke lijsjes met nummers die jij bent tegengekomen gaan niet via de servers van google en de lijstjes met welke nummers coresponderen met corona-besmettingen van óók niet via de servers van google al dat 'downloaden en kijken of er een match is gebeurt lokaal en buiten het zicht van de evil 5 (google apple microsoft facebook en de overheid)

[FvdM]

Hoe en welke data kan er op straat komen te liggen, die google/apple niet al in het bezit heeft, dan?

Maakt dat uit? Waarom moeten we toegeven aan de onstilbare honger van Google e.d. om zoveel mogelijk data te combineren? Ik zie daar gevaar in. IBM was ook van de vriendelijke Amerikanen, maar hun systemen hadden toch vooraf aan en tijdens WO2 een belangrijke rol bij de vijand.

[CivLord]

Ik zou eigenlijk haast willen dat er ergens een luikje in de API zit, waardoor data bij Apple en Google terecht komt. Zodra dat naar buiten komt, geeft dat genoeg ammunitie voor zo'n beetje de helft van de regeringen ter wereld om op Apple en Google in te hakken.
Die bedrijven kunnen heel ver gaan met het wekken van een bepaalde indruk, dat ze iets niet doen, terwijl het ergens in de kleine lettertjes toch niet uitgesloten wordt. Ze kunnen heel ver gaan met iets zeggen dat met en paar vreemd juridische kronkels net iets anders betekent dan iedereen denkt dat het betekent. Maar glashard tegen regeringen liegen, die daarmee hun eigen bevolking voorliegen is niet slim. Zodra dat uitkomt, zulle die regeringen keihard toeslaan, om duidelijk te maken dat zij óók slachtoffer zijn.
Reken maar dat die PAI's heel grondig uitgepluisd worden door de EU. Voor hen is meer ammunitie om de grote tech-bedrijven aan te pakken meer dan welkom.

Dat zullen Apple en Google ook beseffen. Daarom denk ik dat zij alles op alles gezet hebben om dit echt zo veilig en privacyvriendelijk mogelijk te maken.

[A64_Luuk]

Voor zover ik kan inschatten is dat dus nergens op gebaseerd, los van wat eerste geruchten en dingetjes die al lang aangepakt zijn. De uiteindelijke versie is naar ik kan zien goed doordacht, met privacy in het achterhoofd.

Ik gebruik hem in ieder geval gewoon.

[Reactie gewijzigd door A64_Luuk op 23 juli 2024 17:09]

[Djerro123]

Leuk dat dit geëvalueerd wordt! Ondanks alle kritische geluiden was ik positief verrast door de aanpak die uiteindelijk is gekozen (na de tranentrekkende presentaties van de grote melkboeren haha, dat was wel heel sneu).
We moeten overigens niet vergeten dat deze app echt onder stoom en kokend water is gemaakt. Lange dagen voor de developers en designers, etc. Er is echt snoei hard gewerkt met een groot gevoel voor maatschappelijke relevantie en belang. Hiervoor moet de volgende keer wel verdisconteerd worden denk ik, maar de opzet op zich is wel heel transparant

[Anoniem: 1463186]

Ik denk ook niet dat ze perse denken aan de werkdagen

De opzet van een ICT project kan natuurlijk prima hetzelfde blijven, alleen dat de ontwikkeling wat langer duurt omdat er gewoon normale dagen gemaakt worden. De semi-publieke structuur kun je natuurlijk nog wel aanhouden, en dat is volgens mij wat er vooral zo goed bevallen is in bij deze app.

[CivLord]

Maar met meer tijd, is er ook meer tijd om zaken eerst te bespreken, i.p.v. dat knopen meteen worden doorgehakt.
Dat betekent meer besprekingen met programmeurs en managers. Waarbij managers 'iets' zeggen omdat ze anders helemaal voor spek en bonen bij zo'n bespreking zitten, en programmeurs die daar vervolgens 'iets' mee moeten doen, omdat de manager het gezegd heeft.
Dan zit je al weer snel in de reguliere gang van zaken.

[Anoniem: 1463186]

Tja maar dat houd je altijd. Altijd onder moordende deadlines werken moet je als mensheid niet willen, dus het zal altijd voorkomen dat je tijd hebt om zaken te bespreken. Daarnaast doe je alsof bespreken altijd slecht is, zeker met gecompliceerde projecten is het juist goed om dingen te bespreken, omdat één persoon vaak een vrij nauwe kijk op de werkelijkheid heeft.

[CivLord]

Wat je zegt klopt helemaal. Zaken bespreken is niet slecht, het is nodig.
Maar je ziet dat hoe meer tijd er is om zaken te bespreken, hoe meer er besproken wordt en hoe meer ruis die besprekingen opleveren. En hoe meer zaken breed besproken worden, hoe lastiger het wordt om zaken klein te bespreken met alleen de direct betrokkenen.

[Iced Maggot]

Waarom niet op Europees niveau?
Nederland schrijft zijn app, België schrijft zijn app, ...

[croc]

België heeft blijkbaar zijn app op de duitse gebaseerd, en kwam er blijkbaar vanaf met een kostprijs tussen de 750.000 en 1.000.000 euro.

[air2]

Omdat dat dat veelste traag werkt, misschien hadden we dan wel een slechte europese app. Daar wordt je ook niet vrolijk van. De ggd's in ieder land werken anders, het aanvragen van testen in ieder land werkt anders. De taal is in bijna ieder land anders.

[batjes]

Taal is het probleem niet. Dat alles anders werkt is een slap excuus. Dit was in het verleden ook in Nederland, elke gemeente had zijn eigen eisen en moest en zal maatwerk hebben voor al hun uitzonderingen. Provincies, politiekorpsen, post, vervoersbedrijven, kabel-tv/internet boeren...

Uiteindelijk hebben ze in grote lijnen gewoon dezelfde eisen en is vaak alleen de uitvoering of werkwijze "uniek". Zo heeft elke partij dan vaak wel zijn eigen uitzonderingen, maar uiteindelijk is dat totale lijstje uitzonderingen vrij klein en heeft elke partij een handjevol uitzonderingen uit dat zelfde lijstje.

Mooi moment straks om op dit punt als EU eens te kijken of we dit soort zaken een beetje gelijk kunnen trekken. Elke partij denkt uniek te zijn, maar je zult zien dat dit wel mee valt.

[Malarky]

Leuke droom natuurlijk die Europese, maar voor je fantasie op hol slaat kunnen we ook kijken hoe momenteel minder complexe zaken in Europa al jaren duren:

- Politieke, politieke en politieke belangen. Elk land wil de developpers regelelen. Zo kinderachtig zijn ze niet toch in noodsituaties? Ohnee, Macron gemist met zijn preek over dat hij woedend is dat we in corona tijd niet meer elke maand de hele toko verhuizen tussen Brussel en Straatsburg?
- De back-end minimale vereisten van alle 27 lidstaten moeten in kaart worden gebracht. Immers je kunt niet echt aan front-end beginnen voor we iets op dat gebied hebben gedaan.
- Privacy organisaties uit 27 landen willen natuurlijk (en terecht) wel hun zegje mogen doen.

Voor we meer zaken in Europa gaan doen, kunnen we ook wat we doen is een keer goed gaan oppakken. Miljoenen aan subsidies, met name naar de beruchte 4 uit Oost-Europa, worden openlijk en schaamteloos verkwanseld en het lukt is onmogelijk daar iets aan te doen. Ook nu, as we speak, tijdens de Europese onderhandelingen zit dit onderwerp muurvast.

Laten we alsjeblieft eens gaan repareren wat we al jaren doen in Europa maar overduidelijk niet goed gaat, voor we nog meer proefballontjes gaan uitproberen van idealisten met grootste vergezichten maar weinig ervaring met de praktijk van alle dag.

Terwijl het probleem van Europa heel simpel is: een aantal lidstaten wat aantoonbaar ter kwader trouw is. De Visegrad landen spreken en hebben al zovaak publiekelijk bekend gemaakt elkaar te beschermen met veto's in het geval van welke wetschendingen danwel mensenrechten schendingen geconstateerd door Brussel ook. Met zulke vrienden in je club heb je inderdaad geen Chinese of Russische vijanden meer nodig.

[Reactie gewijzigd door Malarky op 23 juli 2024 17:09]

[CivLord]

Maar dan heb je dus een partij nodig die alle EU landen een bepaalde werkwijze op kan dringen, zoals in Nederland de regering de gemeentes iets op kan leggen. Dus een soort federale overheid die boven de lidstaten staat. Dat zie ik nog niet zo snel gebeuren.

[Herko_ter_Horst]

Als er iets vertragend werkt, is het wel proberen dit op Europees niveau te regelen. De reden dat "onze" app er nu pas is, is dat er eerst een wet moest komen dat het mocht. Als je dat op Europees niveau wilt doen, moet er eerst een richtlijn komen (waar ze het eerst in Brussel over eens moeten worden en vervolgens elk land nog al dan niet mee akkoord moet gaan), vervolgens moet het voor elk land apart in een wet worden omgezet en dan moet je nog gaan kijken wie die app dan mag/moet maken, onderhouden en de koppelingen met alle Europese "GGD's" kan gaan regelen.

Het goede nieuws is, dat doordat Apple en Google het over de onderliggende APIs eens zijn en de meeste, zo niet alle, landelijke/regionale apps diezelfde APIs gebruiken, de apps qua basisfunctionaliteit automagisch zouden moeten samenwerken. D.w.z. jij dus ook een notificatie kan krijgen als jij in contact bent geweest met iemand die positief getest is en de Belgische app in gebruik heeft.

[K-aroq]

Dan moet je eerst alle landelijke requirements vertalen, combiner, onderhandelen in geval van conflicterende requirements. Vervolgens heb je nog te maken met lokale wetgeving.
Plus dat de EU hier niet over gaat.

[Bas Boss]

Dat is inderdaad ook wat ik dacht.

Maar het probleem is gewoon dat de zorg niet europees georganiseerd is. Verbeterpuntje zou ik zeggen.
Ook die wetenschappelijke onderbouwingen moeten toch gewoon europees zijn. Dat ieder land vervolgens zijn eigen beleid ontwikkeld is prima.

[Anoniem: 1463186]

Omdat dit gaat over apps in de toekomst, en niet alle landen hebben dezelfde app nodig. Wij hebben DigiD, dat hebben ze in andere landen weer niet. Wij hebben de Berichtenbox, dat hebben ze in andere landen weer niet.
Voor bepaalde zaken is EU samenwerking goed, maar ik denk dat het gezond is om als land onze eigen methoden ook te ontwikkelen en niet alleen maar mee te gaan met de EU.

[FrostyPeet]

Er wordt veel geld verdiend door het uitmelken van de overheid blijkt vaak uit kritische journalisten artikels met betrekking tot ICT projecten. Transparantie lijkt me dan maar lastig.

[K-aroq]

Dit is tegenwoordig hartstikke transparant hoor. Er is geleerd van vorige ICT projecten maar blijkbaar blijft de standaar mantra van overheid en ict is kut nog heel veel jaren hangen bij veel mensen. En er wordt vaak vergeten dat overheids ICT projecten extreem ingewikkeld zijn door de vele stakeholders en wetten. Als je een bedrijf hebt kan je altijd nog kiezen voor standaardsoftware en daar je bedrijfsprocessen op aanpassen. Niet altijd ideaal, maar als de software daardoor flink goedkoper wordt is het een optie. Dan kan bij de overheid niet.

[CivLord]

En er zijn extreem veel ICT-projecten bij de overheid. Wanneer daar maar 1% van zou mislukken of flink uitlopen, dan hebben de kranten geen ruimte meer om ander nieuws af te drukken.
Het meeste voldoet gewoon geruisloos aan de gestelde eisen en werkt met niet meer of minder problemen dat software bij het bedrijfsleven. Maar omdat de overheid veel transparanter over ICT is dan de meeste bedrijven (voor diegenen die de weg weten en het kunnen lezen) valt elke misser meteen op en wordt die breed in de media uitgemeten.
Wanneer een groot ICT project bij bv. AHOLD mislukt, dan kan dat ergens in in de boeken worden weggemoffeld.

[nieuwemens]

Lijkt me goed plan. Ben geen corona app gebruiker. Maar petje af. Het is toch enigzins een wonder dat ze dit in verhouding met andere bedrochten van overheids projecten snel af hebben.

[com2,1ghz]

Ik hoop dat ze het hebben over het proces ipv code base.

[brinkie2004]

Dit gaat volgens mij over het proces, maar was/is er veel aan te merken op de code base dan? Doen ze niet aan code reviews?

[wifikabelhuren]

verklaar nader

[_Pussycat_]

Big Brothel klinkt anders zo verschrikkelijk nog niet...

Was die met opzet of per ongeluk?