Voor de leek is de open source-gemeenschap een groep van gelijkgestemde idealisten die zich bezig houdt met alternatieve software. Dat is deels natuurlijk waar. De iets beter geïnformeerden weten echter hoe zeer binnen die gemeenschap de meningen over de mate van vrijheid omtrent de software kan verschillen.
Deze standpunten zijn vaak gekoppeld aan de softwarelicentie waaraan een persoon de voorkeur geeft. De free software-puristen hangen het Richard Stallman-dogma aan dat open source-code nooit en te nimmer onder een beperkende licentie mag vallen (GPL-licentie). Een andere grote groep kan zich niet bekommeren wat er met de vrije softwarecode gebeurt. Een commerciële partij kan de vrije code in een nieuwe applicatie gebruiken en er vervolgens een beperkende licentie op toepassen. De programmeurs van de oorspronkelijke code slapen er niet minder om (MIT-, BSD-, Apache-licentie). Er zijn nog wat tussenvormen, waarvan de Mozilla Public License (MPL) er één is. De MPL staat toe dat de vrije code samen met niet vrije code kan worden gecombineerd.
Oog voor eindgebruiker
Traditioneel is de open source-gemeenschap een technische aangelegenheid. Veel waarde wordt gehecht aan de kwaliteit van de code. De gebruikers van de software zijn vaak ook diegenen die aan de ontwikkeling bijdragen. Bij een bedrijfsapplicatie als erp is dat overwegend niet het geval. De programmeur is doorgaans niet degene die binnen een bedrijf productieplanning uitvoert of de boekhouding doet. Er is een groot risico dat de door de programmeurs ontwikkelde processen te ver van de beoogde eindgebruikers af liggen. Daarmee zou echt succes (dat wil zeggen algemene acceptatie en groot marktaandeel) van een erp-applicatie moeilijk worden.
Commerciële organisaties als Ubuntu (Linux OS), Alfresco (documentmanagement), SugarCRM (crm) en Openbravo (erp) maken het binnen hun markt mogelijk om een goed doordacht ontwikkelpad voor de software uit te stippelen. Zij besteden extra aandacht aan de behoefte van de eindgebruikers. Dit garandeert dat er een consumentvriendelijke applicatie beschikbaar is.
Professionele ondersteuning
Afnemers van erp-software en andere kritische applicaties willen kunnen vertrouwen op een stabiele professionele organisatie. Een leverancier moet voor hen klaar staan als problemen met de software zijn. Iedere minuut dat er geen verkopen of magazijnleveringen kunnen worden geregistreerd, wordt er geld verloren. Een typische erp-klant van enig formaat wil daarom niet vertrouwen op een forum van een open source-gemeenschap, maar eist een helpdesk die 24×7 bereikbaar is. Een plek waar bugs meteen worden aangepakt. Dit geldt niet alleen voor erp, maar ook voor grote afnemers van Linux, MySQL, Apache, etc.
Snelle verspreiding
Commerciële organisaties kunnen de vrije software oppakken en er klant- of marktspecifieke aanpassingen aan toevoegen zodat het aantrekkelijker wordt voor een klant of groep klanten om de software af te nemen. Hiermee wordt dus sneller een nieuwe markt aangeboord. Het vrije deel van de software blijft vrij en wordt op deze manier ook verspreid. Daarmee neemt het aandeel en het belang van de vrije software ook toe. Met deze toename van het belang zullen er ook meer programmeurs bereid zijn aan het vrije deel van de software bij te dragen. Ook is het mogelijk dat de bestaande gesloten functionele delen opnieuw worden geprogrammeerd door de gemeenschap en zo onder een vrije licentie worden verspreid.
Bestaansrecht
Het belang van een centrale autoriteit voor erp is vanwege het ontwikkelpad en centrale ondersteuning een belangrijke voorwaarde. Een dergelijke organisatie optuigen en in stand houden kost veel geld. Er zullen daarom diensten en producten om de vrije software ontwikkeld moeten worden om voor inkomsten te zorgen.
De diensten die doorgaans worden aangeboden hebben betrekking op training, consulting en helpdesk-ondersteuning. Dergelijke inkomsten worden binnen de open source-gemeenschap als algemeen acceptabel gevonden.
De meningen binnen de gemeenschap zijn wel verdeeld als het op 'versioning' aankomt. Versioning is het aanbieden van een gratis community-editie van de software zonder ondersteuning, maar daarnaast een betaalde enterprise-editie met extra functionaliteit en met recht op ondersteuning. Die extra functionaliteit valt dan onder een beperkende licentie. Dit valt niet in goede aarde bij veel GPL-aanhangers of leidt op z'n minst tot zorgen.
Opwaartse spiraal
Het combineren van vrije en niet-vrije code leidt juist tot een opwaartse spiraal van succes voor open source-software. Centraal gestuurde ontwikkeling door één organisatie leidt tot betere kwaliteit en snellere verspreiding van vrije software die gericht is op een minder technisch onderlegde gebruikersgroep. De organisatie bekostigd zichzelf door omzet te genereren uit verwante diensten en het aanbieden van stukken niet-vrije, niet-gratis software. Snelle verspreiding leidt tot meer zichtbaarheid van de software. Met de levendige aandacht zullen ook meer programmeurs en andere belanghebbenden geïnteresseerd zijn een bijdrage te leveren, waardoor ook het vrije deel van de software groeit. Dit leidt ook weer tot meer commerciële interesse. Zo begeeft de softwareontwikkeling zich in een positieve spiraal. Met de Mozilla Public License is het daarom mogelijk om open source-software voor een veeleisende doelgroep versneld te ontwikkelen en succesvol te laten zijn.
Het is niet relevant om een discussie te voeren over welke licentie het predicaat 'beste' verdient. We kunnen wel stellen dat, zoals in dit artikel beschreven, bepaalde typen software waarschijnlijk sneller succes genieten onder de Mozilla Public License dan wanneer zij zouden zijn gepubliceerd onder een GPL-licentie.
Als licensing piet-lut sprekend, kijk dan ook eens naar de CDDL. Die is er op gericht om alle goede features van de MPl te behouden, maar daarnaast (o.a.) hergebruik te vergemakkelijken. Hernoemen van de MPL naar zeg Henk’s Public License (HPL) vereist eigenlijk een gang naar OSI voor een “stamp of approval”. Met de CDDL is dat niet nodig (en kan daarmee de beruchte open source license sprawl verminderen).
Ook de keuze van rechtbank (MPL: Californie!) wordt vrij gelaten in de CDDL, wat het flink eenvoudiger maakt om de CDDL in te zetten buiten de VS, met de voordelen van de MPL minus de nadelen.
Los van de vraag of de MPL beter is voor duale licentiestructuren, vraag ik me hier toch af of je zonder nadere wetenschappelijke onderbouwing kunt zeggen dat: “Het combineren van vrije en niet-vrije code [..] juist [leidt] tot een opwaartse spiraal van succes voor open source-software. Centraal gestuurde ontwikkeling door ??n organisatie leidt tot betere kwaliteit en snellere verspreiding van vrije software die gericht is op een minder technisch onderlegde gebruikersgroep.”
Met dat laatste beweer je toch eigenlijk dat communitysoftware alleen kwalitatief beter en gebruikersvriendelijker kan worden wanneer er gesloten onderdelen in “the cathedral” worden gemaakt. Ik laat me graag door je aanvullende argumenten overtuigen, maar heb op dit moment wel grote twijfels over de houdbaarheid van deze bewering.
@ Mathieu: mijn hypothese luidt dat de functionele kwaliteit (dus niet de kwaliteit van de code) van front-end bedrijfsapplicaties (dus doelgroep die zich niet met software engineering bezig houdt) SNELLER verbeterd en wordt geaccepteerd bij os projecten met een bazaar waar een cathedraal in het midden staat. Ofwel: het samengaan van beide methoden. Ik beweer dus niet dat software ALLEEN kwalitatief beter en gebruiksvriendelijker wordt met gesloten code.
@ Mathieu 2: kwaliteit van ondersteuning die “kathedraal” organisaties kunnen leveren en die klanten van kritische applicaties eisen kunnen niet door de “bazaar” worden geleverd. Bazaar en kathedraal zijn in deze context misschien misplaatst, omdat we het niet over de ontwikkelkant van software hebben, maar over de dienstverlening er omheen.