Un entretien avec FusionForge

Posté par (page perso) . Modéré par baud123. Licence CC by-sa
27
5
nov.
2011
Gestion de versions

Qui ne connaît pas FusionForge, la célèbre forge logicielle ? Mais, qui connaît bien FusionForge et ses auteurs ?

La seconde partie de la dépêches vous propose le compte rendu d’un entretien avec trois de ses développeurs francophones.

LinuxFr.org : Qui êtes‐vous ?

nerville : Contributeur Fusionforge depuis bientôt 2 ans, je suis sponsorisé par la société Capgemini pour mon travail sur Fusionforge. Je suis aussi contributeur au projet Archipel (http://archipelproject.org) et co‐fondateur de la société TrivialDev (http://trivialdev.com), spin‐off autour d’Archipel. Je suis surtout « C01N C01N WILL SAVE YOUR SOUL !!! ».

Lolando : Un vieux de la vieille, qui a commencé à bosser sur l’empaquetage Debian de SourceForge en 2000/2001, et qui a suivi les forks et renommages depuis. Comme à un moment je me suis aperçu que les forges sont des choses utiles, et que ça n’intéressait personne de s’en occuper sauf moi, je me suis mis à mon compte pour faire le geek intérimaire chez les gens qui n’ont pas de gens à plein temps à consacrer à leur administration système ou à leur forge.

aljeux : Je travaille pour Alcatel‐Lucent et je suis responsable des différentes forges basées sur FusionForge. J’ai commencé à travailler sur les forges il y a environ six ans. À cette époque, nous cherchions une solution pour améliorer les synergies entre nos équipes de R & D réparties dans le monde. Nous avons alors pensé qu’une forge pourrait à la fois permettre aux équipes de mieux savoir ce que les autres font et, donc, d’aider à la réutilisation de code ou au partage d’expérience. J’ai aussi beaucoup appris de ce projet car l’organisation est assez différente dans un projet open source de ce que l’on trouve en entreprise.

LinuxFr.org : C’est quoi FusionForge ? Qu’est‐ce que ça fait, et comment ?

nerville : C’est une suite de génie logiciel offrant les fonctionnalités de gestion de projets, avec des notions de pilotage de projet (planification, avancement). On parle facilement de forge logicielle. Comment ça marche ? FusionForge est un point d’accès unique à une longue série d’outils permettant leur administration et leur utilisation de façon simplifiée. FusionForge offre un cadre d’industrialisation méthodologique de projets.

Lolando : Comme nerville l’a dit, pour les développeurs, ça fournit un point central avec tous les outils (trackers, forums, gestion de versions, etc.). Pour les utilisateurs, ça permet d’ancrer une communauté. Pour les admins système, ça centralise plusieurs outils à un seul endroit, donc ça évite d’avoir à gérer une foule de trucs installés à gauche et à droite par chaque équipe. Et pour les éventuels managers, ça permet de savoir où en est chaque projet, sans avoir à embêter directement les développeurs. Pour la question sur le « comment », c’est principalement une interface Web-Apache-PHP-PostgreSQL-tout-ça, mais ça s’interface avec d’autres outils (gestion de sources, listes de diffusion, etc.), et il y a une grosse poignée de scripts qui s’exécutent en tâche de fond pour orchestrer le tout.

aljeux : FusionForge, c’est la possibilité d’avoir son propre SourceForge, que ce soit pour un petit projet ou pour une entreprise.

LinuxFr.org : C’est sous quelle(s) licence(s) ?

nerville / Lolando / aljeux : Majoritairement GPL v2/v2+. Il y a quelques briques avec des licences BSD.

LinuxFr.org : C’est développé autour de quelles « technos » ?

nerville : Le code est hérité de la souche originale de sourceforge.net, écrite en 1999. Les technologies mises en œuvre sont : PHP, HTML, JavaScript, PostgreSQL, Apache httpd pour toute la partie frontale, mais c’est surtout une intégration de toute une série d’outils offrant déjà des fonctionnalités de travail collaboratif dans différents domaines. Par exemple, dans le monde du SCM, on retrouve Subversion, Git, Mercurial, ViewVC ; dans le monde de la messagerie, on retrouve Mailman (et bientôt Sympa).

Lolando : On gère aussi Bazaar, CVS bien sûr, et même CPOLD.

aljeux : En gros : Linux/Apache/PostgreSQL/PHP (LAPP) + logiciels tiers type Subversion, etc..

LinuxFr.org : Même si FusionForge a une longue histoire, ça a l’air de plutôt bien s’adapter au temps qui passe, non ?

nerville : Les besoins d’industrialisation d’un projet sont finalement les mêmes à travers le temps. Le code peer review n’a pas été inventé par GitHub. Fonctionnellement, FusionForge est toujours à jour. Le gros truc est de suivre les tendances en termes d’outils intégrés. La modularité de FusionForge permet de répondre à cette dynamique.
Dernier point, FusionForge a aussi besoin de suivre les mouvements autour de l’interface.

Lolando : On a eu un gros passage à vide en 2007-2008 (c’était l’époque floue de GForge) qui nous a fait prendre conscience qu’on ne peut pas développer un truc tout seul dans notre coin. Du coup, quand on a commencé FF, on a tout de suite essayé d’impliquer les utilisateurs, et surtout les gros utilisateurs, parce que c’est d’eux que vient l’impulsion pour les évolutions, voire le code lui‐même. La conséquence directe, c’est que FF évolue en fonction des besoins réels (ou perçus), donc reste toujours relativement connecté à l’air du temps.

aljeux : Oui, d’un côté, il y a les évolutions récentes, comme l’ajout des SCM distribués ou des greffons comme Hudson/Jenkins, et d’un autre côté, des efforts pour simplifier et améliorer la cohérence de l’ensemble.

LinuxFr.org : Ça se compare à quoi de libre ou proprio ?

nerville : En libre, cela se compare à des solutions telles que Redmine ou Tuleap. En propriétaire, on peut comparer ça à CollabNet TeamForge, anciennement connu sous le nom de SourceForge Enterprise Edition. Vous imaginez bien la relation d’héritage entre les produits.

Lolando : Fonctionnellement, si on appelle forge un ensemble d’outils aidant le développement collaboratif, on peut aussi inclure Trac et Launchpad. En propriétaire, on peut probablement citer aussi la suite d’IBM.

aljeux : On peut aussi ajouter GitHub, Bitbucket, Google Code, CodingTeam, etc..

LinuxFr.org : Ce sont quoi les tueries de ce soft ?

nerville : La capacité de gérer de manière ultra‐simple un nombre important de projets et d’utilisateurs. Je suis régulièrement impressionné par la tenue en charge de FusionForge.
Les possibilités d’extension, le modèle est ultra-simple. On peut facilement lui accoupler n’importe quel outil. Par contre, l’interface « fin années 90 » tue ce logiciel. Mais c’est en cours d’évolution, avec un nouveau thème « Funky » et un système de bulles d’aide (sur les boutons, labels, etc.) permettant de guider l’utilisateur.
Sa communauté foncièrement ouverte est un vrai plus à FusionForge. J’ai été étonné de l’ouverture d’esprit de contributeurs, de la facilité d’entrée, du respect et des liens qui s’établissent facilement et simplement.

Lolando : La diversité de la communauté et des utilisateurs, je dirais. On a des instances complètement privées, d’autres ouvertes aux quatre vents ; certaines avec 10 000 utilisateurs et 3 000 projets, d’autres avec 10 de chaque ; certaines qui sont intégrées avec un historique et un SI d’entreprise, d’autres indépendantes. Du coup, les idées se recoupent et se combinent, et ce qui finit par être implémenté est suffisamment flexible pour être réellement utilisable dans des cas très différents.

aljeux : Les gros avantages de FusionForge sont, pour moi :

  • une forge solide basée sur des années d’utilisations ;
  • une forge capable de gérer des milliers de projets et des dizaines de milliers d’utilisateurs ;
  • un très faible coup d’administration : les projets sont complètement autonomes ;
  • la gestion de la majorité des SCM : Subversion, Git, Mercurial, Bazaar ;
  • une communauté ouverte, très accessible et très démocratique.

LinuxFr.org : Y a‐t‐il un business model autour ?

nerville : Clairement. Des sociétés se lancent. Je pense à Enalean, qui est derrière la solution Tuleap. Il y a quelque temps, Bull s’était lancé avec NovaForge.

Lolando : Il y a un business model, et même qu’il me fait vivre :-). Il y a plein d’entreprises, d’associations, d’universités, de centres de recherche, etc., qui ont besoin d’héberger des projets collaboratifs, et qui ont donc une forge. Mais comme ça inclut plein d’outils différents, et que tout le monde n’est pas forcément motivé pour se plonger dans le code, on tombe sur le business model standard du service en logiciel libre : administration, maintenance, déploiements, migrations, formation, intégration avec le reste du système d’information de l’entreprise, de l’université, du labo ; adaptation du logiciel aux contraintes locales, etc. Et tout ce qui est pertinent est reversé.

