Comment gérer un projet populaire que vous ne souhaitez plus maintenir?
Je suis le responsable d'un projet qui a une large base d'utilisateurs non techniques. Je le maintiens depuis environ 4 ans maintenant et j'ajoute de nouvelles fonctionnalités comme elles ont été demandées.
J'aimerais passer à d'autres projets maintenant et arrêter de développer pour cette application. En raison de la nature non technique des utilisateurs, il y a eu très peu de contributions de code dans le passé. Je ne pense pas que je pourrai trouver quelqu'un d'autre pour reprendre le projet à ma place.
Bogues, problèmes, demandes de fonctionnalités - ils arrivent toujours. Je réponds toujours aux e-mails pour obtenir de l'aide, car je ne sais pas si je dois les ignorer, leur dire que je ne travaille pas sur l'application ou si je dois répondre aux e-mails dans certains cas uniquement.
Quelle est la meilleure façon d'abandonner ce projet tout en laissant les utilisateurs utiliser l'application?
Mise à jour (juillet 2016) - Cela ne s'est pas passé comme prévu. J'ai fait une annonce dans le README et peu de temps après, j'ai commencé à recevoir des contributions de nature plus substantielle. Tirez des demandes avec des corrections de bugs, des fonctionnalités, de la documentation, une activité de problème. Depuis lors, le projet s'est senti "revigoré" et je suis maintenant heureux de le maintenir avec de nouveaux projets. J'ai aussi des collaborateurs. À mon avis, c'est peut-être le type de contributions qui a affecté ma vision du projet et la qualité des contributions s'est améliorée, cela ne ressemblait plus à une corvée.
Je suppose que ce n'est pas un projet sur un lieu de travail où vous êtes un employé rémunéré et quelque chose que vous faites gratuitement pendant votre temps libre?
Si vous ne gagnez pas d'argent avec cela, alors il n'y a clairement aucune incitation pour vous, et aucune incitation pour que quelqu'un d'autre vienne à frais pour y faire face. (sauf s'il s'agit peut-être d'un organisme de bienfaisance ou d'une organisation bénévole similaire)
Comme alternative, pourquoi ne pas envisager la possibilité d'ajouter des fonctionnalités payantes.
De cette façon, vous pourriez être incité à continuer. Vous pourriez trouver des gens prêts à payer, surtout lorsque l'alternative est que le système cesse d'être développé activement. (bien sûr, les gens peuvent abandonner votre système, mais qu'importe, vous n'êtes pas déjà payé).
Une autre option pourrait être d'utiliser le projet pour apprendre de nouvelles technologies? Est-ce un site Web? Passer à la dernière technologie? Convertir d'Asp.Net en MVC4 par exemple? créer une version mobile, la rendre basée sur les services et créer une application frontale iOS pour elle?
Annoncez votre abandon du produit à votre communauté d'utilisateurs. Vous trouverez peut-être un successeur pour votre rôle de mainteneur. Essayez d'organiser un certain temps de transfert, comme vous le feriez avec un projet dans votre travail de jour.
Comme le dit esr dans La cathédrale et le bazar :
Lorsque vous vous désintéressez d'un programme, votre dernier devoir est de le remettre à un successeur compétent.
Une autre suggestion pour vous, qui est légèrement à l'opposé de ce que vous demandez, mais je pense que cela devrait être dans votre liste pour examen. Avez-vous envisagé de ne pas l'abandonner? Si vous avez un projet pour lequel des personnes utilisent activement et ont des exigences croissantes, mais ne sont pas en mesure de le modifier elles-mêmes et que vous êtes le seul expert du logiciel ... alors vous êtes en mesure de leur facturer de l'argent.
Si la source est ouverte, vous pouvez envisager de la fermer (votre choix si vous voulez étouffer la concurrence en développant davantage le projet). Lorsque la prochaine demande de fonctionnalité arrive, dites oui pour des frais de $ xyz.
Juste une option à considérer.
Il est difficile d'abandonner votre base de fans, surtout lorsque vous êtes différent d'eux. S'il y avait des développeurs dans le groupe d'utilisateurs, ce serait un problème facile à résoudre: il suffit d'annoncer votre sortie imminente et de suggérer que quelqu'un d'autre intervienne, en proposant de les aider à se mettre au courant avant de partir. Puisqu'il n'y en a pas, la question est vraiment la suivante: pouvez-vous (ou vos utilisateurs) trouver quelqu'un pour vous remplacer dans un délai qui vous convient (ou vos utilisateurs).
Dans le passé, j'ai maintenu plusieurs projets pendant des années plus longtemps que je ne le souhaitais, car c'était bon pour ma réputation. Ma stature, si petite soit-elle, dans mon domaine m'a aidé à trouver un emploi quand j'en avais besoin ou voulu, et cela a de la valeur pour moi. Assez de valeur pour que cela vaille la peine de mettre mon temps quand je le pouvais. Finalement, bien sûr, je suis parti, mais je me suis assuré que le code de projet complet était disponible pour tous les successeurs.
Voulez-vous abandonner le projet parce que ...
vous ne voulez plus le faire?
Ensuite: Arrêt gracieux ala Reader.
Ou ... embaucher un développeur (continuer ci-dessous)
Ou parce que vous perdez de l'argent?
Calculez les frais remboursables (et continuez ci-dessous)
Ou parce que vous ne gagnez pas d'argent?
Calculez combien vous devez gagner pour que vous vous sentiez différemment:
- les menues dépenses doivent être couvertes
- coût d'un développeur pour poursuivre le développement
- une marge bénéficiaire
Soyez honnête avec vos utilisateurs: expliquez-leur qu'il faut un certain temps, de l'énergie, etc. pour maintenir le service.
Demandez ensuite des dons et/ou facturez existants fonctionnalités. N'essayez pas d'inventer des fonctionnalités premium qui ne font que retarder la détermination de la pertinence du service pour qu'il se soutienne. Allez simplement avec les fonctionnalités dont vous disposez.
Si les utilisateurs râlent bien, ils peuvent aller ailleurs. S'il n'y a pas assez de dons et/ou d'inscriptions, arrêtez-vous.
Soyez brutal - une fois que vous avez débranché la fiche, ne regardez pas en arrière.
Vous avez quelques options comme d'autres l'ont noté. Mon option est de publier un avis de fin de vie. Indiquez que le produit va s'arrêter à telle ou telle date.
Indiquez en outre que, comme ce produit touche à sa fin de vie, seuls les bogues critiques qui affectent la capacité de l'application à fonctionner comme prévu ou prévu seront traités. C'EST À DIRE. si le serveur est en panne, vous le réactiverez.
Si les utilisateurs ont des données, vous devrez peut-être leur ajouter un moyen de les exporter.
Jetez un œil à ce que Google a récemment fait avec Reader pour obtenir des conseils. Ils l'ont fermé et c'était un service très populaire, mais cela ne correspondait pas à leurs objectifs à long terme, donc la décision difficile de le fermer devait être prise.
Une sorte de mesure à mi-chemin est-elle une solution possible? Poursuivre le projet mais réduire votre charge de travail?
Par exemple, vous dites que vous répondez toujours aux e-mails pour obtenir de l'aide. Pouvez-vous mettre en place un forum d'utilisateurs et insister pour que toutes les demandes d'assistance soient effectuées par ce biais afin que d'autres utilisateurs expérimentés puissent vous aider?
Vous avez inclus le open-source tag, donc je suppose que votre projet est un logiciel open source.
il y a eu très peu de contributions de code dans le passé
C'est malheureux, mais compréhensible au cas où vous feriez tout. De nombreux utilisateurs ne s'impliquent pas tant que cela fonctionne raisonnablement.
Certains dirigeants aiment déléguer toutes les responsabilités, et certains dirigeants aiment garder un contrôle plus strict. Bien qu'un équilibre soit nécessaire, déléguer dès que possible est la clé ici.
J'ai créé plus de 30 projets open source, et beaucoup sont toujours actifs même si je les ai laissés. Voici ce que je recommanderais:
Accordez un accès TRÈS généreusement à l'outil de suivi des bogues, peut-être à toute personne ayant déjà contribué une ligne de code. Si quelqu'un commence à faire des choses folles (très faible probabilité), vous avez toujours le contrôle administrateur pour les supprimer. N'oubliez pas de donner d'autres droits: contrôle du code source, wiki, traduction de foule, page facebook, compte Twitter, site officiel, google analytics, etc.
Poster dans le forum (et avis sur le site Web) annonçant votre départ à la retraite et à la recherche d'un nouveau chef de projet.
Même si personne n'intervient en tant que chef d'équipe, des problèmes fatals qui pourraient survenir (exemple stupide: une URL codée en dur devient 404, faisant planter l'application au démarrage), elle sera probablement corrigée par quelqu'un. Si personne ne corrige des failles fatales, cela signifie que vous ne devriez plus trop vous inquiéter, vous avez fait ce que vous pouviez, mais le projet ne semble plus viable.
Bien passer au pur payé tuera beaucoup d'utilisateurs, mais il existe de nombreuses alternatives au pur payé. Un jeu vidéo auquel je joue offre aux donateurs des avantages supplémentaires comme plus de téléchargements par heure "un jeu basé sur les compétences, à ne pas confondre avec le salaire pour gagner des ordures lol". Un autre jeu Path of Exile propose des améliorations cosmétiques. D'autres sites mettent des sondages en échange de la bande passante. Le codeur de dons donne aux utilisateurs gratuits des licences pour (X Time) renouvelables plusieurs fois comme ils le souhaitent, mais les donateurs obtiennent des licences permanentes.
Il y a des tonnes d'options qui le proposent pour de l'argent, mais gardent également les utilisateurs gratuits.
La plupart des gens n'ont aucun problème à soutenir quelque chose qu'ils aiment, alors honnêtement, j'essaierais simplement de demander d'abord en définissant une zone de pourboire calculée pour couvrir vos coûts mensuels.