Le développement de Geomorph

La philosophie
Les possibilités de contribution

La philosophie

Comme mentionné en introduction, Geomorph est une réponse à mes propres besoins de création de paysages. Il est conçu et développé au fur et à mesure que de nouvelles idées de paysages demandent de nouveaux outils.

La plupart des scènes conçues avec Geomorph sont dérivées d'expériences personnelles associées à une émotion esthétique. Parfois des lectures peuvent être une source d'inspiration, comme les articles de chercheurs sur la formation des dunes qui ont mené à la création des outils de dunes et de vaguelettes de la version 0.3. Des scènes de désert ont été imaginées et créées pour mettre au point ces outils (et les outils ont été mis au point pour créer ces scènes...).

Pour ceux qui connaissent l'essai d'Eric S. Raymond, The Cathedral and the Bazaar, Geomorph n'est ni une cathédrale ni un bazar, ou plutôt c'est à la fois une cathédrale et un bazar! J'avais un plan au point de départ, mais comportant de grandes zones d'imprécision. Il a été complété et ajusté en réponse aux essais des premières versions, aux découvertes d'opportunités ou de nouveaux besoins et aux commentaires des utilisateurs. Ce plan n'est pas documenté, sinon dans les commentaires du code C.

Au travers de ce cheminement mi-planifié mi-opportuniste, le développement de Geomorph respecte quelques principes, que je résumerais ainsi:

Ces principes ont notamment pour conséquence que les livraisons sont assez espacées. Je mets un bémol sur l'adage "Release early, release often". Je teste beaucoup les nouvelles fonctionnalités, d'abord pour les bogues, puis pour m'assurer qu'elles permettent de faire les tâches attendues d'une façon raisonnablement confortable. Un logiciel qui plante et qui fait mal ce qu'il doit faire n'entraîne pas l'adhésion des gens.

En ce qui concerne le délai entre les livraisons, je dois ajouter que le développement et la documentation de Geomorph constituent un passe-temps, entre la famille et un emploi à plein temps qui n'a aucun rapport avec la création de paysages virtuels.

En utilisant le logiciel pour le tester et le documenter, il se crée une sorte de dialogue entre le modèle d'utilisation et le devis du logiciel. L'un et l'autre s'enrichissent mutuellement: l'utilisation montre les limites de l'outil, j'améliore l'outil, je découvre des façons inattendues de l'utiliser, j'améliore le modèle d'utilisation, et ainsi de suite. C'est une boucle de feedback, une alternance entre une approche déductive (du modèle vers la réalisation) et inductive (de la réalisation vers le modèle). Ou pour utiliser le langage des modélisateurs de systèmes d'information, une alternance entre l'approche "top-down" et "bottom-up". Au passage, c'est ainsi que les théories scientifiques se constituent, et je ne pense pas que les logiciels puissent se constituer différemment. C'est la façon qu'ont les êtres humains d'apprendre.

