Quel type de chef de projet faut-il pour qu'un projet de logiciel libre aboutisse ?

Quel type de chef de projet faut-il pour qu'un projet de logiciel libre aboutisse ?

Les projets libres et open source n'aboutissent pas tous. Évidemment, les utilisateurs ne se souviennent que de ceux qui ont réussi, car ce sont ceux que nous utilisons. Par contre, il y a tout autant, ou peut-être plus de projets ouverts, dont le code est accessible, sur lesquels tout développeur peut aider (il suffit de voir la plateforme GitHub) mais qui ne décollent pas ou qui n'aboutissent pas.
Généralement, à leur début, les projets sont portés et développés par le créateur, l'initiateur. C'est lui qui écrit les lignes de code menant à une première version "exploitable" (ne serait-ce que par une preuve de faisabilité). Une fois cette version en ligne, d'autres développeurs et utilisateurs vont découvrir le projet et possiblement le rejoindre. Ainsi, une équipe se constitue. Cette équipe doit être dirigée, notamment par la mise en place d'un style de code, mais aussi par la mise en place de lignes directrices sur les nouvelles fonctionnalités à intégrer : en effet, les utilisateurs vont vouloir mille fonctionnalités qui ne sont pas toujours prioritaires ni même intéressantes et certains développeurs peuvent proposer ces fonctionnalités (ou d'autres).

Le créateur de projet qui n'était qu'un simple développeur devient un chef de projet. Certes pour les projets open source les contraintes ne sont pas équivalentes à celles d'un projet en entreprise, mais il reste nécessaire de mettre en place des règles et de prendre ce rôle pleinement.
Dans ce rôle, certains (Linus Torvalds en est un exemple) sont très stricts, mais n'est-ce pas grâce à cette direction claire et précise que le projet a pu réussir ?


Votre opinion

:fleche: Quelles sont les qualités du chef de projet nécessaires à l'aboutissement d'un projet libre ?
:fleche: Quelles sont vos expériences avec les projets open source et libres auxquels vous avez pu participer ?

Quelles sont les qualités du chef de projet nécessaires à l'aboutissement d'un projet libre ?

• Courage
• motivation
• patience

Quelles sont vos expériences avec les projets open source et libres auxquels vous avez pu participer ?
J'ai initié grâce notamment à developpez.com un projet de framework php que je fais évoluer depuis 2009: le mkFramework ;)

Je ne regrette pas cette aventure, si à l'époque j'avais décidé de garder ce projet pour mon utiisation personnelle,

• il n'aurait pas autant évolué
• j'aurais encore de nombreux bugs
• j'aurais abandonné faute de motivation à le maintenir

L'opensource c'est tout ça à la fois: une communauté qui se déssine et vous fait des feedbacks, critiques, proposent des axes d'amélioration, vous corrige des bugs...

Tout dépend de ce qu'on appelle aboutir. De manière générale, je doute qu'aboutir avec un code libre (philosophie de partage) ait la même signification qu'aboutir avec un code propriétaire (philosophie de profit). Selon que ce soit d'être numéro 1 sur le marché, ou de maximiser les bénéfices, ou de fournir un outil pour l'instant inexistant, chaque objectif exige des compétences associées, et celles-ci sont à adapter aux ressources disponibles et aux contraintes du projet/marché. En posant une question aussi générique, je doute que quiconque puisse apporter une réponse en dehors de généralités évidentes. Style la réponse ci-dessus.

Citation:

---

Envoyé par imikado

Quelles sont vos expériences avec les projets open source et libres auxquels vous avez pu participer ?
J'ai initié grâce notamment à developpez.com un projet de framework php que je fais évoluer depuis 2009: le mkFramework ;)

Je ne regrette pas cette aventure, si à l'époque j'avais décidé de garder ce projet pour mon utiisation personnelle,

• il n'aurait pas autant évolué
• j'aurais encore de nombreux bugs
• j'aurais abandonné faute de motivation à le maintenir

L'opensource c'est tout ça à la fois: une communauté qui se déssine et vous fait des feedbacks, critiques, proposent des axes d'amélioration, vous corrige des bugs...

---

Fais un projet proprio avec une équipe et tu y trouveras la même chose. Sauf que la communauté, c'est celle de l'entreprise (avec ses clients) plutôt que des contributeurs (et utilisateurs).

Soit. Pour moi, aboutir un projet open source, c'est compléter un besoin et faire en sorte que le résultat soit fonctionnel.
Par exemple (ce sont des exemples qui me sont connus), un émulateur comme Dolphin (GameCube, Wii), ou plus récemment Citra (3DS) ont aboutit (enfin, pour le second pas encore complètement). Ils remplissent l'objectif d'émuler une console et y arrive (émulation des jeux commerciaux).
Par contre, parallèlement à Citra, il y a eu 3DMoo. Les deux projets étaient sur GitHub et pourtant, 3DMoo n'a pas eu le même intérêt et est maintenant un projet oublié et arrêté (dernier commit datant du 15 février 2015). Celui-ci n'a donc pas abouti.

Si l'objectif est de faire un petit jeu perso, nul besoin de chef de projet par exemple. Donc j'imagine que tu ne parles que de gros projets. Parce que répondre à un besoin, ça va de l'individuel au général. Et si on cible uniquement les gros projets, ça réduit considérablement la liste.

Citation:

---

Envoyé par Matthieu Vergne

Fais un projet proprio avec une équipe et tu y trouveras la même chose. Sauf que la communauté, c'est celle de l'entreprise (avec ses clients) plutôt que des contributeurs (et utilisateurs).

---

Pas vraiment, comme beaucoup d'entre vous je développe des applications pour mes employeurs depuis des années

Mais ce que je remonte là n'est pas vrai pour les applis propriétaires

1. souvent aucune aide/critique de son code, on développe souvent un projet à 2-3 voir tout seul pour les petits projets
2. des années après (je rappelle que le projet date de 2009) peu de personne ose reprendre le projet pour le faire évoluer: si il y a du budget il sera redéveloppé, sinon uniquement bugfix
3. la volonté d'initier le projet*

* La différence est surtout ici:
si dans votre entreprise vous dites "ok je veux que l'on developpe notre propre framework", vous avez 2 chance sur 3 que votre manager/direction vous rembarre "pourquoi réinventer la roue ?"
En php on en a une multitude opensource avec des philosophies différentes de Zend framework, à Symfony en passant par codeIgniter, jelix ... pourquoi ? parce que n'importe qui peut initier un projet: si il a de la chance il sera suivi/utilsé.. et vivra sa vie, sinon il tombera dans l'oublie (et aura permis à son developpeur d'apprendre)

la page wiki des frameworks php https://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP

L'opensource c'est un peu comme kickstarter : tout le monde peut tenter sa chance, c'est la communauté qui fera le filtre ;)

Ta critique me semble concerner les petits projets, or depuis le temps que je fais des petits projets sur GitHub, les retours... la communauté... J'en vois pas la couleur. Faire des petits projets ou des gros projets, ce n'est pas la même chose, et les avantages que tu cites au dessus, je vois ça pour des gros projets libres, et en entreprise tu peux le retrouver (je dis pas que c'est systématique non plus, mais le libre non plus), alors que la critique est plus valable pour les petits projets d'entreprise, et encore une fois le libre n'y change pas grand chose de mon point de vue.

Un petit jeu vidéo, pour son plaisir ou simplement apprendre ne rentre certes pas dans cette catégorie, car personne ne s'y penchera vraiment (que ce soit sur le code ou, ne serait-ce que l'utiliser). Par contre, un petit jeu vidéo, qui a la volonté de se distribuer (disons les trois système d'exploitation classique), ou qui vise à être intégré dans une distribution sera confronté à deux choses :

• les directives d'intégration (package .deb par exemple) ;
• les possibles retours d'utilisateur (que ce soit par les intégrateurs, par les joueurs, ou ne serait-ce que pour supporter les nouvelles versions de distribution).

Et à partir de là, les gens commenceront à s'y intéresser, d'autres développeurs vont envoyer du code et ainsi de suite.

Donc, même un petit jeu vidéo peut être confronté à la problématique énoncée dans cette discussion.
Peut être la confusion est que j'utilise le terme "Chef de projet", alors que ce n'est pas adéquat pour ce type de projet. Toutefois, il faut toujours une personne qui soit là pour rassembler/ordonner les contributions.

Citation:

---

Envoyé par LittleWhite

Peut être la confusion est que j'utilise le terme "Chef de projet", alors que ce n'est pas adéquat pour ce type de projet. Toutefois, il faut toujours une personne qui soit là pour rassembler/ordonner les contributions.

---

Je pense qu'il doit y avoir de ça. Dans un projet libre où les fonctionnalités sont décidées au vote (il me semble qu'il y en a des gros comme ça), est-ce que la notion de chef de projet aurait encore du sens ? Je pense qu'on parle de quelque chose un poil différent. Si on parle de GitHub par exemple, il n'y en a qu'un qui rassmble/ordonne les contributions : le proprio du dépôt. Les autres font des pull request, et si le proprio n'en veut pas, ben c'est au contributeur à revoir ses commits.

Ouep, mais du coup, quel comportement le proprio du GitHub (et encore, il peut ouvrir les droits à d'autres membres) doit avoir pour que le projet aboutisse ? ( :aie: ).
Pour le système de vote, ce n'est pas le cas dans tous les projets.

Avez-vous croisé des projets qui n'ont pas fonctionné ? Pourquoi ?

Entreprendre un projet open source est pour moi de l'ordre de la profession de foi, car fédérer des compagnons de routes autour d'une ambition sans moyen financier (du moins au départ) avec des heures de travail au delà du raisonnable, une abnégation pour des résultats incertain et un chemin nécessairement jalonné d'échecs ... je dis chapeau, j'admire ces leaders du prochain siècle la plupart des technologies informatiques actuelles proviennent de ces projets menés à bout de bras par ces hommes déterminés.