aljeux : Il y a un vrai besoin pour ce genre d’outil, et il y a de la place pour le Libre.

LinuxFr.org : Quels sont les déploiements publics ou privés (dont vous pouvez parler) les plus significatifs ?

nerville : Lors d’un salon Solutions Linux, j’avais présenté mon retour d’expérience sur FusionForge et le Ministère de l’Éducation nationale. La présentation est disponible.

Lolando : Pour les communautés libres : les forges de Debian (https://alioth.debian.org), de Blender (https://projects.blender.org) ; dans le monde associatif, la forge de l’Adullact (https://adullact.net) ; dans le monde de la recherche : les forges de l’INRIA (https://gforge.inria.fr), de l’Ifremer (https://forge.ifremer.fr), de l’INRA (http://mulcyber.toulouse.inra.fr) ; dans le monde industriel, la forge Open-DO (https://forge.open-do.org)…

aljeux : La forge dont je m’occupe est déployée en interne, elle héberge plus de mille projets avec plus de 18 000 utilisateurs. Nous avons aussi d’autres instances déployées pour des partenariats.

LinuxFr.org : Vous êtes combien de contributeurs ?

nerville : Entre 5 et 10 contributeurs actifs. Chacun ayant des rôles dédiés sans qu’il y ait eu de répartition des tâches. Par exemple, je m’occupe plus particulièrement du module « Gestion documentaire », sorte de mini‐GED. J’assure les évolutions et les correctifs de ce module. J’ai aussi développé quelques greffons dans des états de fonctionnalité variables :

  • scmhook, qui vise à offrir une gestion de bibliothèque de hooks par type de SCM ;
  • mantisbt, un greffon en accès SOAP à une installation MantisBT ;
  • la réécriture et l’extension d’un greffon de gestion de hiérarchie de projets.

Lolando : J’ajouterais que comme on a chacun ses lubies et ses cibles préférées, on se retrouve avec un script d’installation automatisée, plus d’empaquetage Debian, plus de l’empaquetage RPM, et tout ça est validé automatiquement par un serveur d’intégration continue… Ce qui est bien aussi, c’est qu’au-delà des contributeurs, on a des utilisateurs assez divers, donc on a une vision assez large, et on peut faire nos développements en allant directement dans des directions qui seront extensibles vers les besoins qu’on sent venir.

aljeux : Il y a encore de la place pour ceux qui seraient intéressés par une participation dans le Libre, car il y a beaucoup de choses à faire.

LinuxFr.org : Comment est né le projet ? Comment a‐t‐il évolué ? Quels sont les faits marquants ?

Lolando : Historiquement, Christian Bayle et moi avions commencé par bosser sur de l’empaquetage Debian et du code de SourceForge ; quand SourceForge est devenu propriétaire, et que le projet libre GForge a commencé, nous l’avons intégré rapidement. Puis, la société GForge Group a commencé à maintenir en parallèle la version libre, mais aussi une récriture propriétaire (GForge AS). La version libre a progressivement perdu en importance pour le GForge Group, et n’a plus été maintenue que par la communauté sans vraiment de visibilité. Après une certaine période d’incertitude, voire de frustration, la poignée de mainteneurs de la version libre est une deuxième fois partie avec le code et a forké/renommé en FusionForge en 2009. Un des buts du projet (et l’explication du nom) était clairement de récupérer le plus possible des évolutions qui avaient été développées en interne par les utilisateurs pendant la période de stagnation, et de les intégrer dans un projet vivant. Je pense pouvoir dire que ces deux buts ont été globalement bien atteints.

nerville : Le lancement du projet Coclico a redonné une visibilité à ce logiciel qui, à mon avis, était un peu oublié ou négligé. L’arrivée de sponsors comme Capgemini n’est pas négligeable. La dynamique actuelle est bonne, le nombre de contributeurs actifs reste stable mais les commits liés à de nouvelles fonctionnalités ont clairement augmenté.
FusionForge a vu dans les versions 5.x de grosses modifications de son fonctionnement, telles que la refonte de l’interface des pages utilisateurs et des projets, l’extension de fonctionnalités du système de suivi, la réécriture du module documentaire, la réécriture de la gestion des SCM, de nombreux greffons (intégration Gravatar, Hudson, etc.).

aljeux : Pour moi, le fait marquant principal a été notre décision de créer FusionForge, car cela nous a donné l’autonomie nécessaire pour faire évoluer le logiciel.

LinuxFr.org : Quels problèmes avez‐vous rencontrés ?

nerville : J’ai commencé avec la version 4.8 de FusionForge. Le système de configuration de la version 4.8 était, comment dire, rugueux ? La documentation était parfois absente. Il était souvent nécessaire de rentrer dans le code pour comprendre quelques options activées pour avoir la fonctionnalité attendue. De nombreux bogues étaient présents. Les fonctionnalités annoncées étaient présentes, mais cachées dans une interface vieillote et surannée. Heureusement, beaucoup de ces problèmes ont disparus. La partie interface a subi et continue de subir une réécriture avec une arrivée massive du JavaScript. Et ça, c’est une révolution pour FusionForge. Il y a de quoi en rire, mais l’ergonomie et l’expérience utilisateur reste encore assez mauvaise. De gros efforts sont faits actuellement pour qu’un utilisateur ait envie d’utiliser FusionForge.

Lolando : Beaucoup de code très très historique, effectivement. On a travaillé dessus, et on en a remplacé de gros bouts pour simplifier les API internes et faciliter l’extensibilité, mais la migration depuis les anciens systèmes vers les nouveaux ne s’est pas toujours faite sans douleur. Globalement, sur la partie Web on s’en sort à peu près bien, mais l’articulation avec les tâches de fond et certaines parties de la forge qui touchent au système (utilisateurs et groupes UNIX, intégration du courriel…) ont encore un peu l’aspect de bricolages.
On a aussi un problème bizarre : FusionForge a été démarré par une poignée de gens qui se trouvaient être français et qui ont attiré d’autres Français, et au final, on a une grosse cabale française. On essaie de se diversifier (notamment avec quelques Espagnols et Allemands), mais c’est vrai qu’on reste un projet assez peu international, ce qui est un peu ennuyeux. Alors, certes, la traduction française est bien à jour, mais les autres traînent derrière, et si un Californien, par exemple, passe sur IRC à des heures indues de la nuit ouest‐européenne, il ne trouvera pas grand monde d’actif sur #FusionForge. Mais ce n’est pas délibéré, promis, et nous accueillerions avec plaisir des contributeurs d’autres $TZ (timezone).

LinuxFr.org : Quelle est votre feuille de route ?

nerville : Je continue à me concentrer sur le module documentaire. Il ne manque que 2 ou 3 fonctionnalités majeures pour avoir un système de gestion documentaire correct. Je pense à la gestion des versions, à la notion de workflow de validation de documents et l’accès WebDAV au dépôt documentaire. Je travaille actuellement sur l’accès en écriture via WebDAV, après avoir offert l’accès en lecture seule en WebDAV en version 5.1. Objectif : Noël 2011.

Lolando : On n’a pas vraiment de feuille de route bien fixée avec des dates et tout, en fait. On trouve qu’on a un peu traîné à sortir la version 5.1, parce qu’on voulait qu’elle soit basée sur une liste d’évolutions, donc pour la 5.2, on va expérimenter avec un système de gel basé sur le temps, time-based freeze (qui ressemble un peu au processus de fenêtre d’intégration du noyau Linux) : toutes les fonctionnalités qui ne seront pas dans la branche principale au 1er décembre 2011… attendront la version suivante. Sinon, pour la TODO list, actuellement, je bosse à unifier le système de mise à jour des schémas de base de données (qui diffère selon la méthode d’installation, pour l’instant) ; une fois que ce sera fait, un audit de la base de données devrait permettre d’optimiser un paquet de requêtes (même si c’est rarement la base de données qui ralentit), et de traiter le problème de la recherche textuelle en environnement multilingue. J’ai bien envie aussi de revoir l’interaction avec l’authentification UNIX, de généraliser le système de déclencheurs intelligents pour ne plus avoir à attendre le passage d’une tâche en crontab, et ça ne ferait pas de mal de convertir toute l’interface Web pour utiliser un moteur de templates, genre Smarty, etc.. On a de quoi s’occuper. :-)

