Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Open source rammelt aan de Digipoort

 

Expert

drs. Hans Beemsterboer
Senior Ontwikkelaar, Beemsterboer Software. Expert van voor het topic .

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 is afkomstig van Computable.nl (https://www.computable.nl/artikel/4704796). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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.

@nick

Ik weet niet waar je het vandaan haalt, maar je hebt mij nergens zien beweren dat open source niet zou werken!

Daarnaast haal je twee dingen door elkaar in mijn ogen.
Open source zelf zegt iets over het ontwikkelmodel waarmee het product tot stand is gekomen. Hiervan zijn genoeg succesverhalen bekend.

Het commercieel aanbieden van een open source product is een heel ander verhaal. Wil jij dit succesvol doen, dan zul je als bedrijf ook een aantal ontwikkelaars tot je beschikking moeten hebben om de problemen van een klant op te kunnen lossen in de (open) source. Maar wie bepaalt nu of deze oplossingen daadwerkelijk in het product komen? Het commerciële bedrijf dat service probeert te verlenen, of de open source community?
Is de community het niet eens met de aangeboden oplossing (omdat dit voor mij misschien wel werkt, maar voor anderen niet), dan ben ik als klant dus niet geholpen. Op dat moment werkt open source model dus zelfs tegen me!
Het bedrijf kan dan kiezen een eigen "smaak" aan te bieden van het product, om mij als klant tevreden te stellen. De source is dan misschien nog wel open, maar het business model komt al aardig in de buurt van 'closed source' op deze manier.

Terug naar het artikel: de auteur heeft iets gemaakt waarvan hij denkt dat het handig is voor anderen, en biedt dit aan als open source naar de gemeenschap. Niks mis mee, chapeau zelfs!
Maar stel, ik heb een bedrijf, en ik vind een foutje in het product. Waar kan ik dan aankloppen? Als niemand in de open source community zich geroepen voelt het probleem op te lossen, en er geen enkele onderneming is die dit product (al dan niet op commerciële) basis wil ondersteunen, dan heb ik hier als bedrijf heel weinig aan.

Wat dat betreft sluit ik me dan ook aan bij de eerste reactie van Leen Blom, waar in staat:
'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.'

Een lezenswaardig artikel over closed versus open source:
'Open versus closed source: a delicate balance'.
(https://joinup.ec.europa.eu/elibrary/case/open-versus-closed-source-delicate-balance)

Belangsrijkste citaat wat ondersteunt wat ik hierboven ook al zei:

'The reason closed source software does not deliver the most value to society seems to be obvious', von Engelhardt elaborates, 'the lack of code sharing results in a wasteful duplication of effort. That open source software is not welfare-optimal either, is less obvious. Beside the advantage of cost sharing, it also has a disadvantage: open source software helps firms to avoid competition, because shared code can no longer be used to differentiate one firm from another. Since the software is an important determinant for the product quality, code sharing enables firms to avoid quality competition at this level. This has nearly the same effect as an official quality cartel among OSS-using firms would have had: output is reduced while firm profits go up.'

Een prachtige discussie!

Bedenken we dat iedereen hier veel tijd in internet bezig is en dat dat voor 65 procent op open source-code draait (Linux/Apache) nog afgezien van de Wordpress/Joomla/Drupal/Typo3/etc. etc. installaties die allemaal open source zijn.
De nieuwe trend cloud computing' wordt technisch gezien meestal opgebouwd op Linux-clusters.

Wanneer het gebruik dan zo onzeker is, waarom kiezen die grote spelers dan voor open source software? IBM was een van de eersten die begreep dat met de service op open source-programma's goed geld te verdienen is, daarmee betalen ze ook hun programmeurs die werken aan verbeteringen, net zoals Google, Red Hat, Oracle en zelfs Microsoft.

Het zijn al heel lang niet meer de hobbyisten in de achterkamer die open source software schrijven, het inmiddels big business.

Het artikel van de EU moet men met scepsis lezen omdat de EU onder een extreme hoge druk van lobbyisten staat. Het citaat van Leen Blom geeft niet de teneur van het artikel weer, namelijk dat je bij iedere software vele overwegingen moet maken wat de beste keuze is.
Opvallend is dat juist dit artikel te downloaden is als odt-bestand.

Inmiddels werk ik al tien jaar hoofdzakelijk met open source software en zie dat daar net zoveel concurrentie is als bij closed source of commerciële software, dat uit zich in het zogenaamde forking.

Wees trots op Nederland want daar wordt tenminste geprobeerd ook met open source software te werken.

@PaVaKe Quote:
"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)."

Tja, daar schiet je jouw eigen verhaal compleet lek aan het einde. Denk je dat jouw kleine bedrijfje (relatief in verhouding tot reuzen als Oracle/Microsoft) het financiële kapitaal heeft en de zucht om zo steekspel te winnen? Deze bedrijven hebben overigens legers aan advocaten in dienst. Tegen de tijd dat je even kan 'vangûh' ben je al een aantal keer over de kop gegaan door de juridische kosten.

Maar dat is de juridische kant van het verhaal. Als het OSS bedrijf niets doet, kan je nog altijd een derde of een second opinion halen. Andere specialisten kunnen de source code gewoon lezen.

@Jan: zo'n reactie kan ik waarderen.
Niet dat we het helemaal eens zijn, maar de toon en de argumentatie is prima.
Ik zie de goede kanten van open source software ook, maar daarmee hoef je closed software producenten niet te beschuldigen van belazeren (wat jij ook niet doet overigens).

@Jan van Leeuwen, helmaal geen prachtige discussie.

Ik zie hier een paar reacties waarvan de schrijver ervan duidelijk geen idee heeft wat source code is, om nog maar over de zakenlijke modellen ervan te zwijgen.

Ik proef vooral de angst voor OpenSource meuk omdat men er geen zakenlijk model in ziet.
Voor ICT-vakgenoten wiens specialisatie volledig is gericht op 'Are you sure - Next - Next - Register' is die angst mogelijk terecht, maar gelukkig bewijzen de reacties op de Computable artikelen dat er nog zal lui zijn die wel gekwalificeerd zijn.

@ Leen
Ik gebruik beide FOSS en proprietary Software, dat raad ik ook mijn klanten aan. Kies voor je opgaven de beste tool, dat is niet altijd FOSS maar wel vaak . . . bij mij.
Ik zie in betaalde software in doorsnee geen "belazerij" echter als ik de bedragen zie die SAP / Oracle en meer van zulke bedrijven vragen, dan krijg ik een beetje twijfel bij dit soort leveranciers.
FOSS is ook niet altijd gratis en ik denk dat Openbravo ERP, in de betaalde versie, niet slechter is als SAP.
Kiezen moet iedereen voor zich.

@technicus .... waarop baseer je je door te stellen dat ik bij een klein bedrijfje werk als ik vragen mag?

Zowel mijn huidige als mijn vorige werkgevers zaten allemaal in de categorie >100.000 werknemers namelijk, wat in mijn beleving niet echt klein meer te noemen is.

(maar je hebt in die zin een punt dat een dergelijke bedrijfsgrootte wel wat meer mogelijkheden biedt op financieel en/of juridisch gebied dan gemiddeld)

Ik mag graag stevig inzetten maar hier gaat het mis met de interpretatie van wat ik bedoel met "belazeren". Het gaar mij niet om het finaciële gewin van closedsource softwareproducenten maar om het onnodige verlies aan resources omdat 20x het zelfde wiel uitgevonden moet worden en de klant daarvan de dupe is. Niet alleen financieel maar vooral ook omdat dit innovatie belemmert en de ontwikkelingen die het echte meerwaarde opleveren voor de klant niet tot wasdom komen. Gewoon verspilling dus.

Gelukkig zijn de softwarebedrijven die momenteel het hards groeien wel opensourced minded en zien we het marktaandeel van de closed source leveranciers langzaam teruglopen. Dat is geen wonder want tegen de kracht van samenwerking in communities valt niet te concurreren.

Opensource betekend overigens niet ongecontrolelerd en zonder enige vorm van kwaliteitscontrole! Het is een groot misverstand dat bij opensource aanklooien de norm is. Vaak zijn opensource project door grote bedrijven geadopteerd waardoor een kernteam van developers en een communitymanager voor de noodzakelijke structuur en continuïteit zorgen. In tuil daarvoor krijgt het bedrijf directe toegang tot de belangrijkste developers die ook inzetbaar zijn voor klantprojecten . Die klantprojecten leveren vervolgens ook weer een kruisbestuiving op waar ook de community van profiteert. Wat ik daarbij persoonlijk wel nog al een groot probleem ervaar is dt bij adoptie door een groot bedrijf het "legal department" zoveel invloed krijgt dat de community-member die een vrijwillige bijdrage aan de code wil leveren, gedwongen wordt om eerst een "contract"te tekenen. Deze "overname"door de "legals"draagt niets bij en levert niet op behalve schijnzekerheid en werk voor de "legals". Dat is in mijn krachtige terminologie een "een achterlijke situatie"

Dat is ook wel groot. Let op het woordje "relatief" dat ik gebruikte. :-)

Wat ik onbelicht liet en wat ook wel voorkwam is dat een leverancier A leverancier B beschuldigd van een technische fout en omgekeerd en klant zit er dan tussen en is er de dupe van.

Kortom, dat je minder risico loopt met closed source, is gewoon een façade en een vorm van schijn-veiligheid.

Dat je in geval van problematiek meer opties heb met open source (danwel de source beschikbaar bij de afnemer) is aan de andere kant gewoon een feit.

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×