Le modèle propriétaire : le code du service n'est pas fourni, il est très difficile voire impossible d'exporter les données.
Le modèle libre : le code du service est fourni, il est souvent possible d'exporter ses données facilement.
Ce qui est totalement faux. La possibilité de récupérer ses données dépends seulement des fonctionnalités du service, pas du fait que le code du site soit ouvert ou fermé.
La boite qui offre un service reposant à 100% sur du libre ne va pas pour autant ouvrir ses bases de données ou son système de fichier à tout vent. L'export de tes données va donc dépendre des API qu'elle propose, qu'elle ouvre.
Imagine que demain j'ouvre une plateforme wiki basé sur Dokuwiki, je peux très bien ne pas vouloir ouvrir l'API XMLRPC de dokuwiki pour diverses raisons : sécurité, "emprisonner" l'utilisateur, ou encore faire payer l’accès à cet API.
Qu'est ce que cela va changer pour l'utilisateur, par rapport à un service dont le code source est proprio ? Rien. Absolument rien.
Ça fait plusieurs fois que je lis sur linuxfr cet argument "contre" pour les services reposant sur des logiciels proprio. ARRETEZ DE L'UTILISER, c'est totalement bidon, du coup, ça décrédibilise le reste de votre argumentaire.
Les fournisseurs de service misent sur la qualité de service
Oui, mais ça a un coût. Il faut donc payer quelque part (infrastructure, réseau…). Que le soft soit ouvert ou fermé ne change pas grand chose au final. Si on veut de la qualité de service, il faut payer, et c'est tout à fait normal. Maintenant, à qualité égale, on peut effectivement choisir de mettre ses sous dans la boite qui utilise des logiciels libres.
les clients qui n'ont pas la compétence en interne pour installer ce service
Ou pas envie et/ou pas le temps de gérer un service "interne".
Les parties les moins importantes de leur service sont libres, par exemple Gollum leur moteur de wiki utilisant un dépôt git. Mais le cœur de l'application est entièrement propriétaire.
En même temps, ça ferait une belle jambe à tout ceux qui utilisent github, d'avoir le coeur de l'application.
Un paramètre semble être oublié dans l'argumentaire : github héberge des centaines de milliers (millions?) de projets. Donc le coeur de l'appli est architecturé pour une infrastructure spécifique, à forte charge. Ça doit être certainement la plaie à installer et à configurer, parce que très spécifique. Très franchement, j'en voudrais pas pour l'installer sur un intranet en entreprise par exemple, ce serait prendre un marteau pour écraser une mouche.
Si on veut un outil similaire, autant prendre un des outils que tu as cité, ça sera certainement plus simple à installer, et certainement plus adapté à des petites structures. puisque si on veut du github chez soit, en entreprise, c'est qu'à priori, on a une petite infrastructure réservée au développement par rapport à chez github. Je doute qu'il existe une boite qui ait des centaines de milliers de projets à gérer comme sur Github.
Conclusion : tout le monde s'en fout que le coeur de Github soit proprio. sauf les aigris, les intégristes et les empêcheurs de tourner en rond.
Merci sinon pour ta liste d'alternatives. Mais sans troll, ça aurait été mieux.
# Troll de compet
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi GitHub saimal, quelques alternatives. Évalué à 10.
Ce qui est totalement faux. La possibilité de récupérer ses données dépends seulement des fonctionnalités du service, pas du fait que le code du site soit ouvert ou fermé.
La boite qui offre un service reposant à 100% sur du libre ne va pas pour autant ouvrir ses bases de données ou son système de fichier à tout vent. L'export de tes données va donc dépendre des API qu'elle propose, qu'elle ouvre.
Imagine que demain j'ouvre une plateforme wiki basé sur Dokuwiki, je peux très bien ne pas vouloir ouvrir l'API XMLRPC de dokuwiki pour diverses raisons : sécurité, "emprisonner" l'utilisateur, ou encore faire payer l’accès à cet API.
Qu'est ce que cela va changer pour l'utilisateur, par rapport à un service dont le code source est proprio ? Rien. Absolument rien.
Ça fait plusieurs fois que je lis sur linuxfr cet argument "contre" pour les services reposant sur des logiciels proprio. ARRETEZ DE L'UTILISER, c'est totalement bidon, du coup, ça décrédibilise le reste de votre argumentaire.
Oui, mais ça a un coût. Il faut donc payer quelque part (infrastructure, réseau…). Que le soft soit ouvert ou fermé ne change pas grand chose au final. Si on veut de la qualité de service, il faut payer, et c'est tout à fait normal. Maintenant, à qualité égale, on peut effectivement choisir de mettre ses sous dans la boite qui utilise des logiciels libres.
Ou pas envie et/ou pas le temps de gérer un service "interne".
En même temps, ça ferait une belle jambe à tout ceux qui utilisent github, d'avoir le coeur de l'application.
Un paramètre semble être oublié dans l'argumentaire : github héberge des centaines de milliers (millions?) de projets. Donc le coeur de l'appli est architecturé pour une infrastructure spécifique, à forte charge. Ça doit être certainement la plaie à installer et à configurer, parce que très spécifique. Très franchement, j'en voudrais pas pour l'installer sur un intranet en entreprise par exemple, ce serait prendre un marteau pour écraser une mouche.
Si on veut un outil similaire, autant prendre un des outils que tu as cité, ça sera certainement plus simple à installer, et certainement plus adapté à des petites structures. puisque si on veut du github chez soit, en entreprise, c'est qu'à priori, on a une petite infrastructure réservée au développement par rapport à chez github. Je doute qu'il existe une boite qui ait des centaines de milliers de projets à gérer comme sur Github.
Conclusion : tout le monde s'en fout que le coeur de Github soit proprio. sauf les aigris, les intégristes et les empêcheurs de tourner en rond.
Merci sinon pour ta liste d'alternatives. Mais sans troll, ça aurait été mieux.