Réponse à 1: Où dois-je héberger mon code?

En fonction de ce que votre université vous propose, vous pouvez choisir de l'héberger avec l'université, ou peut-être avec un référentiel open source tel que Github , Bitbucket, SourceForge ou similaire.

Beaucoup de ces services ont une option d'abonnement «payant» pour les dépôts privés si ceux-ci sont nécessaires.

Réponse à 2: Quelle licence open-source devrais-je choisir?

Cette question est pertinente car nous avons cette discussion en ce moment dans le cadre de l'un de nos propres projets de recherche. Il se trouve que je connais un peu les logiciels open source, après avoir fait des recherches dans le passé et avoir enseigné quelques cours dessus.

Bien qu'il existe de nombreuses licences open source, elles finissent vraiment par venant en deux familles principales. Ce sont des licences ouvertes permissives (ex: MIT, BSD, Apache) ou elles sont libres (GNU Public License v2 ou GPLv3). Voici un bref aperçu de l ' Initiative Open Source

Licences ouvertes permissives Ces licences vous permettent généralement de publier votre code et n'importe qui peut faire tout ce qui ils veulent tant qu'ils conservent certaines informations de copyright avec le code. En réalité, cela a un certain nombre d'implications.

1. Quelqu'un pourrait prendre toute votre base de code, créer un produit avec et le vendre.

2. Quelqu'un pourrait prendre des parties de votre code, le mettre dans son propre projet (commercial ou non).

3. Parce que la licence est plus permissive, vous pourriez prendre vous-même le code, fermez-le, puis gardez sous silence toutes les versions futures afin que vous puissiez gagner de l'argent avec le code ou le cacher au public.

4. Parce que la licence est plus permissive , vous pourriez générer plus d'intérêt en conséquence. Les gens peuvent prendre du code d'autres projets et l'utiliser pour améliorer le vôtre. D'un autre côté, ils pourraient également apporter des améliorations à votre code source et ne jamais les partager avec vous.

D'un autre côté, la GNU GPL est une licence de logiciel libre qui vous interdit de faire certaines choses. En ce sens, c'est plus restrictif, mais le fait pour un certain nombre de raisons idéologiques.

1. Si vous publiez un logiciel sous GPL, vous ne pouvez pas le fermer. Déjà. Il restera ouvert, et si quelqu'un vous demande le code source, vous êtes obligé par les termes de la licence de le fournir (si vous l'hébergez sur Github ou un autre référentiel public, vous avez déjà satisfait à cette exigence).