aljeux : J’ai beaucoup travaillé sur la mise en place d’un environnement de test, pour parvenir à tester automatiquement la forge et son installation. Grâce à cela, nous sommes maintenant capables de sortir une nouvelle version testée en l’espace d’une à deux heures. Pour ceux que cela intéresse, nous avons mis en place un serveur de construction Jenkins avec un système de création, installation à la demande de machines virtuelles basées sous OpenVZ (et maintenant lxc), suivi du lancement de tests fonctionnels avec PHPUnit/Selenium. Pour le futur proche, nous avons beaucoup d’améliorations sur la recherche, le gestionnaire de document et beaucoup d’autres choses. Ensuite, c’est principalement un mode collaboratif où chacun vient avec ses améliorations. Actuellement, je travaille sur l’empaquetage pour Red Hat / CentOS, et j’aimerais aussi améliorer l’expérience utilisateur, car la forge souffre d’une interface trop ancienne. À plus long terme, je pense qu’il faudrait migrer en douceur vers un framework type Yii, Zend ou Symfony.

LinuxFr.org : Pouvez‐vous nous parler brièvement du projet Coclico ?

nerville : Alors, un coquelicot est une jolie fleur rouge. Coclico a pour objectif de dynamiser l’écosystème de forges logicielles et de permettre une interaction entre elles. Coclico a sponsorisé des contributeurs à FusionForge et ça a clairement eu un impact dans la vitalité de FusionForge. Je crois sincèrement que sans Coclico, nous ne serions pas là à répondre aux questions de LinuxFr.org.

