Le coin de l'open-source géospatial

Des logiciels libres aux données libres (partie 2 sur 3)

Modes de fonctionnement

Parmi la multitude de projet libre les plus connus sont sans aucun doute les projets de logiciels libres. Cette section présente le fonctionnement des projets en tant que projet de logiciels libres. Ce qui me semble définir un projet de logiciel libre est l’existence d’une communauté de développeurs dont des règles écrites ou tacites régissent les comportements et les relations en toute transparence. Les utilisateurs ont la possibilité d’échanger ou de suivre les échanges avec ou entre les développeurs.

Le mode de fonctionnement des projets libres est directement lié aux modèles économiques choisis ainsi qu’aux libertés fondamentales (voir plus haut). Les mots-clés sont les termes communautaire, transparence et indépendance.

Une communauté

Un projet libre a pour vocation de réunir des contributeurs d’horizon divers autour du projet. La licence autorisant les utilisateurs à modifier et diffuser leurs modifications, il est de l’intérêt du projet d’accepter les modifications des utilisateurs et de l’intérêt des développeurs extérieurs à retourner leur développements les plus génériques. Et ce pour différentes raisons :

• le projet évolue ainsi plus facilement et plus rapidement (correction de bugs, nouvelles fonctionnalités, etc.) ;
• les développeurs extérieurs n’auront pas à ré-adapter leurs modifications à chaque nouvelle version (adaptation de leur code aux évolutions du coeur du projet, évolution et adaptation des fonctionnalités qu’ils ont développés par la communauté).

Un travail gagnant-gagnant en somme.

Pour que les contributions puissent être acceptées il faut que le projet se soit réunit autour d’une communauté d’utilisateurs et de développeurs prêt à contribuer. Mais il faut également des règles définies pour que tout utilisateurs et développeurs puissent connaître le processus d’acceptation des contributions au projet et connaître les besoins.

Des outils

Pour une bonne communication entre les développeurs et les utilisateurs, des outils sont mis en place. On trouve généralement :

• des listes de diffusion ;
• un serveur de dépôt de code source, svn ou subversion est généralement utilisé ;
• une interface de gestion de bug et de demande de nouvelle fonctionnalité, appelé bugtracker ;
• un canal irc ;
• un site Internet (avec le minimum vital parfois) ;
• un wiki (mais pas toujours).

Le serveur de dépôt de code, les listes de diffusion et le bugtracker sont le minimum que propose un projet. Ces outils ont chacun une fonction précise dans le processus de développement.

Listes de diffusion et canal IRC

Il existe généralement plusieurs listes, mais toutes celles qui sont présentées ici n’existent pas toujours :

• dev (toujours) ;
• users (toujours) ;
• commit (souvent) ;
• release (souvent);
• listes locales (fr, de, etc.).

La liste dev permet de discuter entre les développeurs : quelles sont les nouvelles fonctionnalités qui vont être ajoutées, discussion sur leur conception, sur les bug et leur résolution, définition du planning des prochaines versions, etc. C’est aussi l’endroit pour poser vos questions si vous désirez ajouter une nouvelle fonctionnalité.

La liste user vous permet de poser vos questions lié à des problématiques d’utilisation du logiciel. Les développeurs y répondent directement et rapidement assez souvent.

La liste commit vous permet de suivre de près (de très près même) les développements qui sont « commité » (d’où le nom de la liste) dans le serveur de dépôt de code source.

La liste release vous permet de vous tenir au courant des sorties des nouvelles versions.

Les listes locales vous permettent de poser votre question dans votre langue. Très peu de ce type de liste existe. Il en existe pour GRASS (grass-fr par exemple).

Un serveur de dépôt de code source

Un serveur de dépôt de code source est un serveur qui permet à plusieurs développeurs de travailler ensemble sur le développement d’un logiciel sans que leurs modifications du code source soient écrasées par celles des autres développeurs. Ce serveur gère également un historique des modifications :

• qu’est ce qui a été modifié ?
• qui a modifié ?
• quand le fichier a t-il été modifié ?

Voici quelques exemples :

• le svn de MapServer ;
• voir les sources de MapServer ;
• un diff entre deux versions du fichier HISTORY.TXT dans lequel une ligne a été rajoutée, cliquez ici.

Bugtracker

Un système de rapport de bug permet au projet de gérer les problèmes et les demandes de fonctionnalités. Il permet d’affecter ceux-ci à une version spécifique et permet de connaître la roadmap des futures versions. Voici celles pour QGIS. Vous trouverez sur cette page la liste des bugs actifs, classés par type de bug.

Site et wiki

Bien sur, un projet a toujours son site, parfois une page, parfois plus, il présente le projet, rassemble la documentation, liste les liens pour télécharger les versions (source et binaires). Parfois un wiki est proposé. De plus en plus souvent les projets utilisent une application appelée Trac qui rassemble un wiki, un bugtracker, une navigation du svn, la roadmap et la timeline ((page qui liste les envois de code sur le serveur de dépôt effectués par les développeurs)).

Des règles écrites ou tacites

Dans le cas un peu spécial où le projet est hébergé par l’OSGeo, le projet se doit d’avoir un minimum de règle écrite pour définir le fonctionnement du comité en charge du projet. Ce n’est pas souvent aussi formalisé au sein d’un projet Open Source. L’OSGeo impose un certain nombre de règle lors de la phase d’incubation : révision du code concernant le copyright, ajout d’en en-tête dans tous les fichiers pour indiquer la licence et bien sur des règles écrites concernant le fonctionnement du projet. Voici par exemple celui du projet OpenLayers.

Vous trouverez chaque Comité de pilotage du projet pour les projets de l’OSGeo sur cette page.

Souscrire aux commentaires de cet article