A quoi faut-il penser lorsqu'on rend un projet open source ?

Question

Je suis sur le point de publier un projet en tant que source ouverte, et j'aimerais vraiment avoir un retour sur certaines choses :

1. Le code est assez propre mais l'historique du contrôle de version ne l'est pas. Erreurs, code de débogage, code peut-être inapproprié, etc. Dois-je effacer l'historique avant de publier, ou l'importer quand même dans le dépôt public ?

2. Dois-je donner la priorité à la réalisation d'un tutoriel, à l'explication des fonctionnalités ou à la documentation de l'API ?

3. D'autres idées qui rendent un nouveau projet facile à mettre en œuvre pour les gens ?

Answer 1

A mon humble avis :

1) Si vous avez l'intention de vous lancer dans l'open source, soyez fier de votre code. Nous savons tous qu'il y a des erreurs et des bogues en cours de route. Il y en aura d'autres, aussi, alors ne vous sentez pas obligé de les afficher publiquement. Vous le pouvez !

2) Définitivement. Probablement aussi dans cet ordre, car c'est dans cet ordre que les personnes qui utilisent votre produit vont les lire. Ils devront utiliser votre logiciel avant de décider de travailler dessus.

3) Le meilleur conseil que je puisse donner est d'avoir des instructions de construction claires, avec si possible des scripts pour aider les gens à configurer l'environnement. Un fléau commun avec les logiciels open source est d'exiger des nouveaux développeurs de télécharger des tonnes de bibliothèques et de configurer leur boîte pour fonctionner . juste ce qu'il faut afin d'être en mesure de construire le logiciel. Pour moi, c'est très frustrant et cela peut me décourager très rapidement.

Bonne chance !

Answer 2

1. C'est votre choix, à moins que vous n'utilisiez un code protégé par des droits d'auteur dont vous n'avez pas les droits de distribution ou qu'il y ait un problème de redistribution, de crédit ou autre.

2. Difficile à dire sans savoir ce que c'est. De quoi auriez-vous besoin pour l'utiliser ? Que voudriez-vous voir en premier ? (Probablement le tutoriel...)

3. Peut-être un exemple du début à la fin, y compris l'installation. Vous devriez peut-être prendre la peine de l'exécuter dans un environnement virtuel ou sur une nouvelle installation de système d'exploitation, afin d'être sûr que vos instructions d'installation traitent de tout.

Answer 3

1. Il devrait être assez facile de rassembler quelques commits, et l'effort en vaut la peine. Les développeurs consultent souvent l'historique pour se faire une idée de la façon dont le projet a été conçu à la base.
2. Définitivement. Le moins que vous puissiez faire est d'utiliser un moteur de documentation comme Doxygen pour générer la documentation. Les tutoriels ne sont probablement pas nécessaires à ce stade ; la communauté les écrira pour vous, à condition que le code soit bien documenté.
3. Un bon emballage aide toujours. Générez des binaires précompilés pour plus d'une architecture et, si possible, créez des RPM et des DEB. Cela réduit considérablement la barrière d'entrée. Personne ne contribue à un logiciel qu'il n'utilise pas. Vous pouvez également utiliser un outil de suivi des bogues comme Bugzilla, ou une solution intégrée comme Launchpad ou Trac. Créez également une liste de diffusion et un canal IRC. Cela contribuera à la création d'une communauté.