Libérer le logiciel open source trop tôt [fermé]

Quelle est la responsabilité morale de publier un logiciel open source trop tôt? Par exemple, un produit presque complet qui n'a pas encore été testé.

Quelle est l'attente du programmeur? Attendez-vous à ce qu'il soit entièrement testé ou passez-vous au format open source, puis poursuivez-vous le développement, les tests et les avancées?

La crainte est que les logiciels soient à source ouverte et pourraient potentiellement poser problème aux consommateurs.

Est-ce une peur sans fondement?

Je crois au contraire que vous devriez publier un logiciel open source dès que possible. Il n'y a pas de "trop ​​tôt" pour cela (mais il devrait compiler).

^{Ou du moins, publiez le code source très tôt et de manière continue (par exemple, en appuyant fréquemment sur github ), sans effectuer de publication officielle .}

Cependant, il est très important de marquer comme stade alpha ou bêta, et si possible de dire (par exemple dans un READMEou TODOfichier, et sur certains blog, etc ...) ce qui manque, non testé, ou en mauvais état. Vous devez également utiliser le numéro de version pour transmettre ces informations.

Avec le logiciel libre , le meilleur qui puisse arriver est que quelqu'un jette un coup d'œil dans le code source et vous propose un petit correctif pour l'améliorer. C'est pourquoi vous rendez votre logiciel gratuit!

^{Par conséquent, vous devez rendre visible votre travail quotidien sur votre logiciel libre! Les contributeurs externes seraient énervés si leur correctif ne fonctionnait pas ou était une copie de votre code source logiciel récent.}

Ce que vous devriez avoir peur, c’est que personne ne s’intéresse à votre logiciel (et qu’il y contribue). Attirer l’intérêt extérieur pour un logiciel libre (en particulier attirer des contributeurs externes) est un long voyage.

TL; DR:

Libérer tôt. Relâchez souvent.

Anecdote personnelle:

J'étais vraiment enthousiasmé par le projet sur lequel je travaillais. Comme, vraiment excité. Je ne pouvais pas dormir la nuit excité. J'ai donc poussé mon co-développeur à publier la v1.0 plus rapidement qu'il ne le voulait.

C'était terrible. Rien ne fonctionnait comme prévu. Il y avait des bugs à chaque tour, mais nous les avons enregistrés et corrigés. Nous avons même eu quelques utilisateurs précoces qui ont soumis des bugs que nous n’avions peut-être pas trouvés. Une semaine ou deux plus tard, nous avons publié une nouvelle version qui traitait de nombreux problèmes, puis nous sommes revenus à la création de nouvelles fonctionnalités.

Sortir tôt était la meilleure chose à faire. Cela met notre produit devant de vrais utilisateurs. Faire cette bugs exposés nous avons pu ou non trouvé et amélioré notre projet. Cela a également permis aux premiers utilisateurs de savoir que notre projet était sérieux. Il y aura plus de versions et de développement actif.

Cela aurait pu facilement être inversé aussi. Nous aurions pu ignorer ces rapports de bugs. Ou nous n'aurions pas pu réagir rapidement. La situation aurait pu être différente si nous avions mis 3 mois pour publier la version 1.1 au lieu de quelques semaines.

C'est la même chose qu'avec un logiciel à source fermée. La communication est importante.

Informez les utilisateurs de l'état du logiciel et des raisons pour lequel il est disponible au téléchargement.

Les logiciels susciteront toujours des problèmes chez les clients, qu'ils soient entièrement testés ou non. La plupart des clients acceptent ce fait, et certains clients ne le font jamais. Mais si le logiciel entraîne plus de problèmes que prévu, il existe une obligation morale d'informer le client du risque qu'il prend. Les informations doivent être à la fois abrégées (libellés "Alpha / Beta / EarlyAccess") * et en détail: liste des problèmes connus, des solutions de contournement et des considérations spéciales, par exemple, s'il est probable que les données puissent être corrompues.

* Sachez que certains grands éditeurs de logiciels ont formé les utilisateurs à considérer la "version bêta" comme un état dans lequel le logiciel est assez solide. Par conséquent, informer l'utilisateur que le logiciel est "bêta" ne constitue souvent pas une information suffisante.

