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:
- Offrir des fonctionnalités pour lesquelles
des résultats ou des tâches précises sont
envisagées. La façon d'utiliser l'outil est
prévisualisée avant de concevoir l'outil. Ou en d'autres
termes, Geomorph n'est pas seulement la traduction d'un concept ou d'un
devis de
logiciel, c'est d'abord et avant tout la
traduction d'un modèle d'utilisation.
- Livrer les nouvelles fonctionnalités lorsqu'elles sont
utilisables pour les tâches envisagées. Éviter les
éléments de dialogue superflus ou non évidents,
ainsi que les plantages, et ce, même si par définition, le
logiciel est en version alpha parce qu'il n'est pas complet.
- Documenter l'utilisation dans des tutoriels ou des guides. C'est
une
nécessité pour transmettre les principes d'utilisation.
Geomorph n'est pas un type de logiciel dont la plupart des utilisateurs
ont une compréhension intuitive, au contraire d'un traitement de
texte.
Le traitement de texte reproduit le paradigme de la feuille de papier
dans la machine à écrire, un logiciel comme Geomorph ne
reproduit aucun paradigme courant. Documenter des scénarios
d'utilisation (des tutoriels) est aussi une excellente
façon de mettre à l'épreuve la robustesse du
logiciel et l'à-propos de son modèle d'utilisation.
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:
- Le travail pris en charge par le contributeur (-trice) doit
être assez facile à définir.
- Le contributeur doit être
autonome, sinon expert, dans son domaine d'intervention.
- Nous devons nous entendre sur des principes de base.
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é:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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