Category Archives: Open Source Software

Patenten als inkomstenbron

Niet zolang geleden las ik op internet dat Microsoft 5 dollar verdient op ieder Android apparaat dat verkocht wordt. Tegelijkertijd is de eigen Windows Phone 7 software geen groot succes. Mogelijk dat de samenwerking met Nokia daar verandering in kan brengen. We zullen moeten afwachten hoe de consument dit beoordeeld.

In mei 2007 maakt Microsoft bekent dat er 235 van haar patenten in Linux zijn te vinden. Het bedrijf weigerde te vertellen om welke patenten het precies ging. Daarmee werd de open source community onder druk gezet. Linus Torvalds was niet onder de indruk. Volgens hem is de kans dat Microsoft zelf patenten van anderen schendt groter dan dat zoiets in Linux gebeurt. Daarnaast was hij van mening dat Microsoft meer te winnen had van de angst die dit met zich meebrengt.

Het heeft er alle schijn van dat Linus Torvalds gelijk heeft gekregen. Microsoft heeft met verschillende bedrijven overeenkomsten gesloten vanwege vermeende patent schending (Velocity Micro, General Dynamics Intronics, Onkyo Corp., HTC en Barnes & Noble). Het gaat in deze gevallen om Android dat op de Linux kernel is gebaseerd.

Onlangs heeft een consortium van bedrijven voor 4,5 miljard dollar Nortel patenten gekocht. Het consortium wordt gevormd door Microsoft, Research In Motion (RIMM) en Apple. Deze Nortel patenten versterken de positie van dit consortium in haar patent rechtszaken.

Nu is Microsoft ook in gesprek met Samsung. Ook hier gaat het om schending van patenten in Android. Per verkochte smartphone of tablet wil Microsoft een vergoeding van 15 dollar hebben. De onderhandelingen lopen nog, dus mogelijk wordt het een lager bedrag. Ook wordt er gesproken met Motorola. Dat zou Microsoft‘s patenten schenden met de Motorola Droid, XDroid en verschillende telefoons.

Niet alleen Microsoft probeert geld te verdienen middels patent rechtszaken. HTC heeft bijvoorbeeld onlangs het bedrijf S3 Graphics gekocht met als hoofddoel het verkrijgen van diens patenten. Het is immers al bekend dat Apple een aantal daarvan schendt. En ook Oracle mengt zich in deze ‘strijd’. Zo is bij Infoworld te lezen dat Oracle 20 dollars per Android telefoon wil hebben. Dagelijks komen er meer van dit soort voorbeelden bij.

We kunnen naar mijn idee inmiddels een aantal conclusies trekken.

Ten eerste heeft Keith Bergelt, CEO van het Open Invention Network gelijk gekregen toen hij in 2008 beweerde dat er een groot aantal patent rechtszaken zou volgen. Hij noemde het toen ‘De stilte voor de storm’.

Daarnaast lijken Microsoft (en de anderen) zich te richten op open source software in het algemeen. Toch is mijn indruk dat vooral gelet is op concurrenten die geld verdienen aan Linux, daar valt immers wat te halen. Het kost Microsoft ook verder niets, met uitzondering van de inhuur van juristen. Op de korte termijn levert dit Microsoft mogelijk veel geld op, misschien wel meer dan de eigen mobile software. Op de langere termijn is het een slecht bedrijfsmodel, er wordt namelijk geen waarde toegevoegd. Zodra de open source community de software herschrijft en de patenten omzeild werkt dit niet meer.

Ook vraag ik me af of patenten (en rechtszaken daarover) wel goed zijn voor de ict-industrie. Naast hoge kosten regeert angst en achterdocht. Het leidt de aandacht af van hetgeen de industrie zou moeten doen, namelijk mooie en innoverende producten maken.

Ik bekijk het vooral graag positief. Open source software is inmiddels ‘Big business’. De grote it-bedrijven doen wat ze altijd al deden, het gebruiken, er rechtszaken over voeren, er overeenkomsten over sluiten en er veel geld aan verdienen. Open source software is daarmee naar mijn idee volledig geaccepteerd in de zakelijke wereld
.

Dit artikel is verschenen op de site van Computable op 11-07-2011

Business case: Zarafa vs. Microsoft Exchange

In de ict is het gebruikelijk om voor productkeuzes een business case op te stellen. Dit belicht de bedrijfsmatige en vaak financiële kant van de verschillende alternatieven. Zo kan een afgewogen en verstandige keuze gemaakt worden voor bijvoorbeeld een nieuwe applicatie.

In een business case worden zo veel mogelijk aspecten meegenomen die de kosten beïnvloeden. Hierbij kan gedacht worden aan kosten voor hardware, stroom, rackspace en licentiekosten. Ook minder voor de hand liggende aspecten zoals kosten voor implementatie, migratie en beheer moeten in de berekening worden meegenomen. Deze berekening wordt total cost of ownership (tco) genoemd. In de tco zitten alle kosten die het gebruik van een toepassing met zich meebrengt.

