GitHub à votre travail?

Une question de point de vue

D’abord, est-ce que votre compagnie / supérieur immédiat est ouvert(e) à l’idée de partager le code source de certaines parties d’une application?

La réponse est probablement non et avec raison. Il faut démontrer que les avantages sont supérieurs aux inconvénients. Cet article se veut comme une introduction au sujet. Vous aurez sans doute à faire vos devoirs avant d’en discuter.

Évidemment, si vous n’avez pas commencé à programmer l’outil en question. Il peut être bien de se demander si cela peut être fait à l’extérieur du travail en tant que projet personnel si c’est raisonnable. Au travail, vous ne faites qu’utiliser la contribution de quelqu’un sur le web. N’est-ce pas ce que l’on fait déjà avec bootstrap ou jquery?

Les bienfaits

Du point de vue de la compagnie

Le coût de la maintenance va diminuer!

Pas tout à fait. Les gens de la communauté vont proposer des changements qu’il juge pertinents. Ce n’est pas toujours en lien avec l’utilisation qu’on en fait. Certains vont corriger des bogues. D’autres personnes vont apporter des idées d’amélioration. C’est variable pour chaque projet.

Le point le plus important est sans doute le suivant :

Encourager les programmeurs à produire du code de meilleure qualité en produisant du code plus générique. De plus, le code source peut être consulté par n’importe qui. On a donc plus tendance à faire attention à écrire du code plus propre et mieux documenté.

Du point de vue des programmeurs

Recevoir du feedback d’autres personnes. Ils peuvent inspirer et suggérer de bonnes idées d’amélioration.

Réutiliser le code source à un prochain emploi. Enfin, cela peut être vu comme un point négatif pour certains. Voyez cela de la manière suivante:

Si le programmeur trouve un bogue à l’avenir, il est en mesure de le corriger et de permettre à la compagnie où il travaillait de bénéficier du correctif. De plus, il peut ajouter de nouvelles fonctionnalités.

Possibles obstacles

Il faut des gens motivés à s’occuper des pull request et à répondre aux issues sur GitHub.

Il faut faire attention à ce qui se trouve dans le dépôt git. Toute l’information devient publique. Il faut donc faire attention à ne pas divulguer d’information confidentielle. Au besoin, il est peut-être plus prudent de recommencer l’historique Git en partant de zéro.

Il faut faire de la publicité! Il y a une quantité incroyable de projets open source. Votre projet doit être pertinent et facile à apprendre. Prévoyez d’ajouter une référence au projet dans des projets awesome-* sur GitHub qui font du sens. Parlez-en avec votre réseau. Partagez la nouvelle sur reddit.com dans le bon subreddit. Créez des articles de blog. Bref, allez vers le monde. N’attendez pas qu’ils viennent.

Mettre en place des tests automatisés et créer une série de tests unitaires par exemple. Une fois créés, ils peuvent faciliter le processus de révision des pull request en validant l’exécution. De plus, vous aurez des tests de régression. Plusieurs compagnies offrent gratuitement des services pour compiler/tester/déployer vos projets open source. (Travis CI pour Linux et AppVeyor pour Windows)

Il faut avoir un readme! Si vous avez pas mal de choses à présenter, créez un Wiki. Ce n’est pas négociable. Il faut de la documentation et des exemples. Si vous avez des tests automatisés, montrez le statut dans le README.

Choisir le bon type de licence. Consultez ce site web pour vous aider : choosealicense.com

On peut choisir de rendre open source un module, un composant, un script, etc. À vous de déterminer la portée. Plus c’est petit, plus c’est facile à partager et à intégrer dans un autre produit.

Idées pour améliorer l’expérience

Créer un package pour votre projet. Par exemple, si vous développez une librairie en .Net ajouter votre package sur NuGet. Si c’est un projet en Node.js, ajoutez votre package sur npm. S’il s’agit d’une librairie front-end (css, javascript, etc.), pensez à Bower.

Si votre projet est populaire, vous pourriez ajouter un fichier indiquant comment contribuer au projet. (contributing.md) Encouragez les gens à faire des commits courts. (C’est plus facile à fusionner et cela cause moins de conflits sur git)

Conclusion

Pensez un peu à ce que serait le monde sans bootstrap et jquery. Il faudrait prendre à nouveau le temps de développer des outils semblables pour faire le travail. Je ne suggère pas de tout rendre open source. Parfois, c’est subtil. Il ne faut pas grand-chose pour aider grandement les autres et soi-même.

Pour finir, je vous laisse sur une réflexion.

L’open source comme moyen pour vous libérer de la propriété intellectuelle en entreprise et laisser place à la créativité de la communauté.