Développement de logiciels open source

Le développement de logiciels open source (OSSD) est le processus par lequel un logiciel open source , ou un logiciel similaire dont le code source est disponible publiquement, est développé par un projet de logiciel open source . Il s'agit de produits logiciels disponibles avec leur code source sous une licence open source pour étudier, modifier et améliorer leur conception. Parmi les exemples de produits logiciels open source populaires, on peut citer Mozilla Firefox , Google Chromium , Android , LibreOffice et le lecteur multimédia VLC .

En 1997, Eric S. Raymond a écrit The Cathedral and the Bazaar . Dans ce livre, Raymond fait la distinction entre deux types de développement logiciel. Le premier est le développement conventionnel à code source fermé. Ce type de méthode de développement est, selon Raymond, comme la construction d'une cathédrale : planification centralisée, organisation serrée et un processus unique du début à la fin. Le second est le développement open source progressif, qui ressemble davantage à « un grand bazar bavard d'agendas et d'approches différents d'où un système cohérent et stable ne pourrait apparemment émerger que par une succession de miracles ». Cette dernière analogie renvoie à la discussion impliquée dans un processus de développement open source.

Les différences entre les deux styles de développement, selon Bar et Fogel, sont en général la gestion (et la création) des rapports de bugs et des demandes de fonctionnalités, ainsi que les contraintes sous lesquelles les programmeurs travaillent. Dans le développement de logiciels à source fermée, les programmeurs passent souvent beaucoup de temps à gérer et à créer des rapports de bugs, ainsi qu'à gérer les demandes de fonctionnalités. Ce temps est consacré à la création et à la priorisation de plans de développement ultérieurs. Cela conduit une partie de l'équipe de développement à passer beaucoup de temps sur ces questions, et non sur le développement lui-même. De plus, dans les projets à source fermée, les équipes de développement doivent souvent travailler sous des contraintes liées à la gestion (telles que les délais, les budgets, etc.) qui interfèrent avec les problèmes techniques du logiciel. Dans le développement de logiciels open source, ces problèmes sont résolus en intégrant les utilisateurs du logiciel dans le processus de développement, voire en laissant ces utilisateurs construire le système eux-mêmes.

Le développement de logiciels open source peut être divisé en plusieurs phases. Les phases spécifiées ici sont dérivées de Sharma et al . Un diagramme affichant la structure des processus et des données du développement de logiciels open source est présenté à droite. Dans cette image, les phases du développement de logiciels open source sont affichées, ainsi que les éléments de données correspondants. Ce diagramme est réalisé à l'aide des techniques de méta-modélisation et de modélisation de méta-processus .

Il existe plusieurs façons de démarrer un travail sur un projet open source :

1. Une personne qui ressent le besoin d’un projet annonce publiquement son intention de développer un projet.
2. Un développeur travaillant sur une base de code limitée mais fonctionnelle la publie au public en tant que première version d'un programme open source.
3. Le code source d’un projet mature est rendu public.
4. Un projet open source bien établi peut être forké par une partie extérieure intéressée.

Eric Raymond a observé dans son essai La Cathédrale et le Bazar qu’annoncer l’intention d’un projet est généralement inférieur à la publication d’un projet de travail au public.

C'est une erreur courante de démarrer un projet alors que contribuer à un projet similaire existant serait plus efficace ( syndrome du NIH ) . Pour démarrer un projet réussi, il est très important d'examiner ce qui existe déjà. Le processus commence par un choix entre l'adoption d'un projet existant ou le démarrage d'un nouveau projet. Si un nouveau projet est lancé, le processus passe à la phase d'initiation. Si un projet existant est adopté, le processus passe directement à la phase d'exécution.

Il existe plusieurs types de projets open source. Tout d'abord, il y a les logiciels et bibliothèques de base, qui sont constitués de morceaux de code autonomes. Certains peuvent même dépendre d'autres projets open source. Ces projets répondent à un objectif précis et à un besoin précis. Parmi les exemples de ce type de projets, on peut citer le noyau Linux , le navigateur Web Firefox et la suite d'outils bureautiques LibreOffice.

