Réflexions et conseils pour faire – durer – un projet personnel ou communautaire

Dans un cadre professionnel, les contraintes de délais, de rendement, et rentabilité nous encouragent à faire atteindre aux projets le niveau de finalité escompté, ainsi qu’à maintenir l’effort aussi longtemps que ces contraintes puissent être surmontées avec les moyens disponibles.
Par contre, les projets personnels ou communautaires accomplis sur le temps libre des participants sont trés vulnérables face au découragement, ou la perte d’intêret, même quand on espère en tirer des subsides financiers. Les projets abandonnés sur SourceForge ne manquent pas pour le témoigner…

La principale cause de découragement n’est pas toujours la faible audience du projet ou le peu de contributeurs, il faut même se préparer à devoir s’y consacrer seul pendant plusieurs mois dans le plus parfait anonymat.

Il faut démarrer un projet personnel avant tout pour soi-même.

En fait, le ou les participants abandonnent un projet personnels quand ils n’y trouvent plus d’intêret pour leurs souhaits ou besoins personnels.
Le premier et plus important conseil est de – s’initier uniquement à des projets qui répondent dans l’immédiat à un besoin personnel – ou pour ceux de personnes « trés » prôches.

Par exemple, le langage de programmation PHP est né du besoin de Rasmus Lerdorf, son créateur, de pouvoir mettre à jour facilement son CV. Tandis que Y!M Plus a été créé pour aider des amis à installer des skins qui leur étaient destinés.

Un projet personnel est dirigé par ses participants, pas par sa popularité ou ses utilisateurs !

Paradoxalement, même si la popularité est au rendez-vous, et quand il n’y a pas d’intêrets économiques, il faut toujours donner la priorité aux attentes des participants plutôt que de vouloir satisfaire en premier lieu aux requêtes des « simples » utilisateurs .oO(c’est celà ou rien !)
Car le ou les participants sont le seul gage de durabilité d’un projet.

Optez pour l’équation : OS = uc²

Le secret du mouvement Open-Source (« OC ») est de permettre aux utilisateurs (« u ») de devenir des contributeurs (« c ») et de faire évoluer un projet communautaire pour ses propres besoins et d’inconsciemment décupler son potentiel de popularité qui multipliera les chances d’attirer d’autres participants…

Si les deux premiers principes paraissent méprisant envers les utilisateurs, ne perdez pas de vue, quand vous pensez être l’un d’eux, qu’ils impliquent que les participants sont eux aussi des utilisateurs et que leurs souhaits peuvent rejoindre les vôtres .oO(trivial, non ?)

Par exemple, le support matériel de Linux, le plus célèbre projet Open-Source, s’est beaucoup amélioré grâce à la volonté de quelques développeurs de pouvoir profiter de leurs périphériques personnels.

Faire face aux critiques dans l’intêret des participants.

Les contributeurs ne sont pas insensibles à la popularité de leurs apports, et souvent les deux vont de pairs pour donner de la vivacité à un projet. Inversement, les critiques sont souvent durement reçue car elles s’attaquent à des convictions personnelles des participants .oO(pensez s’y avant d’assassiner un projet personnel)

Quand on partage et publie un projet personnel ou communautaire, on doit admettre de négliger les critiques sévères de quelques utilisateurs qui concernent des aspects qui ont fait l’unanimité des contributeurs.

Par exemple, l’encyclopédie Wikipédia a été trés critiquée pour ses premières pages « figées » (c’est à dire dont l’édition est bloquée) suite aux trop nombreux vandalismes et « guerre d’édition » dont elles étaient victimes… Cette fonctionnalité avaient été réclamée par les « gros » contributeurs qui assument – volontairement – la plus grosse part des tâches de maintenance, dont la restauration des pages vandalisées.

Prendre de la distance, pour revenir plus intensément.

Si pour un projet professionnel, on a une obligation de résultat avec des délais précis, ce n’est pas le cas pour un projet personnel. Et, plutôt que de s’obstiner dans un projet pour faire face aux difficultés ou obtenir la popularité escompté, il est préférable de faire un « break » pour ne pas user sa motivation et gaspiller son temps libre à – tourner en rond -. Vous reviendrez surement avec des idées nouvelles ou une meilleure approche.

Toutefois, avant de mettre un projet en « standby », prenez le temps de le publier, d’expliquer ce qui a déjà été fait, ce qui reste à faire pour qu’il soit opérationnel, et les fonctionnalités envisagées… Des projets Open Source « endormis » sont souvent réactivé par l’intêret de nouveaux contributeurs.

Diversifier ses projets et les faire converger

Quand un nouveau projet est ambitieux et nécessitera plusieurs mois, voir même plus d’une année, vous avez tout intêret a le décomposer en sous-projets indépendants que vous publierez l’un après l’autre.

Attention, ne dispersez pas votre peu de temps libre de productivité en travaillant sur plusieurs projets (ou sous-projets) en même temps ; séquencez vos efforts en se consacrant exclusivement à un petit projet pendant une semaine, puis un plus gros le mois suivant, etc.

Adopter des outils d’organisation

Pour finir, on pense rarement à se doter d’outils d’organisation et de planification, à l’origine destinés à des professionnels, comme un bloc-note tel que EverNote qui vous évitera d’oublier des idées ou remarques intéressantes.
Et, songez également aux outils de veille technologique, tel ceux suggérés par Outils-Froids, pour suivre les initiatives dans les domaines qui concernent vos projets, et pour découvrir puis adopter des ressources qui répondent à vos besoins.