Comment gérer la croissance d'un projet open source?


11

Je participe depuis un an ou deux au soutien d'un projet open source et le projet a gagné en popularité depuis que j'ai commencé. Le programme voit plus de 100 000 téléchargements par semaine et est utilisé par plus de 60% des personnes dans son domaine principal, nous sommes donc évidemment ravis que les gens aient tellement aimé l'utiliser.

Cependant, le problème est que la base de développement et de support n'a pas augmenté aussi rapidement, et nous commençons à souffrir de difficultés de croissance. La petite poignée de développeurs (le développeur principal en particulier) devient assez mince et les volontaires du support technique commencent à s'épuiser.

Jusqu'à présent, il s'agit à peu près d'un tas de mecs qui traînent sur IRC, écrivent ce programme et aident les utilisateurs. Il n'y a pas d'organisation 501 (c) (3) ou LLC ou quelque chose comme ça.

À l'heure actuelle, nous n'avons pas de base de suivi des bogues ni de base de données très formelle (nous avons un forum avec une catégorie dédiée aux rapports de bogues), ce que j'admets que nous pourrions améliorer pour obtenir plus de développeurs à bord. Mais je suppose que ma vraie question est: comment faire la transition d'un petit projet personnel à une vraie ... chose? Comment les grands garçons comme GIMP, FFmpeg, Blender, etc. ont-ils géré cette transition?

Et en plus de cela, existe-t-il un moyen d'offrir une compensation avec un projet FOSS? Je suppose que les dons aident, mais cela ne va que si loin ... il semble étrange de vivre du logiciel libre, mais si le programme continue de s'améliorer, je ne vois pas comment nous pouvons continuer sans indemniser les gens pour un travail à plein temps.

Fondamentalement, nous éprouvons des douleurs de croissance et nous nous sentons «trop gros pour nos Britches». Que pouvons-nous faire pour gérer cette transition et ne pas nous épuiser à faire trop de choses à la fois?


7
Tout d'abord, commencez par mettre en place un système de suivi des bogues approprié, aucune source ouverte ne survivra sans que l'équipe principale soit très bonne. Assurez-vous également que la direction des fonctions est claire et ne vous dérange pas.
ratchet freak

4
Si cela ne vous dérange pas de me demander, quel est le projet?
Robert Harvey

2
J'hésite à nommer le projet, en partie parce que c'est un peu effrayant d'aller là-bas et de dire aux gens "Hé, nous ne sommes pas vraiment sûrs de ce que nous faisons, et nous avons besoin d'aide!" De plus, je ne voulais pas que ce message soit une publicité pour aider avec le projet. Je suis sûr que quelques détours rapides sur Internet le révéleraient cependant. : /
Ben Torell

Réponses:


13

L'étape de votre projet est vraiment passionnante et cruciale, il est très facile de planter et de graver (mais c'est aussi) où vous pouvez prendre des décisions cruciales qui, si tout fonctionne, aideront à assurer la viabilité à long terme.

