Directives pour le code Open Source?

Question

Étape 1: Convaincre le président de mon verticale pour considérer ouvrir l'approvisionnement un corps du Code

Étape 2: ??? Pour donner un peu plus de détails, j'ai déjà réussi à convaincre mon patron et mon patron de considérer l'ouverture d'un code qui a été écrit principalement comme une plate-forme de démonstration pour notre entreprise. Nous avons déjà déterminé que le code est utile et comprenons les avantages de l'ouverture du code.

Maintenant, la question est où aller à partir d'ici? Quelles sont les prochaines étapes? Le président a dit qu'il aimerait voir une proposition de gestion de projet qui contiendrait des détails comme:

• Qui gérer les changements au code? A quoi ressemblerait le processus pour sortir un nouveau code?
• Comment le processus de révision de code est-il défini avant de libérer le code?
• Qui participera?
• Quels sont les aspects juridiques qui doivent être considérés en premier?

Ce que je pense que je dois un guide « Code Open Sourcing pour les nuls » ou s'il y a quelques directives simples, comment-à, ou des modèles pour mettre sur pied une proposition disponible. Je voudrais frapper un coup de circuit sur mon premier à chauve-souris et plop une proposition solide dans sa boîte de réception. Des conseils, des ressources ou des idées sur la façon de structurer une telle proposition seraient utiles.

Answer 1

Je considère ce qui suit:

• penser clairement sur les objectifs de votre logiciel en Open Source et vérifiez toutes vos décisions dans cette lumière.
• Revérifiez si toutes les licences des bibliothèques utilisées sont compatibles avec la licence choisie et si vous avez la permission d'utiliser quoi que ce soit dans la base de code. Cela inclut également des images ou d'autres non-code. Si la source est visible dans le monde entier, les violations des droits d'auteur sont faciles à repérer et vos concurrents pourraient utiliser l'occasion pour vous causer des problèmes.
• Choisissez une licence appropriée. La décision la plus importante pourrait être copyleft (GPL, AGPL) ou non (Apache, BSD, MIT).
• Vérifiez à nouveau votre code et supprimez tout ce que vous ne voulez pas voir dans le public (commentaires idiots).
• Ecrivez une documentation pour créer le logiciel à partir de la source. Si vous avez un bon buildfile qui pourrait être aussi facile que 'make', mais plus probablement vous devez documenter les dépendances comme les bibliothèques installées et ainsi de suite.
• Fournissez un moyen de contacter votre entreprise à propos du logiciel. peut-être une adresse e-mail et quelqu'un, qui répond à cet e-mail.
• Si vous souhaitez attirer des codeurs externes, documentez certaines parties importantes du code source. Fournir une documentation de base sur la structure, que les développeurs externes peuvent comprendre, quel fichier source ils doivent éditer, pour changer le comportement X du logiciel.
• Si vous voulez travailler avec des programmeurs externes, vous aurez besoin d'un contrôle de version lisible à l'échelle mondiale. Si vous obtenez des correctifs, qui sont obsolètes par rapport à votre base de code réelle, ce n'est pas utile. Si vous avez des personnes qui envoient souvent des correctifs, donnez-leur des droits de validation. Un bug-tracker ouvert est également utile.Si vous ne souhaitez pas héberger vous-même les deux outils dans votre entreprise, utilisez un Open-Source Hosting site.
• Si vous choisissez une licence copyleft, laissez tous les committers externes signer un contrat, qui vous donne la permission d'utiliser leurs ajouts. Sinon, vous ne pourriez pas utiliser les changements dans d'autres produits de votre entreprise.

Voilà, ce qui me vient à l'esprit en ce moment.