Lolando : Coclico, c’est un projet collaboratif qui a duré deux ans et vient de se terminer, qui visait à redynamiser blabla, établir des relations entre divers acteurs (français, puisqu’il y a eu des financements publics), faire converger ce qu’il était possible de faire converger, et faire interopérer ce qu’il était possible de faire interopérer. Le projet avait un pied dans FusionForge, un dans Codendi (ex‐Codex, une autre forge logicielle), un dans NovaForge, et quelques orteils dans Trac et Redmine. Pour la partie redynamisation, comme dit nerville, ça a bien marché (et ça a clairement contribué à la visibilité et au dynamisme de FusionForge). Pour le reste, on a fait converger le modèle de permissions par rôle (le résultat est un sur‐ensemble de ce que permettaient les modèles de FusionForge et de Codendi, tout en ayant une API plus simple), et on a des greffons en commun. On a aussi de l’interopérabilité avec des outils externes, notamment via le protocole OSLC-CM qui permet un accès standardisé à des systèmes de suivi. Et sur l’interopérabilité statique, le projet a grandement participé, en collaboration avec le projet ForgePlucker, à la définition et l’implémentation d’un format d’exportation de projet, qui permet, par exemple, d’archiver un projet hébergé sur un FusionForge ou un Codendi et de le réinjecter dans une autre forge (FusionForge bien sûr, mais aussi Trac ou Redmine).

