Ca faisait un petit bout de temps qu'un message me narguait sur ma page Linuxfr "Cet utilisateur n'a pas encore posté de journaux."
Voici donc mon premier journal !
C'est l'occasion de parler de quelques uns de mes projets open source et de leur très relatif succès.
1er projet : Binocle http://binocle.sourceforge.net
Le but de ce projet est de créer une bibliothèque C++ permettant de faire de la "stéréovision reconstructive". En clair, reconstruire une scène 3D à partir de 2 photographies d'un même objet prises sous des angles différents. C'est un projet de fin d'année que j'ai fait pour mon école ingénieur.
- globalement peu de personnes se sont intéressées à ce projet, rien d'étonnant c'est plutôt un truc de geek. Si le logiciel était de bonne qualité et assez visuel, il pourrait intéresser le grand public.
- le code original est une galerie des horreurs du C++. J'ai essayé de l'améliorer et de le nettoyer à chaque fois que j'en avais l'occasion (merci les intercontrats en SSII). Ca a été un bon moyen pour moi de réaliser les progrès que j'avais accomplis en C++ depuis la fin de mes études !
-A l'origine, le projet n'utilisait aucune bibliothèque externe, je n'ai pas réinventé la roue mais il y a beaucoup de choses que j'aurai pu éviter de faire.
état : inutilisable en tant que tel, le code est assez commenté pour que des étudiants qui puissent le reprendre et en fasse quelque chose.
2ème projet : NabazClapier http://nabaztools.sourceforge.net
C'est un outil pour ajouter des fonctionnalités à son lapin wifi (http://www.nabaztag.com). Je l'ai principalement développé lorsque je recherchais un emploi.
- Il a suscité beaucoup (enfin bon, pas de quoi s'affoler) plus d'intérêt que mon premier projet ! D'une part c'était un des premiers logiciels à offrir ce genre de fonctionnalité et d'autres part il améliorait un produit que je trouvais un peu bridé.
- Le projet se base sur microproxy et linetd. Il utilise aussi iniparser et libhttp. J'ai eu à faire à quelques bugs présents dans linetd mais dans l'ensemble j'ai gagné beaucoup de temps en me basant sur des logiciels existants.
- J'ai eu quelques retours de personnes utilisant Nabazclapier et certaines ont mis des liens vers mon projet sans que je ne leur demande.
- Au final je me suis un peu lassé de ce projet, le Nabaztag ne fonctionne qu'en WEP ce qui fait que je ne l'utilise plus (mon *#@% de DLINK n'accepte pas de firmwares open pouvant résoudre ce problème). Les améliorations que je pourrais apporte au projet réclament trop d'effort par rapport à ce qu'elles apporteraient.
état: fonctionnel et utilisable par un public averti.
3ème projet : XpadML http://dzeus80.free.fr/projects/xpadml-0.1.tgz (nom et URL provisoire)
C'est un script pour xpad qui me permet d'envoyer un mail qui apparaîtra comme un post it sur mon bureau.
- je me sers de cet outil presque tous les jours et je pense que beaucoup de personnes pourraient le trouver utile.
-c'est un projet beaucoup plus court que les précédents, il fait appel à xpad et à mpop.
- je n'ai pas fait de site web digne de ce nom pour le projet et je n'ai pas beaucoup communiqué.
- J'espère améliorer un peu ce projet et le rendre compatible avec d'autres logiciels "post it" tels que XfceNotes ou TomBoy
état : utilisable par un public un peu technique, pourrait être intégré à un projet ou figurer dans son répertoire "contrib".
Ce que j'ai retenu de ces expériences est que finir un projet, même petit, demande du temps. Le rendre assez propre, gérer les différents cas d'erreur, écrire une courte documentation, faire un site web (ça ce n'est vraiment pas mon truc) sont des tâches indispensables que l'on doit faire en plus du développement. Et surtout il faut que le logiciel que l'on développe intéresse les utilisateurs et soit d'une qualité suffisante pour le rendre utilisable par le plus grand nombre. J'ai bon espoir pour XpadML, ca sera une petie contribution au monde du libre mais sans doute la plus utile que j'aurai faite.
Bref, mon conseil est le suivant : ne commencez pas de projet open source ambitieux à partir de zéro, vous serez déçu ! Si vous êtes très doué et persévérant vous obtiendrez un logiciel moyen et mal testé, dans le cas contraire, vous n'obtiendrez rien d'utilisable. Utilisez ou contribuez à un projet existant, vous aurez beaucop plus de chances de parvenir a vos fins.
Ce message ne s'adresse pas qu'aux étudiants qui veulent se lancer dans un projet libre, j'espère que mon futur ex-directeur technique (plus que 2 semaines ;-) tombera sur ce message la prochaine fois qu'il voudra inventer un n-ième protocole de transfert de fichier ou qu'il voudra créer une nouvelle API qui n'arrive pas à la cheville de celles que POSIX définit !
# Well
Posté par chtitux (site web personnel) . Évalué à 8.
Je suis d'accord là dessus, et je partage le point de vue.
Cependant, « il en faut » aussi, des fous qui se disent : « je serai le premier contributeur à mon projet qui deviendra un (noyau d') OS Libre, un serveur http Open Source, etc. »
De nombreux projets, dès qu'ils rencontrent une base d'utilisateurs suffisant et attentifs, prêts à contribuer, peuvent réussir. Et il en faut !
Enfin, on ne le dit pas assez, merci pour ton journal de qualitai. Si ça peut faire réfléchir deux ou trois daicideurs pressai, ça ne sera pas du luxe...
[^] # Re: Well
Posté par Hrundi V. Bakshi . Évalué à 7.
[^] # Re: Well
Posté par Krunch (site web personnel) . Évalué à 7.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Well
Posté par godzom . Évalué à 5.
Étonnant!
[^] # Re: Well
Posté par Obsidian . Évalué à 5.
Ceci m'amène, après 20 années de programmation, à un constat : on peut oublier tout le génie logiciel, l'UML, etc. Les grosses bidouilles seront toujours celles qui ont le plus de succès.
[^] # Re: Well
Posté par Erwan . Évalué à 3.
Alors le fait que ca soit parti d'un ensemble de scripts shell ca surprend pas tant que ca. Ca rassure juste un peu sur la sante mentale des auteurs de CVS parce que s'ils avaient planifie ca, vraiment decide du design il y aurait de quoi s'inquieter.
[^] # Re: Well
Posté par Sylvain Sauvage . Évalué à 3.
[^] # Re: Well
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Sinon, je suis d'accord avec l'auteur du journal. Je ne pensais pas que reviewer des patchs, faire le site, faires les releases et tout prenait autant de temps.
Mes livres CC By-SA : https://ploum.net/livres.html
# ...
Posté par Anonyme . Évalué à 3.
Je te trouve bien pessimiste; comme toujours, il y a des échecs, et des réussites, et réinventer la roue n'est absolument pas un signe d'échec, c'est au contraire une marque d'innovation, et donc une possibilité d'arriver à de nouveaux sommets. Bien-sûr, ça ne marche pas à chaque fois, mais dire «désormais je réutiliserai» n'est pas le meilleur moyen pour changer les choses.
Beaucoup par exemple trouve que recoder une libc est du temps perdu, mais quand on voit la dietlibc, on se dit qu'on est bien content que l'auteur n'ait pas cherché à réinventer la roue.
D'autre dirons que coder un compilo GCC, un kernel, un moteur 3D, un forum PHP, et j'en passe, est une perte de temps ... jusqu'à ce qu'un produit réellement innovant sorte et que tout le monde se jette dessus.
[^] # Re: ...
Posté par jgreg . Évalué à 5.
Par exemple, dans mon premier projet, j'ai écrit du code pour lire un fichier de configuration (type fichier .ini) avec le recul, je trouve ça inutile : des bibliothèques implémentent déja ce genre de fonctionnalités (iniparser par exemple). Ecrire une autre bibliothèque de lecture avec des concepts ou approches différents n'auraient pas été réinventer la roue. Par contre dans mon cas, lire un fichier de configuration était une tâche secondaire sur laquelle je n'aurais pas du passer de temps.
Quand tu parles de moteur 3D, je pense que c'est un très bon example pour illustrer mon journal : il y a un proportion assez incroyable de moteurs 3D inutilisés car inutilisables, et parfois inutilisés alors qu'ils sont utilisables. Il est plus utile (à la fois pour la communauté libre et pour le développeur) de contribuer à un moteur 3D en rajoutant un effet, un rendu, etc. que de commencer son propre moteur.
On peut commencer un nouveau moteur 3D mais il faut avoir des ressources, de l'expérience et du temps, ou s'appeler ID Software ;-)
[^] # Re: ...
Posté par Matthieu Lemerre . Évalué à 1.
Je peux temoigner ici: j'ai ecris un compilateur pour un nouveau langage de programmation, une sorte d'evolution de C (www.nongnu.org/l-lang), qui comporte pas mal d'innovations par rapport a C; pour l'instant, ce n'est pas encore un franc succes mais j'attend d'etre plus avance pour lancer une "campagne de publicite" :)
Apres avoir fait l'experience de la contribution sur un autre projet, je trouve que les deux sont interessants: d'un cote la contribution est interessante car le chef de projet est la pour encadrer et aider a mieux comprendre le projet; de l'autre le projet tout seul apporte une liberte totale qui je pense est le moteur de la nouveaute et du renouveau dans les logiciels d'un meme type, avant que de nouveaux contributeurs n'apportent leurs idees pour ameliorer le projet.
# C'est encourageant ...
Posté par mat3o . Évalué à 2.
J'essaye de programmer le plus proprement possible et j'espère bien ne pas m'arreter a un logiciel moyen/mauvais. Si on s'en donne les moyens, s'il y a de l'interet et une utilisation, je vois pas en quoi un logiciel ne peut pas arriver, à terme, à quelque chose de potable.
Enfin moi j'y crois et j'espère bientot pouvoir poster un journal ici même pour présenter mon projet et le travail que j'ai réalisé (c'est sur ça sera pas parfait, loin de la, mais le but c'est que le projet soit maintenu et actif pour arriver a un logiciel de bonne qualité).
[^] # Re: C'est encourageant ...
Posté par nonas . Évalué à 6.
;)
[^] # Re: C'est encourageant ...
Posté par BAud (site web personnel) . Évalué à 2.
J'espère que tu travailles déjà avec un dépôt subversion avec ton collègue, cela permet de suivre l'avancement et d'avoir un changelog propre.
Tu as pas mal d'hébergeurs libres entre https://gna.org et http://tuxfamily.org qui te permettent de gérer un dépôt voire de mettre en place un wiki pour faire la doc' au fur et à mesure (ou noter tous les liens / articles utiles lors du développement : il est toujours intéressant de se poser les questions avant de se lancer dans le dév, déjà rien que pour évaluer ce qui existe déjà et reprendre ce qui existe de bien ou refaire quand c'est nécessaire).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.