Journal De l'avenir des projets communautaires face aux sirènes de la finance

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
20
21
sept.
2018

Amis de l'OpenSource, une question philosophique me taraude l'esprit depuis un certain temps, et c'est par coincidence que je prends le clavier un vendredi.

Je pense en particulier à la généralisation du modèle OpenCore pour les projets qui fonctionnent bien.
On pourra s'expliquer les motivations, à savoir par exemple pour un développeur d'un produit openSource, sans aucune contribution extérieure, et qui voit son projet largement utilisé par ailleurs.
Par opposition, dans le fond, je m'interroge surtout sur les conséquences pour les utilisateurs qui s'appuient sur ces solutions Open, sans aucune compétence de développeur, et ne pouvant que compter sur la communauté pour faire évoluer les-dites solutions.

[Les exemples sont potentiellement imprécis et servent essentiellement à illustrer l'idée]
Le premier exemple est par exemple Nessus.
Outil de scan largement utilisé et rentabilisé par de nombreuses SSII sans aucun retour, le développeur de ce dernier a pour ainsi dire forké son propre projet pour le rendre rentable, laissant la communauté (c'est à dire plus grand monde) poursuivre son effort, avec une large perte en notoriété à la clé.

Il y a eu ensuite Citrix, qui a racheté la marque Xen, pour, louablement, le développer de manière communautaire, open etc … et on a vu depuis la version 7.2 que tout communautaires qu'ils sont, des fonctionnalités, de plus en plus, sont réservées aux clients qui paient. Et si j'en crois un ticket ouvert récemment, ils y ajoutent même des morceaux de closed Source. Leur recommandation pour les nostalgiques étant de forker le module open et de le maintenir eux-mêmes.
https://bugs.xenserver.org/browse/XSO-878

J'utilise GitLab depuis un certain temps, qui s'appuie également sur un modèle open core. Il n'est plus une version qui ne propose des nouveautés disponibles que pour les clients des versions payantes.
Probablement, ou pas, lié à la visibilité gagnée par le rachat de GitHub par MS, ces derniers ont le vent financier en poupe:
https://datanews.levif.be/ict/actualite/gitlab-recueille-cent-millions-de-dollars/article-normal-986755.html
https://www.linformaticien.com/actualites/id/50329/gitlab-depasse-le-milliard-de-dollars-de-valorisation.aspx

C'est probablement très bien pour eux … mais ces nouveaux investisseurs ne sont sans doute pas là pour la cause, et quand ils voudront un vrai retour sur investissement, ils auront probablement du mal à comprendre qu'autour de GitLab il y a tout un panel d'utilisateur qui s'appuient gratuitement sur leur produit.
A cet instant, je suis inquiet pour l'évolution du produit 'Open'.

Il y en a d'autres, je m'arrête là.

Du coup, plus généralement, quel est votre avis sur cette nouvelle tendance du libre ?
Est la rançon de la reconnaissance toujours plus grande de la qualité des produits open source ?
S'appuyer sur des solutions open source pour construire quelque chose ne deviendrait-il pas dangereux à terme ?

  • # Mon avis

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 21 septembre 2018 à 16:06.

    Je n'ai pas trop d'avis la dessus, mais j'en ai un peu quand même.

    Déjà pour commencer, d'un point de vue idéologique, je n'aime pas le modèle open core -MAIS- je comprends que ça peut permettre de financer des sociétés, et donc à des gens d'avoir un salaire, et ça c'est cool.

    On ne peut pas faire que du libre tout le temps, non pas que le propriétaire soit une fin en soi (en fait de mon point de vue ça ne devrait juste pas exister) mais, selon moi, parce que des fois, ce qu'on fait pour une personne ne servira jamais par ailleurs, et c'est juste inutile de partager ce code qui n'apporte finalement rien à personne.

    Je pense que l'open core, c'est un peu un mélange des deux, le plus gros pour tout le monde, et le spécifique pour les gens qui veulent le payer - pourquoi pas.

    Et puis il y vraiment beaucoup de produits open source qui ne seront jamais open core pour autant, qui resteront complètement communautaires jusqu'à la fin du monde ou leur propre fin.

    J'ai l'impression, je me trompe peut-être, que les produit open core sont presque toujours des produit "finaux", c'est à dire des vraies application métier, pas des frameworks, ni des noyaux de système d'exploitation. Et en ça, finalement, ça me dérange pas, car une application métier, c'est effectivement à la fois long, coûteux, barbant, complexe à maintenir - alors faire payer pour des fonctionnalités qui finalement ne servent pas à tout le monde, ça ne me choque pas.

    Je comprends les gens qui payent pour des solutions payantes pour des applications métier. Il y a un contrat, des garanties, un service, et ça paye des gens. Juste certains projets open core ne respectent pas le jeu comme tu le dis si bien, et finalement ce qui est open n'est pas suffisant pour un monsieur tout le monde, et dans ce cas là, c'est pas du open core, c'est plutôt du "regarde mon code mais paye pour le faire marcher", et là j'aime pas ça.

    GitLab au contraire, on l'utilise chez nous, on a une instance, c'est un produit merveilleux et qui fonctionne extrêmement bien, et le contrat open core est bien respecté, car le produit communautaire est vraiment complet et fonctionnel, et maintenu, et évolue, et a souvent des nouvelles fonctionnalités.

  • # Faire la différence

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

    Oui, c'est compliqué de faire vivre un projet open source, surtout quand plein de monde l'utilise, rapporte des bugs, mais ne paye rien.
    Donc on se pose des questions (moi y compris) sur comment rentabiliser, "open core" peut être pas mal, ça dépend.

    Mais justement, "ça dépend", et dans ta liste tu oublies une grosse différence :
    - Xen, c'est du copyleft, donc seul le propriétaire peut offrir des fonctionnalités proprios (c'est ce que j'adore dans les pro-copyleft qui me bassinent avec le "bien commun" du copyleft face à la fermeture du copyfree : le copyleft est en fait utilisé pour verrouiller, sur le produit publicitaire afin de vendre du proprio, ha ha)
    - GitLab, c'est du copyfree, donc tout le monde peut concurrencer GitLab avec le même business que GitLab, c'est sain (que le meilleur gagne sur la base de ce qui existe).

    Est la rançon de la reconnaissance toujours plus grande de la qualité des produits open source ?

    C'est surtout la rançon de la mentalité "tout gratuit", tiens il y a 1 heure un n-ième mail "oui j'ai besoin de la fonctionnalité mais le mieux est que tu développes gratos car moi je paye pas, c'est bien pour ton projet d'avoir cette fonctionnalité".
    Les utilisateurs "nous" force à ne pas faire que du libre…

    S'appuyer sur des solutions open source pour construire quelque chose ne deviendrait-il pas dangereux à terme ?

    Ca reste open source, juste qu'il faut que tu sois prêt à payer si les autres ne le font plus. Pas de risque sauf si tu ne veux pas payer.

    • [^] # Re: Faire la différence

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

      c'est ce que j'adore dans les pro-copyleft qui me bassinent avec le "bien commun" du copyleft face à la fermeture du copyfree : le copyleft est en fait utilisé pour verrouiller, sur le produit publicitaire afin de vendre du proprio, ha ha

      Prenons un exemple. Une entreprise A a un produit P en copyleft, et un produit P' qui est P avec des fonctionnalités propriétaires. Une entreprise B forke P et commence à ajouter des fonctionnalités pour fabriquer P". Un client C de B achète P". La seule différence avec un client de A, c'est qu'il a accès à l'ensemble des sources de P" et qu'il n'a pas accès aux fonctionnalités de P'. Il peut divulguer les sources de P", la licence l'y autorise, mais il peut aussi les garder pour lui. Admettons qu'il les garde pour lui parce que ça lui coûte de les mettre à disposition et qu'il n'a ni le temps ni l'argent pour ça. Dans tout ça, A n'a pas accès à P". Dans ce scénario, quelle différence, du point de vue de A, avec du copyfree ? Aucun.

      Conclusion : le monde n'est toujours pas binaire avec les gentils copyfree et les méchants copyleft.

      • [^] # Re: Faire la différence

        Posté par  . Évalué à 2.

        Admettons qu'il les garde pour lui parce que ça lui coûte de les mettre à disposition et qu'il n'a ni le temps ni l'argent pour ça

        Argument en bois car cela ne dépend pas de la licence. C'est la même chose avec n'importe quelle autre licence libre. Il y a plein de gens qui font des modifs pour leurs besoins, et qui ne les publient pas car manque de temps, code pas propre, etc.

         

        Dans tout ça, A n'a pas accès à P"

        C'est A qui a créé la situation initiale, donc on s'en tape qu'ils ne puissent pas faire un truc qui découle de ça.

    • [^] # Re: Faire la différence

      Posté par  . Évalué à 10.

      tiens il y a 1 heure un n-ième mail "oui j'ai besoin de la fonctionnalité mais le mieux est que tu développes gratos car moi je paye pas, c'est bien pour ton projet d'avoir cette fonctionnalité".

      Cette réponse sur la mailing-list de Python me paraît parfaitement pertinente. Les banques se gavent, mais elles ne sortiraient pas 200k$ pour payer une année de développement afin de corriger des bugs de sécurité…

      • [^] # Re: Faire la différence

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 21 septembre 2018 à 19:43.

        C'est ce que je réponds mais clairement, ça ne change pas grand chose, les gens se sauvent et se plaignent en ligne que c'est buggué et c'est tout, pour 99% des réponses que je fais dans ce style.
        Et justement, c'est bien le soucis : ça ne marche pas, pour pas mal de monde, d'où la recherche d'un autre modèle.

        • [^] # Re: Faire la différence

          Posté par  . Évalué à 3. Dernière modification le 22 septembre 2018 à 01:16.

          Un modèle alternatif est le financement participatif/communautaire.
          Il existe (ou existait ?) des plateformes sur lesquelles un développeur ou un utilisateur indique que telle fonctionnalité est désirée, que ça coûte telle somme, et les personnes intéressées peuvent donner de l'argent.
          La première fois que j'ai vu ça, je me suis dit que c'est génial, je pensais qu'enfin le libre allait tout exploser. Vu ce que c'est devenu, il semble que mon esprit visionnaire n'est pas très au point.

          Il reste les trucs connus genre Kickstarter qui permettent de financer des projets de toutes sortes (dont du développement), mais il faut un tel effort de marketing que c'est devenu quasi bidon. Il ne reste qu'une immense majorité de projets à la noix, les bons étant noyés dans la masse.

          Il faudrait peut-être que les développeurs mettent un lien vers leur page Kickstarter, avec une liste de fonctionnalités, bugs, etc.
          Avec des incitations, par exemple ceux qui paient ont accès à la version la plus récente, les autres ont accès à la version d'il y a un an (c'est moyen, mais vous voyez le principe).

          • [^] # Re: Faire la différence

            Posté par  . Évalué à 10.

            Le problème du financement participatif est qu'il n'y a pas d'obligation de résultat. Par conséquent il y a des financement qui ne mènent à rien. Comme exemple, qui a vu la nouvelle version de lolix dont le financement avait été dépassé ?

            • [^] # Re: Faire la différence

              Posté par  . Évalué à 7.

              Le problème du financement participatif est qu'il n'y a pas d'obligation de résultat.

              Les autres formes de financement non plus n'ont aucune obligation de résultat.

              Si une personne injecte de l'argent dans mon entreprise, elle n'a aucune certitude que ça donnera quelque chose de bon.

              Si une entreprise paie un développeur, elle n'a aucune certitude qu'il fera bien le travail.

              Donc le financement participatif est kif-kif de ce point de vue.

              • [^] # Re: Faire la différence

                Posté par  . Évalué à 2.

                Et en l'occurrence il n'y a peut-être pas d'obligation de résultat, mais au moins avec Kickstarter il faut quand même pouvoir démontrer que les sommes collectées ont été investies raisonnablement. Je ne sais plus pour quel projet ça avait été fait, mais en gros la personne qui avait récolté un beau pactole l'avait investi dans complètement autre chose que ce qu'il avait promis, et KS l'a poursuivi en justice, comme il était promis en cas de fraude avérée (et remontée par les utilisateurs).

                • [^] # Re: Faire la différence

                  Posté par  . Évalué à 2.

                  Investir raisonnablement n'implique pas qu'on va réussir.
                  C'est juste fait pour l'image de marque de Kickstarter et le bon fonctionnement du système : les investisseurs estiment qu'il y a des gardes fous, ce qui est plutôt sain.

                  • [^] # Re: Faire la différence

                    Posté par  . Évalué à 2. Dernière modification le 10 octobre 2018 à 10:53.

                    Investir raisonnablement n'implique pas qu'on va réussir.

                    Ai-je dit le contraire ? :-) Ce que je décris est effectivement la présence de gardes-fou pour éviter les financements participatifs qui se résument plus ou moins à une arnaque. Tous les sites ne le font pas (et évidemment, même chose pour un employé ou une boite bien entendu). Par contre, je trouve que ton post laissait entendre que c'était la loi de la jungle pour le crowdfunding. Pour les grosses plates-formes, il s'avère que pas trop, non. Et ce n'est pas juste une histoire d'image de marque dans le cas de KS : pour tout ce qui est US, c'est aussi une protection légale au cas où des gens victimes d'arnaquent se retournent contre le prestataire.

          • [^] # Re: Faire la différence

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

            Ben oui, le financement participatif ne supprime pas le besoin de faire du marketing et de la publicité. Il permet juste de regrouper les gens qui ont un besoin commun mais qui ne sont pas prêts à en assurer le coût à 100%.

            Il y a plein de variantes. Par exemple les "bounties", typquement sur le site bountysource, ou on peut mettre des promesses de dons sur une fonctionnalité. Le développeur qui l'implémente récupère le pactole. Personellement ce fonctionnement en mode "chasseur de primes" ne me plaît pas trop (je ne dirai pas non si par hasard je résoud un bug et que j'apprends que quelqu'un avait misé de l'argent dessus, mais bon).

            Tu as aussi Liberapay qui lui se place dans un mode d'économie du don: un développeur (ou n'importe qui, la plateforme est ouverte à tous) reçoit des dons anonymes et donc nécessairement sans contrepartie. Mais les gens sont-ils prêt à financer ça sans contrepartie? Il faut aller le leur expliquer et là encore, ça demande du temps. Mais au moins on est pas obligé, on peut aussi s'inscrire sur Liberapay et juste attendre que les dons arrivent.

            Tu as encore les sites du type Patreon, ou l'idée est que les gens donnent de l'argent pour financer le travail de quelqu'un (développeur, artiste, …) et en échange vont avoir accès à un genre de "zone VIP" avec un apperçu du travail en avant-première, etc. Dans ce cas on retombe dans l'inconvénient des campagnes de type Kickstarter: faire vivre ce genre de plateforme demande du temps de la part de la personne financée.

          • [^] # Re: Faire la différence

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

            Un modèle alternatif est le financement participatif/communautaire.

            Il est quasiment impossible dans la fonction publique de participer à ce genre de projet. Les règles de la comptabilité publique mais aussi le fait que l'argent, venant du contribuable, ne peut être dépensé sans quelques gardes fous. Il en va du respect du contribuable.

            En règle général, c'est compliqué dans la fonction publique de financer directement du libre (or contrat via des boites). Ce qui serait plus simple serait de contribuer en terme de temps homme. C'est le cas sur quelques projets mais mais difficile à faire sur des projets "centraux" comme par exemple LibreOffice… Et pourtant, il y en aurait bien besoin.

            Par contre, on peut financer via une boite un ajout de fonctionnalité qui peut être libre. Je sais que cela se fait pas mal via la territoriale sur les systèmes de positionnement GIS (toutes les cartes de risques et autres à faire ou à numériser)…

    • [^] # Re: Faire la différence

      Posté par  . Évalué à 3.

      Nessus aussi était copyleft, et le problème était double :

      1. Les « experts » sécu lançaient Nessus sur des machines (serveurs et clients) windows, Nessus ne disait rien, et ces super consultants disaient que le réseau était clean. Sauf que… La distribution de Nessus (en GPL2) ne contenait que les filtres pour Unix/Linux, et pas de filtres spécifiques à Windows (c'était comme ça que les gens de Nessus espéraient se faire des sous, entre autres).
      2. Tout un tas « d'experts » se contentaient de foutre une interface graphique par-dessus Nessus, changer les noms ici ou là dans le programme, et surtout, surtout, venaient avec « leurs » outils, en modifiant le soft ou en le corrigeant, sans rien reverser au projet, et sans dire au client d'où venaient leurs outils (c-à-d : en mentant). Et ça, y'a zéro moyen de se prémunir contre, car l'outil ne sort pas du laptop ou de la clef USB du « consultant ». Il n'y avait donc aucune reconnaissance ni contribution au projet (malgré l'aspect illégal de certaines pratiques, mais qui sont impossibles à vérifier/établir en pratique). C'est ce qui a poussé les auteurs de Nessus à fermer (dans le sens : rendre propriétaire) leur projet.
  • # Et vous, vous faites quoi?

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

    On en arrive là parce que le modèle communautaire n'a pas marché. Quand on est une entreprise et qu'on veut faire du logiciel libre et le diffuser gratuitement, il faut bien trouver un "modèle d'affaires" (business model), une façon de faire rentrer des sous.

    Il y a des projets pleinement communautaires, parce qu'ils sont gros, et que du coup plusieurs entreprises/fondations/… peuvent y contribuer. Je pense à Linux, à WebKit, à clang par exemple.

    Et il y a des projets plus petits, portés par une seule entreprise dont c'est le métier principal. On pourrait se dire "ils pourraient fournir le logiciel libre gratuitement, et vendre le support". Oui mais voilà, quand en plus on est sur un mode "service" (comme github ou gitlab), on est quand même un peu obligé de fournir du support sur le produit.

    Ils pourraient aussi facturer les nouveaux développement à la première personne qui les demande (ou bien en partageant via des bounties/crowdfunding), mais ça serait très cher, et si la personne qui paie sait que ça finira par être libre, elle peut aussi bien décider d'attendre que quelqu'un paie à sa place.

    En ce qui me concerne, je travaille dans une entreprise qui utilise beaucoup de logiciel libre. Gitlab (déployé en interne), Linux, iptables, …
    Cependant, jusqu'à maintenant on n'a que peu contribué. Notre démarche va être (on y réfléchit) d'avoir des développeurs avec un peu de temps réservé (par exemple une journée par mois) pour contribuer à du logiciel libre. Les logiciels ont vraiment besoin de contributeurs, et faire en sorte que les entreprises paient avec du temps de leurs employés, plutôt qu'avec de l'argent, ça serait peut être intéressant. Pour le projet libre qui récupère les contributions, pour l'employé qui peut faire du logiciel libre, et pour l'entreprise qui bénéficie des nouvelles fonctionnalités ainsi réalisées, d'employés contents qui sont plus motivés, et de retombées en terme d'image de marque.

    Si plus de monde se met à faire ce genre de choses, alors on pourra avoir du logiciel communautaire bien maintenu. Sinon, à un moment donné il va falloir se décider à passer à la caisse. Et si une entreprise voit qu'elle ne récupère pas de contributions valables en publiant ses sources, il est probable qu'elle arrête de s’embarrasser avec ça. C'est là qu'on tombe dans le modèle "open core". Du Libre en version "on aimerait bien, mais ça paie pas les salaires à la fin du mois".

    • [^] # Re: Et vous, vous faites quoi?

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

      Il y a un autre modèle qui fonctionne : les logiciels libres à haute valeur ajoutée pour les services. Je vais en citer un que peu de gens dans cette noble assemblée connaissent : https://koha-community.org
      C'est un soft 100% libre, 100% communautaire et il y a plein de boites qui se sont créées par et font du business dessus. J'en cite quelques unes:
      - https://www.bywatersolutions.com aux USA, 4M USD de CA aux dernières nouvelles
      - https://www.ptfs-europe.com en UK, une quinzaine de salariés.
      - https://interleaf.ie en Irland, une petite dizaine
      - https//theke.io en Argentine : 4 personnes, en grosse croissance
      - https://biblibre.com, ma boite, 18 personnes, 80% sur Koha
      - … et encore bien d'autres (Allemagne, Inde, Pakistan, Nouvelle Zélande, Australie, Turquie, Espagne, plus tous ceux que je ne connais pas)

      Modèle 100% libre et communautaire, services à très haute valeur ajoutée (paramétrage, intégration SI des bibliothèques, migration, formation, hébergement et maintenance, support)

      Je sais que le cas est assez rare, mais il existe. Il s'applique lorsque les softs sont complexes et/ou stratégiques.

      • [^] # Re: Et vous, vous faites quoi?

        Posté par  . Évalué à 6. Dernière modification le 21 septembre 2018 à 17:45.

        Qui contribue le plus à la communauté Koha? C'est vos entreprises? Dans ce cas, c'est vraiment le modèle idéal : on partage l'outil, tout en gardant la taille raisonnable d'entreprise…

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Et vous, vous faites quoi?

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

        De façon générale, si tu as un logiciel générique qui répond à un besoin récurrent d'entreprises, tu peux t'en sortir en vendant le support, le déploiement, et le développement pour personnaliser ce logiciel pour les besoins exacts de chaque client.

        C'est possiblement moins de rentrée d'argent que si tu vendais le logiciel tel quel avec une licence par nombre de postes installés ou je ne sais quoi. Mais d'un autre côté ça peut permettre d'être moins cher qu'un concurrent qui développerait un truc à partir de zéro pour chaque client.

        Il y a quelques mois, Mozilla avait présenté une taxonomie des projets libres, avec plusieurs types de projets selon la gouvernance, le financement, etc. C'est probablement bon à relire pour voir les modèles qui semblent les plus pertinents du point de vue de la perrenité et de l'efficacité.

  • # Ça dépend de l'Open Core

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 26 septembre 2018 à 11:24.

    Dans le cas de GitLab, le logiciel fonctionne très bien en version libre. Je peux donc me satisfaire du fonctionnement ; en plus certaines fonctionnalités ont fini par être libérées.

    En revanche, il y a des projets qui sont inutilisables dans leur version libre et qui sont donc plus de la publicité qu'un projet.
    Un développement obscur (par exemple, pas de versionning public, pas d'acceptation de patches externes, etc.) est aussi un problème.

    Ceci dit, il me semble qu'il y a des produits qui étaient complètement libres et qui ont arrêté d'être maintenus pour devenir propriétaires. Donc ça ne me semble pas lié à l'Open Core, c'est donc un danger pour un peu tout.

    Je dirais qu'il faut plutôt se méfier des projets qui ne sont pas assez communautaires.

    Bref, je n'ai pas de réponse tranchée sur le sujet mais c'est effectivement une très importante question à se poser.

Suivre le flux des commentaires

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