Les distributions sont un autre type de projet open source. Les distributions sont des collections de logiciels publiés à partir de la même source avec un objectif commun. L'exemple le plus connu d'une « distribution » est un système d'exploitation. Il existe de nombreuses distributions Linux (telles que Debian , Fedora Core , Mandriva , Slackware , Ubuntu etc.) qui intègrent le noyau Linux ainsi que de nombreux composants utilisateur. Il existe d'autres distributions, comme ActivePerl, le langage de programmation Perl pour divers systèmes d'exploitation, et les distributions Cygwin de programmes open source pour Microsoft Windows .

D'autres projets open source, comme les dérivés de BSD , conservent le code source d'un système d'exploitation entier, le noyau et tous ses composants principaux, dans un système de contrôle de révision unique ; ils développent l'ensemble du système en équipe unique. Ces projets de développement de systèmes d'exploitation intègrent étroitement leurs outils, plus que dans les autres systèmes basés sur une distribution.

Enfin, il existe le projet de livre ou de document autonome. Ces éléments ne sont généralement pas fournis dans le cadre d'un package logiciel open source. Le Linux Documentation Project héberge de nombreux projets de ce type qui documentent divers aspects du système d'exploitation Linux. Il existe de nombreux autres exemples de ce type de projet open source.

Il est difficile de mener un projet open source en suivant une méthode de développement de logiciel plus traditionnelle comme le modèle en cascade , car ces méthodes traditionnelles ne permettent pas de revenir à une phase antérieure. Dans le développement de logiciels open source, les exigences sont rarement recueillies avant le début du projet ; elles sont plutôt basées sur les premières versions du produit logiciel, comme le décrit Robbins. Outre les exigences, des bénévoles sont souvent attirés pour aider au développement du produit logiciel en se basant sur les premières versions du logiciel. Cet effet de réseau est essentiel selon Abrahamsson et al. : « si le prototype présenté attire suffisamment d’attention, il commencera progressivement à attirer de plus en plus de développeurs ». Cependant, Abrahamsson et al. soulignent également que la communauté est très dure, tout comme le monde des affaires du logiciel à source fermée : « si vous trouvez les clients, vous survivez, mais sans clients, vous mourez ».

Fuggetta soutient que « le prototypage rapide, le développement incrémental et évolutif, le cycle de vie en spirale, le développement rapide d'applications et, récemment, la programmation extrême et le processus logiciel agile peuvent être appliqués de la même manière aux logiciels propriétaires et open source ». Il souligne également que la programmation extrême est une méthode extrêmement utile pour le développement de logiciels open source. Plus généralement, toutes les méthodes de programmation agile sont applicables au développement de logiciels open source, en raison de leur caractère itératif et incrémental. D'autres méthodes agiles sont également utiles pour le développement de logiciels open source et fermés : Internet-Speed ​​Development , par exemple, convient au développement de logiciels open source en raison du principe de développement distribué qu'il adopte. Internet-Speed ​​Development utilise des équipes géographiquement dispersées pour « travailler 24 heures sur 24 ». Cette méthode, principalement adoptée par les grandes entreprises fermées (car elles sont les seules à pouvoir se permettre des centres de développement dans différents fuseaux horaires), fonctionne tout aussi bien dans les projets open source car un logiciel développé par un grand groupe de bénévoles aura naturellement tendance à avoir des développeurs répartis sur tous les fuseaux horaires.