Veel organisaties willen financieel profiteren van de mogelijkheden die open source software hen biedt. Een van de mogelijkheden is Microsoft Exchange te vervangen door Zarafa Collaboration Platform. Beiden betreffen mail/groupware-software en kunnen naadloos met Microsoft Outlook werken. De vraag die velen bezighoudt is natuurlijk: hoeveel kan er bespaard worden? Dit artikel beschrijft de business case van Zarafa versus Microsoft Exchange. Voor beide producten is een tco-berekening gemaakt waarbij (nagenoeg) alle denkbare kosten zijn meegenomen.

Soms is het erg lastig om een goede tco-berekening te maken. Op verschillende punten zijn applicaties niet vergelijkbaar, bijvoorbeeld omdat de licentiestructuur verschillend is. Bovendien zijn er altijd aspecten die je niet kan kwantificeren. Een voorbeeld hiervan zijn de kosten van incidenten. De eerste vraag die daarvoor beantwoord moet worden, is het gemiddeld aantal incidenten van een applicatie. Hoe is dat objectief vast te stellen? Hoe kan bovendien de schade die een organisatie oploopt door downtime vastgesteld worden? Dit wordt sterk beïnvloed door het belang van de applicatie voor de betreffende organisatie.

Voor de lastig te bepalen aspecten worden aannames gedaan. Alle aannames in deze tco-berekeningen zijn aangegeven. Hierdoor kan de lezer zelf bepalen wat de invloed is als deze aannames gewijzigd worden of komen te vervallen.

De business case

In deze case wordt een fictief bedrijf met vijfhonderd medewerkers gebruikt. Deze organisatie heeft noch kennis en ervaring met Exchange, noch met Zarafa. Men wil het zelf hosten op een enkele fysieke server. De overige aannames zijn:

– De tco-berekeningen zijn gemaakt over een periode van drie jaar en zes jaar.
– Voor de licentiekosten van Exchange is met opzet niet gekozen voor de Software Assurance, dit zou de licentiekosten voor Exchange substantieel hoger maken (50 tot 75 procent hoger). In de berekening van zes jaar worden in jaar vier de licenties nogmaals gekocht omdat er dan net als bij Zarafa niet alleen updates, maar ook upgrades beschikbaar zijn. Zo zijn de alternatieven beter vergelijkbaar.
– Vijfhonderd gebruikers kunnen op een enkele server draaien.
– Voor alle softwareproducten is een versie met support genomen.
– De kosten van incidenten en schade door downtime zijn buiten de tco-berekening gehouden omdat deze niet op voorhand zijn vast te stellen.
– De implementatiekosten voor Zarafa zijn inclusief een testmigratie en fixed price.
– In de tco-berekening is ervoor gekozen de licentiekosten en subscriptiekosten in een keer te voldoen (in plaat van over drie jaar af te schrijven). Dit zal de meest voorkomende situatie zijn.
– Speciale (branche)kortingen en surfcontracten zijn buiten beschouwing gelaten.
– De prijzen voor het Microsoft Exchange-alternatief zijn door een Microsoft-partner aangeleverd.
– Er is geen sprake van een voorkeur voor één van de alternatieven, functioneel acht ik beide producten gelijk.

In de tco-berekening zijn meegenomen:

– Hardware (stelpost voor beiden gelijk gehouden).
– Spare parts (stelpost voor beiden gelijk gehouden).
– Hardware support (stelpost voor beiden gelijk gehouden).
– Stroom (stelpost voor beiden gelijk gehouden).
– Rackspace (stelpost voor beiden gelijk gehouden).
– Licenties en/of subscripties.
– Implementatiekosten (installatie en inrichting).
– Ten behoeve van de berekening van migratiekosten wordt uitgegaan van een migratie van Exchange naar een nieuwe versie van Exchange of van Exchange naar Zarafa).
– Beheerkosten (in beide gevallen kan beheer in vier uur per maand uitgevoerd worden, echter vanwege een lager beheertarief in het Microsoft Exchange-alternatief, vallen de beheerkosten daar lager uit).
– Opleidingskosten (in beide gevallen is gekozen voor certificering van zowel operating systeem als de groupware software).

Natuurlijk kunnen in een specifieke situatie of organisatie de uitgangspunten verschillen. Deze business case is zo generiek mogelijk gehouden om de significante verschillen aan het licht te brengen.

Resultaten

Zarafa vs. Microsoft Exchange

