Sommaire
- Pourquoi migrer chez un autre hébergeur ?
- Choix de l'hébergeur
- Récupération des données chez SourceForge
- Transfert chez TuxFamily
- Trafic
- Bilan
Bonjour,
Je voudrais faire un retour d'expérience sur le changement d'hébergeur que je viens d’effectuer pour mon projet libre VST Preset Generator. Il était historiquement hébergé chez SourceForge et il vient d'être migré chez TuxFamily.
Pourquoi migrer chez un autre hébergeur ?
J'ai commencé à développer le logiciel VST Preset Generator en 2007. A l'époque, l'hébergeur de référence pour le libre était SourceForge. N'ayant aucune compétence en administration système à ce moment là, j'ai choisi cette plateforme populaire.
Depuis, SourceForge perdant en popularité face au phénomène GitHub, la monétisation des téléchargements en ajoutant des publicités dans les installeurs est arrivée. Mon modeste projet n'a pas été touché par ce changement, heureusement, mais cela a grandement entaché la réputation de cet hébergeur.
De plus, alors que certains projets ciblés par cette publicité forcée ont décidé de partir de cette plateforme, leurs comptes ont été récupérés par SourceForge pour continuer à percevoir des revenus tirés de la publicité. Voir cette dépêche qui prend l'exemple de Gimp. Il semble que NMap et VLC ont subi le même sort.
Ces pratiques ont apparemment cessé depuis le rachat de SourceForge par Dice Holdings, et ils ont annoncé qu'ils scannaient les binaires pour enlever toute trace de logiciels malveillants, dont la majorité a été introduite par eux, ironie du sort.
Malgré ces efforts, SourceForge n'est plus digne de confiance car cela n'empêchera pas un prochain décideur de recommencer une expérience similaire pour monétiser les contenus.
D'ailleurs la page de téléchargement de mon projet ressemblait à cela:
avec un gros bouton TELECHARGER vérolé et des publicités dans tous les coins.
De plus, suite à l'obligation par la loi française d'informer les usagers des sites Internets que certaines de leurs données sont collectées, l'accès à SourceForge depuis une IP française affichait cet écran avec un panneau attention sur un drapeau français :
Je me suis donc rendu compte que l'accès à mon logiciel n'était pas facile. De nombreuses personnes ne devaient jamais arriver à la page de téléchargement et VST Preset Generator devait être considéré comme du gratuiciel vérolé.
Il était donc grand temps de déménager.
Choix de l'hébergeur
Voilà quels étaient mes besoins :
- de quoi héberger un site web vitrine
- un espace de téléchargement
- un dépôt Subversion
- une possibilité de publier des nouvelles
en bonus :
- un logiciel de suivi de problèmes (je n'utilisais pas celui de SourceForge)
- un réseau de projet pour se faire connaître
Une solution envisagée a été l’auto-hébergement ou un hébergement mutualisé, de façon à être un maximum indépendant. Pour répondre à mes besoins un serveur dédié virtuel était nécessaire, notamment pour le dépôt Subversion. Mais ne voulant pas me rajouter la tache de maintenir à jour toute une pile de logiciels, j'ai écarté cette idée.
Actuellement il existe de nombreuses plateformes qui répondent à ces besoins. La quasi totalité étant gérée par des entreprises privées je ne voulais pas retomber sur les mêmes soucis qu'avec SourceForge poussé par le profit à court terme.
Par exemple, la plateforme actuellement la plus populaire pour héberger du code libre est GitHub. Même si j'ai un compte vitrine chez eux, il n'est pas envisageable d'y héberger des projets pour le long terme car il n'est pas garanti qu'ils n'auront pas un comportement similaire à SourceForge une fois que leur popularité aura disparue.
J'ai donc regardé les forges libres existantes comme Gna ou Savannah, un peu vieillissantes à mon goût. FramaGit et NotABug étant réservés à Git, TuxFamily était le seul à répondre à mes besoins tout en étant recommandé par le milieu libre francophone et géré par une association. Parfait !
Donc après une période d'évaluation je me suis lancé dans la migration vers TuxFamily.
Récupération des données chez SourceForge
En dehors des aspects négatifs de SourceForge évoqués plus haut, leur plateforme basée sur Allura est techniquement de bonne qualité.
Je me suis donc servi de leur Interactive Shell Service qui crée une sorte de shell sécurisé virtuel donnant accès à toutes les données d'un projet. Il fut donc très simple de cloner le dépôt Subversion avec la commande svnadmin dump, de copier tous les fichiers binaires de l'espace de téléchargement, et d'exporter toutes les données (news, descriptions, screenshots, etc.).
On peut d'ailleurs aussi récupérer toutes les informations depuis la page projet au format JSON. A croire que même leurs développeurs nous encouragent à partir !
Transfert chez TuxFamily
Création d'un compte chez TuxFamily, puis d'un groupe à partir de ce compte. Un groupe est une sorte de projet. Il faut bien préciser la nature de la licence du projet pour qu'il soit accepté, ce qui n'était pas le cas lors de ma première tentative.
Pour le dépôt Subversion, il me fallait le cloner pour garder l'historique. Mais là, pas d'accès en ssh au serveur Subversion de TuxFamily pour la commande svnadmin load ! Heureusement, un gentil administrateur a fait la manipulation à ma place en lui fournissant le dump généré chez SourceForge.
Ne voulant pas une adresse en xxx.tuxfamily.org, j'ai opté pour un nouveau nom de domaine : vst-preset-generator.org. Même si cela a un coût, l'adresse officielle ne dépendra plus de l'hébergeur. Par exemple l'ancienne adresse était vst-preset-gen.sourceforge.net que j'utilisais dans les communications sur le projet, ce qui m'oblige à la garder avec une redirection. De plus je n'ai pas la garantie que SourceForge ne récupérera pas cette adresse un jour, ou ne la supprimera pas. Donc grâce à ce nouveau nom de domaine le projet gagne en pérennité pour un faible coût (environ 10€ par an).
TuxFamily fournit aussi les DNS et le domaine de courriel, ce qui est très pratique.
Ensuite création d'un espace web principal ainsi que d'un sous-domaine bugs pour héberger un logiciel de suivi de problèmes. J'ai choisi FlySpray, comme recommandé sur le wiki de TuxFamily, avec sa base de donnée MySQL associée.
La page par défaut des projets étant moins accueillante que celle de Sourceforge (TuxFamily n'est pas une forge) j'ai donc développé un petit site web statique. Le site est généré avec un script Python maison qui me permet d'incorporer des nouvelles et un flux rss. TuxFamily m'a fourni un dépôt subversion supplémentaire pour héberger ce code, avec le commentaire suivant :
PS: Sinon, Git, c'est très bien aussi, hein :).
Finalement, création d'un espace de téléchargement pour les fichiers binaires, accessible en http, https et ftp anonyme. Cet espace a ses statistiques séparées du site web du projet ce qui est pratique pour comptabiliser le nombre de téléchargements.
Une fois la migration effectuée j'ai ajouté des redirections sur la page de SourceForge vers la nouvelle page du projet, ainsi que l'effacement de tout le contenu pour forcer les utilisateurs à venir sur la nouvelle page.
Trafic
Suite au lancement du nouveau site web et la suppression des contenus sur SourceForge, le trafic en téléchargement a quasiment été divisé par deux. Plusieurs hypothèses :
- les statistiques SourceForge ne sont pas fiables, elles pourraient inclure la synchronisation de leurs miroirs par exemple
- certains sites avaient des liens directs vers les fichiers à télécharger, comme des annuaires de logiciel
Par contre trois personnes m'ont contacté en un mois pour parler du VST Preset Generator, ce qui est environ 10 fois plus qu'avant (je recevais maximum trois à quatre retours par an). C'est très positif et cela montre que l'accessibilité au projet s'est améliorée !
Bilan
Cela fait maintenant 2 mois que j'ai effectué cette migration, et j'en suis pleinement satisfait. Je voulais me séparer de SourceForge depuis plusieurs années et TuxFamily m'a permis de sauter le pas. Merci !
Les points positifs :
- Énormément de services fournis par TuxFamily, voir leur page dédiée.
- TuxFamily est en français. Même si je n'ai pas de problème avec l'anglais c'est quand même toujours plus facile d'exprimer les problèmes dans sa langue natale.
- Les administrateurs sont très réactifs et toutes mes demandes ont reçu une réponse dans la demi-journée, voire dans l'heure pour la plupart.
- En bonus j'ai un accès en https valide sur tous les sites web grâce à Let's Encrypt.
- J'en ai profité pour adhérer à l'association, histoire d'être au courant quand TuxFamily rajoutera des publicités dans les téléchargements ;-)
- Et puis cela m'a même permis de contribuer à leur plateforme d'hébergement VHFFS.
Dans les points négatifs :
- TuxFamily ne fournit pas de logiciel de suivi de problèmes, donc j'ai dû installer FlySpray que je vais devoir maintenir à jour, au moins pour les failles de sécurité.
- Pas d'accès à Subversion en https, la solution proposée est de migrer vers Git ou Mercurial…
Donc un grand merci à toute l'équipe de TuxFamily pour leurs efforts et leur plateforme, et que ceux qui veulent migrer leurs projets libres depuis SourceForge n'hésitent plus !
# Git
Posté par NumOpen . Évalué à 4.
Je suis passé de CVS à SVN sur Sourceforge puis de SVN à Git sur Framagit, franchement, Git c'est bien.
[^] # Re: Git
Posté par mzf (site web personnel) . Évalué à 2.
Quels sont les avantages et inconvénients que t'ont amené Git par rapport à Subversion ?
Sinon Git a plein d'avantages c'est sûr et je l'utilise quotidiennement, mais sa possibilité de tout changer à postériori me gêne un peu. J'aime bien le principe d'autorité centrale de Subversion où tout l'historique est archivé de façon immuable.
Pour ce projet avec un seul développeur je ne vois pas d'argument pour changer dans l'immédiat.
Et puis les numéros de révision qui sont des empreintes d'une fonction de hachage (
f27084b3b9b36450969876069a9ab6c79560e2bc) c'est quand même moins lisible que ceux de Subversion, on perd la notion de chronologie.[^] # Re: Git
Posté par Zenitram (site web personnel) . Évalué à 2.
Avoir des gens qui peuvent fournir des patchs, différence entre nom du commiteur et nom du patcheurs.
Pouvoir passer à GitHub (je suis passé de 2 contributeurs externes en 10 ans à 10 propositions de merge en 1 an, en passant de SVN à Git/GitHub, c'est peu mais ça te donne une idées de ce que ça peut être), de voir les clones etc.
Espérer avoir plus de contributeurs.
Plus de visibilité.
[^] # Re: Git
Posté par tanguy_k (site web personnel) . Évalué à 4.
Et ca pourrait etre plus si la page web officiel avait un bandeau "Fork me on GitHub" ou meme un lien : https://mediaarea.net/en/MediaInfo
[^] # Re: Git
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
L'historique immuable avec Git, c'est deux lignes dans un fichier de config (receive.denyNonFastForwards et receive.denydeletes). Si c'est tout ce qui te retient avec Subversion … ;-).
Maintenant, je rejoins Zenitram : si tu veux des contributeurs, donnes leur des bonnes conditions de travail, donc exit Subversion. Contribuer à un projet quand on n'a pas la possibilité de faire un commit, c'est vraiment pas pratique.
# GitHub
Posté par tanguy_k (site web personnel) . Évalué à 3.
C'est vrai mais la probabilité que GitHub change est faible : Google, Facebook, Microsoft… ont tous leur code source chez eux et ce sont des boites bien plus grosses que GitHub.
Dans le cas de Google et Microsoft, ils ont meme laché leurs propres plateformes d'hebergement de code (Google Code et CodePlex) - ca a du leur arracher un bras !
Surtout, GitHub aurait donné de la visibilité et des contributions à ton projet :
"Moving FlashDevelop from Google code svn to Github did effectively result in a huge increase in code contributions"
"Symfony […] the switch to GH brought a lot of new contributors, tickets & PRs. That was a great move."
"I moved WebPagetest from Google code to Github around a year ago. On Google code it was pretty much a ghost town […] On Github there are 29 contributors and 98 forks"
"I remember Walter Bright saying that D's compiler (dmd) had a 10x increase in contributions after moving to GiHub"
Source : https://plus.google.com/+SethLadd/posts/d4XAL24Te1L
[^] # Re: GitHub
Posté par barmic . Évalué à 7.
Il fait bien ce qu'il veut mais je suis d'accord. J'ajouterai que ça ne me paraît pas pertinent de penser qu'un service sur internet est immuable et qu'on aura jamais à changer. Même avec toute la bonne volonté du monde, une association peu disparaître (comme ça a failli être le cas pour la quadrature) ou des éléments extérieurs peuvent intervenir (si la loi les oblige à donner à l'état un accès à tout ce qu'ils hébergent par exemple, il y a des chances qu'ils se sabordent).
Bref de la même manière que github peut dans l'avenir faire n'importe quoi, tuxfamilly peut disparaître. L'important c'est donc plus de garder la main sur les données et d'avoir de quoi changer facilement (avoir son propre nom de domaine par exemple c'est bien).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: GitHub
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Et surtout : le fait qu'un service soit associatif te protège effectivement assez bien des dérives à la sourceforge, mais pas du tout de la faillite ou des interruptions de services à rallonges. On se souvient de kernel.org qui a été coupé très longtemps (je crois que le wiki a mis plus d'un an à revenir), plus récemment, l'hébergeur Olympe mettra la clé sous la porte s'ils ne trouvent pas 28000 € dans les 12 jours qui viennent. Le fait que GitHub ait un service payant et fasse autant de pognon avec est quand même une bonne garantie que ce genre de chose n'arrive pas.
Il y a des tas de bonnes raisons de ne pas choisir GitHub, mais « j'ai plus confiance dans la pérennité d'un service non-commercial » ne me parait pas être la meilleure.
[^] # Re: GitHub
Posté par mzf (site web personnel) . Évalué à 3.
Oui, vous avez raison, une association ne garantit en rien de la pérennité d'un service. C'est plus pour éviter les dérives commerciales contraire à l'esprit des logiciels libres que j'ai fait ce choix. Et puis le nom de domaine me permet maintenant d'être indépendant de l'hébergeur pour migrer encore plus facilement la prochaine fois !
[^] # Re: GitHub
Posté par mzf (site web personnel) . Évalué à 1.
Justement ça me fait peur que GitHub fasse pareil, même si l'hébergement de code est leur activité principale.
Les utilisateurs du VST Preset Generator ne sont pas informaticiens et encore moins développeurs, contrairement aux projets cités. En 9 ans je n'ai eu qu'un seul retour de quelqu'un qui a essayé de compiler le logiciel. Même si tu as raison sur le fait que GitHub aurait pu apporter plus de contributions au niveau du code, je préfère favoriser d'autres types de contributions (retours d'expérience, demande d'amélioration, régionalisation, documentation, etc.) et pour cela le départ de SourceForge a été bénéfique.
[^] # Re: GitHub
Posté par tanguy_k (site web personnel) . Évalué à 3.
C'est pas exclusif : des contributions au niveau du code n'empechent pas d'autres types de contributions. Au contraire, c'est meme plutot complementaire.
Au contraire, le fait que Google et Microsoft aient laché leurs propres plateformes pour GitHub pérénise davantage encore GitHub.
Au final rien n'est eternel et si on suit cette logique de peur alors il faut créer son propre hébergement (ce qui represente bien plus d'inconvenients que d'avantages).
TuxFamily est resté fermé pendant un an (en 2004/2005 ?), source : https://fr.wikipedia.org/wiki/TuxFamily
TuxFamily = 6000 utilisateurs vs GitHub = 14 million et 65eme site au niveau mondial
[^] # Re: GitHub
Posté par Misc (site web personnel) . Évalué à 6.
C'est amusant, parce que justement, Github a changé. Par exemple, ils ont changés les prix. J'ai entendu parlé de client avec pleins de repo publiques et quelques dépôts privés, et dont les tarifs passeraient de 50
par mois, vu que ça compte maintenant par personne au lieu de payer par dépot.
Github a aussi changé car ils étaient en train de s'endormir (avant d'avoir une lettre de gens pour dire "votre issue tracker est pourri", on peut pas dire que grand monde faisait des changements sur ce bout du logiciel)
Ensuite, pour le moment, les changements sont positifs (à mon sens) pour la majorité, mais je pense que c'est pas ce que tout le monde croit. Par exemple, il y a tout une frange des utilisateurs qui semble s'opposer aux positions actuelles de Github (http://dancerscode.com/blog/why-the-open-code-of-conduct-isnt-for-me/ et http://garrett.damore.org/2016/02/leaving-github.html pour 2 exemples). D'un coté, je me dit que c'est des opinions minoritaires, mais de l'autre, c'est souvent une source de discussions des plus chaudes et donc peut être que c'est moins minoritaires que je le crois.
Et je ne suis pas super confiant dans l'avenir de Github, car d'une part, le nombre de projet libre ne va faire qu'augmenter, donc les coûts de github aussi, mais je ne voit pas forcément le nombre de clients grimper aussi vite (ne serais ce que parce les startups semblent avoir moins de fond qu'avant, ce qui me rappelle la première bulle).
Je suppose que les changements de tarif sont aussi la pour ça, retirer un chouia plus de pognon des boites qui utilisent github maintenant qu'ils estiment être en position de force, afin d'absorber la crise qui vient.
Donc j'attendrais perso de voir ce que ça va donner d'ici 2 ans.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.