Krijg je een woo verzoek dat volledig zwart is. Vermoed dat het een redelijk kansloze actie is. Zeker als de inhoud op papier zal worden aangeleverd. Daarnaast zal het vast lang duren voordat het document überhaupt gepubliceerd wordt.

Volgens mij zijn er geen regels wanneer het document aangeleverd moet worden na de initiële aanvraag? Maar heel eerlijk waarom zal je dit doen? Wat is de meerwaarde ervan? De aanvragen zal vast wel security.nl lezen dus hopelijk kan daar iets meer achtergrond gegeven worden?

Over het algemeen prefereren overheidsorganen publicatie op hun website, is goedkoper dan dode boom verschepen.

Informeer je:

Ik snap ook niet wat het belang van een "burger" is om inzicht in de broncode te hebben. De belastingwetgeving voor de BTW is gewoon openbaar. Als je denkt dat de code soms niet goed rekent, kun je zelf ook je btw narekenen.

Verder heeft een burger nooit te maken met BTW aangiftes. Het zijn bedrijven die te maken krijgen met deze software. Maar ook die kunnen de BTW gewoon narekenen. De enige reden die ik kan bedenken waarom iemand inzicht in de code wil hebben is het plegen van fraude.

Zoals de tekst ook al aangeeft, bepaalt de code ook de criteria waarop de belastingdienst besluit om tot een fysieke controle van de aangifte over te gaan. Als je die criteria kent, weet je precies hoe je kunt frauderen zonder dat je controles krijgt.

Naar wat de agenda is van die burger kunnen we alleen maar raden. Misschien wil hij/zij dat de belastingsdienst ns vaart maakt met het up-to-date-brengen van het BTW-systeem bij de belastingdienst. Met COBOL-code uit de jaren 90 kunnen ze natuurlijk niet naar buiten komen.
McKinsey heeft er een ontluisterend verhaal over geschreven.

https://www.consultancy.nl/nieuws/53562/mckinsey-it-systeem-belastingdienst-voor-innen-btw-piept-en-kraakt

Zoiets dacht ik dus ook. Het kan een persoonlijke interesse zijn, maar dan ga je je op een hellend vlak begeven. Wat is het belang om broncode in te zien? Als je denkt dat er fouten in de berekening zitten, lever je een tegenberekening aan en ga je dat traject in. Je gaat geen tienduizenden regels doorspitten, waarvan een deel sowieso niet zal worden aangeleverd, waardoor je nog niet weet hoe de software werkt. Wat is daar dan het doel van?

Dit lijkt meer op "wat is het aantal steentjes in straat XYZ?", om dan een claim in te dienen als niet tijdig genoeg wordt gereageerd op de aanvraag. Op deze manier houden we de overheid wel lekker bezig.

Ik wel wan t de overheid moet open source om heel veel redenen.

Er zijn meerdere argumenten te geven voor de openbaarmaking van maatwerk broncode bij de Belastingdienst.
- De democratische controle van ZBO's laat te wensen over. daar wordt politiek soms gebruik van gemaakt. B.v. door te zeggen dat een BTW wijziging niet doorgevoerd kan worden. In openbare code is dat toetsbaar.
- de Belastingdienst blijkt jarenlang discriminerende methodes gehanteerd te hebben bij fraudeopsporing. Openheid in de broncode van de betrokken database had dat jaren eerder aantoonbaar gemaakt.
- We dienen ons een beeld te kunnen vormen van de kwaliteit van de door overheden gebruikte programmatuur. Enerzijds kan dit een rol spelen in beroepsprocedures, anderzijds zal zichtbaarheid leiden tot een hogere kwaliteit door meer aandacht van medewerkers en belangstellenden.
- Openbare code kan aan informaticaopleidingen gebruikt worden om een realistisch beeld van de stand van de techniek in Nederland te geven aan aanstaande ontwikkelaars.

Nou zeg, zoiets verwacht je eigenlijk alleen maar in belastingparadijzen waar criminelen schimmige dealtjes hebben met corrupte ambtenaren.
Zoiets kan natuuuurlijk noooit in het keurige Nederland....ooh wacht

Organisaties zoals Oxfam en de EU hebben Nederland om bestempeld als een van de ‘ergste belastingparadijzen’

