2. Présentation personnelle
● Ingénieur de Recherche au département INF à
TELECOM & Management SudParis (B 303)
● Projets de R&D sur le logiciel libre (CALIBRE,
HELIOS, COCLICO, ...)
● Contributeur à la distribution Debian
● Recherche : plate-formes de développement
collaboratif de logiciels (forges)
● Google est mon ami, mais au cas où :
http://www-public.it-sudparis.eu/~berger_o/
http://www-public.it-sudparis.eu/~berger_o/weblog/
page 2
3. Sondage rapide
● Déjà eu des cours sur le sujet ?
● Logiciel libre ?
● Linux ?
● GNU ?
● FSF ?
● APRIL, AFUL, etc. ?
● Firefox ?
● Ubuntu ?
● Creative Commons ?
page 3
● SourceForge ?
4. Objectif de cette conférence
● Donner une idée des enjeux liés à la
collaboration dans les projets libres
● Rappel des fondamentaux du modèle libre
● Démythifier un modèle loin d'être magique
● Quelques pistes permettant d'intégrer le libre
dans les projets industriels
page 4
10. Définition du logiciel libre
● « La liberté d'exécuter le programme, pour tous les
usages (liberté 0).
● La liberté d'étudier le fonctionnement du programme,
et de l'adapter à vos besoins (liberté 1). Pour ceci
l'accès au code source est une condition requise.
● La liberté de redistribuer des copies, donc d'aider
votre voisin, (liberté 2).
● La liberté d'améliorer le programme et de publier vos
améliorations, pour en faire profiter toute la
communauté (liberté 3). Pour ceci l'accès au code
source est une condition requise. »
Définition de la Free Software Foundation (FSF)
page 10
11. Terminologie
● Logiciel Libre ~= OpenSource
● Liberté !
● Coût ?
● Autres :
freeware, domaine public, shareware, shared
source, etc.
● Libre = ouvert ?
● Ne pas se fier aux déclarations : vérifier les
licences
page 11
12. Libre vs. non-libre
● En théorie, identification facile :
● droit d'utilisation : OK - NOK
● droit d'étudier : OK - NOK
● droit de modifier : OK - NOK
● droit de diffuser copies (modifiées) : OK – NOK
● En pratique, parfois complexe (jargon licences)
● Demander aux experts
● Free Software Foundation (http://www.fsf.org/),
● OpenSource initiative (http://www.opensource.org/).
page 12
16. ValeurS : mouvement logiciel libre
● Philosophie : Liberté, Egalité, Fraternité
● Liberté : faire des copies, améliorer, distribuer
● Égalité : mêmes droits pour tout le monde
● Fraternité : Co-opération pour construire des biens
communs
● Mouvement « politique »
● Éthique, philosophie, activisme politique
● Richard M. Stallman et la FSF (Free Software
Foundation : http://www.fsf.org)
http://stallman.org/
● APRIL, en france http://www.april.org/
page 16
17. « Mouvement » Open Source ?
● Approche orientée vers le marché (créé en
réaction au mouvement du libre)
● Bénéfices pratiques
● Coûts (ambiguïté free)
● « Mouvement »
● Open Source Initiative
(http://www.opensource.org)
● La plupart des industriels de l'informatique, les SS2I,
etc.
page 17
19. Chronologie
● Au début était le code source (< 80) Unix, BSD (> 80)
● GNU project & Free Software Foundation créés par Richard M.
Stallman (> 83/84)
● Noyau Linux créé par Linus Torvalds (> 91)
● Distributions GNU/Linux ( > 95)
● Création de l'APRIL (96)
● IBM entre en jeu (2001)
● Sun rachète StarOffice et création de OpenOffice.org (2002)
● Ubuntu, Firefix 1.0 (2004)
● OpenOffice.org 2.0 (2005)
● Google sponsorise
● Java sous GPL (2007)
● Android, ...
page 19
20. Le libre est partout
● Internet : Apache, Bind, etc.
● Serveurs (Samba, MySQL, etc.)
● Groupware, CMS, ERP, ETL, etc.
● Appliances, embarqué, grand public
● Nokia 900
● Freebox, Easybox, routeurs, etc.
● Téléphones (Google Android, etc.)
● GPS, ...
● Impots
● Poste de travail des gendarmes, députés AN
● ...
page 20
21. Impact global dans la société
● Impact sur tous les aspects de la production et
de la diffusion du savoir, et plus largement tous
les artefacts immatériels :
● Publications et données scientifiques (open archives, etc.)
● OpenStreetmap, Wikipedia
● Création artistique : creative commons (CC)
● Entertainment - gratuité ?
● Débat public, démocracie, régulation de l'utilisation des
ressources, etc.
● Nouveau paradigme : (Creative) Commons (L.
Lessig)
● Des biens publics aux biens communs ?
22. Résistances
● Copyright / droit d'auteur
● Brevets
● DRM
● FUD
● Hadopi
● ...
23. Aujourd'hui incontournable
● 20/25 ans plus tard
● La partie est en voie d'être gagnée
● Mais au fait, comment ça marche !?!
page 23
24. Qu'est-ce que le logiciel libre ?
● Juridique / Licences
● Organisationnel / Communautés
● Economique / Modèles d'affaires
Pas un seul modèle !
page 24
26. Droit d'auteur sur le logiciel
● A la base : le droit d'auteur / copyright
● Similaire à propriété littéraire et artistique
● Fondement : code source
● Ensuite : oeuvres dérivées
● IANAL
page 26
27. Protection vs. Contrôle
● Comment bien exercer un contrôle ?
● Le Copyright contrôle si
● Utiliser
● On peut copier pour donner ou vendre
● (essayer de) Modifier
● Toute autre chose non prévue dans un contrat de licence
● Le libre rééquilibre la donne en faveur des tiers,
utilisateurs, concurrents
page 27
28. Droit d'auteur, licences
● Droit d'auteur :
● Prérogatives de l'auteur, faibles
● Conditions d'exploitation (employeur ?), fortes
● Attaché à :
● au fichier source, d'abord
● œuvres dérivées (y compris exécutable)
● Régime par défaut : restrictions des droits
● Licence libres établissent des exceptions
● Œuvres composites : compliqué
● Mixibilité des licences ?
page 28
29. Brevets sur les logiciels
● Le droit d'auteur/copyright ne controle pas si
un programme similaire peut être écrit par un
tiers
● Le brevet protège une idée
● Au départ destiné à protéger l'intérêt général
● Dérive
● Controverse législative en Europe
page 29
31. Catégories de licences libres
● Deux grandes catégories :
● Façon « domaine public » (BSD, X11)
● Façon « Copyleftées »
● Copyleftées (GPL, LGPL):
● Liberté de changer le logiciel
● Impossibilité de changer la licence sur oeuvres dérivées
● Un même logiciel + plusieurs licenses =
segmentation des « marchés » (dual license)
● Modèles économiques des éditeurs de
logiciels libres
page 31
32. Points clés
● Question d'oeuvres dérivées
● Edition de liens, etc.
● Pas questions modèle éco, mais seulement
copyright
● Compatibilité des licences
● Éviter la prolifération des licences
● Qui est titulaire des droits ?
● SAAS, Cloud computing ? (Affero GPL)
page 32
35. Économie du logiciel
● Non rivalité
● Valeur augmente quand on s'en sert (effets de
réseau)
● Monopôles
● Création d'un « bien commun »
● Faciliter la réutilisation
● Mutualisation de l'investissement
● Logiciel libre == gratuit (une fois qu'il a été payé)
page 35
37. « Bataille » immense
● Réduire les coûts (commoditisation)
● Effets de réseaux pour établir des standards
● Mutualiser la R&D
● « Co-opétition » :
● coopération
● compétition
● Prendre position dans le libre pour maîtriser
son évolution
● Modèles économiques ?
page 37
38. « Commoditisation » du logiciel
source : Frank van der Linden (Philips)
page 38
39. Valeur du libre ?
● Exemple: Debian 2.2 GNU/Linux (2001)
● Lignes de code source :
● 55 201 526
● dont noyau Linux < 6%
● x 2 tous les 2 ans
● Si applique métriques traditionnelles du
développement en entreprise :
● Effort estimé : 14 005 hommes x années
● Délai estimé : 6,04 ans (équipe de 2 318 p.)
● Coût développement : US$ 1 891 990 000
(Source: "Counting potatoes" par Gonzalez-Barahona et al)
● Cf. http://ohloh.net pour d'autres chiffres
page 39
(Méthodologie discutable)
40. ROI utilisateurs
● Profusion d'études
● Libre != gratuit ... heureusement ;-)
● Économie gestion des licenses
● Transfert de coût entre licences et formation
● Paradoxes
● Au final coût des licences souvent marginal dans
les coûts d'un projet
page 40
41. Modèles d'affaires pour fournisseurs
● Service
● « Valeur ajoutée » couches hautes
● Editeur
● Double licence
● Marché en croissance
● Positions stratégies industrielles
● Exemple : Linagora (fondée par anciens INT Management)
page 41
44. Qui participe
● Individus bénévoles
● Parfois très isolés
● Parfois de façon organisée (Apache, GNU project, etc.)
● Sociétés
● Services
● Utilisateurs finaux (sponsors)
● Pas un seul profil d'activités :
● Utilisation, tests, rapports de bugs
● Support communautaire (forums, listes, etc.)
● Code
● Vendre du libre
● etc.
page 44
45. Rapide panorama d'un écosystème
Debian
Debian
s
rs ion
ve gs packages
bu
Développeurs versions Utilisateurs
amont RedHat
RedHat
bugs
(“upstream”)
bugs
ve
rsi
bu ons
gs
OpenSuse
Éditeurs SSII
distributions
page 45
46. Le libre est global
● debian
Debian developers
page 46
47. Où sont ces développeurs ?
Par pays (SourceForge) :
Rang Pays Developpeurs
1. United States 425620
2. Germany 95800
3. United Kingdom 60768
4. Canada 49109
5. France 44587
6. China 36517
... ... ...
(source : Gregorio Robles and Jesús M. González Barahona - 2006)
page 47
48. Où sont ces développeurs ? (2)
Par continent :
Continent Développeurs
Africa 12 560
Asia 127 275
EU401 845
Europe 466 792
North America 485 679
Oceania 46 422
South America 36 330
(source : Gregorio Robles and Jesús M. González Barahona – 2006)
page 48
62. Prendre part à une nouvelle communauté
● Rencontrer des hommes (et des femmes), pas
seulement des compagnies ou des services
marketing
● Construire un projet où différents modèles peuvent
cohabiter
● Apprendre les règles des communautés
● Méritocratie
● De nombreux mode d'organisation sociale
● Comme dans la « vie réelle » c'est souvent plus subtil
que ce qu'on en dit dans les présentations ou les
publicités !
● Communiquer pour construire la confiance
page 62
67. Sélection d'un produit
● Facilité à tester
● Ne pas confondre vitesse et précipitation
● Sous-traiter ce qui peut l'être
● Identifier les éléments critiques et monter en
compétence
● Préférer les solutions déjà packagées
(distributions)
● Éléments de dépendance sur des tiers non-
contractualisés
page 67
68. Nombreuses qualités
● Qualités génériques ... déjà connues
● Qualités particulières d'un logiciel libre
=> à évaluer
● sa licence
● sa communauté
● son code (sa doc, son langage, etc.)
● Méthodes d'évaluation (QSOS, OpenBRR, ...)
http://fr.wikipedia.org/wiki/Méthode_d'évaluation_de_logiciels_libres
page 68
71. Analyse des besoins
Conduite de projet
Spécification
Architecture
Conception détaillée
Codage
Tests
?
Déploiement
page 71
72. Maintien en condition opérationnelle
● Réactivité pour les mises à jour
● Diminuer l'adhérence dans les composants
spécifiques
page 72
73. Stabilisation impossible
● Mises à jour de sécurité permanentes
● Répétition des mises à jour
● Automatisation souhaitable
● Diminuer la taille du code spécifique
page 73
74. Reverser au projet
● Rendre générique les éléments spécifiques
● Maintenus à l'extérieur
● Améliorés à l'extérieur
● Pas besoin de les repackager
● Plus facile à dire qu'à faire
● Participer aux projets externes ASAP
page 74
75. Compétences pour le développement
● Développement distribué
● Communication en réseau
● Rendre générique ce qui peut l'être
(bibliothèques, sous-projets)
● Méthodologie d'intégration (versions dérivées,
customisations)
● Savoir packager (exemple : Debian)
● Traditionnels : doc, specs, tests, etc.
● Animation de communauté
● ...
page 75
76. Comment bien intégrer un projet libre
● Guides nouveaux contributeurs
● Être de bonne volonté (commencer petit pour
se faire connaître)
● Pas magique (le diable est dans les détails)
● Identifier la roadmap
● Stratégie de stabilisation de versions
● Système d'Assurance Qualité
● Identifier les acteurs clé
● Rencontres physiques
● Canaux temps réel (IRC, etc.)
page 76
77. Spécificités du projet
● Pas que la licence
● Communauté
● développement
● utilisatrice
● Personnes, rôles
● Acteurs économiques
● But, objectifs
● Méthodologie
page 77
78. Règles de vie en communauté
● Bénévoles (motivations)
● Professionnels
● Contractualisation ?
● Confiance
● Leadership
● Barrières à l'entrée
● Humour, culture et autres folklores
page 78
79. Enjeux sociaux plus que techniques
● Comprendre les règles du jeu
● Identifier les éléments influents
● Motiver des bénévoles
● Faire accepter ses contributions
● Impact sur les décisions
● Prouver son implication
● Se faire (re-)connaître
● Anticiper les alea
page 79
80. Où rencontrer la communauté
● En ligne
● Salons / conférences :
● Solutions Linux
● Rencontres Mondiales LL
● Open World Forum
● FOSDEM
● Associations :
● April
● CNLL
● etc.
page 80
81. Contribuer : une nécessité
● Cercle vertueux des contributions
● Quasi-obligation du fait des licences
● Externalisation de la maintenance
● Se faire plaisir et apprendre en vraie grandeur
● Se faire connaître et reconnaître
● Influer sur le pilotage d'un projet
page 81
82. Comment bien contribuer
● Il n'y a pas besoin de savoir coder
● Assurer une veille régulière
● Beaucoup d'effort même pour des choses
simples
● Minimum légal : faire vivre la base de bugs
dans le bugtracker du projet
page 82
83. Comment bien contribuer (suite)
● Accepter des usages sociaux différents
● Communiquer avant tout
● Jouer le jeu selon les règles
● Eviter l' « abandonware » non déclaré
● Respecter copyright
● Respecter les licenses
page 83
84. Conclusion
Loin de l'exhaustivité
Le libre est un changement extrèmement positif
Plein d'oportunités
Pas un seul modèle : mais quelques bonnes pratiques
générales
Contribuer est nécessaire pour la survie du modèle,
mais aussi concrètement dans les effets utiles aux
projets locaux.
page 84
85. ●
Merci à :
●
Jean-Christophe Becquet / APITUX
●
Roberto Di Cosmo / Paris 7 – PPS
●
Gregorio Robles
●
Aller plus loin :
●
«Richard Stallman et la révolution du logiciel libre» Eyrolles, 2010
●
http://www.april.org
●
http://www.apitux.org/index.php?2009/05/25/199-cours-logiciel-libre-standards-ouve
●
http://loli.fsa.ulaval.ca/index.php?id=9
●
http://dpt-info.univ-littoral.fr/mediawiki/index.php/I2L:Accueil
●
http://www.dicosmo.org/CourseNotes/LogicielLibre/
page 85
86. Conditions d'utilisation
● This work is Copyright 2009-2010 by Institut
TELECOM and Olivier Berger, published under a
Creative Commons ShareAlike license
page 86
87. Merci de votre attention
http://www-public.it-sudparis.eu/~berger_o/weblog/
page 87 direction ou services <pied de page>