Les développeurs et les utilisateurs d'un projet open source ne travaillent pas nécessairement tous à proximité sur le projet. Ils ont besoin de moyens de communication électroniques. Le courrier électronique est l'une des formes de communication les plus courantes entre les développeurs et les utilisateurs open source. Souvent, des listes de diffusion électroniques sont utilisées pour s'assurer que les messages électroniques sont délivrés à toutes les parties intéressées en même temps. Cela garantit qu'au moins un des membres peut y répondre. Afin de communiquer en temps réel, de nombreux projets utilisent une méthode de messagerie instantanée telle que IRC . Les forums Web sont récemment devenus un moyen courant pour les utilisateurs d'obtenir de l'aide en cas de problèmes qu'ils rencontrent lors de l'utilisation d'un produit open source. Les wikis sont devenus un moyen de communication courant pour les développeurs et les utilisateurs.

Dans le développement d'OSS, les participants, qui sont pour la plupart des bénévoles, sont répartis dans différentes régions géographiques. Il est donc nécessaire de disposer d'outils pour aider les participants à collaborer au développement du code source.

Au début des années 2000, Concurrent Versions System (CVS) était un exemple frappant d'outil de collaboration de code source utilisé dans les projets OSS. CVS permet de gérer les fichiers et les codes d'un projet lorsque plusieurs personnes travaillent sur le projet en même temps. CVS permet à plusieurs personnes de travailler sur le même fichier en même temps. Cela se fait en déplaçant le fichier dans les répertoires des utilisateurs, puis en fusionnant les fichiers lorsque les utilisateurs ont terminé. CVS permet également de récupérer facilement une version précédente d'un fichier. Au milieu des années 2000, le système de contrôle de révision Subversion (SVN) a été créé pour remplacer CVS. Il gagne rapidement du terrain en tant que système de contrôle de version de projet OSS.

De nombreux projets open source utilisent désormais des systèmes de contrôle de révision distribués, qui évoluent mieux que les référentiels centralisés tels que SVN et CVS. Des exemples populaires sont git , utilisé par le noyau Linux , et Mercurial , utilisé par le langage de programmation Python .

La plupart des projets à grande échelle nécessitent un système de suivi des bogues pour suivre l’état des différents problèmes dans le développement du projet.

Les projets OSS étant soumis à des intégrations fréquentes, des outils permettant d'automatiser les tests lors de l'intégration du système sont utilisés. Tinderbox est un exemple de ce type d'outil. Tinderbox permet aux participants d'un projet OSS de détecter les erreurs lors de l'intégration du système. Tinderbox exécute un processus de construction continu et informe les utilisateurs des parties du code source qui présentent des problèmes et sur quelle(s) plateforme(s) ces problèmes surviennent.

Un débogueur est un programme informatique utilisé pour déboguer (et parfois tester ou optimiser) d'autres programmes. GNU Debugger (GDB) est un exemple de débogueur utilisé dans le développement de logiciels open source. Ce débogueur offre un débogage à distance, ce qui le rend particulièrement applicable au développement de logiciels open source.

Un outil de détection de fuite de mémoire ou débogueur de mémoire est un outil de programmation permettant de détecter les fuites de mémoire et les dépassements de tampon . Une fuite de mémoire est un type particulier de consommation de mémoire inutile par un programme informatique, où le programme ne parvient pas à libérer de la mémoire qui n'est plus nécessaire. Des exemples d'outils de détection de fuite de mémoire utilisés par Mozilla sont les outils XPCOM Memory Leak. Les outils de validation sont utilisés pour vérifier si des morceaux de code sont conformes à la syntaxe spécifiée. Un exemple d'outil de validation est Splint .

Un système de gestion de paquets est un ensemble d'outils permettant d'automatiser le processus d'installation, de mise à niveau, de configuration et de suppression de paquets logiciels d'un ordinateur. Red Hat Package Manager (RPM) pour le format de fichier .rpm et Advanced Packaging Tool (APT) pour le format de fichier .deb sont des systèmes de gestion de paquets utilisés par un certain nombre de distributions Linux.

Répertoires de logiciels et journaux de versions :

1. Le répertoire des logiciels libres

Articles:

1. Actualités hebdomadaires sur Linux
2. IBM DeveloperWorks