Forker, reproduire ou distribuer un projet?

Je parlais hier avec @zenos de la meilleure façon de redonner du souffle au projet DPF.

On a un peu parlé de la « project rescue team » évoquée récemment par @antoine.selosse, ce qui a amené la question du risque de « détournement » du projet initial.
Plutôt que de voir arriver une équipe « arrachant » le projet à l’équipe initiale (notamment parce que plusieurs centaines d’euro de composants ont été acquis par l’Electrolab pour le projet), Zenos est fortement de l’avis de « forker » le projet, en reprenant les actions recommandées dans l’étude publiée à la base du projet, et de reproduire et améliorer le moteur dans différents tiers-lieux de production collaborative, et ensuite de publier.

Ce qui amène en fait à un constat : certains projets, composés de multiples briques, sont particulièrement adaptés à un mode de fonctionnement distribué (Ad Astra, Marsproof, Dryade…) tandis que d’autres sont plus adaptés à un fonctionnement sur un seul site (DPF, EmCubeSat, SEE…). Dans le premier cas, l’objectif sera de correctement gérer la répartition des sous-systèmes et la capacité d’intégration finale, tandis que dans le deuxième, il sera de reproduire un même système à plusieurs endroits en vérifiant ainsi reproductabilité, fiabilité et amélioration incrémentale.
On peut se dire que c’est tout simplement une question de « est-ce qu’on parle d’un sous-système assez miniature pour pouvoir être réalisé par une équipe de quelques personnes dans un fablab » ou est-ce que c’est un système complexe qui va faire appel à de multiples sous-systèmes correspondant au point précédent". Intuitivement ça ne me semble pas aussi tranché que ça : par exemple, on peut imaginer sur l’EmCubeSat une équipe se focalisant dans un lab sur la cavité, et une autre à un autre endroit sur la structure et la communication. Ou sur SEE, une équipe se focalisant sur la méca, une autre sur les capteurs et l’électronique d’interprétation. Etc.

Il me semble en tous cas que cette discussion est importante pour bien comprendre comment traiter au mieux la répartition géographique des projets. Des idées et avis sur le sujet ?

2 « J'aime »

Ton idée de vérifier la reproductibilité d’un projet sur un autre site est très intéressante. C’est un test pour vérifier l’exhaustivité de la documentation, d’un part, et de vérifier que le transfert sur d’autres machines de production donne un même résultat.

Pour les systèmes plus complexes, je suis d’accord avec toi que l’intégration est un point crucial ; pour reprendre une partie des discussions avec @zakaria.elqotbi de samedi dernier, l’utilisation du BGC sur un lanceur d’essai fait remonter cette question.

Dans l’idée d’une « rescue team », je pensais plus à de l’aide méthodo plutôt que technique pure, justement pour éviter le détournement. Parfois, un peu de sang frais redonne du souffle à l’équipe.

1 « J'aime »

L’idée me semble très bonne, avoir une liste de mentor/référent/conseiller à appeler pour avoir de l’aide et du soutien permettrais de débloquer situations conflictuelles et les « paliers de développement » que peuvent rencontrer les projet.

Paliers de développement souvent critiques pour un projet (basé sur mon humble expérience):

  • Equipe à plus de 8 personnes -> Necessité de méthode de travail adaptées
  • Départ d’un membre moteur de l’équipe -> Perte de motivation des acteurs
  • Arrivé d’une autre équipe sur un deuxième site -> Nécessité de nouvelles méthodes de travail
  • Travail à distances de tous les membres -> Très compliqué pour la pérénisation du projet
  • Echec d’un essai / destruction importante de matériel -> Motivation
  • Attaque en règle (ou non) par des détracteurs -> Motivation + AIde en communication
1 « J'aime »