2. Une entreprise pourrait prendre le code, fabriquer des produits avec et le vendre (c'est son droit de le faire), mais elle devrait le faire à condition que n'importe quelle source le code qu'ils écrivent pour le projet est également publié sous la GPL. Pour cette raison, beaucoup d'entreprises qui gagnent beaucoup d'argent en écrivant des logiciels n'aiment pas cela parce qu'elles doivent continuellement publier du code au public. D'un autre côté, tout ce qu'ils font est mis au public sous la GPL, vous pouvez donc le replier dans votre projet et l'améliorer. Ils ne peuvent pas prendre votre code, l'améliorer et ne plus jamais le partager.

3. Si vous avez utilisé un code GPL dans votre projet (disons que vous avez pris un quelques lignes du noyau Linux ou du contrôle de version Git ou autre) alors vous devrez également publier votre code sous GPL.

En fin de compte, le choix de la licence affecte davantage la manière dont vous souhaitez que le logiciel soit utilisé (et la communauté éventuelle qu'il pourrait apporter). Si vous envisagez de commercialiser le logiciel (et autorisez implicitement d'autres personnes à faire de même), alors vous voudrez peut-être utiliser BSD. Si vous ne voulez pas que les gens prennent votre travail acharné et en tirent profit sans vous montrer les résultats, alors vous voulez passer à la GPL. Si vous ne vous souciez pas de l'une ou de l'autre, vous pouvez probablement en choisir une. Je pense que BSD est populaire dans le milieu universitaire précisément en raison de l'aspect de la commercialisation (par exemple, LLVM gagne beaucoup de terrain en raison de sa licence permissive).

Réponse pour 3: Comment puis-je faciliter la tâche des autres exécuter le code?

Vous facilitez l'exécution du code en l'ingéniant pour qu'il soit facile à exécuter et en étant extrêmement détaillé avec votre documentation.

L'emballage / distribution peut en fait être assez difficile et demandent généralement plus d'efforts que la plupart des gens ne le pensent. Un bon moyen de rendre le logiciel facile à exécuter est de le tester sur plusieurs machines. Assurez-vous de n'oublier aucune des bibliothèques que vous utilisez dans votre projet logiciel, par exemple, et si possible, essayez d'utiliser des bibliothèques de logiciels communes et bien entretenues. Utilisez des langages traditionnels avec des référentiels de paquets faciles à gérer.

Le cas échéant, utilisez des installateurs, des scripts d'installation, des Makefiles (distutils, qui utilise automake / autoconf est mieux), etc. Même les scripts shell valent mieux que rien . Si vous pouvez fournir des binaires et / ou un installateur, cela rendra les choses encore plus faciles. Le problème est que c'est BEAUCOUP de travail!

Accompagnez-le de documentation. Idéalement, la documentation contiendra une description de la façon de la configurer et de l'exécuter, avec des descriptions des packages / bibliothèques nécessaires, des données que vous pourriez avoir à obtenir et sur quoi taper ou cliquer. Habituellement, quelque chose appelé README ou INSTALL attirera l'attention. Mettez également les instructions sur la page Web, la plupart des solutions d'hébergement vous permettent également d'avoir des pages Web.

J'espère que tout cela vous aidera. La partie la plus difficile du processus est de loin l'étape 3 et la plupart des gens ne parviennent pas à utiliser de bonnes techniques comme les installateurs, l'automake / autoconf, etc. car c'est BEAUCOUP de travail et le développement avance souvent plus vite que vous ne le pouvez. rédiger des documents. Cependant, personne ne vous évalue sur votre style, il est donc souvent plus facile de le sortir que de le nettoyer et de le mettre en valeur d'abord.

Dans une certaine mesure, la réponse dépendra de ce que vous souhaitez accomplir avec cette version. Il y a eu un article de blog récemment fantastique sur ce sujet précis.

Si le code est de bonne forme et que vous espérez que d’autres le construiront, alors le choix de la licence va reflètent votre philosophie. Une licence de style BSD si vous voulez juste l'algorithme et le code là-bas, ou peut-être une licence de style Copyleft (GPL) si vous voulez vous assurer que les améliorations reviennent au commun.

Si le code n'est pas dans si grande forme, mais par souci de transparence doit être là-bas, envisagez quelque chose comme le CRAPL, qui reconnaît la nature désordonnée des sciences informatiques modernes. Je pense que le préambule mérite d'être cité:

  I. PreambleScience prospère sur l'ouverture.Dans la science moderne, il est souvent impossible de reproduire des affirmations sans accéder au logiciel sous-jacent à ces affirmations.Soyons tous honnêtes: lorsque les scientifiques écrivent du code, l'esthétique et les principes d'ingénierie logicielle passent au second plan pour avoir un code en cours d'exécution et fonctionnel avant un Alors, libérons le laid. Et soyons fiers de cela.  

En ce qui concerne les mécanismes de création du code, utilisez GitHub ou Bitbucket. Ces services vous donneront un hébergement de code, un accueil pour le projet, la possibilité de gérer la contribution et la possibilité de suivre les bogues et les problèmes.

Matthew G. et Irwin ont donné d'excellentes réponses, mais j'aimerais fournir des ressources supplémentaires et des références pour les personnes intéressées.

Tout d'abord, jetez un œil aux réponses à cette question similaire sur scicomp. SE:

Quel matériel dois-je inclure dans un article de journal (ou publier en ligne) afin de rendre mes recherches informatiques reproductibles?

La reproductibilité a fait l'objet d'un atelier 2012 à l'ICERM; vous trouverez de nombreux documents utiles sur le wiki et dans le rapport final (voir en particulier les annexes D, E et F).

Archivage / hébergement

Mise à jour : vous pouvez obtenir un DOI et un hébergement permanent pour un instantané de votre code via Figshare ou Zenodo.

Licences

Voir cette section du wiki pour une liste complète des ressources.

Simplifier l’exécution du code

Il existe des sites et des outils spécifiquement destinés à cela. Ceux-ci résolvent également le problème d'hébergement:

• ActivePapers: Un ActivePaper est un fichier unique contenant tous les logiciels et ensembles de données liés à un projet de recherche.
• RunMyCode: ce service est basé sur le concept innovant d'un site Web compagnon associé à une publication scientifique.

Un obstacle majeur est souvent de recréer le bon environnement (y compris les bibliothèques et autres) nécessaires pour exécuter le code. Pour surmonter cela, vous pouvez

• distribuer une machine virtuelle ou utiliser Vagrant ou CDE
• vous assurer que votre code s'exécute sur une plate-forme cloud, comme
  • Wakari
  • SageMathCloud
  • Services Web Amazon
  • Windows Azure

Il peut être utile de mettre votre code dans un format de feuille de calcul, où vous pouvez intercaler des commentaires et même des formules mathématiques (par exemple, en utilisant le bloc-notes IPython ou une feuille de calcul Sage. Voici un exemple.

Exemples

Enfin, ici sont quelques exemples de mes propres efforts. Ils sont loin d'être parfaits, mais peuvent tout de même être utiles.

Je recommande github.

Les autres réponses données sont bien détaillées et l'incluent mais avec un tas d'autres choix. Le choix est évidemment bon. Sans les avantages spécifiques énumérés, je vous suggère d'utiliser simplement github.

Ma raison est que je pense que github est devenu un leader incontesté dans le domaine du stockage et du partage de code. C'est la technologie sous-jacente de git en tant que système dvcs moderne a largement remplacé les technologies plus anciennes telles que svn. Il compte maintenant plus de 2,8 millions d'utilisateurs, ce qui est assez impressionnant.

Github est également idéal pour la collaboration de code, permettant à plusieurs personnes de modifier et de fusionner leurs modifications de manière contrôlée mais décentralisée.

Github vous permet d'avoir à la fois des référentiels publics (tout le monde peut voir) et privés auxquels vous contrôlez l'accès en vue. Pour la mise à jour, vous ajoutez les clés ssh des utilisateurs demandés pour accorder l'accès aux mises à jour.

Toutes les réponses ci-dessus sont excellentes. Je voudrais simplement ajouter que, si vous prévoyez de le publier sur le site Web de votre laboratoire ou sur un site Web personnel, vous devez également le copier ailleurs.

Dans de nombreux champs, il semble que les données ( y compris les programmes originaux) disparaissent tout le temps. Lorsqu'un laboratoire déménage dans une autre université, ferme ou subit une restructuration, son site Web est susceptible de changer et les données qui y sont stockées peuvent être perdues. Donc, à moins que votre université ne dispose d'un référentiel centralisé, vous devriez placer votre code là où il peut rester pendant des décennies, par exemple sur Github.

À mon avis, il est lié au code spécifique que vous souhaitez partager.

Je veux juste donner un exemple, pour le code JavaScript, vous pouvez le partager sur http: // jsfiddle .net / Nous pouvons tester notre JavaScript, CSS, HTML ou CoffeeScript en ligne sur le Web. Il existe également une option pour inviter des personnes à collaborer au développement de notre code.

Bonne chance.

Pour mon papier de fin d'études, j'ai partagé mon code en l'imprimant en tant que volume d'accompagnement du document de recherche principal.
Attention, c'était pré-Internet, et le papier (et le code) était classé si peu de gens jamais le lire.
J'ai tout mis sur disquette et j'en ai également inclus des copies avec le papier imprimé.

De nos jours, vous le mettriez probablement sur un serveur quelque part où tous ceux qui y ont accès sur le papier peut accéder au code, et personne d'autre.
Bien sûr, vous aurez besoin de savoir qui ce sera. La plupart des documents de recherche sont considérés comme des secrets d'entreprise (ou des secrets de département) et ne sont pas destinés à une diffusion publique. Votre code tomberait sous les mêmes restrictions.
Le simple fait de le lancer sur github, google code ou source forge sans l'autorisation préalable de vos employeurs / coordinateurs ne vous fera pas beaucoup d'amis, en fait vous pourriez finir avec une demande assez lourde de dommages-intérêts et / ou de peine de prison pour cela.

Il y a beaucoup de bons conseils dans les différentes réponses; Je vais aborder uniquement le point 3, "Comment puis-je faciliter l'exécution du code pour d'autres personnes?"

La réponse ici est d'automatiser autant que possible. Cela aura également l'avantage de vous faciliter la vie, car vous passerez moins de temps à taper (et retaper) des incantations magiques et à vérifier la sortie.

Commencez, le plus tôt possible, avec un top- script de niveau (je l'appelle généralement Test ) qui construit et teste tout votre code. (C'est toujours la première chose que j'écris.) Dans votre cas, il semble qu'il soit trop tard pour commencer, mais ajoutez-le maintenant et développez-le de la même manière.

Chaque fois que vous en faites un nouveau extraction ou clonage de votre référentiel, commencez par exécuter le script de test. Lorsqu'il atteint la première erreur de quelque nature que ce soit, réfléchissez à la manière dont vous pouvez modifier le script pour éliminer cette erreur (si cela est facile à faire) ou détecter la condition d'erreur et envoyer un message informatif à l'utilisateur. Par exemple, si vous dépendez de la présence de libfrozzit et de ses fichiers d'en-tête à compiler, vous ne pourrez peut-être pas l'installer, mais vous pouvez au moins essayer de vérifier sa présence et, s'il est absent , échoue avec, "libfrozzit introuvable. Installer avec apt-get frozzit-dev ou yum install frozzit-devel?"

Écrivez des tests de tout type, que ce soit des tests unitaires de base ou des tests fonctionnels, pour votre code. Même en choisissant la fonction la plus simple et en lui envoyant une valeur, ou en exécutant myprogram --help et en vous assurant qu'il imprime n'importe quel message, cela signifie que vous avez lancé un cadre de test et le rend beaucoup, beaucoup plus facile pour quelqu'un d'autre pour venir et ajouter un test. Si vous pouvez atteindre, par exemple, une couverture de test de 5% de votre code, c'est un avantage considérable, car même cela sera d'une grande aide pour quelqu'un qui se demande si le code a été construit correctement.

Rendre le code facile à construire et à exécuter pour les autres n'est pas magique et ne peut pas être fait en agitant une baguette ou en exécutant un outil spécial. C'est une question de dire, chaque fois que vous vous trouvez en train de faire un réglage manuel pour faire fonctionner les choses, aussi simple soit-il, vous demandez-vous "comment pourrais-je automatiser le besoin de cette modification manuelle"?