Logiciels libres - Département d`informatique et de recherche

IFT3902 :
(Gestion de projet pour le)
développement, (et la)
maintenance des logiciels
Yann-Gaël Guéhéneuc
Professeur adjoint
[email protected], local 2345
Département d’informatique et de recherche opérationnelle
Université de Montréal
© Yann-Gaël Guéhéneuc 2004
Les logiciels libres
1.
2.
3.
4.
5.
Définitions
Naissance
Gestion de projet
Avantages / inconvénients
Pour approfondir
2/44
1. Définitions
n Free
(1/8)
software : logiciel libre
– Richard Stallman
– 1975 : Emacs au MIT AI Lab.
– 1984 : commencement « officiel » du projet
GNU avec Bison (cf. Yacc)
– 1985 : création de la Free Software Foundation
+ licence GNU GPL
– 1990 : bibliothèque C et interpréteur Bash
– 1996 : première version du noyau Hurd
3/44
1. Définitions
n
(2/8)
Free software : logiciel libre
– Liberté d'exécuter le programme, pour tous les usages
(liberté 0)
– Liberté d'étudier le fonctionnement du programme, et de
l'adapter (liberté 1)
– Liberté de redistribuer des copies, donc d'aider votre
voisin (liberté 2)
– Liberté d'améliorer le programme et de publier vos
améliorations, pour en faire profiter toute la communauté
(liberté 3)
Humanisme (et Trois Lois de la Robotique J)
4/44
1. Définitions
(3/8)
n Open
source software : logiciel avec code
source ouvert
– Eric Raymond
– Deuxième génération de hackers
– 1980 : projet Xanadu (hypertexte)
– 1991 : presque co-inventeur du WWW + New
Hacker’s Dictionary aux MIT Press
– 1997 : « La cathédrale et le bazar »
– 1998 : idée de code source ouvert
5/44
1. Définitions
(4/8)
n Open
source software : logiciel avec code
source ouvert
n
n
n
n
n
n
Redistribution libre
Code source
Travaux dérivés
Intégrité du code source de
l’auteur originel
Pas de discrimination contre
des personnes ou des
groupes de personnes
Pas de discrimination
contres des champs
d’activités
n
n
n
n
Distribution de licence
Licence non spécifique à un
produit
Licence ne doit pas
restreindre d’autres logiciels
Licence doit être
technologiquement neutre
Pragmatisme
6/44
1. Définitions
n En
(5/8)
clair… Un logiciel « libre »
– Est disponible « gratuitement » depuis au moins
une source de diffusion (d’autres sources
peuvent être payantes)
– Peut être utilisé pour des développements
commerciaux ou sans but lucratif, même par
ceux n’ayant pas payé (il peut y avoir des
restrictions)
– Peut être obtenu sous forme de code source
7/44
1. Définitions
(6/8)
n Philosophies
– Proprietary software is legal but illegitimate and immoral. Manufacturing and
using proprietary software causes a lot of unhappy social and psychological
side-effects. The knowledge that a software cannot be shared causes
people to become reluctant to sharing, which is a natural and good part of
living in a human society. The inability of people to modify software for their
own needs, makes them feel helpless, and at the mercy of external
software
– Proprietary software is not illegitimate, just problematic from the economic
sense. Open Source software gives many advantages to the end-users and
is a generally a good thing. Copyleft licenses are important in making sure
certain software is not abused. It is not immoral to use proprietary software,
it's just risky. Using or producing software that is not 100% open-source but
pretty close can be a good idea, depending on its license and the general
attitude of its developers
8/44
1. Définitions
n Philosophies
(7/8)
appliquées
– Licence sous gauche d’auteurs (copyleft)
• GPL
• Pas de dérivés privés sauf pour l’auteur
• Stratégie de marque (branding)
– Licence « ouverte »
• Apache, BSD…
• Possibilité d’ajouter des innovations et de les vendre
en plus du projet
• Renommée, qualité, consistance
9/44
1. Définitions
(8/8)
Voir www.fsf.org/philosophy/categories.html
10/44
Les logiciels libres
1.
2.
3.
4.
5.
Définitions
Naissance
Gestion de projets libres
Avantages / inconvénients
Pour approfondir
11/44
2. Naissance
(1/2)
n Les
logiciels libres / à code source ouvert
implantent (souvent) des normes ouvertes
– Norme Posix → Linux
– Norme TCP/IP → Internet (logiciels BSD)
– Norme HTML → Web
– Norme J2EE → JBoss
– Norme BitTorrent → Azureus
12/44
2. Naissance
n Norme
(2/2)
ouverte
– Documentation
– Implantation de référence
– Tests unitaires
13/44
Les logiciels libres
1.
2.
3.
4.
5.
Définitions
Naissance
Gestion de projets libres
Avantages / inconvénients
Pour approfondir
14/44
3. Gestion de projet
(1/20)
n Pas
de processus de développement
« formalisé »
n Structure
externe toujours par projet
n Structure interne peut être contrôle
centralisé, décentralisé, egoless
programming team
15/44
3. Gestion de projet
n Emacs
(2/20)
(www.gnu.org/software/emacs/)
– Depuis 1975 ! J
– Télécharger le code source
– Écrire une « rustine »
– Soumettre à [email protected]
16/44
3. Gestion de projet
n Emacs
(3/20)
(www.gnu.org/software/emacs/)
– Revue par quelqu’un ?
– Incorporée ?
– Le développement se fait de manière assez
anarchique
17/44
3. Gestion de projet
n XEmacs
(4/20)
(www.xemacs.org)
– Télécharger le code source
– Écrire une « rustine »
– Soumettre à [email protected]
– Revue par les membres du conseil
18/44
3. Gestion de projet
n XEmacs
(5/20)
(www.xemacs.org)
– Chaque membre du conseil connaît un domaine
précis (?)
• Support Cygwin
• Mule
• …
Et a accès seulement à son domaine
19/44
3. Gestion de projet
n Linux
(6/20)
(www.tux.org, vger.kernel.org)
– Télécharger le code source
– Écrire une « rustine »
– Soumettre à [email protected] (ou
autre liste de diffusion)
– Revue par les lieutenants de Linus Torvald
– Envoyé à Linus Torvald qui centralise
l’application des rustines
20/44
3. Gestion de projet
n Linux
(7/20)
(www.tux.org, vger.kernel.org)
– Linus Torvald semble déléguer le contrôle de
plus en plus à ses lieutenants
21/44
3. Gestion de projet
n Eclipse
(8/20)
(www.eclipse.org)
– Télécharger le code source
– Écrire une « rustine »
– Attacher la « rustine » au bogue associé dans
Bugzilla
22/44
n Eclipse
(www.eclipse.org)
3. Gestion de projets libres
(9/20)
23/44
3. Gestion de projet
n Eclipse
(10/20)
(www.eclipse.org)
– Envoyer la « rustine » à l’équipe concernée et
signer un décharge
– Revue par les développeurs concernés
– Au bout d’un certain temps (et du nombre de
rustines et de leur qualité), un contributeur peut
devenir comitter
– Le contributeur n’est pas obligé de maintenir
son code
24/44
3. Gestion de projet
n Eclipse
(11/20)
(www.eclipse.org)
– Une certaine tendance dans les projets à code
source ouvert « entreprise »
• Une entreprise réalise le noyau
• L’entreprise gère l’addition des rustines des
contributeurs
• Certains contributeurs peuvent contribuer
directement (au mérite)
25/44
3. Gestion de projet
(12/20)
n Mozilla
(www.mozilla.org/hacking/life-cycle.html)
– Télécharger le code source
– Compiler le code source
– Suivre les conventions de programmation
• Règles de style
• Règles de portabilité
– Écrire une « rustine »
– Attacher la « rustine » à un (au) bogue (associé)
dans Bugzilla
26/44
3. Gestion de projet
(13/20)
n Mozilla
(www.mozilla.org/hacking/life-cycle.html)
– Révision par le propriétaire du module réparé
(ou ses collègues)
– Super-révision par un groupe de développeurs
« acharnés »
• <module owner>@<address>.<domain>
• [email protected]
• [email protected]
27/44
3. Gestion de projet
(14/20)
n Mozilla
(www.mozilla.org/roadmap.html)
– Carte routière (au 08/11/04)
28/44
3. Gestion de projet
(15/20)
n Mozilla
(www.mozilla.org/contribute/
hacking/first-bug/)
– Prendre en main le code source
– Écrire des rustines
– Simplifier le code
– Minimiser la taille du code
29/44
3. Gestion de projet
n Mozilla
(16/20)
(www.mozilla.org/tools.html)
– CVS : gestion du code source
– LXR : navigation dans le code source
– Bonsai : contrôle de l’arbre CVS
– Tinderbox : contrôle des « builds »
– Bugzilla : contrôle des bogues
– Doctor : édition des pages web
30/44
3. Gestion de projet
(17/20)
n Mozilla
(www.mozilla.org/projects/marketing/)
– Équipe pour l’identité visuelle de Mozilla
– Lettre de nouvelles
– Documentation de Mozilla
– Les champions de Mozilla (comme au temps
des gladiateurs)
– Par exemple : Firefox (www.spreadfirefox.com) !
31/44
3. Gestion de projet
(18/20)
n SourceForge (www.sourceforge.net)
– Référentiel de projets libres
– Techniques pour développer les projets
•
•
•
•
•
Pages Web
Listes de diffusion
Suivi des bogues
CVS
…
32/44
3. Gestion de projet
(19/20)
n SourceForge (www.sourceforge.net)
– L’administrateur de chaque projet contrôle
• Les permissions des développeurs pour
– Le suivi des bogues
– Les forums de discussion
– Le gestionnaire des tâches
• Tous les développeurs ont accès au serveur CVS
– L’administrateur de chaque projet peut
demander… des dons !
33/44
n SourceForge
: le projet Azureus
3. Gestion de projets libres
(20/20)
34/44
Les logiciels libres
1.
2.
3.
4.
5.
Définitions
Naissance
Gestion de projets libres
Avantages / inconvénients
Pour approfondir
35/44
4. Avantages/inconvénients
(1/5)
n Qualité
– La qualité des projets libres a été jugée
comparable à celle de projets propriétaires
– Les bogues peuvent être corriger plus
rapidement
– Mais tout le monde est un « client » du code
même son développeur originel !
36/44
4. Avantages/inconvénients
(2/5)
n Financement
– « Gratuit » ?
• Mécènes, millionnaires
– Donation
• Temps libre
– Financé par les impôts
• Universités
Voir www.apostate.com/programming/bm-freesoftware.html
37/44
4. Avantages/inconvénients
(3/5)
n Financement
– Fonds privés
• Entreprises
– Sponsorisé par les impôts, par le privé
• Universités, entreprises
• Le système GNU de Richard Stallman
Voir www.apostate.com/programming/bm-freesoftware.html
38/44
4. Avantages/inconvénients
n Retombées
(4/5)
économiques
– L’argent vient de la valeur ajoutée au code
•
•
•
•
•
Mise en boîte
Documentation
Soutient aux usagers
Formation
…
39/44
4. Avantages/inconvénients
n Retombées
(5/5)
politiques
– Microsoft « contre » le Péru
– Une loi pour garantir
• L’accès libre aux informations par les citoyens
• La permanence des données publiques
• La sécurité de l’état et des citoyens
– Une loi obligeant l’état à utiliser des logiciels
libres / à code source ouvert
40/44
Les logiciels libres
1.
2.
3.
4.
5.
Définitions
Naissance
Gestion de projets libres
Avantages / inconvénients
Pour approfondir
41/44
5. Pour approfondir
n Sur
(1/3)
Linux
– Glyn Moody ; Rebel Code: Linux and the Open
Source Revolution ; Perseus Publishing,
January 23, 2001
– www.cs.helsinki.fi/linux/linux-kernel/
2002-13/0063.html
n Sur
les listes de diffusion
– www.catb.org/%7Eesr/faqs/smart-questions.html
42/44
5. Pour approfondir
n Sur
(2/3)
le développement de Linux
– catb.org/~esr/writings/cathedral-bazaar/
n Sur
le financement
– www.apostate.com/programming/bmfreesoftware.html
– www.advogato.org/article/94.html
n Sur
les retombées financières
– www.theopenenterprise.com/story/TOE2002100
8S0002
43/44
5. Pour approfondir
n Sur
(3/3)
la qualité
– www.germane-software.com/~ser/Files/
Essays/FreeCommercial.html
– www.internetnews.com/dev-news/
article.php/2230481
– mysite.fh-coburg.de/~wielandt/OSSIE03/
ossie03-SeidelNiedermeier.pdf
n Sur
les retombées politiques
– www.opensource.org/docs/peru_and_ms.php
44/44