Tax Justice Network zet Nederland op nummer 4 van de ergste belastingparadijzen ter wereld.
Uiteraard geldt dat alleen voor het groot-kapitaal. De Nederlandse burger betaald krankzinnig hoge belastingen.

Die broncode kun je naar fluiten, die komt nooit.

Alsof er vandaag de dag nog mensen bekend zijn met z/OS en FORTRAN.

Meteen het eerste artikel in de Wet open overheid begint met een heel ander perspectief dan dat van jullie (nadruk door mij toegevoegd):
Jullie redeneren volledig vanuit een persoonlijk belang dat iemand erbij kan hebben vanwege de eigen aangifte, maar dit gaat niet over individuele belangen maar over het algemeen belang: het functioneren van de overheid moet controleerbaar zijn voor burgers en voor de samenleving.

Dank voor die link. Een veertig jaar oud systeem stamt overigens niet uit de jaren '90 maar uit de jaren '80; 40 jaar voor dat artikel werd geschreven is 1983. Dat is het jaar dat IBM met de eerste release van DB2 kwam; als ze toen al een RDBMS gebruikten hebben ze destijds een hypermoderne start gemaakt ;-).

Bij een overcomplex systeem waar in de loop van de jaren 35 voorzieningen aan zijn toegevoegd, met nog maar een handjevol mensen dat overziet hoe het eigenlijk werkt en voor bepaalde functies die het vervult redenen om die niet te openbaren snap ik het probleem dat men heeft: het is echt een teringklus om dit uit te splitsen in wat wel en niet openbaar gemaakt kan worden en van de mensen die het zouden kunnen hebben ze er al veel te weinig voor het normale werk.

Toen ik in 1985 als programmeur in een mainframe-omgeving begon (niet bij de Belastingdienst) liepen er in die wereld nog de nodige ontwikkelaars rond die oorspronkelijk hadden leren programmeren in assembler en die programmeren benaderden als zelf alles moeten optimaliseren (in plaats van dat aan de compiler over te laten) op een systeem waar je zuinig moest zijn met alle resources. Hoe knap ze ook waren, programmeurs van die generatie zagen typisch maar één reden om code in een subroutine te plaatsen: als die vanuit meer dan één plek in de programmalogica nodig was, anders zagen ze het nut er niet van in en maakten ze bezwaar tegen de overhead die een extra call en return opleverden — dat soort herinneringen komt nu althans bij me opborrelen. Zelf had ik al een stuk beter gestructureerd leren programmeren, maar nog steeds volgens ideeën die ik nu nogal primitief vind: je plaatste dingen voornamelijk bij elkaar in een subroutine als ze op hetzelfde moment in de verwerking uitgevoerd moesten worden, en niet omdat ze functioneel een geheel vormden.

Het zit er dik in dat code die uit die tijd stamt naar de huidige maatstaven nogal bedenkelijk en onoverzichtelijk in elkaar zit. Als er dan ook nog vele jaren aan onderhoud overheen zijn gegaan, er dingen in zijn geperst die niet goed in het oorspronkelijke ontwerp passen, dan kan je er welhaast gif op innemen dat het een trieste bedoening is die nog maar heel moeilijk te overzien en te ontwarren is, en dat past bij dat beeld dat McKinsey schetst.

Als dat inderdaad de situatie is zou het de staatssecretaris goed staan om dat als verklaring te geven in plaats van de mededeling te ontwijken dat openbaren domweg niet lukt omdat het een zooitje is dat ze zelf niet aankunnen.