Développer un logiciel n'est pas une entreprise de pure ingénierie, mais ce n'est pas non plus une entreprise de pure créativité ni de pure expression. Un logiciel est un artefact construit qui a des propriétés formelles, et à cet égard il intéresse l'ingénieur, le mathématicien, le logicien. Mais c'est aussi un texte qui véhicule des significations et des procédés intellectuels (un programme est lu et compris par des humains - même lorsqu'il est trop encore trop bogué pour être exécutable), et à cet égard c'est un objet d'expression et de créativité, qui peut intéresser le linguiste, le philosophe, l'artiste, le psychologue. Enfin, et surtout, lorsqu'il est au point, un logiciel est un système, ou un tout qui possède des propriétés qu'on ne peut pas expliquer en analysant l'ensemble de ses parties. L'une de ces propriétés est la cohésion ou la complétude. Je n'utilise évidemment pas ces termes dans leur sens formel, mais une interprétation formelle n'est pas à exclure lorsque la situation s'y prête. On "sent" la présence de cette propriété devant une construction qui tout en étant "complexe" reste "équilibrée" et "simple". Cette propriété peut être partagée par à peu près tous les produits de l'esprit humain, dont les oeuvres d'art et les théories scientifiques. Le "sens" qui nous permet de l'identifier intuitivement est à mon avis de nature esthétique.


Les possibilités de contribution

Je travaille actuellement seul à la conception et à la réalisation de Geomorph. J'en suis aussi le principal testeur.

J'ai obtenu des commentaires constructifs de quelques utilisateurs, qui m'ont aidé à faire évoluer le produit.

Dans ce sens, tous vos commentaires seront très appréciés: à quoi vous utilisez le logiciel, les difficultés que vous avez rencontrées, vos suggestions, etc.

J'ai aussi obtenu des contributions appréciées de deux utilisateurs allemands, Tim Schürmann, qui a traduit la version 0.22, et Simon Donike, qui a pris la relève pour la version 0.3. Simon a aussi beaucoup testé la version 0.3 avant son lancement et commenté la documentation html.

Je n'ai pas de modèle de développement très précis. Je n'ai pas de "postes" à proposer pour l'instant. Cependant, je suis heureux d'accepter des offres, comme celles de Tim et Simon. La condition fondamentale à respecter est que le développement de Geomorph reste un plaisir. Cela implique, entre autres, les conditions suivantes:
Personnellement, je ne veux pas me transformer en manager au sens traditionnel du terme. Cela deviendrait un travail et je préfère réserver de tels efforts à ma vie professsionnelle, non à mes passe-temps.

Dans ce cadre, certaines contributions sont plus faciles à intégrer au projet que d'autres. Voici des possibilités, dans un ordre croissant de difficulté:
  1. Les traductions sont probablement les contributions les plus simples. Les prérequis sont de comprendre la langue de départ (le français ou l'anglais, dans ce cas - j'ai l'intention de continuer à publier dans les deux langues), de comprendre le fonctionnement du logiciel, et de maîtriser la langue cible écrite, habituellement la langue maternelle du traducteur. Il faut distinguer la traduction du logiciel de celle du site Web. La traduction du logiciel consiste à convertir 400 à 500 mots ou expressions utilisés dans les dialogues, sauvegardés dans un fichier texte. La mise en contexte des messages, dans leur dialogue d'origine, est nécessaire, c'est pourquoi il faut connaître le logiciel. La traduction du site Web est plus hasardeuse: elle représente beaucoup de travail et les documents source sont appelés à changer souvent.
  2. Les révisions sont une autre contribution simple. On peut réviser le texte du site Web ou les mots et expressions des dialogues de Geomorph, pour la clarté des expressions et la qualité de l'orthographe ou de la syntaxe. En particulier, un ou des réviseurs anglophones seraient les bienvenus.
  3. Le test des pré-versions sous différentes distributions serait une contribution appréciée. La compilation, l'installation et le fonctionnement sont les trois aspects à tester. Les prérequis sont de la débrouillardise, de la persévérance, et une bonne capacité à décrire les problèmes rencontrés. Tester la compilation requiert de plus certaines connaissances techniques de base.
  4. La conception de textures et le cas échéant de scènes Povray prédéfinies. Les prérequis sont de bien connaître Povray et d'avoir le sens de l'observation, afin d'imiter des textures naturelles de façon convaincante.
  5. L'amélioration des scripts d'installation et la constitution de paquetages pour différentes distributions (ex. .RPM, .DEB) sont un autre domaine de contribution, dont je ne maîtrise pas tous les aspects et pour lequel votre expertise pourrait être appréciée. Un prérequis est la connaissance des langages de script (ex. bash, les "specs" RPM, etc.), des distributions concernées et du processus de compilation.
  6. L'interface avec d'autres moteurs de rendus. Geomorph fonctionne avec Povray parce que c'est l'outil que je connaissais quand j'ai commencé le projet. La version actuelle de Povray (3.6) n'est pas libre au sens de la GPL. Des moteurs de rendu libres pourraient être utilisés, comme Aqsis et YafRay. Une contribution serait de développer une interface et des scènes prédéfinies avec ces moteurs de rendus, ou d'autres dont j'ignore l'existence. Une évaluation de la faisabilité et de l'opportunité serait requise au point de départ. Si un moteur de rendu n'est pas en mesure de prendre comme input un fichier PNG ou similaire, et qu'il faille transformer chaque image en treillis (mesh) avant le rendu, il n'y a peut-être pas d'intérêt à investir dans ce moteur.
  7. Le développement (conception et programmation) constitue probablement la contribution la plus difficile, pour le contributeur et pour moi. C'est sur ce point que l'autonomie et mon désir de ne pas me transformer en manager au sens traditionnel du terme prennent toute leur importance. En ce qui a trait à la programmation, des prérequis sont de connaître le langage C et la bibliothèque GTK, ainsi que d'être à l'aise avec la structure du code et mon style de programmation. Un mot là-dessus: je suis préoccupé de bien structurer mes données et mes programmes, mais n'ayant pas travaillé comme développeur depuis une quinzaine d'années, j'ai probablement élaboré un style qui ne ressemble à celui d'aucune communauté de développement. Je ne connais pas, non plus, tous les standards applicables (par exemple, les standards GNU - trop long à lire...). Mais je ne demande pas mieux que d'être relu et critiqué. En tout état de cause, si vous désirez explorer cette possibilité, la première étape est de lire le code! En ce qui a trait à la conception, elle peut concerner l'interface, l'outil, mais aussi les processus particuliers à la génération et à la transformation d'images de relief. Peut-être même pourriez-vous me faire profiter de votre expertise en géomorphologie pour faciliter le développement d'algorithmes, si nous arrivons à trouver un langage commun pour en discuter.
D'autres opportunités de contributions sont à envisager dans le futur, selon l'accueil que recevra Geomorph et l'orientation que son développement prendra. Je pense, par exemple, à la gestion et à la modération d'un forum, ou encore à la gestion d'une base de donnée en ligne qui pourrait contenir les textures ou les objets Povray fournis par les utilisateurs.

Rédigé en septembre 2005

Contact:    Patrice St-Gelais


SourceForge.net Logo