Voici quelques suggestions.

  • Lisez le grand livre de Karl Fogel Producing Open Source Software . Il couvre la plupart des grands problèmes immédiats. Bien que je ne sois pas d'accord avec tout ce qu'il dit, ce n'est qu'une opinion. Il comprend parfaitement le monde open source.

  • Comme l'a dit @Ross Patterson, vous devez absolument mettre en place un tracker et une liste de diffusion ou quelque chose de similaire afin d'éviter le chaos total. Qu'utilisez-vous pour le contrôle de version? Si vous êtes sur github, vous pouvez commencer avec leur tracker ou vous pouvez intégrer avec Jira ou quelque chose de similaire ou si vous voulez, vous pouvez aller à SourceForge pour l'instant et utiliser leur infrastructure gratuite. Vous ne dites pas d'où les gens téléchargent, mais vous voulez vous assurer que vous l'avez configuré de manière fiable et avec un bon décompte des téléchargements.

  • Il n'y a aucune raison pour laquelle vous ne pouvez pas gagner votre vie avec un logiciel libre si c'est ce que vous voulez, beaucoup de gens le font, mais cela prend beaucoup de formes différentes. Vous devez décider comment vous voulez le faire avant de prendre des décisions organisationnelles importantes. Par exemple, vous pouvez et devez probablement créer une société pour détenir la marque et les droits d'auteur, ce qui fournira également une protection juridique si nécessaire. Cependant, vous aurez besoin d'un président ou d'un trésorier. Le type d'organisation que cela devrait être (à but non lucratif ou à but lucratif, LLC, coopérative, partenariat) dépend vraiment de vos objectifs et doit être discuté avec un bon avocat. Si vous étiez accepté par Software Freedom Conservacy, ils vous aideraient à comprendre cela et à résoudre les problèmes comptables et fiscaux, etc. Il existe également quelques autres incubateurs FOSS tels queLogiciels dans l'intérêt public . De plus, je pense que Outercurve est une possibilité.

  • En termes de revenus, cela dépendra beaucoup de la nature de votre projet. C'est aussi pourquoi je ne sauterais pas immédiatement pour dire que vous avez besoin d'un 501c3 (et vous pourriez ne pas l'obtenir ... voir le projet Yorba). Blender se soutient principalement en vendant de la documentation. D'autres projets ont des écosystèmes de petites entreprises et / ou de conseil qui les entourent et les développeurs en tirent leur subsistance. D'autres projets ont des modèles de licence double, ils vendent donc des versions prises en charge (c'est pourquoi MySQL l'a fait et pourquoi il pourrait être vendu à Sun et bien sûr il y a RedHat) et ont une version communautaire distincte. D'autres comme WordPress ont la version hébergée comme modèle commercial. Il y a donc toutes sortes d'options et vous devez déterminer ce qui a du sens pour vous et votre communauté.

  • Choisissez quelqu'un pour être votre gestionnaire de communauté pour commencer. Et lisez le livre de Jono Bacon après avoir terminé celui de Fogel.

  • Décidez maintenant d'une feuille de route qui a du sens pour votre équipe principale; soyez réaliste et ne vous laissez pas intimider par des gens qui ne contribuent pas. La feuille de route ne signifie pas seulement les plans et fonctionnalités techniques, elle concerne où vous voulez aller en tant que projet.

  • N'hésitez pas à parler à d'autres projets que vous admirez ou qui sont d'ailleurs dans le même espace. Découvrez ce qui a fonctionné et n'a pas fonctionné pour eux. Envoyez simplement un e-mail. En outre, vous pouvez accéder à certains des événements généraux open source et simplement parler aux autres projets. Dans l'ensemble, les gens fossiles sont très utiles.

Bonne chance, c'est excitant d'être à ce stade.


Merci! Le code est déjà hébergé sur Github (qui est également l'endroit où les versions sont hébergées), mais nous n'aimons vraiment pas le tracker de problèmes de Github ... l'un des gars de l'équipe a de l'expérience avec Mantis, donc je pense que nous allons utiliser cette. Je vous entends également parler de la feuille de route ... à tout le moins, avoir une feuille de route publique sera bien juste de référer les utilisateurs à ceux qui réclament des fonctionnalités particulières, afin que nous puissions leur dire quand de telles fonctionnalités arrivent par rapport à d'autres fonctionnalités. J'explorais Outercurve plus tôt ce soir, et je vérifierai aussi les autres, ainsi que les livres. Merci pour l'encouragement!
Ben Torell

1
@BenTorell Je dis à tous ceux qui demandent: "Chaque traqueur de bugs est nul, la seule question est:" Lequel est le moins efficace par rapport à vos processus? "".
Ross Patterson

Ross a tout à fait raison. Je n'aime vraiment pas le tracker de Github pour un certain nombre de raisons, mais surtout son manque de véritable ACL. Je suis d'accord pour en trouver un qui correspond à vos processus. De nombreux trackers ne fonctionnent pas très bien pour les projets dirigés par des bénévoles, car ils font toutes sortes d'hypothèses qui ont du sens dans les environnements commerciaux, même dans le vocabulaire qu'ils utilisent. Bien sûr, parler de vos processus est un bon exercice. N'essayez pas d'utiliser un tracker pour apporter des modifications irréalistes à vos processus. Les choses sont vraiment différentes quand ce sont tous des bénévoles.
Elin

3

Les garçons vraiment grand mis en place tous les mécanismes que vous connaissez - ils exploitent de grandes fermes de serveurs, ils courent (parfois écriture) suivi de bogues et des systèmes de construction, etc. Ils ont souvent 501 (c) 3 fondations qui possèdent les droits d' auteur, etc. Ils obtenir de gros dons d'entreprises, et les entreprises leur prêtent des développeurs, etc. Vous savez, de GRANDES choses.

Les garçons pas si grands reçoivent beaucoup d'aide d'ailleurs. Le Software Freedom Conservancy , par exemple, aidera les projets de taille moyenne à obtenir leur fondement juridique et facilitera les dons. Il existe de nombreuses options pour l'hébergement de code et le suivi des bogues de nos jours - diable, n'importe qui peut obtenir un site GitHub. Et vous constaterez que de nombreuses petites et moyennes entreprises de logiciels feront don de licences pour leurs produits propriétaires pour soutenir des projets Open Source organisés - en particulier lorsqu'ils s'alignent sur leur entreprise d'une manière ou d'une autre.


3
Je n'essaie pas d'être pédant et je suis sûr à 100% que vous ne vouliez pas dire cela de manière négative, mais cela n'aide vraiment pas à accroître la participation à l'open source pour désigner les personnes impliquées en tant que garçons. Juste quelque chose à penser; Je sais que c'est une expression que les gens utilisent.
Elin

@Elin Répondant simplement à la question posée: "Comment les grands garçons comme GIMP, FFmpeg, Blender, etc. ont-ils géré cette transition?"
Ross Patterson

Oh, et +1 sur le commentaire - nous, les gars, devons nous rappeler de temps en temps. Cette entreprise est beaucoup trop centrée sur les hommes.
Ross Patterson

Merci et ouais je n'ai pas remarqué cette référence dans le post original.
Elin

Ouais, j'utilisais juste "gros garçons" comme tournure de phrase ... Je suppose que je n'y pensais pas de cette façon, mais je peux comprendre ce que tu veux dire. Merci pour le conseil! Ma priorité absolue en ce moment est d'obtenir un véritable suivi des problèmes que les contributeurs peuvent parcourir et, espérons-le, sélectionner un problème à résoudre (en ce moment, tout ce que nous avons est un tableau Trello en désordre). Comme je l'ai dit à @Elin, je me penche vers Mantis au lieu du système d'émission de Github. Je suppose que nous avons juste besoin de quelque chose à ce stade.
Ben Torell
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.