Souscrire via RSSDes 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.
Des logiciels libres aux données libres (partie 1 sur 3)
Introduction
«Il est, je crois, un principe élémentaire du droit d’auteur que l’auteur n’a pas de droit d’auteur des idées, mais seulement dans l’expression de celles-ci. La loi du droit d’auteur ne lui donne pas tout monopole de l’utilisation des idées avec lesquelles il traite ou de toute propriété, même si elles sont originales. Ses droits d’auteur se limitent à l’œuvre littéraire dans laquelle il les a exprimées. Les idées sont des biens publics, l’œuvre littéraire est la sienne.» Justice Thorson P. in Moreau v. St. Vincent
Ce document, constitué de 3 billets dont celui-ci est le premier, a pour ambition de démontrer l’intérêt des données libres en partant d’une description du microcosme des projets libres (communauté, licence, modèle économique, etc.).
Le premier billet décrit les projets libres : liberté, modèles économiques, etc. La plupart des utilisateurs de Firefox, Linux, ou OpenOffice.org etc., ne connaissent ni les principes ni les implications d’un projet libre ou open source et pourtant celles-ci ont des implications sur le logiciel et leur utilisation. Le deuxième billet expliquera le mode de fonctionnement des projets en logiciels libres et open source : communauté, outils utilisés, organisation. Enfin le dernier billet traitera des données libres : quelles licences ? Quels modèles économiques ? Quelles organisations ? Quelles données doivent être libérées ?
Le lecteur notera que je parle ici de “projet libre” et pas de logiciel libre ! Pourquoi ? Parce que le concept du libre a aujourd’hui largement dépassé le cadre des logiciels pour toucher à tout ce qui se créer : logiciel bien sur mais aussi données, document, dessin, musique et vidéo.
Un exemple de coopération d’une commune avec OpenStreetMap ?
La liste OSGeo-qc, lieu d’échange de la Représentation Locale de l’OSGeo pour le Québec, permet aux utilisateurs d’applications Open source en géomatique d’échanger et de diffuser des informations sur les avancés de la géomatique Open Source. Hier (mercredi 3 juin), dans un fil appelé “La Ville de St-Hyacinthe se lance dans la géomatique Open Source“, Yves Moisan nous apprenait qu’en plus d’intégrer les données libérées par la commune de Sherbrooke, ils allaient les contacter afin de mettre en place une procédure de mise à jour des données OSM par la ville.
Je ne sais pas ce que cela va donner : la ville va t-elle accepter ? Quelle procédure sera mise en place ? Mais au délà de ces questions légitimes, il était intéressant de voir les prémices d’une coopération gagnante pour la ville et le projet OpenStreetMap.
Merci à Yves Moisan pour cette information, nous attendons donc des nouvelles de cette coopération 
Courte échelle
Rapidement, des nouvelles du monde de la géomatique Open Source :
- Sortie de MapServer 5.4.0, vous pouvez maintenant utiliser le mapfile de Thomas Bonfort pour les données OpenStreetMap ;
- Sortie de QGIS 1.0.2 et QGIS 1.1.0, la doc a aussi été mise à jour et la traduction en français se poursuit ;
- La France bien placé dans les contributeurs de l’open source, et pour la géomatique ?
OGRS 2009 : le salon de la géomatique open source
Si vous vous intéressez à la géomatique Open Source, que vous réalisez une veille technologique ou tentez de vous auto-former à ces technologies, ou bien que vous ayez besoin de connaître ce qui se prépare dans les laboratoires de recherche, toujours en matière de géomatique Open Source, mais que vous doutez de pouvoir vous déplacer au fameux FOSS4G 2009 qui aura lieu en octobre à Sydney en Australie, peut être devriez vous réfléchir à vous déplacer à Nantes, en juillet.
Ouverture des inscriptions à la conférence FOSS4G
Sydney, Australie. Le 4 mai 2009. http://2009.foss4g.org
La conférence internationale pour les Logiciels Libres et Open Source en Géospatial (FOSS4G), aura lieu à Sydney, en Australie, du 20 au 23 octobre 2009, est maintenant ouverte pour l’inscription.
Pourquoi adhérer à l’OSGeo-fr ?
L’association OSGeo-fr a lancé un appel à l’adhésion à l’association le mois dernier. Cet appel au delà de l’objectif de communication permet aussi d’expliquer l’objectif d’une telle association.
Google Summer of Code : la liste des projets
L’OSGeo a encore été choisie cette année comme association pouvant recevoir des fonds de Google pour financer des développements de logiciels. Voici la liste des 11 projets qui ont reçu l’approbation de Goggle Summer of Code (Google SoC) :
- uDig (Web Map Tiles) ;
- GDAL ;
- OpenRouter ;
- GRASS (analyse réseau) ;
- GeoServer / GeoTools ;
- Quantum GIS (intégration d’OssimPlanet dans GRASS et QGIS, placement des étiquettes) ;
- MapServer (gestion des symboles SVG et gestion du format KML en sortie) ;
- Laval Uni ;
- gvSIG ;
- Mapbender ;
- OpenJUMP/Deegree ;
Mais aussi PostGIS qui va développer la gestion du format Raster.
C’est également pas moins de 3 mentors Francophone et concernera 20 étudiants.
GDAL-OGR : documentation en français pour la version 1.6.0
La documentation en français pour la version 1.6.0 de GDAL-OGR a été mise à jour. Vous trouverez la documentation pour tous les nouveaux formats et commandes de cette nouvelle version sortie en décembre 2008.
Retrouvez la documentation sur le site Softlibre.
Annonce des tutorials et Workshop du FOSS4G 2009
Cet article est une traduction de l’annonce de Cameron Shorter, président du Comité d’organisation du FOSS4G 2009.
Sydney, Australe, le 30 Mars 2009.
C’est avec plaisir que nous terminons les spéculations sur les tutorials et workshops pour le FOSS4G d’octobre. Bien que les descriptions finales ne seront pas publiées avant l’ouverture des inscriptions, voici la liste finale.
