Forges logicielles et hébergement de projets libres

30
26
juil.
2018
Communauté

Une forge logicielle est un outil qui permet de travailler et collaborer autour d’un projet logiciel.

Elle comporte généralement un gestionnaire de code source, un visualiseur de code source, une gestion des droits d’accès, un gestionnaire de tickets, un espace de rédaction (wiki…) et des fonctionnalités de gestion de projet.

Panorama des solutions libres de forge logicielle

Les infos ci‐dessous ne sont probablement pas exhaustives et pourront être complétées grâce à vos commentaires. Elles montrent néanmoins assez clairement plusieurs éléments :

  • la profusion de solutions techniques, utilisant des langages différents et des technologies variées ;
  • les différents niveaux de services rendus ;
  • la notoriété de quelques gros acteurs et néanmoins la présence de nombreux plus petits acteurs (historique ou marché de niche) ;
  • la profusion des solutions disparues : être adossé à une grande boîte ne rend pas une forge immortelle ;
  • l’évolution dans le temps : vieillissement des choix techniques, nouveaux langages ou nouvelles technologies apparues depuis, importance du choix des communautés, importance du choix de la masse des projets.

Forges logicielles d’actualité

Nom Technologie utilisée Exemple d’utilisateur(s) et dernière version stable
Allura Python SourceForge, fournit une page de comparaison des forges, v1.0.0 (août 2013) → v1.8.1 (mars 2018)
Gogs Go ULCO connue pour son Master Ingénierie du Logiciel Libre et NotABug.org qui a créé une divergence ; 0.11.53 le 5 juin 2018
Gitea - Divergence de Gogs car le développeur et créateur du projet fut à plusieurs reprises inactif plusieurs mois sur le projet et semblait peu ouvert aux contributions externes ; 1.4.3 le 26 juin 2018
GitLab Community Ruby Framagit et Unixcorn ; 11.1 le 22 juillet 2018
Phabricator PHP Wikipédia, Enlightenment ; rolling out depuis le dépôt Git
Redmine Ruby Rudder, v3.4.6 le 10 juin 2018
Savane PHP Savannah (FSF) ; plutôt moribond
Trac Python LIP6, v1.2 en nov. 2016
Tuleap PHP GNU Ring, v4.0.9 (juillet 2010) → v10.0 (avril 2018)
FusionForge PHP Forge Alioth de Debian, SourceSup de Renater ; 6.0.5 en décembre 2016
VHFFS PHP / C / Perl TuxFamily et Toile-Libre, v4.6.0 en octobre 2016 et 4.7-dev-fbf4cb479d
Launchpad - Forge de Canonical (Ubuntu), devenue libre (AGPL) en 2009 ; rolling out depuis le dépôt Bzr
Fossil C SQLite et Chiselapp ; 2.6 depuis le 5 mai 2018
Pagure Python+Git 4.0.4 le 19 juillet 2018
GitPrep Perl rolling out depuis le dépôt Git

Note : GitHub n’est pas libre (ni même open source), on peut à ce sujet relire les critiques de Carl Chenet.

Celles qui ont disparu

Note : Google Code a fermé en 2015 (voir ce journal sur la fermeture) mais n’était pas sous licence libre.

Logiciels proches mais qui ne disposent pas de toutes les fonctionnalités

Il existe aussi des logiciels n’offrant pas toutes les fonctionnalités habituellement attendues d’une forge. Par exemple :

  • gestion des dépôts et du code source (contributions, revues, accès) :
    • RhodeCode Community Edition, la base en logiciel libre de RhodeCode Entreprise Edition ; développé en Python, les contributions doivent être sous licence MIT, ce qui permet à la société de les inclure aussi dans la version non libre ; 4.12.4 le 16 juillet 2018,
    • Kallithea, divergence de RhodeCode car la licence n’était pas claire ; développé en Python ; utilisé par exemple par le Software Freedom Conservancy ; historique des versions : 0.1 (août 2014) → 0.3.5 (juin 2018) ;
    • etc.