LinuxFr.org : Fermeture imminente de BerliOS, quel impact pour vous ?

nerville : BerliOS était un service d’hébergement de projets. Fusionforge est un outil pour mettre en place l’infrastructure permettant d’offrir ce type de service. Je pense que les projets actuellement sur BerliOS migreront vers des sites type Bitbucket, GitHub. L’impact pour nous est minime, voire nul.

Lolando : On a déjà vu arriver des demandes de migration de projets vers alioth.debian.org, par exemple (qui est un service d’hébergement). Pour le projet FusionForge, ça ne change pas grand chose, effectivement. Mais en réfléchissant un peu au‐delà : si des projets actuellement chez BerliOS décident de s’auto‐héberger, FusionForge serait un outil particulièrement adapté. D’abord parce que BerliOS est aussi un descendant de SourceForge, donc un cousin, mais aussi à la lumière de ce qu’on disait sur ForgePlucker : il « suffirait » de transformer les exportations de BerliOS dans le format de ForgePlucker, et on pourrait réinjecter les projets en perdant le minimum de données et de méta‐données.

LinuxFr.org : Quelles sont vos relations avec les autres dérivés de SourceForge comme Codendi et le nouveau Tuleap ?

nerville : J’avoue ne pas m’intéresser aux autres projets de forge. Certains d’entre nous sont contributeurs ou utilisateurs d’autres forges, ils sont intéressés par un rapprochement. Personnellement, je me focalise plutôt sur mettre à disposition une solution fiable. Disons simplement que je nettoie devant notre porte avant de regarder les interactions possibles avec les autres.

