Journal Comment Github a ressuscité mon logiciel libre

Posté par  (site web personnel) . Licence CC By‑SA.
76
7
mar.
2016

On parle régulièrement de Github en négatif ces derniers temps: ça centralise tout, ça capture les données, ça bouffe les autres plate-formes d'hébergement de projets libres avec en plus quelques soupçons de misogynie et sexisme en interne. En gros, Github, ce serait pas bien © (et je pèse mes mots!).

Je partage ici ma petite expérience. Pour les plus pressés, vous pouvez sauter directement aux trois derniers paragraphes.

J'ai créé en 2004 une bibliothèque de test unitaires pour le langage Lua : LuaUnit. C'était pour exécuter des tests de non-régression sur le clone de Vim qu'on développait, qui était scriptable en Lua. Il n'y avait pas rien de tel de disponible dans l'écosystème Lua à l'époque, du coup, j'étais tout frétillant d'apporter une vraie pierre à la cathédrale au bazar. Manque de chance, un autre type a fait pratiquement le même logiciel et l'a sorti au même moment que le mien ! Mais c'est pas très grave, il y a de la place pour tout le monde.

Le projet était assez modeste mais fonctionnait correctement pour ce qu'il devait faire. Je l'ai hébergé sur le site de mon ami qui sert à publier nos diverses contributions ( www.freehackers.org ) et sur luaforge, qui voulait devenir le sourceforge du langage Lua. J'ai eu des retours d'utilisateurs, et quelques micro-patchs utiles. On m'a même proposé de m'associer à l'écriture du framework de test pour the Kepler project, un système complet de packaging pour Lua mais j'ai pas pris le temps de m'investir là-dedans, LuaUnit restait pour moi un mini-projet passe-temps.

Ensuite, le temps a passé, notre clone de Vim est mort, le suivant que j'ai refait dans mon coin n'est jamais né, j'ai fait encore d'autres bouts de logiciels libre à droite à gauche, je me suis mis en couple, j'ai pris de galon dans la vie professionnelle et j'ai complètement laissé tombé LuaUnit. Grace à LuaForge, je recevais quand même de temps en temps des mails d'utilisateurs me demandant d'ajouter des fonctionnalités que j'ignorais faute de temps et de motivation. J'ai intégré un patch pour le portage vers Lua 5.1 parce que le 5.0 commençait à se faire vieux, et j'en ai profité pour faire une petite migration CVS vers Mercurial mais c'est tout. En 2007, un quidam m'a demandé s'il pouvait forker et sortir une v2 avec des fonctionnalités que j'avais pas. J'ai accepté à condition qu'il change le nom. Son fork n'ai jamais apparu dans la nature, mon attitude l'a peut-être refroidi…

Après, encore plus de temps a passé. LuaForge a cessé d'être maintenu, et de 2009 à 2012, plus personne ne s'est intéressé au projet. Il mourrait tranquillement comme des milliers d'autres logiciels libres. Ça me serrait le cœur, d'autant plus que j'avais encore un ou deux patch datant de 2008 à intégrer, mais vraiment, j'avais pas le temps avec maintenant un enfant, une vie de famille, beaucoup de boulot, etc etc.

En 2011, un type a carrément importé mon projet sous GitHub, créé son fork et sorti une v2. Tout ça sans même m'envoyer un mail de politesse. J'ai laissé faire mais j'ai pas trop aimé: il y avait maintenant un LuaUnit v2 qui n'était plus le mien. C'est bien que quelqu'un fasse vivre ce logiciel, mais LuaUnit, c'était normalement mon bébé. Grrrr.

Et puis est arrivé l'année 2012 avec plusieurs évènements: Luaforge a fermé ses portes et migré tous les dépots vers GitHub. Puis j'ai reçu une contribution pour ajouter une sortie des tests au format TAP, pour de l'intégration sous Jenkins. Faire le lien entre un vieux projet à l'agonie et un truc aussi moderne et hype que Jenkins m'a bien plus.

Côté temps libre, tous mes projets libres étaient à l'abandon depuis longtemps et j'étais frustré de ne plus rien faire. J'avais besoin d'un petit projet auquel je pourrai consacrer quelques heures par mois, mais qui serait quand même utile. LuaUnit était le candidat idéal: stable, petit mais suscitant de l'intérêt, avec un potentiel d'utiliser des trucs hype. Je suis allé voir où en était le fork v2 sous GitHub: il était plutôt à l'arrêt. Bien, ça veut dire qu'il y avait de la place pour faire de nouveau avancer LuaUnit sans se marcher sur les pieds.

J'ai donc pris une grande décision cet été 2012: je ferai revivre LuaUnit, sous GitHub ! J'allais en faire un projet de haute qualité: bien documenté, bien testé, moderne (voire même hype avec Jenkins) et dynamique. J'enterrerai de honte le salaud qui a osé forké mon projet sous Github avec un projet plus mieux que le sien. Ce serait la revanche de mon ego de développeur libre!

J'ai quitté à regret mercurial (snif), puis la plate-forme d'hébergement de mon ami (snif) et j'ai tout migré sous Github. J'ai integré le patch pour Jenkins et sorti une version dare-dare. Ensuite, j'ai repris le développement de LuaUnit. C'était un vieux coucou, il avait bien besoin d'un coup de lifting: beaucoup plus de tests, simplification du code, correction de bugs à gauche à droite. J'en ai profité pour rendre facile l'ajout d'un nouveau format de sortie.

Et là, j'ai commencé à bénéficié de l'effet GitHub. Automne 2012, on m'a ouvert un bug; printemps 2013, deux contributeurs, l'un pour des correctifs à droite à gauche et un packaging dans Debian, l'autre pour une autre fonctionnalité majeure (toute proportion gardée pour logiciel de 5000 lignes): une sortie en XML. Sur mon hébergement précédent, il y avait moyen de reporter des bugs officiellement (avec un Redmine) et de m'envoyer des patchs en tirant partie de Mercurial. Mais rien de cela n'est arrivé en 3 ans. Alors qu'en 8 mois sur Github, j'ai obtenu des bugs et patchs de très bonne qualité, à jour, facile à intégrer. L'effet GitHub a continué, depuis 2012, j'ai eu 25 Pull Requests, toutes intéressantes et 17 bugs ou demandes de fonctionnalités. J'ai 3 développeurs engagés qui répondent aux bugs ouverts, suivent ce que je fais et proposent des améliorations. Ça m'a bien remotivé pour continuer à faire vivre LuaUnit.

En plus des contributions pures, Github donne accès à un écosystème pratique: la mise en place de l'intégration continue pour Linux sous Travis CI m'a pris quelques heures. A peine plus longtemps pour la même chose sous Windows avec AppVeyor. Côté doc, j'ai utilisé readthedocs pour rendre la doc facilement accessible. Maintenant, j'ai 3 beaux badges qui montrent que mon projet est en intégration continue. Prochaine étape, un badge pour la couverture de code et je serai au top de l'intégration continue.

