Peur de libérer un projet de loisir - comment surmonter [fermé]

Je ne sais pas si cette question est strictement liée au développement logiciel, mais je vais quand même essayer:

Comme beaucoup de programmeurs, j'aime travailler sur des projets de loisir. Parfois, apparemment, les bonnes idées s'avèrent être moins bonnes, alors je laisse tomber le projet. Mais parfois, quelque chose d’utile découle du projet. Donc, je pourrais le libérer, le présenter au monde, non?

Faux. D'une certaine manière, je ne semble pas être capable de faire cette étape. Je crains que mon code ne soit pas assez bon, je peux toujours penser à des choses qui ne sont pas optimales, à des fonctionnalités qui pourraient être ajoutées. Donc, je ne lâche rien, je perds mon intérêt et, à un moment donné, abandonne le projet.

Est-ce normal? Comment surmontez-vous une telle situation?

Tout d'abord, rappelez-vous: l' expédition est une fonctionnalité . Il vaut mieux libérer quelque chose d'imparfait que de ne rien libérer du tout.

L'autre chose à noter est que ce sont des projets de passe-temps. Si vous ne respectez pas les délais ou si vous perdez tout intérêt, ce n'est pas grave. Vous faites le projet pour le plaisir après tout.

Mettez-le là-bas.

Ce n'est pas si difficile à faire avec un site de codage social tel que GitHub ou Bitbucket . La plupart des éléments de ce que vous allez publier ne seront probablement pas beaucoup utilisés, mais c'est correct. C'est à peu près normal dans ces sites de codage social, et beaucoup de projets sont abandonnés (même certains utiles). Mais le plus important, c’est que d’autres personnes puissent récupérer ce que vous avez laissé (étant donné que vous avez une licence permissive).

Même si vos documents ne seront probablement pas utilisés par quelqu'un d'autre, il y a plusieurs avantages à les expliquer:

• Vous apprendrez à utiliser le contrôle de version, ce que beaucoup de programmeurs ne savent pas comment, ce qui vous rend plus désirable.
• Les gens peuvent signaler des problèmes pour vous; toutes les occasions pour vous d'apprendre à faire les choses différemment
• Vous aurez un portfolio en ligne de choses que vous avez faites, ce qui est bien d'avoir comme complément à votre CV.

Obtenir des contributeurs dans un projet open source qui est déjà exempt de bogues est probablement plus difficile que ceux avec beaucoup de bogues faciles à résoudre, car ces bogues incitent les premiers utilisateurs à se familiariser avec le code.

Lorsque Linus a introduit le noyau Linux pour la première fois, il ne s’agissait pas d’un code complet, stable, clair et sans bogues; c'était un clavier incomplet, de mauvaise qualité, inutilisable et câblé pour le clavier finlandais .

En gros, je ne m'inquiéterais pas si les gens aiment mon code ou non. Publiez-le sous licence libre, si cela est utile pour les utilisateurs, mais ils trouvent des bogues, des solutions sous-optimales et ont besoin de plus de fonctionnalités. Ils sont libres de le réparer eux-mêmes. L'utilisation de GPL ou de LGPL vous permettra également de trouver ces corrections et de les appliquer vous-même si vous les trouvez utiles / appropriées.

Je suis désolé mais vous faites exactement le contraire de ce que vous devriez faire!

Publiez-le dès que possible, écoutez les réactions des utilisateurs, puis implémentez une nouvelle fonctionnalité basée sur celle-ci. Pas l'inverse!

Qu'avez-vous à perdre ?

Vous pouvez également vous consoler en sachant que cela ne sera probablement pas remarqué de toute façon, à moins que ce soit vraiment bon ou occupe un nouveau créneau.

Et si vous obtenez un retour négatif, vous aurez une chance d'apprendre. Ne le gaspillez pas.

Complètement normal, dans tous les domaines autres que les logiciels. Assurez-vous qu'il soit construit dans quelques environnements différents, écrivez un fichier README et lancez-le dans github / codeplex / etc. Passer à travers cela la première fois est le seul moyen de surmonter l’anxiété.

Deuxième, troisième et nième fois, l’amusement réside!

Voici une raison de publier un logiciel inachevé: pour commencer à créer une communauté. Si vous souhaitez que votre projet devienne un outil open source utile, vous avez besoin d'autres développeurs. Une façon de les attirer est de le publier tôt, puis de continuer (publiquement) à apporter des améliorations. N'ajoutez pas ces fonctionnalités en secret - faites-les publiquement, sur la page Github ou ailleurs. Cela génère de l'activité dans l'histoire.

D'autres développeurs ne veulent pas travailler sur un projet apparemment abandonné. Votre travail de développement en public démontre donc un intérêt actif et continu. Il est judicieux de garder intentionnellement quelques fonctionnalités pour pouvoir les ajouter en public.