Lolando : Le monde des forges étant à la fois relativement petit et (curieusement) assez dense en France, forcément, on les connaît, et on discute régulièrement en vrai ou via planetforge.org. Les discussions sont plutôt fonctionnelles, notamment parce que la famille Codendi / Tuleap a divergé de la famille GForge / FusionForge il y a longtemps, donc il est un peu délicat d’échanger du code directement. Mais sur les tendances, les fonctionnalités et la définition d’API, on discute avant d’implémenter.

aljeux : Nous avons à la fois des intérêts communs, car nous avons les mêmes fonctionnalités et problématiques d’intégration, mais aussi des directions et des choix technologiques différents. C’est très enrichissant de partager avec d’autres forges, mais le revers de la médaille est que l’on se retrouve avec des doublons de code qui alourdissent trop les forges. C’est un équilibre à trouver, mais je pense qu’il y a plus à gagner qu’à perdre dans ce genre de collaboration.

LinuxFr.org : Comment vous situez‐vous par rapport aux plates‐formes de « social coding » de type GitHub ?

nerville : Je suis clairement intéressé par intégrer des fonctionnalités provenant de GitHub au sein de FusionForge. Mais soyons réaliste, GitHub est git‐centric. Il manque à GitHub tout ce qu’offre Fusionforge : intégration avec des outils internes type Hudson, gestion de listes de diffusion, gestion documentaire, système de tâches et de tickets. Je vois GitHub comme une belle opportunité pour dynamiser le greffon SCMGit de FusionForge et revoir notre interface utilisateur.

Lolando : Bizarrement, l’approche un peu plus « à l’ancienne » de FusionForge est considérée comme un atout à certains endroits. Dans les environnements un peu industriels, la centralisation et le contrôle sont importants, et l’anarchie perçue fait peur aux cadres intermédiaires. Mais ça n’empêche pas de rester à l’affût de fonctionnalités qui seraient utiles à FusionForge.

aljeux : En fait, je pense qu’il faudrait arriver à marier les deux. Il faut un mode projet relativement bien structuré, car cela donne un référentiel stable ; mais permettre aussi la souplesse d’un mode plus personnel, car cela facilite l’innovation et l’investissement personnel.

LinuxFr.org : Merci les mecs !

  • # Moi

    Posté par . Évalué à 10.

    Je ne connais pas FusionForge.

    Heureux d'avoir pu aider.

    BeOS le faisait il y a 15 ans !

  • # lien

    Posté par (page perso) . Évalué à 3.

    Y a une erreur dans le lien vers Open-DO ")..." a la fin

    Sinon très bon entretien, je connais pas tellement le monde des forges mais c'est intéressant

  • # Les forges perdent du terrain face à des solutions propriétaires

    Posté par . Évalué à 10.

    Je pense que les projets actuellement du BerliOS migreront vers des sites type Bitbucket, Github. L'impact pour nous est minime voire nul.

    Pour moi ces deux phrases consécutives sont une contradiction. On a une tradition relativement solide de forges libres et riches en fonctionnalité, mais fracturées (chacun sa forge), lourdes et évoluant lentement. Depuis quelques années apparaissent des solutions plus légères, qui proposent un hébergement global, et majoritairement propriétaires.

    Concrètement, dans la communauté du logiciel libre, les forges sont en train de mourir. Dire que les utilisateurs de BerliOS vont migrer vers des solutions d'hébergement propriétaires, ça n'a pas "un impact minime" sur les forges : c'est un clou de plus dans leur cercueil.

    Je remarque par ailleurs que cette dépêche a cité github un grand nombre de fois (8 à la louche), sans même mentionner gitorious, une alternative libre raisonnable (même si moins riche en fonctionnalités).
    Je trouve dommage ce monopole de github et bitbucket; on dirait que les développeurs de logiciels libres, qui font des efforts pour utiliser des outils libres sur leur machine, ne se posent pas la question pour les outils disponibles en ligne. On a en plus un effet réseau bien entretenu par le fait que tout le monde ne parle que d'eux. Résultat, quand un développeur se cherche un hébergeur (au hasard, Linus Torvalds), il va choisir un hébergeur propriétaire parce que "c'est le nom qu'il a retenu parce qu'on le voit partout".

  • # Recherche de livre blanc sur les "forges" de logiciels

    Posté par . Évalué à 0.

    Merci pour cet entretien intéressant.

    Je recherche un livre blanc sur les forges de logiciels libres.

    merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.