1. Logiciels libres
Olivier Berger,
TELECOM SudParis - Département INF
<olivier.berger@it-sudparis.eu>
Telecom SudParis
CSC4522 / DSI - 2010/06/10

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

5. Contenu
Introduction générale
page 5

6. Pourquoi ?
page 6

7. Le logiciel libre incontournable
● Semble simple
● Loin d'être si simple
● Processus humains plus que technologiques
● Pluri-disciplinaire
● Oportunités
● Risques
page 7

8. Introduction générale sur le libre
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines

9. Liberté, égalité, fraternité...
4 libertés
page 9

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

13. Logiciel libre
page 13

14. Logiciel non-libre (Propriétaire)
page 14

15. Exemples de logiciels libres
● GNU/Linux, FreeBSD, OpenBSD
● Apache
● Perl, PHP, Python
● Java (récent)
● Eclipse, Maven, Hudson
● GNOME, KDE, etc.
● Jonas, Jboss, MySQL, PostgreSQL
● Asterisk
● Videolan
● Firefox, OpenOffice, Thunderbird
● Talend, CPS, XWiki
● etc.
page 15

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

18. ●
Principes
●
Historique
●
Aspects juridiques
●
Aspects économiques
●
Projets / Communautés
●
Evaluation outils libres
●
Guidelines
page 18

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

25. ●
Principes
●
Historique
●
Aspects juridiques
●
Aspects économiques
●
Projets / Communautés
●
Evaluation outils libres
●
Guidelines
page 25

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

30. Licences libres
page 30

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

33. ●
Principes
●
Historique
●
Aspects juridiques
●
Aspects économiques
●
Projets / Communautés
●
Evaluation outils libres
●
Guidelines
page 33

34. $/€
● Libre == gratuit (oui, mais)
● ROI
● Technologies clés
page 34

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

36. Software Wars
page 36

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

42. Acteurs spécialisés Logiciel libre
Source : Cartographie des Entreprises du Logiciel Libre (CNLL, 2010)
page 42

43. Qui ?
(source : Sam Hocevar)
page 43

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

49. Comment ?
page 49

50. ●
Principes
●
Historique
●
Aspects juridiques
●
Aspects économiques
●
Projets / Communautés
●
Evaluation outils libres
●
Guidelines
page 50

51. Vidéo
« 5 years of Linux kernel development in GIT »
Visualisation avec GOURCE
page 51

52. Comment le libre est-il développé ?
● Outils de travail collaboratif :
● Internet, CVS, SubVersion, Git, mailing-lists, chat IRC
● « Forges » publiques (ou privées) :
–SourceForge, GitHub, LaunchPad
– FusionForge, Redmine,...
● Structure projets (caricature)
● old-style traditional model : Cathedral
● new unexpected style : Bazaar
"The Cathedral and the Bazaar" (Eric Raymond)
● Projet == réseau social
page 52

53. Communautés, résaux sociaux
Linux 1.0
(1994)
Developers linked by
common authorship to
same files
source [Robles]
page 53

54. Bon sang, mais c'est le bazar !
Classical analysis of Apache modules feb. 2004 (source [Robles])
page 54

55. Amélioration de la visualisation
Reshaped with Girvan-Newman algorithm (source
[Robles])
page 55

56. Apache 01/01/1999
page 56

57. Apache 01/01/2000
page 57

58. Apache 01/09/2000
page 58

59. Apache 01/01/2002
page 59

60. Apache 01/02/2004
page 60

61. Développement collaboratif et distribué
● Forces centrifuges
● Fork / branch
● Git, Bzr, etc
● Forces centripètes
● Cohésion
● Communauté
● Leadership
● Merge
page 61

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

63. « HOWTO » projets
basés sur le libre
page 63

64. ●
Principes
●
Historique
●
Aspects juridiques
●
Aspects économiques
●
Projets / Communautés
●
Evaluation outils libres
●
Guidelines
page 64

65. Qualités
● Prépare l'avenir
● Sécurité
● Adaptabilité
● Indépendance
● Faible coût
● Portabilité
● ...
Encore faut-il vérifier ?
Qui fait vraiment ce travail ? -> VOUS !
page 65

66. Annuaires
● Freshmeat http://freshmeat.net/ (> 39000
projets)
● FSF/Unesco : http://directory.fsf.org/ (> 5800
projets)
● Framasoft : http://framasoft.net/ (> 1400)
● Ohloh : http://ohloh.net/ (> 300 000 projets ??)
page 66

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

69. Méthode QSOS (http://www.qsos.org/)
page 69

70. Fiche QSOS
page 70

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>