Embed Size (px)
Citation preview
Logiciels libres
Olivier Berger, TELECOM SudParis - Département INF<[email protected]>
Telecom SudParisCSC4522 / DSI - 2010/06/10
page 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 3
Sondage rapide
● Déjà eu des cours sur le sujet ?
● Logiciel libre ?
● Linux ?
● GNU ?
● FSF ?
● APRIL, AFUL, etc. ?
● Firefox ?
● Ubuntu ?
● Creative Commons ?
● SourceForge ?
● Bugzilla ?
page 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 5
Contenu
Introduction générale
page 6
Pourquoi ?
page 7
Le logiciel libre incontournable
● Semble simple
● Loin d'être si simple
● Processus humains plus que technologiques
● Pluri-disciplinaire
● Oportunités
● Risques
Introduction générale sur le libre
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines
page 9
Liberté, égalité, fraternité...
4 libertés
page 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 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 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 13
Logiciel libre
page 14
Logiciel non-libre (Propriétaire)
page 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 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)
● APRIL, en france http://www.april.org/http://stallman.org/
page 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 18
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines
page 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 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
● ...
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 ?
Résistances
● Copyright / droit d'auteur
● Brevets
● DRM
● FUD
● Hadopi
● ...
page 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 24
Qu'est-ce que le logiciel libre ?
● Juridique / Licences
● Organisationnel / Communautés
● Economique / Modèles d'affaires
Pas un seul modèle !
page 25
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines
page 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 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 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 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 30
Licences libres
page 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 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 33
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines
page 34
$ / €
● Libre == gratuit (oui, mais)
● ROI
● Technologies clés
page 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 36
Software Wars
page 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 38
« Commoditisation » du logiciel
source : Frank van der Linden (Philips)
page 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 (Méthodologie discutable)
page 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 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 42
Acteurs spécialisés Logiciel libre
Source : Cartographie des Entreprises du Logiciel Libre (CNLL, 2010)
page 43
Qui ?
(source : Sam Hocevar)
page 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 45
Rapide panorama d'un écosystème
Développeursamont
(“upstream”)
OpenSuse
DebianDebian
RedHatRedHat
distributions
versions
versions
versions
bugs
bugs
bugs
Utilisateurs
SSIIÉditeurs
packages
bugs
page 46
Le libre est global
● debian
Debian developers
page 47
Où sont ces développeurs ?
Par pays (SourceForge) :
Rang Pays Developpeurs1. United States 4256202. Germany 958003. United Kingdom 607684. Canada 491095. France 445876. China 36517... ... ...
(source : Gregorio Robles and Jesús M. González Barahona - 2006)
page 48
Où sont ces développeurs ? (2)
Par continent :
Continent DéveloppeursAfrica 12 560Asia 127 275EU401 845Europe 466 792North America 485 679Oceania 46 422South America 36 330
(source : Gregorio Robles and Jesús M. González Barahona – 2006)
page 49
Comment ?
page 50
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines
page 51
Vidéo
« 5 years of Linux kernel development in GIT »
Visualisation avec GOURCE
page 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 53
Communautés, résaux sociaux
Linux 1.0 (1994)Developers linked by common authorship to same files
source [Robles]
page 54
Bon sang, mais c'est le bazar !
Classical analysis of Apache modules feb. 2004 (source [Robles])
page 55
Amélioration de la visualisation
Reshaped with Girvan-Newman algorithm (source [Robles])
page 56
Apache 01/01/1999
page 57
Apache 01/01/2000
page 58
Apache 01/09/2000
page 59
Apache 01/01/2002
page 60
Apache 01/02/2004
page 61
Développement collaboratif et distribué
● Forces centrifuges● Fork / branch
● Git, Bzr, etc
● Forces centripètes● Cohésion
● Communauté
● Leadership
● Merge
page 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 63
« HOWTO » projets
basés sur le libre
page 64
● Principes
● Historique
● Aspects juridiques
● Aspects économiques
● Projets / Communautés
● Evaluation outils libres
● Guidelines
page 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 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 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 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 70
Fiche QSOS
page 71
Conduite de projetAnalyse des besoins
Spécification
Architecture
Conception détaillée
Codage
Tests
Déploiement
?
page 72
Maintien en condition opérationnelle
● Réactivité pour les mises à jour
● Diminuer l'adhérence dans les composants spécifiques
page 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 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 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 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 77
Spécificités du projet
● Pas que la licence
● Communauté● développement
● utilisatrice
● Personnes, rôles
● Acteurs économiques
● But, objectifs
● Méthodologie
page 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 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 80
Où rencontrer la communauté
● En ligne
● Salons / conférences :● Solutions Linux
● Rencontres Mondiales LL
● Open World Forum
● FOSDEM
● Associations :● April
● CNLL
● etc.
page 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 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 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 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 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-ouverts-et-interoperabilite
● 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 86
Conditions d'utilisation
● This work is Copyright 2009-2010 by Institut TELECOM and Olivier Berger, published under a Creative Commons ShareAlike license
direction ou services <pied de page>page 87
Merci de votre attention
http://www-public.it-sudparis.eu/~berger_o/weblog/