Het eerste vergelijk is over een periode van drie jaar. In dit kostenoverzicht is te zien dat het Zarafa-alternatief goedkoper is over een periode van drie jaar. Ook is te zien dat in beide gevallen de meeste investeringen in het eerste jaar vallen. Dit heeft te maken met de aanschaf van hardware, licenties/subscripties, implementatie en migratiekosten. De subscripties van Zarafa geven recht op updates en upgrades. De licenties van Microsoft geven alleen recht op updates. In deze berekening zien we een besparing van ruim 28 procent in het voordeel van Zarafa.

Zarafa vs. Microsoft Exchange

 

 

In een grafiek is een en ander als volgt voor te stellen.

 

 

 

Zarafa vs. Microsoft Exchange

Het tweede vergelijk betreft een periode van zes jaar. In dit tweede vergelijk is het verschil tussen Microsoft Exchange en Zarafa groter geworden, zowel absoluut als procentueel. Ook hier geeft de Zarafa-subscriptie recht op zowel updates als upgrades. De gekozen licenties van Microsoft geven alleen recht op updates. Om toch een eerlijk vergelijk te maken worden daarom in jaar vier de Microsoft-licenties opnieuw gekocht zodat ook een upgrade kan worden uitgevoerd. Dit verklaart de extra kosten bij Exchange in jaar vier. Indien deze strategie niet wordt gevolgd, zou na zes of zeven jaar een break even-punt bereikt kunnen worden. De consequentie is dan dat dezelfde versie zes of zeven jaar te gebruiken is, zonder te (kunnen) upgraden. In deze berekening is de besparing van het Zarafa-alternatief ruim 36 procent.

Zarafa vs. Microsoft Exchange

 

 

In een grafiek is een en ander weer als volgt af te beelden.

 

 

 

Conclusies

De tco-berekening laat zien dat deze business case aantoont dat met Zarafa kosten kunnen worden bespaard in vergelijk met Microsoft Exchange (25 procent over drie jaar en 36 procent over zes jaar). Hoewel deze verschillen procentueel klein lijken, gaat het om ruim 24.000 euro over drie jaar en ruim 53.000 euro over zes jaar. Dit zijn bedragen waarmee zinvolle dingen te doen zijn, zoals betere apparatuur aanschaffen, extra support inkopen of opleidingen volgen.

Naast de bovenstaande conclusie zijn er enkele relevante kanttekeningen te maken:

– Los van de kosten van licenties en subscripties zijn er veel open source softwaretools te vinden die het operationeel houden van Zarafa kunnen vereenvoudigen en verbeteren. Bijvoorbeeld monitoring tools (zoals Nagios of OpenNMS), deployment tools (Cobbler, Coan) of ten aanzien van configuratiemanagement (Puppet).
– Als een organisatie per se gebruik wenst te maken van een van de alternatieven, dan is een financieel vergelijk zinloos. Een duidelijke voorkeur zal bepalend zijn voor de keuze.
– In de tco-berekening is uitgegaan van gelijke (fysieke) hardware. Microsoft Exchange-experts houden als ‘vuistregel’ een maximum van vijfhonderd gebruikers per fysieke server aan. Zarafa doet met IBM samen op dit moment onderzoek naar duizend gebruikers per fysieke server.
– Verwacht wordt dat de verschillen bij een multi-servers set-up (bijvoorbeeld wanneer er meer dan vijfhonderd gebruikers zijn of wanneer er maatregelen getroffen worden voor een hoge beschikbaarheid) groter worden in het voordeel van Zarafa.
– De Zarafa-subscripties geven recht op support van Zarafa zelf. Het aantal supportverzoeken is gekoppeld aan het aantal subscripties dat wordt afgenomen. Een dergelijke support is niet standaard bij Microsoft Exchange inbegrepen.
– De kwaliteit van de alternatieven (als in het aantal incidenten, gemiddelde incidentduur en bedrijfsschade als gevolg van downtime) zijn in deze tco-berekening, zoals gezegd, buiten beschouwing gelaten. Van deze gegevens was geen data beschikbaar. Uit mijn ervaringen van weet ik dat Zarafa ook op dat punt zeker niet achterblijft.

Een goed vergelijk op basis van een tco-berekening blijft erg moeilijk. Er zijn altijd wel verschillen te benoemen die aanleiding kunnen zijn tot een discussie. In deze business case is geprobeerd een zo zuiver mogelijk vergelijk te maken en de aannames te verwoorden. In antwoord op de vraag uit de inleiding kan gesteld worden dat er aanzienlijk bespaard kan worden door over te stappen van Microsoft Exchange naar Zarafa.

Dit artikel is verschenen op de site van Computable op 22-02-2011

Code management en open source met GIT

We kennen Linus Torvalds als de maker van Linux. Hij heeft daarnaast ook GIT gemaakt. GIT is een source code management systeem, dat zelf volledig open source is. Het combineert technische eigenschappen en sociale aspecten die het bij uitstek geschikt maken voor open source software projecten.

