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?
Dit artikel geeft precies aan waar het onderscheid zit tussen de beleving over open source software en de praktijk.
Heel goed dat de auteur de moeite neemt om zijn software te ontwikkelen en daarna te doneren. Maar er zijn maar weinig ondernemers die deze moeite nemen, als ze al in staat zijn dit te doen. En wat doe je dan? Dan koop je een oplossing of je neemt een dienst af. Met garanties voor support en beschikbaar e.d. Een ondernemer die ontzorgd wil worden heeft daar ook geld voor over. Open source is in dat proces totaal geen issue.
Ofwel: alleen de politiek en degenen die om kunnen gaan met de techniek vinden open source belangrijk. De rest zal het een worst zijn.
Ik laat me graag overtuigen dat het anders is. Zijn er niet-technische mensen in het bedrijfsleven die open source belangrijk vinden t.o.v. andere betaalde toepassingen? Graag zou ik daar de redenen dan van willen weten. Dus ik stel de vraag aan niet-technische en niet-overheidslezers van Computable!
Hans dank je voor je OSS bijdrage 😉
Dat is nog geen OSS implementatie was is niet zo vreemd, toen ik eind maart bij mijn belastingconsulent was, gaf deze aan dat hij wel DigiPoort spulletjes had ontvangen maar dat het aan de kant van de belastingdienst nog niet werkte.
Zo te zien was het weer het gebruikelijke geklungel met certificaten waar de boel vast liep.
(onder Windows moet je dat dan kennelijk in je browser regelen)
Even vluchtig naar XBRL gekeken. In eerste instantie dacht ik dat het weer zo’n SOAP gruwel was, maar het valt reuze mee. Kom ik een dezer dagen vast ook tegen op mijn pad.
Beetje achterlijk om 10x dezelfde functionaliteit te ontwikkelen die vervolgens geen enkel onderscheidend vermogen oplevert. Die kosten hadden bespaard kunnen blijven , gedane investeringen hadden beter benut kunnen worden en last but not least de factuur aan de ondernemer/gebruiker is veel hoger dan noodzakelijk. Opensource is vanuit de ratio de beste oplossing op een zo goedkoop mogelijke wijze implementeren. Kostenbeheersing is nauwelijks interessant voor techneuten of de overheid maar voor het bedrijfsleven essentieel.
Garanties voor support en beschikbaarheid is evengoed beschikbaar voor opensource software en dus zeker geen usp voor closed source.
Het feit dat het bedrijfsleven zich anno 2013 nog steeds laat belazeren door closed-source softwareleveranciers die hun kostenplatje niet op orde hebben en dus veel te hoge prijzen moeten rekenen .
Ontzorgen door closed source software ? Proest!
@Nick: leg dat eens uit: belazeren door closed source?
Geef eens voorbeelden met bewijzen?
@nick
Als bedrijf/klant wil ik een product dat werkt, waar ik een onderhoudscontract op kan afsluiten en een leverancier waar ik een claim heen kan sturen in het geval er een ondeugdelijk product is geleverd.
Of dit product nu open- of closed source is, zal me verder chorizo wezen.
Stel, ik gebruik het product van de auteur om mijn omzetbelasting door te geven aan de fiscus, maar er blijkt een fout in het product te zitten, waardoor ik een blauwe envelop krijg met een boete van duizenden euro’s.
Kan ik dan bij de auteur aankloppen en zeggen: hè vriend, een leuk programma wat je gemaakt hebt, maar dat geintje heeft me een paar duizend euro gekost. Kén ik ff vangûh?
@PaVaKe: ‘Kan ik dan bij de auteur aankloppen en zeggen: hè vriend, een leuk programma wat je gemaakt hebt, maar dat geintje heeft me een paar duizend euro gekost. Kén ik ff vangûh?’
Heb je weleens de leveringsvoorwaarden en licenties van b.v. Microsoft of Oracle doorgelezen? Zo ja, dan zou je moeten weten dat zij bij fouten in hun applicaties geen schade vergoeden. Waarom verwacht je dat dan wel bij een open souce-applicatie?
@Leen Blom
Dat is toch eenvoudig uit te rekenen: 20x code from scratch ontwikkelen of 1x code from scratch ontwikkelen en 20x implementeren scheelt een berg ontwikkelingskosten. Vervolgens kijk je met z’n 20-en naar de code zodat een fout veel sneller ontdekt wordt en dus ook test -en patchkosten vele malen lager liggen dan bij closed source.
Leveranciers van closed software hebben onnodig een veel te hoge kostenstructuur voor generieke functionaliteit en belazeren hun klanten omdat ze deze kosten één op één moeten doorberekenen.
@Pavake
Wat jij eigenlijk beweert is dat software ontwikkeld met bijvoorbeeld open source-componenten van Springsource ( die door de halve Java ontwikkelaarsgemeenschap gebruikt wordt) niet zou werken en/of dat op die producten geen onderhoudscontract kan worden afgesloten.
Wordt wakker!
Het businessmodel van opensource bedrijven is juist grotendeels op ondersteuning via een onderhoudscontract gebaseerd en hebben de grootste bedrijven in de wereld als klant.
Wat is slimmer , ieder softwarebedrijf z’n eigen xbrl- implementatie laten ontwikkelen of dit gezamenlijk in een open source-project doen waar iedereen de vruchten van kan plukken?
Verder sluit ik mij bij de omerkingenen van @Frank aan.
@Frank
Hangt er heel erg vanaf welke producten van zo’n leverancier je gebruikt.
Een database of een msoffice worden door mij niet gebruikt om een product te maken. Makro’s, databases etc die ik zelf maak, heb ik zelf verantwoordelijkheid voor.
Maar als database zelf corrupt raakt door fouten in de oracle software zelf, dan staan er wel degelijk penalties op aan de kant van oracle als ze niet de benodigde support kunnen leveren en het bedrijf daardoor verlies lijdt (is juridisch overigens wel een heel steekspel omdat je aan moet tonen dat leverancier iets ondeugdelijks heeft geleverd).
Dito met microsoft compilers. De kwaliteit van de code die ik erin stop, daar heb ik zelf verantwoordelijkheid voor. Maar doet de compiler niet wat ik ervan verwacht (gebaseerd op de informatie van microsoft) dan kan dat ook een claim opleveren.
Wellicht ten overvloede: ik heb het hier niet over de standaard contracten die je het MKB afsluit, maar over grote premium support contracten die rechtstreeks met een microsoft, oracle en anderen af worden gesloten.
Hier zit ook nog een ander addertje onder het gras: als je maar groot genoeg bent (en genoeg wil betalen) dan kun je ook eisen gaan stellen aan bijvoorbeeld de validatie van de producten die geleverd worden; iets wat in sommige sectoren verplicht is.
Bij open source heb ik geen rechtspersoon waar ik zaken mee kan doen, wat e.e.a. juridisch heel complex maakt.
@Nick: Goed ondernemersschap wordt door jou belazeren genoemd. De markt doet zelf zijn werk hierin. Je gaat uit van wereldbeeld dat niet bestaat: de nobele ontwikkelaars die de wereld het beste van het beste gunnen.
Maar innovatie wordt in hoge mate gedreven door concurrentie, niet door liefdadigheid. Het continu kunnen onderscheiden, verbeteren en vernieuwen moet betaald worden. Kijk naar de automobielindustrie: auto’s kunnen best zuiniger rijden als de klant dit wil, b.v. door support van de overheid op het gebied van belastingen.
We hebben in Nederland een grote maak-industrie van software met een exportwaarde van tegen de tien miljard euro. Dit afdoen met de opmerking dat dit allemaal klant-belazerende partijen zijn, getuigd op zijn minst gezegd over grote onkunde.
Open source software heeft goede kanten, met name voor commodity omdat daarvoor een levensvatbare community zal blijven. Maar voor vervelende zaken als het moeten doorvoeren van wetswijzigingen met terugwerkende kracht: niemand die daarvoor opstaat, tenzij betaald. Als we vervolgens alleen maar dienstverleners zouden overhouden, dan krijg je precies waartegen je strijdt: twintig aanbieders die de vraag elk op de eigen wijze probeert op te lossen.