Structure du référentiel du projet open source

Question

Je suis au début du démarrage d'un petit projet open source. Lors du clonage du référentiel principal, on obtient un environnement de compilation complet avec toutes les bibliothèques et tous les outils nécessaires pour créer un fichier d'installation officiel, avec les numéros de version corrects. J'aime le fait que tous ceux qui veulent contribuer peuvent cloner le dépôt et commencer avec tout ce qu'ils veulent. Mais je pense que cela permet à Evil People de créer facilement des programmes d'installation malveillants et de les lancer dans la nature.

Comment devrait-il être structuré? Que recommandez-vous d'inclure dans le référentiel, par opposition à garder sur le serveur de construction seulement?

Answer 1

Ce que vous cherchez semble être une disposition de répertoire. Vous avez étiqueté votre question de manière agnostique, mais cela dépend de la langue (s)/du framework/de l'outil de construction que vous voulez utiliser. Pour vous donner quelques exemples

• Standard directory layout si vous construisez avec Maven
• For mixed languages
• django et ruby peut créer une mise en page par défaut pour vous

Il ne cesserez mal Les gens font du mal , mais cela aidera vos contributeurs potentiels.

Answer 2

En quittant vos bibliothèques de support et de construire des outils en fait une énorme douleur pour:

• tous ceux qui veulent juste essayer le logiciel, peut-être sur une plate-forme pour laquelle vous n'avez pas fourni un installateur, ou à partir d'une version plus récente que vous avez déjà publiée

• toute personne qui souhaite contribuer ou pirater votre projet.

Ce sont les gens que vous avez besoin de retirer tous les arrêts pour répondre à un projet qui ne sera pas un service marketing proxénétisme dehors et ne sera pas avoir une équipe rémunéré à temps plein développement de nouveaux fonctionnalités et corrections de bugs (aka, projets personnels/open-source/hobby).

Personne ne va jouer avec ou pirater votre projet si c'est une énorme douleur dans le cul pour l'amener à construire, et ils vont juste passer à la prochaine chose. Quelqu'un qui, pour une raison quelconque, a un intérêt à usurper votre logiciel avec des intentions malveillantes, va déjà faire beaucoup plus d'efforts qu'il n'en faudrait pour traquer quelques autres paquets pour mettre un installateur ensemble, alors vous découragez le mauvais sous-ensemble d'utilisateurs pour aucun gain appréciable. (Considérez-le comme une forme de security through obscurity, qui ne fonctionne jamais.)

Concentrez-vous sur l'accessibilité de votre référentiel aux utilisateurs et autres développeurs. En outre, les personnes qui téléchargent et construisent un logiciel devraient avoir l'habitude de vérifier le code de toute façon, ou à tout le moins de décider si elles font confiance au distributeur avant d'installer et de faire fonctionner les choses localement.