En conclusion, Github, pour mon projet et moi, ça a fait beaucoup de bien: des contributeurs, des reports de bugs, des développeurs engagés, des services pour améliorer la qualité de mon projet et une motivation regonflée à bloc. L'effet est bien due à la place proéminente de Github et à la centralisation des projets sur ce réseau social, les principes mêmes qui sont dénoncés comme des problèmes du service Github. L'écosystème autour de Github est d'une bonne qualité en rend des services inestimables. Je trouve ces points sous-estimés dans les « Gitlab fait pareil » . Sous Gitlab, LuaUnit serait encore ce qu'il était il y a 3 ans: un projet agonisant.

  • # Backup

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

    Je me demande si une solution n'est pas d'avoir une version du code (et des outils ?) sur Github pour profiter de l'effet « réseau », et d'avoir une copie de ses données synchronisée ailleurs au cas où Github décide de faire n'importe quoi.

    Autant c'est facile pour le dépôt lui-même (Git est conçu pour ça), autant pour d'autres éléments c'est plus délicat, même avec un outil comme une instance personnelle de GitLab.

    La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Backup

      Posté par  . Évalué à 10.

      Le vrai problème au fond, c'est celui de l'identification.

      Je veux dire, dans un monde quasi-idéal quasi-peuplé de gens quasi-parfaits selon la théorie des auto-hébergionistes (ceux qui veulent nous convaincre que tout le monde doit héberger son site et ses mails soi-même parce que la centralisation c'est le mal… je ne mets pas tous les gens qui gèrent leur hébergement eux-même dans ce panier, je précise) les contributeurs potentiels devraient avant tout créer un Nième compte avec un Nième mot de passe (je ne connais encore aucun site qui utilise des clefs ssh pour remplacer les login/pass classiques… par exemple) différent bien sûr, au cas ou il y ait une Oième faille de sécurité qui fait que l'attaquant pourrait leur piquer tous leurs codes sources libres (sigh) ou non ( nous sommes tous des génies en puissance, pourquoi ne pas faire fortune? ) sur tous les sites sur lesquels ils sont inscrits.

      Dans la pratique, ça se résume soit à:

      • oh… putain, encore un site qui a son propre bugtracker… bon, 2 solutions:
        • je fait un nouveau compte, avec mon pass classique
        • ça me soule, je zappe ( <=== solution la plus populaire je pense, en tout cas celle que j'adopte le plus souvent )
      • ah cool j'ai déjà un compte ici, bon ben c'est l'occase de filer un coup de main
      • bon, j'ai pas de compte sur leur site, mais ma distro intègre un bugtracker et c'est censé remonter. Autant essayer. [2 ans plus tard] Tiens, j'ai reçu un mail d'un mainteneur de Debian… il me demande si le bug que j'ai rencontré il y à 2 ans (une boucle infinie sur udev de mémoire) est encore valide… ah, c'est con, depuis le temps, l'image de 500Gio, je l'ai virée je peux plus aider!

      À noter, ce sont des situations que j'ai vécu. Et quand je reçois un mail d'un contributeur, je répond systématiquement, même si je suis parfois en retard sur mes mails de plus de 2 semaines (mes mails persos je les consulte pas assez souvent).

      • [^] # Re: Backup

        Posté par  . Évalué à 1.

        Pour pallier à ton problème de « n-ième compte/mot de passe », je t'invite à adopter d'urgence un gestionnaire de mots de passe avec son greffon Firefox.

        • [^] # Re: Backup

          Posté par  . Évalué à 3.

          Et ne surtout pas utiliser un mot de passe générique (surtout si tu as fréquenté le forum de Linux Mint) !

        • [^] # Re: Backup

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

          Et pour pallier ton problème de transitivité verbale je t'invite à adopter d'urgence un Bescherelle.

        • [^] # Re: Backup

          Posté par  . Évalué à 1.

          1) je n'utilise pas firefox.
          2) je n'aime pas ce type d'outils. Mes mots de passe sont générés en fonction de données du site et de l'importance que j'accorde aux données sur le site (les sites sur lesquels je n'ai aucunes données ont un mot de passe "classique" identique, les autres un pass unique, mais ils sont vachement moins nombreux…). Pourquoi je n'aime pas? parce que quand on te pique le pass maître, on connais tous tes pass. Sans parler du besoin de faire des backup (certes, c'est de toute façon une bonne pratique, mais je suis une feignasse sur mes machines perso) tandis qu'avec la mémoire, pas besoin de backup (par contre oui, si d'un coup tu deviens amnésique ou si tu passes l'arme à gauche, pour un pass qui sert à d'autres, c'est balo…).

      • [^] # Re: Backup => il y a de l'idée

        Posté par  . Évalué à 1. Dernière modification le 08 mars 2016 à 09:47.

        J'adore ton idée d'identification par clef ssh pour remplacer les mots de passe, c'est une super idée.

        • [^] # Re: Backup => il y a de l'idée

          Posté par  . Évalué à 7.

          Le protocole TLS permet ça depuis ses débuts (pas avec une clef SSH mais avec un certificat X.509, qui est en gros une clef avec quelques métadonnées autour et une signature), c’est l’authentification du client.

          C’est pris en charge à ma connaissance par la plupart des serveurs web et par la plupart des navigateurs… et c’est complètement inutilisé.

          En France, le fisc avait utilisé ça à une époque pour la connexion des télédéclarants, ils ont rapidement fait marche arrière. Trop de gens qui ne comprenaient pas comment ça marchait, et qui ne savaient pas quoi faire de leur certificat. (C’est une leçon à retenir pour ceux qui veulent la mort des mots de passe, au passage : peu importe votre solution, si elle est plus compliquée pour l’utilisateur que « taper un mot de passe dans un champ », ça ne marchera jamais, ou en tout cas pas au-delà d’un public averti.)

          Ça reste néanmoins une « super idée », personnellement je m’en sers autant que possible (je m’en suis servi par exemple pour protéger l’accès à l’espace d’administration d’un site SPIP).

          • [^] # Re: Backup => il y a de l'idée

            Posté par  . Évalué à 2.

            C'est pour ça qu'une smart card PKCS#11 peut être une solution, il te faut un simple mot de passe pour la débloquer. Reste que ce n'est pas répandu et que personne n'a de lecteur… Et encore mieux un lecteur pinpad …

            • [^] # Re: Backup => il y a de l'idée

              Posté par  . Évalué à 2.

              Il faut en plus le bon driver dans ton navigateur.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Backup => il y a de l'idée

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

              C'est ce qu'on utilise en Belgique, basé sur la carte d'identité

              On va sur un site web, ça ouvre une page pour l'authentification qui se fait via le site du gouvernement, puis on est redirigé vers le site

              ça permet de faire des papiers a la commune (demande de document), faire sa déclaration d'impôts, demander sa retraite (+consulter tous les docs genre carrière, et la date de la retraite ), pour la mutuelle santé, signer des documents (valeur légale) etc

              Le lecteur de carte ne coûte pas cher (<10€)

              Mais aucun site web "normal" ne l'utilise, d'un autre côté je suppose que le gouvernement aurait le nombre de consultation du site…

              • [^] # Re: Backup => il y a de l'idée

                Posté par  . Évalué à 3.

                On va sur un site web, ça ouvre une page pour l'authentification qui se fait via le site du gouvernement, puis on est redirigé vers le site

                Par contre, pas mal de site utilisent une applet Java pour faire l'authentification, ce qui pose problème avec de plus en plus de navigateur.

                Mais aucun site web "normal" ne l'utilise

                Ma banque l'offre comme méthode d'authentification.

                d'un autre côté je suppose que le gouvernement aurait le nombre de consultation du site

                Pourquoi ?

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Backup => il y a de l'idée

                  Posté par  . Évalué à 3.

                  Pourquoi ?

                  Les logs OCSP pourraient donner pas mal d'info ?

                  • [^] # Re: Backup => il y a de l'idée

                    Posté par  . Évalué à 3.

                    C'est vrai. (Pour ma défense, personne ne vérifie les révocations de certificats)

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Backup => il y a de l'idée

            Posté par  . Évalué à 4.

            C’est pris en charge à ma connaissance par la plupart des serveurs web et par la plupart des navigateurs… et c’est complètement inutilisé.

            Et c'est normal, parce que c'est vraiment vraiment vraiment très complexe.

            Les serveurs web le prennent en charge, cool, mais pour le prendre en compte dans ton code, c'est déjà une autre paire de manche. La mise en place dans le navigateur est compliquée. Coté serveur la gestion connexion/déconnexion n'est pas simple (il faut utiliser un mode où le client n'est pas obligé de s'authentifier). Pour l'utilisateur, transférer son identité sur un autre navigateur n'est pas simple. Tu prends encore plus de pleins fouet les problèmes d'autorité, mais tu peux créer ta propre PKI (on avait dit compliqué ?). On doit renouveler son identité régulièrement (oui les certificats client ont aussi une péremption).

            Sur le papier c'est vraiment bien, mais dans les faits il vaut AMHA laisser ça pour les connexions M2M ou de serveur à serveur.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Backup => il y a de l'idée

              Posté par  . Évalué à 3.

              c'est vraiment vraiment vraiment très complexe.

              Bof, pas beaucoup plus selon moi que toutes les technologies d’authentification à deux facteurs (HOTP, TOTP et assimilés) qui elles sont de plus en plus déployées.

              Pour l'utilisateur, transférer son identité sur un autre navigateur n'est pas simple.

              Exporter un fichier PKCS#12 (contenant le certificat et la clef privée associée), l’importer sur l’autre navigateur. Granted, les interfaces pour ça dans les navigateurs ne sont pas des plus intuitives (je suppose que personne n’a travaillé dessus depuis 1997…), mais ce n’est pas insurmontable.

              Et comme dit plus haut il y a la solution des cartes PKCS#11, qui permettent d’avoir son certificat sur soi et non dans le magasin d’un navigateur. Chiant à déployer, de demander à tout le monde d’avoir une smartcard ? Pas plus que de demander à tout le monde d’avoir un token USB comme le propose le standard U2F

              mais tu peux créer ta propre PKI (on avait dit compliqué ?).

              Encore une fois, pas plus compliqué que gérer la double authentification par SMS, code TOTP, et tout le toutim. Et ça c’est déployé — et pas seulement par les « gros », même les « p’tits gars » de Framasoft le font.

              • [^] # Re: Backup => il y a de l'idée

                Posté par  . Évalué à 3.

                Bof, pas beaucoup plus selon moi que toutes les technologies d’authentification à deux facteurs (HOTP, TOTP et assimilés) qui elles sont de plus en plus déployées.

                Je ne dis pas le contraire.

                Exporter un fichier PKCS#12 (contenant le certificat et la clef privée associée), l’importer sur l’autre navigateur. Granted, les interfaces pour ça dans les navigateurs ne sont pas des plus intuitives (je suppose que personne n’a travaillé dessus depuis 1997…), mais ce n’est pas insurmontable.

                En s'assurant de ne pas foutre le certificat n'importe où, avec l'espoire que l'utilisateur ne va pas faire sauter le mot de passe du certificat parce que ça va plus vite.

                Encore une fois, pas plus compliqué que gérer la double authentification par SMS, code TOTP, et tout le toutim. Et ça c’est déployé — et pas seulement par les « gros », même les « p’tits gars » de Framasoft le font.

                Je ne sais pas ce que fait framasoft, mais pour la plupart c'est les gros le déploient et les autres utilisent les services de ces gros.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Backup => il y a de l'idée

                Posté par  . Évalué à 2.

                La plupart des gens terminent ssl au load balancer frontal, du coup bonne fete des morts pour soit valider l'authentification client et la forwarder au server d'appli derriere, soit router du ssl en aveugle jusqu'au bon serveur d'appli.

                C'est pas impossible, mais ca reste loin d'etre simple a mettre en place.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: Backup => il y a de l'idée

                  Posté par  . Évalué à 4.

                  Ajouter un header HTTP ne me semble pas compliqué et pas d'applis gère ça bien. J'en connais plusieurs en prod comme ça.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Backup => il y a de l'idée

            Posté par  . Évalué à 2.

            Ça reste néanmoins une « super idée », personnellement je m’en sers autant que possible (je m’en suis servi par exemple pour protéger l’accès à l’espace d’administration d’un site SPIP).

            Tu m’intéresses. Comment tu fais en PHP pour accéder au certificat et au résultat de la validation ? La dernière fois que j’ai regardé, yavait strictement rien un tant soi peu normalisé pour ça, fallait le faire à la main à coups de fascgi_param TLS_CLIENT_CERT $ssl_client_cert avec nginx.

            • [^] # Re: Backup => il y a de l'idée

              Posté par  . Évalué à 3.

              C'est comme ça qu'il faut faire.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Backup => il y a de l'idée

              Posté par  . Évalué à 3.

              Comment tu fais en PHP pour accéder au certificat et au résultat de la validation ?

              Ça, je ne sais pas. J’ai déployé le site SPIP, je n’ai pas écrit le code. Mais je ne pense pas que SPIP ait même besoin d’accéder au certificat, c’est l’option FakeBasicAuth du module ssl d’Apache httpd qui fait tout le boulot.

              Moi tout ce que j’ai fait, c’est configurer le serveur comme suit :

              <Location /ecrire>
                SSLVerifyClient       require
                SSLCACertificateFile  /etc/ssl/private/mysite/client-ca.crt
                SSLOptions            +FakeBasicAuth
                AuthType              basic
                AuthName              "My site private area"
                AuthUserFile          /etc/apache2/private/mysite.passwd
                Require               valid-user
              </Location>
              

              client-ca.crt est le certificat qui doit signer les certificats des clients, et mysite.passwd est un fichier de mot de passe de Apache « classique » (tel que généré par htpasswd) au détail près que le mot de passe associé à un utilisateur dans ce fichier est systématiquement password (c’est un mot de passe bidon qui ne sert à rien).

          • [^] # Re: Backup => il y a de l'idée

            Posté par  . Évalué à 2.

            La grande question c'est: pourquoi ne pas permettre les 2 à la fois? L'utilisateur choisit la solution qu'il préfère, comme ça les geeks peuvent utiliser ssh, et les autres leur solution faible.

      • [^] # Re: Backup

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

        Dans la pratique, ça se résume soit à:
        - oh… putain, encore un site qui a son propre bugtracker… bon, 2 solutions:
        * je fait un nouveau compte, avec mon pass classique
        * ça me soule, je zappe ( <=== solution la plus populaire je pense, en tout cas celle que j'adopte le plus souvent )

        Ou https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/integration/omniauth.md (qu’on peut voir par exemple sur https://gitlab.com/users/sign_in, avec le logo google, github etc).

        Qu’en pensez-vous ? Ça permet d’avoir le compte en 3 clics, et pas de nouveaux identifiants à retenir.

        Bien sûr on part du principe que la personne a un compte github, mais on suppose que c’est le cas, vu que la discussion tourne autour du fait que le centralisation de github est un de ses avantages.

        • [^] # Re: Backup

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

          C'est pas que une histoire de compte à créer. C'est aussi que les utilisateurs/développeurs sont déjà familiers avec l'interface GitHub et savent comment ouvrir des bugs et faire des clones. La familiarité et le confort jouent beaucoup dans l'effet de réussite!

          • [^] # Re: Backup

            Posté par  . Évalué à 2.

            La seule raison d'être de mon compte github c'est pour contribuer aux projets des autres. J'ai toujours trouvé l'interface de ce site horrible (les goûts et les couleurs…) et surtout: lente!

    • [^] # Re: Backup

      Posté par  . Évalué à 1.

      Je me demande si une solution n'est pas d'avoir une version du code (et des outils ?) sur Github pour profiter de l'effet « réseau »

      C'est moins pire que mettre tout uniquement sur GitHub. Mais c'est un cercle vicieux, si tout le monde raisonne comme cela, tout le monde contribuera à l’attractivité de GitHub. Certes utiliser un autre service permet de se passer de GitHub, mais il y en a plein (GitLab, Gogs, etc) (et c'est bien), mais GitHub continuera d'être de facto la solution la plus intéressante en terme de nombre de potentiels contributeurs. De plus, certaines personnes ne prendront pas cette précaution et mettrons tout sur GitHub, par flemme, non connaissance des problèmes (logiciel non libre, centralisation et ce qui va avec), etc.
      Ça risque de mettre du temps, mais je pense qu'au long terme il faudrait un protocole libre permettant la décentralisation et la fédération, ou une extension d'un protocole pour gérer le cas du visionnement des pull requests (XMPP ?). http://blog.schiessle.org/2016/02/12/the-next-generation-of-code-hosting-platforms/

      • [^] # Re: Backup

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

        Peux-tu m'expliquer le problème que pose GitHub en tant que plate-forme populaire d'hébergement de projet libre ? Je trouve perso qu'au contraire, ça résout un problème, ils proposent un hébergement de bonne qualité avec un effet social qui sauve des projets libres.

        Et ma parle pas d'appropriation de tes données, on parle de Git, le SCM où tu as en permanence une sauvegarde complète de tout l'historique de ton code sur ton ordi. Ils ne peuvent rien te prendre, tu ne fais que partager avec eux.

        • [^] # Re: Backup

          Posté par  . Évalué à 5.

          Il n'y a pas que le code, mais aussi l'historique des bugs reports, etc …

          • [^] # Re: Backup

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

            Et pour ça, il y a des api et des outils existants pour les récupérer. Les wiki, c'est du git aussi. etc. etc..

            • [^] # Re: Backup

              Posté par  . Évalué à -1.

              Pour l'instant, mais rien ne te garantit que du jour au lendemain GitHub ne va enlever ou complexifier l'exportation étant donné que tu n'as aucun contrôle sur le serveur.

              • [^] # Re: Backup

                Posté par  . Évalué à 5.

                Et ben ce jour la, t'arreteras de l'utiliser, et on migrera au nouveau service qui remplira le vide que github aura laisse.

                C'est ouf, j'arrive pas a comprendre cette mentalite. Parce qu'il est possible qu'ils fassent de la merde dans le futur, on va s'empecher d'utiliser un outil maintenant?
                Arrete d'utiliser linux alors, rien ne te garantit que linus va continuer a ecrire du code open source demain, si on suit ta logique.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: Backup

                  Posté par  . Évalué à 2.

                  Parce qu'il est possible qu'ils fassent de la merde dans le futur, on va s'empecher d'utiliser un outil maintenant?

                  Oui, c'est le principe de précaution et il fait partie de notre Constitution depuis Chirac : de peur que ce soit mal un jour, on n'utilise pas ! :-/

                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: Backup

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

                  Tu pars du principe qu'un service va emerger. Mais ça, c'est si github fait tellement de la merde que quelqu'un décide de refaire des trucs.

                  Par exemple, si demain, y a soit github, soit trois fois rien, et que github décide de bannir tout ce qui a trait à la crypto, parce que raison stupide (remplace "la crypto" par "popcorn time" par exemple). Il se passe quoi ?

                  Si demain, tel gouvernement contraint de fermer un compte à GH, genre la chine qui demande à fermer un miroir d'un soft libre qui contourne son firewall, il se passe quoi ?

                  Si demain, une entreprise fait fermer un soft qui démontre l'insécurité d'une de ses solutions, il se passe quoi ?

                  Si on concentre tout l'infra chez 1 fournisseur, alors, ce fournisseur deviens critique, et tu as beau parler d'autres services, ça va causer des soucis.

                  Si le projet Lua dont on parle se fait bannir de GH pour une raison quelconque, il va être moins vivace si j'en crois l'article. Alors ouais, le code est encore la, mais c'est une piètre consolation.

                  Donc oui, c'est une raison suffisante pour au moins donner du souffle à des alternatives, et peut être à rendre github moins centrale d'une maniére ou d'une autre.

                  Par exemple, gitlab.com permet d'avoir un projet qui est un miroir tenu à jour depuis github, ce qui est déjà un bon début.

                  • [^] # Re: Backup

                    Posté par  . Évalué à 4.

                    Tu pars du principe qu'un service va emerger. Mais ça, c'est si github fait tellement de la merde que quelqu'un décide de refaire des trucs.

                    Parce que ça a toujours était le cas pour tous les services qui ont de la valeur. Si ça ferme, un concurrent prend là main ou un nouveau service arrive pour combler le vide.

                    Pour tout ce que tu décris, il y a déjà des alternatives. Si tu veux vraiment quelque chose de neuf et de solide va regarder du coté des fondations comme Apache ou Eclipse. Ces fondations ont des règles claires et précises et fournissent certains nombre de garanties. Ce ne sont pas des projets communautaires mais la gestions par de multiples entreprises améliore leur solidité.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Backup

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

                      Si tu veux vraiment quelque chose de neuf et de solide va regarder du coté des fondations comme Apache ou Eclipse.

                      Le mouroir des projets fauxpensource abandonnés ?

                      • [^] # Re: Backup

                        Posté par  . Évalué à 5.

                        Eclipse (l'IDE) ? Apache (le serveur web) ? Groovy ? Ant ? Spark ? Subversion ? Kafka ? Hadoop ? Tomcat ? Maven ? Spamassassin ? Cordova ? Cassandra ? Zookeeper ?….

                        Je connais très mal la fondation Eclipse mais pour devenir un top project Apache (sortir de l'incubateur), il faut (entre autre) que le projet soit assez vivace.

                        Et puis reprocher à la fondation Apache de recevoir des projets morts alors que, pour sûr ce n'est pas sur github qu'on y trouve des projets morts.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Backup

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

                      Les fondations comme Apache ne vont aller que dans des cas précis. Comme tu dis, il y a des règles, notamment d'avoir assez de contributeurs (de boites différentes aussi), ce qui rends ça impropre pour la majorité des projets (mais pas forcément pour la majorité des projets qui ont un impact).

                      Et oui, y a des alternatives, mais pour le moment, si les gens n'utilisent pas, ça ne va pas influer vraiment sur la décentralisation.

        • [^] # Re: Backup

          Posté par  . Évalué à 0.

          Peux-tu m'expliquer le problème que pose GitHub en tant que plate-forme populaire d'hébergement de projet libre ?

          • [^] # Re: Backup

            Posté par  . Évalué à 10.

            Carl Chenet a fait un article sur le sujet : "Le danger Github". http://carlchenet.com/2016/01/22/le-danger-github/

            Tu veux dire, le mec qui quemande des etoiles pour ses projets github dans la plupart de ses posts?

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Backup

              Posté par  . Évalué à 3.

              Tu veux dire, le mec qui quemande des etoiles pour ses projets github dans la plupart de ses posts?

              Je n'en sais rien. Même s'il le fait, ça n'enlève pas la pertinence de sa réflexion sur GitHub. Son intégrité est une autre question, c'est une question sur la personne et pas sur les idées.

              • [^] # Re: Backup

                Posté par  . Évalué à 3.

                Même s'il le fait, ça n'enlève pas la pertinence de sa réflexion sur GitHub.

                Ben un pti peu quand meme. Le message qu'il envoit, c'est que la valeur apportee par github est superieure a l'inconvenient de centralisation, ce qui demonte un peu son argumentaire (et le tien aunpassage).
                'fin si on le considere pertinent, ce qui a l'air d'etre ton cas.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Backup

          Posté par  . Évalué à 4. Dernière modification le 31 mars 2016 à 10:47.

          Peux-tu m'expliquer le problème

          Une société privée se retrouve en position dominante avec dans un premier temps l'intention de faire le bien (sauver des petits projets libres, permettre une recherche efficace sur le web, retrouver ses copains de lycée) mais surtout la nécessité de rentabiliser l'argent des investisseurs.

          Comme google, facebook, etc. Tous partent d'une bonne intentions, presque altruiste. Mais sont très vite rattrapés par les règles du capitalisme ou l'attrait du pouvoir que leur donne leur position.

          Le problème : la plateforme n'appartient pas à ses utilisateurs et ceux-ci n'en ont pas forcément conscience avant que celle-ci ne devienne incontournable.

          C'est très piégeux.

  • # business model de github ?

    Posté par  . Évalué à 8.

    Le récit est une réponse très intéressante au récit paru il y a peu.

    Perso je ne connais pas très bien github, mais sur quoi est basé leur business model ? En effet, je doute qu'il fournisse un service gratuitement, ils doivent donc gagner de l'argent avec… mais comment ?

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Expérience enrichissante

      Posté par  . Évalué à 10.

      Vraiment ?
      Il n'y a aucune licence libre qui IMPOSE la courtoisie ? … Monde de merde !

      • [^] # Re: Expérience enrichissante

        Posté par  . Évalué à 3.

        meme dans les autres domaines c'est pas tip top, sans juger de la qualité du travail de l'auteur, regarde la futur nouvelle comédie musicale, avec des music d'Obispo

        il l'a appris dans la presse qu'il y allait avoir une reprise \o/

      • [^] # Re: Expérience enrichissante

        Posté par  (Mastodon) . Évalué à 10.

        En même temps tel que c'est décrit il recevait des patchs et des bug reports mais ne faisais pas suite…donc question courtoisie, balaye devant ta porte toussa, je comprends qu'un mec qui décide de faire un fork ne prenne même pas la peine de contacter l'auteur original si celui-ci n'a jamais répondu aux requêtes précédentes.

        Moi si on me fais un cadeau, je remercie même si ledit cadeau ne me plait pas et que je n'en aurai pas usage.

    • [^] # Re: Expérience enrichissante

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

      Si tu forkes, c'est une bonne pratique de changer de nom. Si tu fais revivre un logiciel à l'abandon comme dans mon cas, c'est plus délicat. Mais un mail de courtoisie me parait le minimum. Ca m'est déjà arrivé plusieurs fois d'être celui qui reprend un projet et j'ai toujours écrit à l'auteur original, parfois avec succès (allez-y les gars, c'est fait pour), parfois avec une réponse plus mitigée (je vais voir si je peux intégrer tes changements puis finalement rien ne se passe). Mais le fork non annoncé, c'est pas très sympa.

      Après, je m'agace peut-être pour rien, le modèle de GitHub est basé sur du fork a tout va, le monsieur n'a pas pris la mesure de tout ce qu'il faisait.

    • [^] # Re: Expérience enrichissante

      Posté par  . Évalué à 5.

      J'ai une fois utilisé une bibliothèque nommée pluma-framework (gestion de plug-ins utilisables sous windows/Linux pour projets C++).
      C'était hébergé sur sourfeforge, pas de contribution pendant un moment, mais après avoir testé un "hello world" (qui était fourni par le dev original) j'ai adopté: simple à utiliser, doc potable (ce qui est trèèès rare dans les lib C et C++ selon moi), code décemment propre (ce qui est rarissime dans ce que j'ai pu lire jusqu'ici) malgré la présence de template (ce qui n'est pas simple à faire, en plus d'être rarissime).

      Manque de bol, à l'usage je me suis aperçu que ça manquait de souplesse sur un ou deux points. J'ai codé les fonctions en questions, et comme j'étais dans ma période de transition vers le full command-line, j'ai pondu un CMakeLists.txt pour compiler aussi, je suis pas sûr pour le CPack, par contre, j'ai peut-être pas fait les chose jusqu'à la fin…

      En tout cas, j'ai publié le fork comme dépendance du logiciel sur lequel je bossait à ce moment, en "changeant" le nom: j'ai ajouté "-fork" à la fin. Et j'ai prévenu l'auteur.

      Tu as raison, je n'avais aucune obligation de prévenir l'auteur, en théorie.
      Dans la pratique, j'en avais une: si lui faisais des modifications un jour, autant qu'il prenne en compte les mienne, histoire que je puisse tuer un fork qui n'a que peu de raisons d'être.
      Et dans l'idéal, il y a encore d'autres raisons: politesse, respect.

      Bien que j'aie choisi le chemin facile, autrement dit le fork avant la discussion, j'ai quand même prévenu (et crédité et encouragé à aller voir dans le README) l'auteur d'origine. Dont la réponse était pour le coup assez indifférente, mais peu importe.

      Certes, les licences libres autorisent voire encouragent tout le monde a forker, mais si tout le monde fork à tout va sans même se prévenir, on va perdre des contributions, du temps de travail, de la qualité, tout ça pour rien.
      Le modèle centralisé, on peut en dire que ce que l'on veut, mais chez les faitneants, c'est pas le plus populaire pour rien: plus on centralise, plus on peut optimiser les efforts. Malgré que ce soit limité à la condition que tout le monde ait un objectif assez proche. Si l'objectif est trop loin, le libre à la décence de permettre le fork, et que le meilleur gagne!
      J'ai comme l'impression que l'on confond trop "libre" et "décentralisé" qui n'ont pourtant rien à voir… et pour cause: ils sont sur des axes différents dans le multivers.

      • [^] # Re: Expérience enrichissante

        Posté par  . Évalué à 3. Dernière modification le 08 mars 2016 à 00:22.

        Et dans l'idéal, il y a encore d'autres raisons: politesse, respect.

        Et ca marche dans les 2 sens. Des fois lorsque le chef de projet est un trouduc, il mériterait son petit fork.

        Exemple:
        Prenez "Git pour Windows". Tout le monde n'a pas envie de se coltiner le man de Vi pour éditer un commentaire de commit ou faire un rebase interactive.
        Il n'apparaitrait pas saugrenu pour attirer des newbies git sous Windows, de proposer autre chose qu'un notepad détaché et de pouvoir utiliser un éditeur de terminal compatible avec le cerveau un être humain correctement formaté ("Vi has two modes and you're in the wrong one" joke inside), par exemple "nano", qui a le bon goût d'être dispo sous MacOSX en plus.
        Et bien, quand on voit le prétexte foireux du dev qui ne veut pas juste rajouter un package à son mSys2 et qui fait la leçon, on se dit que des fois un petit fork hostile ça pourrait faire du bien à certains:
        https://github.com/git-for-windows/git/issues/587

        Parce que bon hé jusqu'à preuve du contraire, Vi ce n'est pas du git non plus.
        Pis tant qu'à faire si vous regardez sous le /bin local vous y retrouverez
        plein d'outils qui n'ont rien à voir avec git comme du curl par exemple.
        Et comme ni cygwin et mSys2 n'ont le bon goût de permettre d'installer des packages depuis rawgit, on se dit qu'on pourrait contourner par exemple avec un petit script bien comme il faut:
        https://github.com/transcode-open/apt-cyg
        Et là, manque de bol ca marche avec du wget ou du lynx mais pas du curl. Faut-y proposer une pull request à ce dernier pour voir s'il sera plus avenant ?
        Ou alors se coltiner tout à la mimine et gagner des XPs en postant son tip (un de plus sur Git) sous StackOveflow ?

        Ma bonne dame , un utilisateur de base, qui trouve que git ca ressemble à la grosse Bertha pour écraser une mouche, il a pas que ça à foutre.

        Mais après faut surtout pas aller raconter que windows est un citoyen de seconde zone pour git.

        Mais, je sais: même pas cap de forker

        • [^] # Re: Expérience enrichissante

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

          Mais après faut surtout pas aller raconter que windows est un citoyen de seconde zone pour git.

          En effet, il faut dire que windows est un citoyen de seconde zone pour le développement.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Expérience enrichissante

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

            Pour le développement avec Git en particulier. Mercurial avait le bon goût d'être parfaitement fonctionnel sous Windows, sans aucune bidouille à la c** comme git. Sinon, je recommande sourcetree, c'est closed source mais ça marche très bien.

            Pour ces histoires de Windows, l'histoire se répète. Il y a quelques années, Gtk a plus ou moins gagné la bataille des GUI préféré pour le dev d'applis sous Linux. Sauf que avec Gtk, Windows est une plate-forme de seconde zone. C'est pas un problème pour une appli qui démarre mais pour toutes les applis très populaires, Windows devient un jour une plate-forme cible et là, le cauchemar commence. Certains persistent (comme Gimp, mais au prix d'un seul développeur, donc d'une grande fragilité de la maintenance) et d'autres laissent tomber pour un choix plus pérenne (Wireshark, Subsurface, GCompris, …).

            Pour Git, on est reparti pour un tour. Le support Windows est moyen, Git n'a pas du tout été écrit pour fonctionner sous Windows. Ce qui est donné sous Linux (tout un tas d'outil en ligne de commande) est difficile à avoir sous Windows. Et c'est pas prêt de changer. Mon dernier exemple en date, c'est que si je rajoute git à mon path sous Windows pour travailler sur un projet Git, je peux plus utiliser subversion sur mon autre projet. Git embarque en effet son propre subversion, incompatible avec le mien.

            Et contrairement à la bataille Qt/Gtk où Qt a de nouveau ses chances, la bataille Git/Mercurial est perdue depuis longtemps par Mercurial. GitHub ne va a priori jamais rajouter un support Mercurial (tout leur flow est basé sur Git). Même chez Atlassian qui soutenait pas mal Mercurial avec Bitbucket, on laisse tomber Mercurial tranquillement: tous leurs produits sont basés sur Git.

            • [^] # Re: Expérience enrichissante

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

              Et c'est pas prêt de changer

              Euh, c'est pas comme si il n'y avait personne qui travaillait là dessus … Y'a eu du gros développement pour le support de Git sous Visual Studio (avec contributions de Microsoft à libgit2 en open-source). Maintenant il y a un salarié Microsoft à plein temps sur « Git for Windows ».

              • [^] # Re: Expérience enrichissante

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

                Ca arrive toujours après la bataille. Le jour où Linus et tous les contributeurs majeurs de git compileront tout leur code sous Linux et Windows, on en reparlera. En attendant, Windows restera à la traine.

                • [^] # Re: Expérience enrichissante

                  Posté par  . Évalué à 4.

                  « Après la bataille » ? C'est du libre s'ils veulent contribuer il n'y a pas de soucis (ce qu'ils font), s'ils veulent utiliser des clients alternatifs (comme celui éventuellement proposé dans leur IDE, le client lourd de github, l'excellent sourcetree ou Hg-Git) il n'y a pas de problème.

                  Linus a écrit git pour les développeurs du noyau linux, lui reprocher que ça ne fonctionne pas sous un OS donné (que ce soit Windows ou AIX) c'est assez risible. Ce qu'on remarque, c'est surtout que git fonctionne très bien sur tout ce qui se rapproche d'un unix. Windows est une exception, ses utilisateurs en paient le prix. C'est très utile quand on est la plateforme qui a le leadership comme pour les jeux vidéos, mais quand on ne l'est plus c'est tout de suite moins rigolo. Les annonces de ses derniers temps semblent montrer que c'est de moins en moins rigolo.

                  Cette peine que tu as, ne semble surtout ne pas vraiment être partagée. Si c'était si douloureux d'utiliser git sous windows, je doute que github aurait pu s'imposer avec git.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Expérience enrichissante

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

                  Linus et tous les contributeurs majeurs de git

                  Ahem, rien que ça, ça en dit long sur à quel point tu ne t'es pas renseigné sur la question. Ça fait belle lurette que Linus a passé la main sur Git, il ne suit même plus régulièrement la mailing list, il envoie un patch de temps en temps mais je peux t'assurer que le fait que Linus compile Git sous Windows ne changerait strictement rien à la santé de Git pour Windows.

  • # Libre ?

    Posté par  . Évalué à 10.

    En 2011, un type a carrément importé mon projet sous GitHub, créé son fork et sorti une v2. Tout ça sans même m'envoyer un mail de politesse. J'ai laissé faire mais j'ai pas trop aimé: il y avait maintenant un LuaUnit v2 qui n'était plus le mien.
    […]
    J'enterrerai de honte le salaud qui a osé forké mon projet sous Github avec un projet plus mieux que le sien. Ce serait la revanche de mon ego de développeur libre!

    Si je lis bien tu as préféré relancer ton projet de ton côté et au lieu de contribuer à l'autre version plus avancée. J'ai du mal à comprendre. Pourquoi alors publier sous licence libre si personne n'a le droit d'y toucher ?

    Le but n'est-il pas justement d'avoir la possibilité de reprendre un projet qui m'est utile mais abandonné par son auteur ?

    Ta réaction possessive me semble en conflit avec le but des licences libres.

    • [^] # Re: Libre ?

      Posté par  . Évalué à 4.

      Je ne suis pas sûr qu'il soit judicieux de prendre la dernière phrase que tu cites au premier degré …

      • [^] # Re: Libre ?

        Posté par  . Évalué à 8.

        Tout d'abord félicitations par contre pour la reprise du projet et de manière générale merci pour le code que tu livres sous GPL.

        Après, encore plus de temps a passé. LuaForge a cessé d'être maintenu, et de 2009 à 2012, plus personne ne s'est intéressé au projet. Il mourrait tranquillement comme des milliers d'autres logiciels libres. Ça me serrait le cœur, d'autant plus que j'avais encore un ou deux patch datant de 2008 à intégrer, mais vraiment, j'avais pas le temps avec maintenant un enfant, une vie de famille, beaucoup de boulot, etc etc.

        En 2011, un type a carrément importé mon projet sous GitHub, créé son fork et sorti une v2. Tout ça sans même m'envoyer un mail de politesse. J'ai laissé faire mais j'ai pas trop aimé: il y avait maintenant un LuaUnit v2 qui n'était plus le mien. C'est bien que quelqu'un fasse vivre ce logiciel, mais LuaUnit, c'était normalement mon bébé. Grrrr.

        En gros tu ne l'avais pas touché depuis 2008, 3 ans plus tard un gars a forké. Personnellement je ne vois pas le problème. Légalement c'est correct. L'éthique c'est personnel et ça ne choque pas la mienne.

        Le libre c'est ça aussi.

        • [^] # Re: Libre ?

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

          Même un logiciel qui semble inutilisé depuis 3 ans peut avoir une vie sans que ça se voit. En m'envoyant un mail, il aurait aussi pu me remotiver on se serait attaquer ensemble à la prochaine version.

          Légalement, bien sur qu'il n'y a aucun problème. Mais la communauté du logiciel libre a des usages sociaux qui ne sont pas uniquement dictés par la loi de la licence. Typiquement, reporter un bug, reporter des modifications à un logiciel, contribuer à son amélioration ne sont pas des obligations mais des actes sociaux qui font partie du fonctionnement de la communauté en général.

          Il me semblait avoir indiqué quand même indiquer relativement clairement ce qui m'a posé souci : c'est mon ego qui en a pris un coup. L'ego, c'est justement le truc qui s’accommode mal de gentilles explications.

          Après, si ça me posait vraiment un gros problème, j'aurai agi plus fermement. Faire revivre le logiciel est finalement la meilleure façon de réparer mon ego sur ce coup là et de sortir par le haut. Coup de bol, ça a des externalités positives ! Tout est bien qui finit bien.

          • [^] # Re: Libre ?

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

            Après, si ça me posait vraiment un gros problème, j'aurai agi plus fermement.

            En faisant quoi du coup ? En changeant pour une licence non libre rétroactivement ?

            • [^] # Re: Libre ?

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

              Quelle idée bizarre! Je n'ai aucun problème avec la licence de mon logiciel.

              J'aurai réagi en envoyant un mail en signalant que la politesse quand on sort une version officielle d'un soft qui est le fork d'un autre veut qu'on informe quand même l'auteur original de ce qui se passe. Et je lui aurai parlé des évolutions que j'avais en tête pour la v2 et des problèmes que je connaissais à l'heure actuelle sur la v1 pour qu'il puisse les intégrer à son plan de développement si ça a un sens pour lui. Bref, avoir un vrai canal de communication pour faire des échanges constructifs.

              • [^] # Re: Libre ?

                Posté par  . Évalué à 10.

                J'aurai réagi en envoyant un mail en signalant que la politesse quand on sort une version officielle d'un soft qui est le fork d'un autre veut qu'on informe quand même l'auteur original de ce qui se passe.

                Heu, tu dis toi même que ton soft était léthargique depuis 3 ans. En informatique, ça signifie ni plus ni moins que ton le d;veloppement de ton soft est mort et enterré, et que son seul salut est que quelqu'un d'autre prenne la relève. Alors bon, moi il me semble que tu es bien le seul à blamer ici, et que l'auteur du fork a l'entier mérite de t'avoir mis un coup de pied aux fesses bien mérité! Le logiciel libre, c'est aussi ça! >:P

          • [^] # Re: Libre ?

            Posté par  . Évalué à 9.

            C'est marrant que tu parles d'égo, car en ce qui me concerne, c'est de voir le compteur de fork s'incrémenter sous mes projets github qui flatte le miens.

            Un fork est justement un signe que ton travail intéresse d'autres utilisateurs, si tu te sens mal à l'aise à l'idée que d'autres personnes puissent s'approprier ton travail, il vaut mieux ne pas faire de libre en effet.

            Mais je comprends tout à fait ton point de vu, juste que je pense que le code qu'on écrit, à partir du moment où il est libre, ne nous appartient plus.

            • [^] # Re: Libre ?

              Posté par  . Évalué à 1.

              Mais je comprends tout à fait ton point de vu, juste que je pense que le code qu'on écrit, à partir du moment où il est libre, ne nous appartient plus.

              Je suis bien d'accord. Ce qu'on crée vraiment pour nous et uniquement pour nous quand on fait du logiciel libre, c'est l'amélioration de ses compétences en général et plus spécifiquement une expertise sur le logiciel précis qu'on développe. Si il existe quelqu'un qui désire payer pour des modifications, il y a de grande chance pour qu'on soit le mieux placer pour les faire et donc récupérer le pognon.

            • [^] # Re: Libre ?

              Posté par  . Évalué à 3.

              Mais je comprends tout à fait ton point de vu, juste que je pense que le code qu'on écrit, à partir du moment où il est libre, ne nous appartient plus.

              Un code, oui. Un projet (avec un nom et une image), je ne suis pas d'accord. Personnellement, je jour ou je diffuse un projet libre, je garde la main sur le nom (gestion de l'image).

            • [^] # Re: Libre ?

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

              Il y a une grosse incompréhension. Je n'ai aucun problème avec le fait que les gens utilisent mon code et le modifient. Ma licence préférée est d'ailleurs la WTFPL, qui décrit le mieux les contraintes que je veux mettre sur l'utilisation de mon logiciel (en gros, aucune). J'ai choisi BSD parce que ça fait plus respectable et que je suis contre la prolifération des licences mais vraiment WTFPL, c'est le bon esprit.

              Par contre, il y a une grosse différence entre utiliser un logiciel, le bidouiller dans tous les sens, le faire évoluer, etc etc et sortir une version officielle d'un logiciel existant en l'estampillant v2. J'avais des plans précis sur ce qui justifierai un passage de la v1 en v2. Et comme je l'ai dit plus haut, le fait que aucun dev ne soit visible n'empêche pas qu'il y a peut-être des choses en cours, qui auraient pu être intégrés à ce fork (typiquement, les 3-4 patch que j'ai reçu par mail).

              J'ajoute que je trouve les remarques qu'on me fait assez condescendantes: "ne fais pas de logiciel libre, change la licence". Je rappelle que la communauté du logiciel libre est régie par des licences mais aussi par des usages: reporter des bugs quand on les trouve, proposer des patchs quand on peut développer, contribuer au logiciel libre quand on est une société qui gagne de l'argent avec, etc. Aucun de ces usages n'est réclamé par une licence et pourtant, beaucoup sont choqués quand ils ne sont pas respectés.

              De même, j'ai la faiblesse de penser que pour sortir une version officielle d'un logiciel, les usages veulent qu'on en informe l'auteur original. Une anecdote intéressante au passage, lunit - l'autre bibliothèque de test unitaire en Lua qui est sorti en même temps que la mienne - a suivi plus ou moins le même chemin: abandonware, puis fork et rajout de fonctionnalité. Sauf que ce fork a eu la délicatesse de changer le nom en lunitx .

              A vous lire, j'ai l'impression que mon travail devrait être entièrement dépassionné, rien dans dans ce que la licence l'autorise ne devrait m'affecter. Ce n'est pas comme cela que je fonctionne, je suis un être humain, mu par des émotions positives comme négatives: fierté de mon travail et joie lorsque j'écris mon premier logiciel, petite honte quand je le laisse pourrir, colère envers moi-même quand je constate mon échec à le maintenir alors qu'un autre y arrive, colère quand un autre réutilise le même nom que le mien pour son travail, fierté de nouveau quand je reprends la main. Le monde où toute émotion contraire à la licence n'aurait pas sa place me semble bien triste… J'espère que ce n'est pas le votre ?

              • [^] # Re: Libre ?

                Posté par  . Évalué à 3.

                A vous lire, j'ai l'impression que mon travail devrait être entièrement dépassionné, rien dans dans ce que la licence l'autorise ne devrait m'affecter. Ce n'est pas comme cela que je fonctionne, je suis un être humain, mu par des émotions positives comme négatives: fierté de mon travail et joie lorsque j'écris mon premier logiciel, petite honte quand je le laisse pourrir, colère envers moi-même quand je constate mon échec à le maintenir alors qu'un autre y arrive, colère quand un autre réutilise le même nom que le mien pour son travail, fierté de nouveau quand je reprends la main. Le monde où toute émotion contraire à la licence n'aurait pas sa place me semble bien triste… J'espère que ce n'est pas le votre ?

                Pas du tout, pourquoi dépassionné ? Tu peux être fier qu'un autre dev considère que c'est une bonne base pour continuer. Tu as participé au mouvement du logiciel libre comme peu le font, en publiant du code sous licence libre. Par contre en licenciant ce code comme tu l'as fait, tu as permis ce fork.

                Ton comportement est très humain et se comprend très bien ne t'inquiète pas. Mais tu prends ça trop à cœur. Ok il a pas été très poli, mais ça ça ne l'est pas particulièrement non plus :

                J'enterrerai de honte le salaud qui a osé forké mon projet sous Github avec un projet plus mieux que le sien.

                Bref, son comportement se comprend, le tien aussi. Beaucoup de bruit pour rien et j'y participe. Je cesse donc d'émettre. ;)

            • [^] # Re: Libre ?

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

              Attention chez github le fork est routinier pour proposer une évolution avec pull request et effectivement peut refléter l'intérêt que suscite le projet ; là on parle de fork "agressif" du genre "je reprends le projet car le mainteneur fait le mort", pas grand chose à voir.

              • [^] # Re: Libre ?

                Posté par  . Évalué à 7.

                là on parle de fork "agressif" du genre "je reprends le projet car le mainteneur fait le mort"

                Mouais fork agressif il ne faut pas exagérer. Un fork agressif pour moi, c'est plutôt dans le cas ou l'on fork un projet actif et qu'on cherche à exterminer l'original.

                La bienséance aurait voulu que celui qui veut reprendre le projet essaie de contacter l'auteur/le mainteneur orignal. Mais d'ailleurs qui est le mainteneur d'un projet libre ? Celui qui détient le nom de domaine ? Celui qui a le plus grand nombre de commits ? Celui qui a fork prems ?

                Bon en cherchant bien on peut trouver je ne cherche pas a excuser l'acte. Mais si un projet dort pendant quelques années on peut imaginer que l'auteur à lâché les rênes et qu'il n'y a plus personne au volant. Encore une fois un mail pour s'en assurer ne peut pas faire de mal sauf si la réponse n'est pas très cordial en retour du genre : "nah t'y touche pas avec tes mains sales, c'est à moi et je veux bien te prêter si tu joues dans une autre cour ie renommes".

                • [^] # Re: Libre ?

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

                  C'est marrant je me suis dit "expliquer la différence de sémantique derrière les deux notions de fork, mettre entre guillemets l'adjectif agressif, allez ça suffira je vais pas alourdir le texte pour anticiper les chieurs".

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 7.

            Ce commentaire a été supprimé par l’équipe de modération.

  • # Commentaire supprimé

    Posté par  . Évalué à -1. Dernière modification le 11 mars 2016 à 16:52.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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