Ik vind het overigens vooral triest dat men het zo ver heeft laten komen. De meest productieve groep ontwikkelaars op een mainframe-site die ik heb meegemaakt werkte ergens waar men als uitgangspunt had dat een applicatie een bruikbare levensduur van 10-15 jaar had (op een mainframe is een applicatie een collectie aan afzonderlijke programma's en jobs met een database eronder). Door al het onderhoud ontstaan er onvermijdelijk puistjes en knobbeltjes die geleidelijk aan het geheel minder overzichtelijk maken, en veranderende marktomstandigheden en wetten (daar heeft de Belastingdienst zeker mee te maken) doen het hele ontwerp waar de applicatie op gebaseerd is verouderen en steeds slechter aansluiten bij de behoeftes. Misschien zou je het met de hedendaagse refactor-tools anders aanpakken, hoewel ik me kan voorstellen dat ook dat zijn grenzen heeft, maar toen en op die plek was de conclusie dat er domweg na die 10-15 jaar een vervangende applicatie moest worden gebouwd. Dat was altijd maar een fractie van het totaal aan applicaties, desondanks wel een fors project, maar niet zo fors dat de organisatie zich eraan vertilde. Het maakte de productiviteit bij onderhoud tussendoor hoger, omdat je qua onderhoudbaarheid niet voor de eeuwigheid hoefde proberen te bouwen en vooral omdat de software nooit zo verouderd was dat elke onderhoudshandeling een worsteling werd. Ik heb de indruk dat die vernieuwbouwprojecten daardoor meer productiviteitswinst opleverden in de onderhoudsfase dan ze zelf kostten. En natuurlijk kreeg je domweg nooit de situatie dat je de worsteling met een 40 jaar oud systeem amper meer kon bolwerken, in de werkwijze van die organisatie waar ik toen werkte was dat systeem in die periode 2 tot 4 keer helemaal herbouwd geweest, met de kennis van het voorgaande systeem nog goed op peil bij elke herbouw, en was het nu geen problematische oude meuk geweest maar goed onderhoudbare code in een taal/platform waar je ontwikkelaars voor kan vinden.

McKinsey adviseert de Belastingdienst om een vervangend systeem niet zelf te bouwen maar in te kopen, lees ik in dat artikel. Ik hoop dat ze, ook als ze het uitbesteden, zo verstandig zijn om te zorgen dat de overheid het auteursrecht op de broncode krijgt, dat er bij de bouw van meet af aan een duidelijke splitsing wordt gemaakt tussen code die probleemloos openbaar kan worden gemaakt en code die vertrouwelijk moet blijven, bijvoorbeeld omdat eruit blijkt hoe de Belastingdienst controles op fraude uitvoert. Breng dat onder in aparte git-repository's (of welk versiebeheersysteem er ook wordt gebruikt), hanteer voor het deel dat geopenbaard mag worden een open source-licentie en openbaar het van begin af aan, zodat een Woo-verzoek met een verwijzing naar een openbare repository beantwoord kan worden.

Die zijn er, en je kan het leren. Het lijkt erop dat je dan een baangarantiw hebt.. ;-)

@anoniem 13:04,
In 1985 waren de optimizers van compilers over t algemeen niet heel goed. En wat ze deden was minimaal.

Cobol is ook een taal die niet bepaald uitnodig voor optimale machine code. Al is t niveau nauwelijks hoger dan assembly.

Ik weet niet of inkoop de juiste oplossing is. Mogelijk heeft McKinsey "toevallig" iets op de plank liggen.
Een one-off inkopen, en elk jaar opnieuw laten bouwen is ook het paard achter de wagen spannen. En ja dat was ingekocht bouwen.
Uitdaging de 2 maal per jaar nieuwbouw kon maximaal 3 maanden voor opleveren gestart worden ivm oplevering van specs, die meestal als delta op het bestaande werden aangeleverd.

De software zal vooral de Nederlandse wetgeving moeten implementeren en volgen.
Mogelijk is een andere benadering nodig waarbij er meer scripting op wetgeving niveau mogelijk is, op een framework dat fiscale basisregels implementeerd.

De staat gebruikt Palantir in hun systemen om allerlei data aan elkaar te knopen.
Zie het toeslagenschandaal.

En waarom zou het niet in het algemeen belang zijn dat één ieder het "controle mechanisme" zou mogen bekijken?


Wie heeft dit systeem zonder medeweten aangeschaft en ingevoerd?
Dick Schoof

Voor ontduiken van belasting kun je meer krijgen
dan voor het ontduiken van antwoorden door de staatssecretaris.
We spellen Belastingdienst niet voor niets met een hoofdletter, toch?

Voor de eerstgenoemde overtreding wel tot twee jaar gevangenisstraf, naar recentelijk verluidt.
Houdt het vooral onduidelijk.