Dezelfde motivatie die destijds ten grondslag lag aan Linux zette Torvalds er ook nu toe aan om zelf iets te maken. Hij was namelijk ontevreden met hetgeen er al was. In zijn presentatie over GIT bij Google talk laat hij zich dan ook negatief uit over CVS (en in mindere mate over Bittracker). Beiden zijn source code beheer systemen met een voor Torvalds onwerkbare opzet (om verschillende redenen overigens). Het kon en moest beter besloot hij en het GIT-project was geboren. De afkorting GIT staat voor ‘Global Information Tracker’ alhoewel Wikipedia en de home site van GIT daar nog grappige alternatieven voor bieden.

Gedistribueerd

Een van de belangrijkste eisen die Torvalds aan een source code management systeem stelt is dat het gedistribueerd werkt. Dit betekent dat iedereen een eigen versie van de code heeft. De meeste source code management systemen werken daarentegen met een centrale repository (opslag van code) en dat heeft nadelen. De code is daarbij voor alle developers toegankelijk. Daarom zijn er bijvoorbeeld naamconventies nodig zodat code-takken niet dezelfde naam krijgen (ze moeten uniek blijven). Ook zijn er performance problemen. Een vergelijk van twee code-takken (een diff), gaat binnen een centrale repository niet snel genoeg, zeker niet wanneer ook andere developers tegelijkertijd dergelijk bewerkingen uitvoeren. Andere nadelen zijn dat het branchen (aftakken) en mergen (weer samenvoegen) van code-takken erg lastig is. Als laatste noemt Torvalds de noodzaak van security. Een centrale repository heeft een uitgebreide autorisatie nodig. In de praktijk levert dat altijd problemen op.

In het gedistribueerde model van GIT behoren de genoemde problemen tot het verleden. Iedereen heeft een eigen kopie van de code. Het branchen (aftakken) is eenvoudig en er is geen naam conventie nodig. Je kan immers zelf bepalen hoe je een nieuwe code-tak noemt. Ook mergen (samenvoegen) gaat eenvoudig. Performance en security zijn niet langer een issue, je bent immers de enige op het systeem. Code gaat ook niet snel verloren. Meerdere developers hebben een versie van dezelfde code op hun systeem. Tevens doet GIT een checksum (controle op basis van sha) van alle bestanden. Hierdoor komen onbedoelde veranderingen in code bestanden (bijvoorbeeld als gevolg van corruptie van bestanden) meteen aan het licht. De goede performance van GIT leidt tot een andere manier van werken. Doordat bewerkingen op code-takken veel sneller kunnen voer je deze bewerkingen ook makkelijker en dus vaker uit. Omdat daarnaast het branchen (aftakken) van een code-tak zo eenvoudig gaat, nodigt dit developers uit snel nieuwe dingen uit te proberen. Op een centrale repository is dat niet gewenst. Het uiteindelijke resultaat van deze werkwijze is betere code en dat is waar het om gaat.

Als een developer een goed stuk code heeft gemaakt, kan hij dat aan een andere developer geven. Omdat de code-takken makkelijk kunnen mergen (samengevoegd worden), kan het eenvoudig opgenomen worden in het software project. Middels de hiërarchie, die de mensen binnen een software project kennen, wordt bepaald welke code uiteindelijk opgenomen gaat worden. Het is daarmee gebaseerd op het netwerk van vertrouwen dat er tussen de verschillende developers bestaat. Binnen het Linux project is het uiteindelijk Torvalds die bepaalt welke code in de kernel opgenomen wordt.

Bazaar

Naast de technische aspecten interesseert GIT me om nog andere redenen. Het is wederom een mooi voorbeeld van de manier waarop een open source project gestart wordt. Iemand heeft een probleem en zorgt zelf voor een oplossing. Inmiddels werken er vele developers aan GIT mee, blijkbaar voorziet het bij meer mensen in een behoefte.

GIT is naar mijn idee bij uitstek geschikt voor open source software projecten. Het sluit goed aan bij de manier van software ontwikkelen binnen communities. Dit wordt ook wel de bazaar wijze van software ontwikkelen genoemd. Ook past het bij de sociale hiërarchie die binnen open source projecten gebruikelijk is. Commerciële (of defensie gerelateerde) bedrijven zullen mogelijk niet zo blij zijn dat iedere developer de complete code van een software project op zijn laptop mee neemt. Toch kan GIT bijdragen aan kwalitatief betere code, dat is iets dat ook voor deze bedrijven interessant is.

Eigenlijk verbaast het me niet dat juist Linus Torvalds, als grondlegger van het meeste bekende open source project ter wereld (Linux), een source code management systeem bouwt dat bij uitstek geschikt is voor open source projecten. Ik vraag me alleen af wat de marktadoptie is van GIT. Welke bedrijven gaan dit gebruiken?

Dit artikel is verschenen op de site van Computable op 20-01-2011