Il n'y a aucune responsabilité morale que ce soit. Personne n'est obligé d'utiliser votre logiciel à moitié cuit.

Votre seule préoccupation serait votre crédibilité.

Mon expérience est qu'il y a un équilibre à atteindre.

En ce moment, je travaille (dans le sens de répondre aux questions et de fournir des suggestions de développement, sans rien voir de code) avec un développeur qui produit ce qui semble être un projet FOSS très intéressant utilisant le code que j'ai écrit. La publication a été retardée à plusieurs reprises par des modifications de conception qui amélioreront considérablement le projet à long terme, mais qui nécessitent d'importantes réécritures de code déjà écrit et qui fonctionnait déjà. Mon point de vue est que si une publication efficace mais imparfaite avait été réalisée dès que quelque chose fonctionnait, les idées de changements (et les correctifs actuels) auraient pu émaner de la communauté plus large intéressée par ce projet et l'avoir accéléré au lieu de l'avoir les problèmes surgissent lentement, un à la fois, en tant que développeur, pense à eux et demande des commentaires sur la conception de ma part et des autres membres de la communauté intéressés. Donc, de ce point de vue, je suis un fervent défenseur de la "libération anticipée, de la libération fréquente".

D'autre part, des versions de faible qualité peuvent donner à un nouveau projet une mauvaise image avant même qu'il ne soit lancé. Certains pièges que j'ai vus incluent:

• Arbres squelettes avec des définitions d'interface mais pas de code.
• Code qui ne se compile pas avec succès sauf pour le développeur.
• Aucune instruction sur la façon de construire / exécuter le programme.
• Aucune documentation sur les aspects susceptibles de fonctionner.
• Description peu claire de ce que le programme fait ou fera.
• Absence de démonstration d’utilité.

Pour le dernier point, je pense à des choses comme:

• Compilateur / interprète qui ne peut même pas compiler / exécuter un programme de type hello-world.
• Un émulateur qui ne peut pas au moins exécuter un exemple de programme ou démontrer de quelque manière que ce soit qu'il fait quelque chose.
• Outil de traitement d'image qui ne peut rien faire d'autre que charger et réenregistrer l'image non modifiée.
• Jeu avec rien mais un écran de titre.

Ces types de problèmes donnent une image de "vaporware" qui peut être difficile à éviter sauf si vous êtes très ouvert sur le manque de code fonctionnel.

Enfin, donnez du sens à vos numéros de version. N'appelez pas votre projet "1.0" tant qu'il ne répond pas aux attentes des utilisateurs sans planter. J'ai toujours eu de la chance avec l'utilisation de numéros de version autour de "0.5" pour une première publication publique, mais j'ai aussi vu des choses comme "0.1" ou "0.10" qui ont du sens.

Il y a un cas où la publication de logiciels libres peut avoir des conséquences négatives. Certaines spécifications sont concédées sous licence publique à la condition que toutes les mises en œuvre distribuées au public soient entièrement conformes à la spécification lors de la première publication. L'éditeur vous interdit légalement de distribuer une implémentation en cours de la spécification. Sans une licence négociée spécifique de l'éditeur de la spécification, vous ne devez la partager avec personne jusqu'à ce que tous les tests soient réussis. Cela oblige un "modèle cathédrale" (comme l’appelait Eric S. Raymond) pour la mise en oeuvre de la spécification.

Une spécification sous une telle licence est la spécification du langage Java . Cette restriction s’applique aux développeurs de machines virtuelles compatibles avec la machine virtuelle, mais heureusement pas aux développeurs d’applications exécutées dans une machine virtuelle.

L'article de Liu Qihao et Ciaran O'Riordan, intitulé " 4 détails décalés sur le logiciel Microsoft" Open Source "de Microsoft, mentionne la possibilité d'interpréter la promesse de brevet de Microsoft pour les bibliothèques .NET et les composants d'exécution afin d'exclure les implémentations incomplètes du CLR de manière similaire. . Mais encore une fois, cela ne s'applique pas aux applications qui s'exécutent dans le CLR.