Vous souhaitez passer votre projet en open source ?
0 j'aime52 vues
Le document présente un guide sur la transition vers le modèle open source pour un projet software, soulignant l’importance d’une communauté engagée et le choix d’un modèle commercial adéquat. Il aborde les moments opportuns pour passer en open source, les types de licences disponibles et les différentes manières de structurer une communauté. Enfin, il encourage les équipes à publier dès le début pour bénéficier des retours et améliorer le projet.
Vous souhaitez passer votre projet en open source ?
- 1. VOUS SOUHAITEZ PASSER VOTRE PROJET EN OPEN SOURCE ? Bruno Cornec, HPE Open Source and Linux Strategist
- 2. 2 Introducing Bruno Cornec ● Software engineering and Unices since 1988: – Mostly Configuration Management Systems, Build systems, quality tools, on multiple Unix systems – Discovered Open Source & Linux (OSL) & made first contributions in 1993 – Full time on OSL since 1995, first as HPE reseller then @HPE ● Currently: – OSL Technology Strategist in HPE WW Customer Innovation Center, Grenoble, France – WW Linux Community Lead for the HPE Open Source Profession – Conferences at WW level at LinuxCon, Linux.conf.au (2007, 2013, 2014), Fosdem, RMLL POSS, ... – MondoRescue, Project-Builder.org, python-redfish, UUWL and PUSK Project Lead – LinuxCOE, mrepo, tellico, rinse, fossology, collectl, Ironic contributor – FOSSBazaar/SPDX and OSL Governance enthusiast – Mandriva, Mageia, Fedora packager ● And also: – Amateur singer (Alto / Tenor), recorder player since 1976 and Choir director since 1987, CD collector (7500+), Concerts, Photography
- 3. 3 CONTEXTE •Un projet qui mature depuis 2 ans •Un management ou une équipe convaincue par les vertus de l’Open Source •Décision de passer ce projet en Open Source •On ouvre un compte au nom de l’entreprise sur GitHub.com •On publie les sources dans ce compte •On n’a plus qu’à profiter et retirer tous les avantages de ce passage en open source, n’est-ce pas ? •Eh bien non ! •Peu de bénéfices seront retirés de cette approche
- 4. 4 QUAND PASSER EN OPEN SOURCE ? • ”RELEASE EARLY, RELEASE OFTEN”, le pertinent mantra de Linus Torvalds (mode de dev inclusif) – Early => Passer en Open Source le plus tôt possible – Early => Avant même d’avoir du code ! – Release => Code disponible même si pas fini – Release => Faire savoir à diverses communautés. – Often => Démontrer une dynamique – Often => Démontrer une continuité temporelle •Bénéfices : – Constitution d’une communauté impliquée et influente car là à l’origine (partage de coûts de dev) – Choix de l’outillage du cycle de vie de développement (langages, forge, CI/CD, Tests, …) – Gouvernance autour du contrôle à garder ou partager dans le temps. – Étudier en amont la propriété intellectuelle, monter un OSPO,
- 5. 5 QUOI PASSER EN OPEN SOURCE ? •Choix d’un modèle business : – Revenus par les logiciels – partiellement propriétaire ● Propriétaire à libération progressive ● Open Core (Cœur ou bibliothèques libres, extensions propriétaires), SSPL – Revenus par les services – Open Source complet ● Formation et/ou Support/Souscriptions et/ou Consultance et/ou Développement à façon ● Hébergement / SaaS •Bénéfices / Risques : – Pérennité financière de la société en fonction du modèle choisi – Mixte => Complexité technique potentielle – Coût de gestion des licences logicielles
- 6. 6 QUELLE LICENCE OPEN SOURCE ? •Mode libre permissif ou compatible propriétarisation (BSD, Apache) •Mode libre à réciprocité ou compatible libre éternellement (GNU GPL - privilégier la v3) •Mode libre à réciprocité pour l’hébergement (GNU AGPL) •Penser à la pertinence ou non d’un CLA (Contributor Licence Agreement) •Penser à la pertinence ou non du dépôt de marque •Bénéfices / Risques : – Impact sur la nature de la communauté (OpenStack vs Linux) – Facilité/difficulté de recevoir des contributions – Permettre l’éclosion de produits commerciaux ou non – Bonne gestion de la propriété intellectuelle GNU LGPL MIT IBM Mozilla W3C Apache permissive copyleft GNU GPL FLOSS BSD
- 7. 7 QUELLE COMMUNAUTÉ OPEN SOURCE ? •Adossement à une communauté existante – sa culture prime •Bâtir une nouvelle communauté – Dictateur bénévole ou méritocratie technique ou démocratie participative – Très structurée (feuilles de route, rôles, sous-équipes, délégation) ou pas – Pilotage par des individus / des entreprises •Bénéfices / Risques : – Internationale par conception – Avec l’augmentation de l’implication vient l’augmentation de l’influence – Trouver le bon modèle de gouvernance – La dépendance envers la stratégie de sociétés peut fragiliser le projet en cas d’évolution
- 8. 8 MAINTENANT , ALLEZ-Y ! •Une fois réfléchis : – Le modèle commercial – La licence – La communauté – La gouvernance – Les outils alors vous pouvez commencer à partager avec votre communauté sur la spécification, la conception, le codage, le test et l’intégration de votre logiciel libre. Publiez dès le début ce que vous avez Profitez des retours pour améliorer votre code et vos processus
- 9. 24/12/2021 Private | Confidential | Internal Use Only ”Changes are never easy to make. There is comfort and safety in tradition, but change must come, no matter how painful or expensive it may be.” Bill Hewlett [email protected] (Open Source and Linux Technology Strategist at the WW Customer Innovation Center) http://downloads.linux.hpe.com/ Linus Torvalds, Richard Stallman, Eric Raymond, Nat Makarevitch, René Cougnenc, Eric Dumas, Rémy Card, Bdale Garbee, Bryan Gartner, Craig Lamparter, Lee Mayes, Gallig Renaud, Andree Leidenfrost, Phil Robb, Bob Gobeille, Martin Michlmayr, Ren Ribaud among others, for their work and devotion to the Open Source Software cause... and my family for their patience :-) THANK YOU