Lancement trop tôt d'un logiciel open source
Quelle est la responsabilité morale de publier trop tôt un logiciel open source? Par exemple, un produit presque complet qui n'a pas été entièrement testé.
Quelle est l'attente du programmeur? Attendez qu'il soit entièrement testé ou libérez-le pour l'open source, puis continuez le développement, les tests et les avancées?
La crainte est que les logiciels soient open source et pourraient potentiellement entraîner des problèmes pour les consommateurs.
Est-ce une crainte non fondée?
Je pense 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 au moins publier le code source très tôt et en continu (par exemple en appuyant fréquemment sur github ), sans faire des versions formelles .
Cependant, il est très important de le marquer comme stade alpha ou bêta, et si possible de dire (par exemple dans un fichier README ou TODO, et sur un blog, etc ...) quoi est manquant, non testé ou en mauvais état. Vous devez également utiliser le numéro de version pour transmettre ces informations.
Avec logiciel gratuit , le mieux qui puisse arriver est que quelqu'un jette un œil au code source et vous propose un petit patch 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 gratuit! Les contributeurs externes seraient énervés si leur correctif ne fonctionnait pas avec ou était un doublon de votre code source logiciel récent.
Ce dont vous devriez avoir peur, c'est que personne ne s'intéresse à votre logiciel (et n'y contribue). Attirer un intérêt extérieur vers un logiciel libre (en particulier, attirer des contributeurs externes) est un long voyage.
TL; DR:
Libérez tôt. Libérez souvent.
Anecdote personnelle:
J'étais vraiment excité par le projet sur lequel je travaillais. Genre, vraiment excité. Je ne pouvais pas dormir la nuit excitée. 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. Quelques adopteurs précoces ont même soumis des bogues que nous n'aurions 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 que nous aurions pu faire. Il a mis notre produit devant de vrais utilisateurs. En faisant ces bogues exposés, nous pouvons ou non avoir trouvé et amélioré notre projet. Cela a également permis à ces premiers adoptants de savoir que nous sommes sérieux au sujet de ce projet. Il y aura plus de versions et de développement actif.
Cela aurait pu facilement aller dans l'autre sens aussi. Nous aurions pu ignorer ces rapports de bogues. Ou nous n'aurions pas pu réagir rapidement. Cela aurait pu être une autre histoire s'il nous avait fallu 3 mois pour sortir la v1.1 au lieu de quelques semaines.
C'est la même chose qu'avec les logiciels à source fermée. La communication est importante.
Informez les utilisateurs de l'état du logiciel et des raisons pour lesquelles il est disponible en téléchargement.
Le logiciel entraînera toujours des problèmes pour le client, qu'il soit entièrement testé ou non. La plupart des clients acceptent ce fait et certains ne le font jamais. Mais si le logiciel entraîne plus de problèmes que ce à quoi on pourrait raisonnablement s'attendre, il existe une obligation morale d'informer le client du risque qu'il prend. Les informations doivent être à la fois sous forme abrégée (étiquettes "Alpha/Beta/EarlyAccess") *, et en détail: une liste des problèmes connus, des solutions de contournement et des considérations spéciales, par ex. s'il est probable que les données peuvent être corrompues.
* Sachez que les utilisateurs ont été formés par certaines grandes sociétés de logiciels à considérer la "Bêta" comme un état où le logiciel est plutôt solide, donc dire à l'utilisateur que le logiciel est "Bêta" n'est souvent pas une information suffisante.
Il n'y a aucune responsabilité morale. Personne n'est obligé d'utiliser votre logiciel à moitié cuit.
La seule chose à craindre serait votre crédibilité.
D'après mon expérience, 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 voir de code) avec un développeur qui produit ce qui semble être un projet FOSS très excitant qui utilise le code que j'ai écrit. La publication a été retardée à plusieurs reprises par la réalisation de modifications de conception qui amélioreront le projet à long terme, mais qui nécessitent d'importantes réécritures de code qui ont déjà été écrites et qui fonctionnaient déjà. Mon opinion est que, si une version fonctionnelle mais imparfaite avait été faite dès qu'il y avait quelque chose à montrer, des idées de changements (et de correctifs réels) auraient pu émaner de la communauté plus large intéressée par ce projet et l'avoir accéléré plutôt que d'avoir les problèmes apparaissent lentement, un par un, à mesure que le développeur y pense et demande des commentaires sur la conception de moi-même et d'autres membres intéressés de la communauté. Donc, de ce point de vue, je suis un ardent défenseur de la "libération anticipée, libération fréquente".
D'un autre côté, des versions de mauvaise qualité peuvent faire mal paraître un nouveau projet avant même qu'il ne décolle. Voici certains pièges que j'ai vus:
- Arbres squelettes avec définitions d'interface mais pas de code.
- Code qui ne se compile pas correctement pour quiconque sauf le développeur.
- Aucune instruction sur la façon de construire/exécuter le programme.
- Aucune documentation sur les aspects susceptibles de fonctionner.
- Description imprécise de ce que le programme fait ou fera même.
- Absence de toute 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.
- Émulateur qui ne peut pas au moins exécuter un exemple de programme quelconque ou démontrer autrement 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 d'autre qu'un écran de titre.
Ces types de problèmes prêtent à une image "vaporware" qui peut être difficile à secouer à moins que vous ne soyez très ouvert sur le manque de code de travail pour commencer.
Enfin, donnez un sens à vos numéros de version. N'appelez pas votre projet "1.0" jusqu'à ce qu'il fasse ce que les utilisateurs attendent de lui sans se bloquer. J'ai toujours eu la chance d'utiliser des numéros de version autour de "0.5" pour la première version publique et de partir de là, mais j'ai également 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 au public à condition que toutes les implémentations distribuées au public soient entièrement conformes à la spécification lors de leur 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 devez la partager avec personne jusqu'à ce qu'elle passe tous les tests. Cela impose un "modèle cathédrale" (comme l'appelait Eric S. Raymond) sur les implémentations de la spécification.
Une spécification sous une telle licence est la Java Language Specification . Cette restriction s'applique aux développeurs de machines virtuelles compatibles avec la JVM, mais heureusement pas aux développeurs d'applications qui s'exécutent dans une JVM.
L'article " 4 Shifty Details About Microsoft's 'Open Source' .NET " par Liu Qihao & Ciaran O'Riordan mentionne la possibilité d'interpréter le Microsoft Patent Promise for .NET Libraries and Runtime Components pour 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.