Suite à notre discussion concernant la stratégie, discutons ici plus précisément de solutions pour mieux gérer la dépendance aux projets externes.
L’idée est de se doter d’une stratégie (à l’échelle globale mais on peut la décliner pour OSM-Fr) pour organiser, prévoir, mieux articuler la relation qu’OSM maintient avec des acteurs externes.
De mon point de vue, pour l’instant voilà notre stratégie actuelle :
(bazar étant entendu dans sa version noble telle que définie par Eric Raymond dans "la cathédrale et le bazar)
Le projet est organisé en mode binaire : soit un sujet est géré directement en interne, soit il est laissé au bon soin du bazar.
Affinons la stratégie
Ce fonctionnement ne convient plus, il me semble, à la taille et l’ambition d’OSM.
Et voilà vers quoi nous pourrions tendre :
Pour chaque projet en particulier (Les routeurs, les notes, les API …), faisons une évaluation de la dépendance basée sur de nombreux critères (code source ouvert, données publiées en open data, gouvernance, but lucratif ou non, proximité / intrication avec la communauté …) et décidons en conséquence d’une stratégie.
Cette stratégie pouvant être plus fine que « laissez-faire » ou « faire nous-même », impliquant des possibilité de délégation (partielle ou complète, sous forme de partenariat (financé ou non) ou de sous-traitance. De très nombreuses possibilités mixtes existent et surtout, l’approche pour chaque sujet doit être réévaluée au cours du temps.
Exemple 1 : l’API de contribution tombe parfois en panne. Pour atteindre notre vision de devenir la plateforme cartographique libre, ouverte, collaborative et universelle pour le crowdsourcing nous avons besoin d’une API constamment fonctionnelle.
Conclusion : on sous-traite (tout ou partie) pour garantir un taux de disponibilité plus élevé.
Exemple 2 : Pour atteindre notre vision de devenir la plateforme cartographique libre, ouverte, collaborative et universelle pour la consommation de données une appli mobile généraliste grand public (style Google Maps) est importante.
Le mouvement OSM n’ayant pas vocation a créer une appli OSM officielle, nous mettons en place / déléguons (selon les cas) des APIs, des SDK, de la doc … pour qu’une telle appli émerge.
Il peut être envisagé de soutenir plusieurs applis (des « distributions ») ayant chacune leur spécificités. Le soutien d’OSM peut être remis en cause en cas de manquement.
PS : l’idée des cercles concentriques est issue du concept de « cercles concentriques de communauté » (source) tels qu’appliqués chez Mozilla.
PPS : la seule structure ayant la légitimité de porter une telle stratégie me paraît être la fondation. La réforme de sa gouvernance étant un sujet à part entière.