Aller plus loin

  • # Forge décentralisée basée sur XMPP

    Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 27 juillet 2018 à 07:14.

    Bonjour,

    j'en profite pour indiquer que je suis plus ou moins en train de faire une forge décentralisée basé sur XMPP et indépendante de l'outil de version de contrôle (utilisé avec Mercurial actuellement, mais n'importe lequel peut être intégré, Git inclus bien entendu).

    J'ai écris 2 billets à ce sujet pour expliquer et faire une courte démonstration des requêtes de fusion (merge-requests) :
    - Vers une forge décentralisée basée sur XMPP
    - Tickets et « merge-requests » basés sur XMPP avec SàT

    Ceci a été fait en premier lieu pour nos propres besoins, mais c'est fonctionnel, et il ne manque pas grand chose pour avoir une petite forge décentralisée (principalement l'affichage du code : nous n'hébergeons et n'affichons pas le code nous même, c'est le serveur intégré à Mercurial qui le fait actuellement).

    Le système est très souple, par exemple le gestionnaire de tickets peut être utilisé avec des champs libres, il peut ainsi servir à faire une liste de choses à faire (TODO), ou une liste de courses.

    Le tout est basé sur le pubsub de XMPP, avec son système de permissions (on peut ainsi faire un gestionnaire de tickets privé avec une liste blanche).

    • [^] # Re: Forge décentralisée basée sur XMPP

      Posté par  (site web personnel) . Évalué à 2.

      C'est une chouette idée. Un des trucs qui me gonfle avec les diverses instances de forges locales, c'est justement que j'ai disséminé des comptes un peu partout pour des tickets, souvent pour un pauvre rapport de bug seulement. Bon par contre bon courage pour développer tout ça, les forges logicielles complètes ont vraiment des tonnes de fonctionnalités. Pas toutes toujours utiles suivant les projets, d'ailleurs. Ça peut être intéressant d'envisager le développement à base de plugin, afin de faciliter l'ajout d'une fonctionnalité par d'autres devs et de permettre aux administrateurs d'activer ou désactiver ce qui est vraiment approprier dans leur projet.

      • [^] # Re: Forge décentralisée basée sur XMPP

        Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 27 juillet 2018 à 12:17.

        Ça peut être intéressant d'envisager le développement à base de plugin, afin de faciliter l'ajout d'une fonctionnalité par d'autres devs et de permettre aux administrateurs d'activer ou désactiver ce qui est vraiment approprier dans leur projet.

        Oui c'est l'idée à moyen terme. Mais de toute façon c'est principalement pour notre utilisation à l'heure actuelle, et du coup on (enfin je pour le moment) développe ce dont on a besoin. Après ça sera en fonction des demandes, du temps qu'on peut y consacrer, et des contributions.

        À mon avis, les 2 fonctionnalités les plus importantes sont la gestion des tickets/bugs, et les requêtes de fusion (gérer ses patchs, faire la revue), et ça c'est déjà en place. Après c'est de l'amélioration petit à petit. Je pense ajouter assez vite un système de tests automatisés, et éventuellement une génération de doc.

        Y'a aussi des choses très intéressantes à tout avoir sur XMPP : on peut trivialement faire un système de rapport de bogue intégré directement dans les clients (en cas de plantage par exemple). Et on peut aussi profiter des notifications pubsub, par exemple pour afficher les nouveaux tickets dans le salon MUC.

  • # SCM supportés

    Posté par  (site web personnel) . Évalué à 4.

    Tout le monde n'utilise pas Git, ça aurait été un petit plus de rajouter une colonne avec les SCM supportés par ces outils :-)

    git is great because linus did it, mercurial is better because he didn't

  • # Il existe aussi sr.ht

    Posté par  (site web personnel) . Évalué à 5.

    Une forge qui mérite d'être mentionnée: sr.ht

    Ce n'est pas encore ouvert au public cela dit.

    La particularité de cette forge c'est que tout se passe par e-mail.

    Vous pouvez lire les explications de l'auteur sur son blog:

    Je trouve que c'est une approche vraiment intéressante.

  • # Comparatif

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Il y a sur le Wikipédia anglophone un comparatif intéressant : Comparison of source code hosting facilities.
    On y trouve à la fois du libre et du propriétaire, mais c’est précisé.

  • # Et sur la JVM !

    Posté par  . Évalué à 1.

    Il existe aussi GitBucket qui est développée en Scala. C'est fournit sous la forme d'un WAR auto-porteur. Ils embarquent Jetty pour le serveur web et H2 pour la base de données (qui sont, par ailleurs, deux supers projets je trouve).

  • # Celles qui ont disparues

    Posté par  . Évalué à 3.

    Codendi de XeroX ;

    Puis de Viseo. Par contre c'est effectivement https://www.codendi.com/accueil/…

    Il y a aussi novaforge de Bull Atos. L'idée de novaforge c'est qu'une forge est une collection d'outils et que c'est dommage de refaire tous ses outils. Ils font donc un travail d'intégration d'outils par exemple ils utilisent mantis comme gestionnaire de bug. Une fonctionnalité qu'ils mettais en avant pour la version 3 (il y a 4 ans maintenant), c'est une gestion des releases. Cela permettait d'avoir comme une gestion de release maven, mais en plus global (construction automatique de release note depuis le gestionnaire de ticket, tag de tous les documents, tag des sources, passage de l'intégration, mise à jour des liens de téléchargement sur le site et ajout de la documentation de la nouvelle version,…).

    Ça ne convient probablement pas à tout le monde, mais c'est une façon différente de voir les choses que le point de vu minimaliste qu'on voit partout (et qui pour beaucoup est minimaliste uniquement parce que les projets sont jeunes et développé par peu de gens.

    • [^] # Re: Celles qui ont disparues et Novaforge

      Posté par  (site web personnel) . Évalué à 1.

      Je me demande si ce n'est pas Novaforge qui propulse Tyforge, une plate-forme utilisée dans l'EN.

      En tous cas, les disparitions de Berlios, Gna! et Alioth sont encore une claque: tout un pan de l'histoire du libre du début des années 2000 qui disparaît :-(

  • # phabricator

    Posté par  . Évalué à 2.

    Parmi les utilisateurs de phabricator, comptez le dashboard* de FreeBSD.

  • # Fossil incluera un Forum?

    Posté par  . Évalué à 2.

    Salut,

    je viens de voir sur le site de Fossil:

    D'après les derniers commits, il semblerait qu'ils travaillent à l'ajout d'une fonctionnalité Forum.

  • # 1 projet = plusieurs depots git

    Posté par  (site web personnel) . Évalué à 2.

    Ce qui est bien dommage c'est que souvent la vision des projets de ces logiciels impose 1 seul dépôt GIT par projet… Tuleap n'a pas cette limitation. Je vais aller voir les autres. Mais ça a pas l'air de courir les rues… me tromperais-je ?

    • [^] # Re: 1 projet = plusieurs depots git

      Posté par  (site web personnel) . Évalué à 2.

      Tout dépends de ce que tu appelles « projet ». Avec GitLab et GitHub, tu as la notion d'organisation qui peut répondre à ça. Par exemple, l'organisation linuxfr sur GitHub contient plusieurs dépôts, tous liés à linuxfr : https://github.com/linuxfrorg.

      Là où le système trouve ses limites, c'est quand tu veux avoir une gestion des bugs globale à un projet qui contient plusieurs dépôts (par exemple un point d'entrée unique pour les rapports de bugs, puis aiguillage sur un sous-projet et ré-aiguillage possible a posteriori).

  • # Notabug.org

    Posté par  (site web personnel) . Évalué à 2.

    Il manque notabug.org, hosting base sur Gogs. Interface slick a la github, uniquement des projets libres:

    Exemple:

    https://notabug.org/zoobab/kubebuild

  • # chiliprojet, redmine, gitlab

    Posté par  . Évalué à 3.

    on peut aussi citer Chiliprojet qui est un fork de Redmine, abandonné depuis 2005.

    Concernant Redmine, ce qu'on peut regretter, c'est l'impossibilité d'exporter un projet pour l'intégrer sur une forge alternative. Pour le reste, ca fonctionne assez bien. Pas trop de mauvaises surprises lors des différents upgrades et l'ajout de plugins supplémentaires.

    Concernant le poids lourd du domaine, je pense à Gitlab, c'est du sérieux. Mises a jour pratiquement quotidiennes. Nouvelle version tous les mois. Une offre diversifiée community, et diverses pour entreprise. On peut avoir un peu peur que l'aspect commercial prenne le dessus. Je l'héberge sur l'un de nos serveurs d'entreprise en virtualisé (KVM). Pas de soucis, si ce n'est un vilain bug concernant la registry docker qui ne purge pas bien les containers devenus inutiles. Du coup, les giga grimpent sans jamais prendre congé de mes espaces disques. J'en suis à 130Go, ce qui n'est pas affolant du tout : merci à mes valeureux utilisateurs. A savoir que j'exploite la version "bundle" appelée Omnibus. J'ai vu passer l'existence d'un paquetage sur Debian. C'est courageux. Le bundle omnibus est assez facile à exploiter.

    mes 36 centimes …

    • [^] # Re: chiliprojet, redmine, gitlab

      Posté par  . Évalué à 4.

      Je ne peux qu'aller dans ton sens. Gitlab est vraiment une forge complète et qui évolue comme il faut.
      Dans ma boite, on l'utilise depuis 2014. En 4 ans, l'évolution a été vraiment impressionnante.

      Du coup, le cycle de développement de nos logiciels est entièrement réalisé dans Gitlab.

      Nous suivons également le rythme des mises à jour mensuelles (tous les 22), la roadmap, les releases notes et la doc étant vraiment de qualité !

      Bref, que du bon ! Pour info nous utilisons la version CE en omnibus.

      PS: Nous utilisons les registry depuis peu, le bug que tu rencontres porte la milestone 11.2 qui sera releasée le 22/08 donc tu n'auras pas beaucoup à attendre ;) (https://gitlab.com/gitlab-org/gitlab-ce/issues/25322)

Suivre le flux des commentaires

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