Un peu d’éthique sur MOVIM

Je sais ce que vous allez dire: "Il est braque Anto' avec son Eric S. Raymond, il nous le ressort à toutes les sauces et ça commence à bien faire". Ok, ok, j'entends vous avez raison, je suis complétement centré sur ces principes d'organisations et j'en parle à chaque fois que j'en ai l'occasion, comme pour mieux vous bourrer le mou. Eh bien j'assume et persiste, car c'est selon moi les règles d'organisation les plus modernes pour tout type d'organisation humaine.

Le projet MOVIM avance vraiment bien, et il m'a semblé utile que soit relus par les contributeurs ces quelques règles fondamentales.

Au fait, pour ceux que cela intéresse, une réunion est prévue le 19 mai à 20h00

Tiré de l'article de Eric S. Raymond, la cathédrale et le bazar.

Principes du bazar

Le bazar, pleins d'approches et rituels différents, c'est une foule grouillante.

Distribuer vite

• Montrer que le projet progresse.
• Faire sans cesse appel aux utilisateurs pour détecter et corriger les bugs.
• Numérotation des versions afin que les utilisateurs les plus expérimentés se risquent à utiliser les dernières versions et que les utilisateurs moins expérimenté utilisent des versions stable.

Motiver la communauté

• Laisser le libre choix du travail à accomplir.
• Gratifier les contributeurs et les pousser à améliorer leur travail.
• Établir une documentation simple et claire.
• Déléguer un maximum pour impliquer un maximum de personnes.

Avoir beaucoup d'utilisateurs

• Trouver les bugs : Les débogeurs peuvent travailler en parallèle, il n'est pas nécessaire qu'ils soient coordonnés. Pas d'augmentation du cout et de la complexité du projet.
• Trouver des co-développeurs.
• Trouver une solution à chaque problème en faisant appel aux compétences de chacun et la diversité des approches.
• Trouver de nouveaux usages aux fonctionnalités (marque de reconnaissance d'un excellent logiciel).
• Quand un programme n'intéresse plus son auteur, il est de son devoir de lui trouver quelqu'un d'autre pour le reprendre.

Être ouvert

• Réutiliser intelligemment les codes et idées préexistante.
• Savoir reconnaître les bonnes idées des utilisateurs aussi important que d'avoir de bonnes idées soit même.
• Laisser un libre accès au code source.
• Les solutions les plus innovantes arrivent quand on remet en question notre approche.

Structurer un logiciel intelligemment

• Produire une structure robuste quitte à ce que le code manque d'originalité.
• Créer une identité au logiciel à travers la manière dont il est codé.
• Développer un code concis répondant aux besoins fonctionnels.

PS: Ce document peut être librement modifié par les contributeurs inscris au blog, comme sur un wiki.