OSPM - het Open Source Participation Model

Een interessant artikel in de GIS magazine waarmee we de zomer doorkomen. Onder de titel "hoe te kiezen" beschrijven Luuk Schaminee en Harco de Jager (beiden werkzaam bij Ordina) over het traject waarmee de provincie Noord-Holland een gefundeerde keuze wil maken tussen diverse open source compenenten om daarmee een deel van de provinciale geo-infrastructuur mee in te richten.

Een vraag waar veel organisaties mee zitten: is Mapserver nu een betere (of scherper gesteld: voor mijn organisatie geschikter) mapping server dan GeoServer of Deegree, is Mapcache te verkiezen boven MapProxy of GeoWebCache voor mijn tile-caches.
(Nu hoor al wat mensen zeggen: het gaat niet om "of-of", maar je haalt er het meeste uit met "en-en", maar ik kan me wens wel voorstellen om het provinciale geo-applicatielandschap niet net zo gevarieerd te maken als het Noord-Hollandse landschap zélf).

In het artikel wordt beschreven hoe met het Open Source Maturity Model (OSMM) de volwassenheid van de diverse communities die de open source producten ontwikkelen wordt gemeten, en -het lijkt mesje 2 van Gilette wel- met het Open Product Selection Process (OPSP) in de hand de geschiktheid -getoetst aan je eigen gebruikerswensen- kan worden gescoord. (Details over de 2 modellen vind je op de site van Ordina).

Een interessante benadering. Toch mis ik er een belangrijk aspect aan.
De diverse open source producten (of moet ik zeggen: de producten van de diverse communities) worden naar mijn idee met OPSP vooral benaderd als producten met een afgebakende fucntionaliteit, waarbij OSMM als garantie moet dienen voor het levensvatbaarheid van de community voor onderhoud en support.
Wat ik mis is een score die aangeeft hoe groot de kans is dat ik mijn functionele wensen en/of eisen -als die nog niet in een product aanwezig zijn- in een nabije release kan verwelkomen. Daarbij ga ik er gemakshalve van uit dat je vooral mee wilt werken aan de verdere ontwikkeling van het product zélf, en minder gericht bent op het starten van een eigen afsplitsing ("fork") van de software. Is de "wishlist" enigszins in overeenstemming met mijn eigen wensen, en kan ik de verwezenlijking er van positief beïnvloeden door mensen uit mijn eigen organisatie, of ingehuurd door mijn organisatie- in de community in te zetten? Eigenlijk de afweging: wat is mijn return-on-investment in een open source community?

Zo hoeft zelfs een must-have functionaliteit bij een open source product niet persé tot een knock-out bij pakketselectie te leiden. Als het zelf (laten) toevoegen van die functionaliteit eenvoudig mogelijk is (en dat bij voorkeur in de volgende standaard release mee komt) kan een product toch hoog scoren.
Misschien wel het beste voorbeeld hiervan is het een paar jaar terug in opdracht van de Ordnance Survey door Boundless laten uitbreiden van Geoserver zodat Geoserver volledig ana de Inspire eisen voldoet. De Ordnance Survey blij, omdat zo zo bij het hun vertrouwde Geoserver konden blijven én aan de Inspire eisen voldoen, u en ik blij omdat we de webservice van de Ordnance Survey soepel kunnen gebruiken, en alle andere Geoserver gebruikende partijen die ook Inspire verplichtingen hebben (zoals de provincie Noord-Holland) blij omdat zij op deze ontwikkeling kunnen meeliften.

Misschien dat daarvoor naast het OSMM  en het OPSP nog een derde model kan worden ingevoerd Ik zou dat het Open Source Participation Model (OSPM) willen dopen, dat beschrijft in hoeverre een organisatie in staat is de mogelijkheden van open source volledig uit te nutten.