Sinds 1 januari jl. zijn ondernemers die hun aangiftes via software doen, verplicht gesteld om xbrl-berichten aan te leveren via de Digipoort van de Belastingdienst. Xbrl, of tegenwoordig beter gezegd sbr, is een open standaard en ook de Digipoort zelf is gebaseerd op open standaarden. Het wachten was dus op de eerste open source-koppeling met de Digipoort. Die kwam maar niet.
Ieder voor zich gingen zo’n twintigtal softwareleveranciers aan de slag om de koppeling voor elkaar te krijgen. Gezien de redelijk hoge complexiteit van sbr moest hiervoor soms een lange weg bewandeld worden. Sommige leveranciers die het voor elkaar hebben gekregen, bieden inmiddels een portal aan waar snr-berichten verstuurd kunnen worden. Via de SBR Software Check, beschikbaar op softwarepakketen.nl, kunnen deze ontwikkelingen op de voet gevolgd worden.
Open source-hoek bleef stil
Vanuit de open source hoek bleef het stil. Er bestond kennelijk geen behoefte aan een koppeling met de Digipoort voor open source-projecten. Zelf leek het mij wel handig om mijn omzetbelasting via de Digipoort te versturen, dus uiteindelijk heb ik hiervoor de code geschreven en deze ook open source gemaakt. Wel een jaar te vroeg, want de omzetbelasting is pas vanaf volgend jaar verplicht om verstuurd te worden via de Digipoort. Dat is ook het kenmerkende van open source. Het ontstaat vanuit een behoefte, niet vanwege een opgelegde verplichting.
Tijdens het bouwen van de open source Digipoort-koppeling waren er helaas geen codevoorbeelden beschikbaar. In Australië, volgens dexbrlsite.nl, samen met Nederland één van de koplopers op het gebied van het sbr-concept, is dit anders geregeld. Daar is voorbeeldcode, een reference client, beschikbaar gemaakt voor zowel .Net- als Java-applicaties. Hoewel voor deze code een software developer’s licence moet worden aangevraagd, is deze code gratis verkrijgbaar. En dat terwijl xbrl down under nog niet eens verplicht is.
Vastgelopen ontwikkelaars
De Nederlandse overheid biedt vastgelopen ontwikkelaars een helpende hand met de servicedesk van Logius. Wel een beetje onwennig om als open source-ontwikkelaar een helpdesk te moeten raadplegen. Normaal gesproken vind je je antwoord toch wel ergens op het internet. Toch ben ik een keer de goede kant op gewezen door een verwijzing van de servicedesk naar de StackOverflow-site. Dit is de populaire online vraagbaak waar ontwikkelaars elkaar onbaatzuchtig helpen en samen uit ingewikkelde problemen proberen te komen. Want waarom zou je zelf in je eentje opnieuw het wiel uitvinden?
Je kan het ook omkeren. Als Digipoort geen open standaard had gebruikt maar een gesloten wat was dan het geval geweest?
Per partij zal er dan nog steeds een eigen implementatie worden gebouwd. Maar al die partijen zouden afhankelijk zijn van een partij hoe deze informatie over de koppeling zou aanbieden. Er zou dan geen bron-code beschikbaar zijn en alleen een handleiding met eventueel nog een referentie implementatie.
Al die partijen zouden dus afhankelijk geweest zijn van de kwaliteit van informatie en als dat toevallig een concurrent zou zijn dan is het aannemelijk dat het bedrijf zelf een voordeel zou hebben om wel inzage te hebben in de broncode en een op een met de programmeurs te schakelen.
Aangezien het hier om een koppeling met een overheids instantie gaat is het wat dat betreft niet wenselijk om partijen voor te trekken maar om objectief te blijven en een zo transparant mogelijke manier aan te bieden. Alleen al om die reden hoort de overheid bij voorkeur open standaarden te gebruiken.
@Nick / Technicus
In mijn optiek moet je hier 2 dingen van elkaar onderscheiden
Doordat de source open is, heb je inderdaad meer bijdragen van mensen die ervaring opgedaan hebben met het product, en kun je als gebruiker, in geval van nood, eventueel zelf de code induiken als er een probleem is. Dat is de kracht van open source.
Maar, zoals Nick al aangeeft, zijn er ook legal departments die hun zegje willen kunnen doen. Vooral in Amerika, maar ook steeds meer in andere landen, heerst een claim-cultuur. Ergens ook begrijpelijk. Als ik een product koop vind ik het wel prettig als ik ergens aan kan kloppen als dit product niet goed werkt. Door legal departments van gebruikende bedrijven wordt ook software gezien als een product wat je aanschaft, dus als verkopende partij zul je je daar helaas tegen moeten wapenen. Dit heeft haar weerslag op het open source karakter van de software.
Van de ene kant is dit inderdaad een stukje schijn-zekerheid, maar het (imago-)verlies van de leverancier kan verstrekkende gevolgen hebben.