Journal Succès de l'extension de mesa en financement participatif

Posté par . Licence CC by-sa
20
10
août
2013

Juste quelque mots pour vous dire que Timothy Arceri a trouvé financement en 15 jours.
Son but est de créer l'extention GL_KHR_debug [0], et ce faisans devenir plus familier avec le code de mesa.

Il va donc passer deux semaines a faire l'extension, sa documentation et (espérons le) les tests piglits[1] kivonbien™.
Vous pouvez trouver le code sur Github [2] et sa campagne sur Indiegogo [3].

Quoi que l'on pense du financement participatif pour faire du logiciel libre, c'est une bonne nouvelle pour le support d'OpenGL 4.3.

[0] http://www.opengl.org/wiki/Debug_Output
[1] http://cgit.freedesktop.org/piglit/tree/README
[2] https://github.com/tarceri/mesa-debug/commits/khr_debug_wip
[3] http://www.indiegogo.com/projects/help-improve-opengl-support-for-the-linux-graphics-drivers

  • # Rapide !

    Posté par . Évalué à 1.

    Wow, encore tout à l'heure il était à 1700, impressionnant.

  • # Bien bien !

    Posté par . Évalué à 7.

    Ça fait un moment que je me dis que certains projets libres devraient utiliser le financement participatif pour se peaufiner.
    En particulier les logiciels qui ont déjà un bon niveau, pour renforcer l'édifice du libre, en faire des logiciels incontournables et solides.

    Via des campagnes de masse qui utilisent une bonne communication(développement "proche de l'utilisateur").

    Je pense qu'il est important qu'ils se rapprochent des utilisateurs avec une bonne comm' pour permettre un autre type d'économie de se développer, celle qui rend service à tout le monde.

    • [^] # Re: Bien bien !

      Posté par (page perso) . Évalué à 0.

      Le logiciel de montage vidéo Openshot a également réussi sa campagne de financement sur Kickstarter. 20.000 $ demandés et 40.000 $ obtenus pour l'ajout de nombreuses fonctionnalités et le portage vers windows et mac os.

      Ça ne me choquerait pas qu'un logiciel libre développe une fonctionnalité via un financement participatif et que cette fonctionnalité soit accessible exclusivement à ceux qui ont participé à son financement pendant quelques mois avant de devenir disponible pour tout le monde.

      • [^] # Re: Bien bien !

        Posté par (page perso) . Évalué à 10.

        ça ne serait plus du logiciel libre du coup. Tu n'aurais pu par exemple l'intégration dans les distributions, tu n'aurais pas la relecture par d'autres codeurs de la communauté, les gens avec la feature en plus auraient moins de chance d'avoir des réponses sur le forum, et les documentations et traductions devraient être geré à part.

        D'un point de vue logistique, ça semble une mauvaise idée.

        Quand à l'idée de base, ça reste quand même risqué. Au bout de combien de temps est ce qu'on va voir quelqu'un qui va refuser de faire une fonctionnalité dans le but de réussir à se faire financer ? Et comment tu fait si la fonctionnalité n'est pas terminé à temps ?
        Comment tu repartis ça dans le cas d'un travail en équipe ?

        Et finalement, avoir ça comme source de revenu principal, ça me parait assez mauvais, on précarise les codeurs et ça ne me semble pas sain du tout.

        • [^] # Re: Bien bien !

          Posté par (page perso) . Évalué à 5.

          ça ne serait plus du logiciel libre du coup.

          C'est du libre décalé : pas libre au début, mais libre ensuite. Perso, ça ne me choque pas plus que ça.
          Google fait ça aussi avec Android (si tu veux un peu d'avance sur les autres, tu te plies aux règles) et c'est un projet qui marche plutôt pas mal ;-) tout en restant libre au final.
          Après, on aime ou pas, certes. Mais c'est un moyen comme un autre de financer du libre.

          Tu n'aurais pu par exemple l'intégration dans les distributions

          Ben si, juste avec quelques mois de décalage par rapport aux sponsors. Vu le cycle de certains distros, ça ne change vraiment pas grand chose.

          tu n'aurais pas la relecture par d'autres codeurs de la communauté

          Ca change de d'habitude pour 99% des projets?

          et les documentations et traductions devraient être geré à part.

          Ou pas.
          Juste un bandeau "fonctionnalité dans la version pour sponsors, libre le X".
          En plus, ça fait de la pub pour le sponsoring.

          D'un point de vue logistique, ça semble une mauvaise idée.

          C'est pas comme si personne ne maintenait des branches à part (libres mais refusées upstream, ou non libre etc…)
          Rien de neuf au niveau logistique.

          Et finalement, avoir ça comme source de revenu principal, ça me parait assez mauvais, on précarise les codeurs et ça ne me semble pas sain du tout.

          Euh… Peut-être que je n'ai pas compris ton message, mais en fait le financement des nouvelles fonctionnalités est la principale source de revenu de moi et d'autres développeurs libres.
          Un financement participatif n'est que le prolongement de ce travail.
          Pourquoi "précariser les codeurs" avec ça?

          Au bout de combien de temps est ce qu'on va voir quelqu'un qui va refuser de faire une fonctionnalité dans le but de réussir à se faire financer ?

          Je le tourne dans l'autre sens : ça ne m’intéresse pas moi le principal codeur de faire sur mon temps libre et je ne suis pas ton esclave, mais si tu payes je veux bien m'y mettre (ou un autre si tu veux) à travers un sponsoring, si tu peux pas seul un financement participatif est possible.

          Et comment tu fait si la fonctionnalité n'est pas terminé à temps ?

          Comme dans tout contrat et/ou comment dans tout financement participatif.
          Je ne vois pas la différence.


          Libre != développement communautaire (qui n'est qu'une façon parmi d'autres).
          L'argent n'est pas le mal, le libre n'a pas à être contre l'argent, au final on a bien du libre, alors si ce genre de façon de faire du libre marche, pourquoi pas?

          • [^] # Re: Bien bien !

            Posté par (page perso) . Évalué à 7.

            Google fait ça aussi avec Android (si tu veux un peu d'avance
            sur les autres, tu te plies aux règles) et c'est un projet qui
            marche plutôt pas mal ;-) tout en restant libre au final.

            Ça dépend de ton critère pour "qui marche". D'un point de vue de l'input de la communauté sur le projet, je pense pas que ça soit flagrant, ça reste chasse gardé de Google. Ensuite, je pense que Google fait ça avec android juste parce qu'ils ont pas le choix. Si tu va par la, Apple montre rien et ça marche aussi pour eux. Donc on peut dire que "avoir des parts de marché" n'est pas dépendant dans le mobile de "donner le code source avec du retard".

            Ca change de d'habitude pour 99% des projets?

            Y a pas mal de projet qui font de la relecture, genre tout les gros. Y a aussi pas mal de gens qui font de la relecture pour trouver des failles de sécurité, et donc ton chiffre de 99% est à mon sens trompeur et incorrect. Il y a des boites ( par exemple RH pour RHEL, Canonical pour la partie main ) qui font de l'audit avant d'intégrer ou de proposer quoi que ce soit. Mais oui, ça change rien si personne ne bosse avec toi d'habitude, et si tu n'as finalement aucune communauté de développeurs autour de ton produit, soit parce qu'il s'y prête pas, soit parce que le caractère du codeur ne s'y prête pas.

            Juste un bandeau "fonctionnalité dans la version pour
            sponsors, libre le X".

            Je parle de la production, pas de l'usage. IE, traduire ou écrire de la documentation sans avoir accès au logiciel est un peu plus dur, et ça aboutit au final à avoir quelque chose de moins bonne qualité. Donc il faut prendre en compte le cout de faire soit même la traduction ou la documentation, ou de donner accès à la version aux bénévoles qui vont le faire dans le cadre du projet libre, ou se satisfaire d'une qualité inférieur ou la traduction est pas relu en situation, tout comme la doc.

            Et je rajouterais le fait de faire des tests, des betas, etc. Il me semble évident que le nombre de sponsors testeurs est inférieur ou égal à la communauté entière, vu que les dits sponsors font parti de la communauté par définition. Encore une fois, on aboutit à un truc de moins bonne qualité, ou quelque chose qui requiert plus de travail, si la communauté est fonctionnel ( encore une fois, si elle n'existe pas, ça ne change rien ).

            C'est pas comme si personne ne maintenait des branches à part > (libres mais refusées upstream, ou non libre etc…)
            Rien de neuf au niveau logistique.

            Justement, c'est parce qu'on sait que maintenir des branches est un cout que les gens qui ont un peu plus de bouteille poussent les choses upstream. On a vu ce que ça donne justement avec android et le kernel, et qu'au bout d'un temps, avoir tes branches sur un projet dynamique est lourd.

            Au jour le jour, avoir 2 branches de dev ( la branche dispo pour tous, et la branche pour le soft sponsorisé ) fait que tu dois faire 2 fois plus de tests, que tu doit backporter les fonctionnalités et les bugfixes de l'une à l'autre. Ou que tu fait tout dans la branche sponsor, ce qui ralentit fortement les contributions externes ( chose que tu n'as peut être pas sur le projet à la base, ou dont tu te fout, mais du coup, ça me semble aller à l'encontre du développement collaboratif ).

            Ensuite, ça dépend grandement de la durée du développement, mais comme tu rajoutes quelques semaines de bloquage de façon artificiellement, ça fait toujours ce temps ou tu doit faire des rebases, etc.

            Pourquoi "précariser les codeurs" avec ça?

            Bosser en ayant un flux d'entrée d'argent dépendant du bon vouloir des autres et de ta capacité à ne pas coder les features pour les faire payer me parait plus fragile que d'être employé comme dev en CDI. Si ensuite, toi, ça te va, ça veut pas dire que ça va pour tous.

            Comme dans tout contrat et/ou comment dans tout financement
            participatif.

            Donc tu payes une pénalité, comme dans un contrat bien fait en faveur pour le client, ou le client paye sans avoir de garantie ( comme dans un contrat moins en sa faveur ) ? Ou tu impliques les avocats, comme dans un contrat classique ?

            ça ne m’intéresse pas moi le principal codeur de faire sur mon
            temps libre et je ne suis pas ton esclave, mais si tu payes je
            veux bien m'y mettre (ou un autre si tu veux) à travers un
            sponsoring, si tu peux pas seul un financement participatif
            est possible.

            J'ai du mal à suivre en quoi ça réponds à la question "combien de temps avant que le codeur refuses quelqu'un qui va faire ça sur son temps libre alors qu'il pourrais avoir de l'argent pour le faire ?"

            Des exemples de ce genre, tu en trouve autour des communautés de logiciel open-core.

            Ensuite, je sais pas pour toi, mais moi, si y a un truc que j'ai pas envie de faire, c'est rarement rajouter de l'argent qui va me le faire faire, sauf si je suis vraiment à l'arrache ou si il y a vraiment beaucoup d'argent. J'ai pas encore une estime de moi si basse que je vais me vendre à pas cher pour coder un truc que je veux pas coder et en plus m'infliger de faire de la paperasse pour ça. Et pas non plus un compte en banque tellement vide que je n'ai pas le choix.

            Mais bon, si ça marche pour toi et plein d'autres, tant mieux.
            Je cherche pas à te convaincre du contraire, ça serait totalement idiot et ça m'apporterais rien.

            Mais je reste persuadé que ça n'est pas une solution très pérenne pour les systèmes libre tel qu'ils sont aujourd'hui.

            Je voit bien par contre que c'est une solution pour les développeurs propriétaires :
            - moins de piratage, car au final, les gens qui veulent pas payer vont prendre la version libre
            - un minimum d'implication de la communauté pour la traduction/documentation/portage, etc, donc des économies, et une qualité supérieure à un logiciel propriétaire équivalent ( vu qu'il y a rarement des traductions pour les plus petits, et souvent des horreurs pour que ça tourne sans le code source sur divers distributions et OS )
            - un financement, car filer le soft gratos, ça paye rarement le loyer
            - la possibilité de dire "je fait du libre (en partie )", ce qui est quand même plus glorieux et meilleur pour l'ego que "j'ai fait un shareware", du moins de nos jours sur un CV
            - un argument de vente auprès des utilisateurs, histoire de dire "c'est libre, c'est bien (tm)", et de surfer sur la vague ( tout comme le crowdfunding ).

            • [^] # Re: Bien bien !

              Posté par (page perso) . Évalué à 5.

              Chacun son point de vue, je réagirai que sur ce point :

              Bosser en ayant un flux d'entrée d'argent dépendant du bon vouloir des autres et de ta capacité à ne pas coder les features pour les faire payer me parait plus fragile que d'être employé comme dev en CDI.

              Tu ne fais que déplacer la précarité sur celui qui paye le CDI. Bref, un intermédiaire. Ca n'enlève rien à la façon de fonctionner. Un CDI ne change rien à l'affaire, si l'employeur n'a plus de contrat, il te virera, CDI ou pas. le CDI n'est qu'un tampon intermédiaire (que tu payes, ne pas s'inquiéter, en gagnant moins que si tu n'avais pas d’intermédiaire. Ben ça tombe bien un indépendant peut créer lui-même cet argent tampon en se payant moins par mois, comme un CDI, il peux même cotiser à l'assurance chômage avec une SASU, bref indé ou salarié, finalement pas de grande différence sur la précarité à part dans la tête des banquiers lorsqu'ils doivent te prêter de l'argent. La seule différence est dans les grandes boites où tu peux aller au pire sur un autre projet, mais faut alors pas se plaindre que le projet n'est pas intéressant ni que le salaire pue, ça fait partie du jeu).

              • [^] # Re: Bien bien !

                Posté par . Évalué à 4.

                le CDI n'est qu'un tampon intermédiaire (que tu payes, ne pas s'inquiéter, en gagnant moins que si tu n'avais pas d’intermédiaire.
                Pas toujours. Une boîte client peut refuser de traiter avec un indépendant (sans intermédiaire) pour la simple raison que si ça se passe mal, se retourner contre lui ne pourra lui rapporter que des clopinettes. Contre une grosse boîte, une négociation sera toujours plus fructueuse. Donc l'indépendant sans intermédiaire est aussi un risque, déporté sur la boîte cliente, qui le fait donc payer également.

      • [^] # Re: Bien bien !

        Posté par (page perso) . Évalué à 3. Dernière modification le 11/08/13 à 13:49.

        Libre != Gratuit
        les développeurs ne sont pas des créatures virtuelles vivant d'amour et d'électrons,
        on pourrait dire que le logiciel est libre à partir du moment où il a été payé

        je n'ai pas trouvé (pas vraiment cherché non plus) d'infos sur la campagne de financement du projet sur mesa à l'origine du journal, mais celle sur Openshot parle de récompenses sous forme de tee-shirt ou d'autres "goodies" (clés usb,…)

        très intelligent :
        - les développeurs sont payés,
        - le projet voit sa comm (donc sa visibilité) améliorée,
        - ça flatte les sponsors,
        - ça évite d'avoir plusieurs versions du produit avec des licences différentes (entre autres complications)

        tout le monde est content

        je crois qu'il ne faut pas faire plusieurs catégories d'utilisateurs : ceux qui ne payent pas, ceux qui payent xx $, ceux qui payent xxxxx $, etc, sinon on ne peut plus parler de logiciel libre (tout au plus d'open-source, open-core ou de freemium)

        Envoyé depuis mon Archlinux

        • [^] # Re: Bien bien !

          Posté par . Évalué à 2.

          Tu aurais pu cérrément mettre vivant de l'amour des électrons :)

        • [^] # Re: Bien bien !

          Posté par (page perso) . Évalué à 4.

          je crois qu'il ne faut pas faire plusieurs catégories d'utilisateurs : ceux qui ne payent pas, ceux qui payent xx $, ceux qui payent xxxxx $, etc, sinon on ne peut plus parler de logiciel libre (tout au plus d'open-source, open-core ou de freemium)

          Je défie n'importe quel développeur de ne pas prioriser son sponsor (celui qui le fait vivre) par rapport à Mr n'importe qui qui ne paye rien, n'aide rien, et fait que râler. C'est faux-cul de dire le contraire (déjà à commencer par le fait que ceux qui payent, en général tu les connais plus personnellement). Toi tu vas me dire que tu vas aider l'inconnu à l'autre bout de la terre plutôt que tes parents? Je n'y crois pas, et la c'est le même type de lien (en moins fort certes).
          Désolé, mais dans la vraie vie, libriste compris, presque (il va bien y avoir qui vont dire qu'ils s'en foutent du fric et font vraiment pareil…) tout le monde fait cette priorisation : ceux qui ne payent pas, ceux qui payent xx $, ceux qui payent xxxxx $, comme tu dis.
          Et je vais commencer par moi : je fais cette priorisation.

          • [^] # Re: Bien bien !

            Posté par (page perso) . Évalué à 3.

            ne me fais pas dire ce que je n'ai pas dit, bien entendu que tu vas donner priorité à ceux qui te payent !

            ce que je voulais dire c'est qu'à partir du moment où tu as déjà été payé pour faire le boulot, il est sans doute contre-productif de pénaliser ceux qui n'ont pas payé (en retardant la libération du produit ou de la fonctionnalité)

            Envoyé depuis mon Archlinux

            • [^] # Re: Bien bien !

              Posté par (page perso) . Évalué à 2.

              La question est : qu'est-ce que tu fais si la personne paye seulement si tu "pénalises" (=tu avantages un peu pendant un laps de temps donné afin que le concurrent soit un peu en retard, sinon pas de sous du tout ce qui au final fait bien moins de libre)? Car on parle de ça. Evidemment que si c'est pas dans le contrat il n'y a aucun intérêt à pénaliser les autres.
              Note : ce n'est pas que de la théorie.

              • [^] # Re: Bien bien !

                Posté par (page perso) . Évalué à 0.

                sérieusement ?
                tu as eu des clients qui mettaient ce genre de clauses dans leur commande ?

                Envoyé depuis mon Archlinux

                • [^] # Re: Bien bien !

                  Posté par (page perso) . Évalué à 3.

                  Sérieusement : oui (mais très rare, 2 fois en 6 ans de mémoire, après tu as aussi "ok mais tu en fais pas la pub", bref des clients peuvent être différents vis à vis du libre même si la majorité est "rien à branler tant que je l'ai à la prochaine version").
                  Google fait pareil avec Android (si tu veux avoir la version de développement pour être prêt quand la version officielle sort, tu te plies aux règles. Sinon tu as un retard de 2 mois le temps d'intégrer), pour un exemple en tête, et j'ai déja entendu d'autres ne pas commiter dans le SVN avant J-1 de la release alors que la fonctionnalité était prête depuis un moment.

                  La première question est vraiment se savoir si il vaut mieux "bloquer" et ne pas travailler dessus du tout faute de contrat (et le concurrent non libre peut être choisi au passage), ou accepter un décalage (donc quelques mois en "proprio").

                  La deuxième question de la vraie vie pour reprendre ton "je crois qu'il ne faut pas faire plusieurs catégories d'utilisateurs : ceux qui ne payent pas, ceux qui payent xx $, ceux qui payent xxxxx $, etc, sinon on ne peut plus parler de logiciel libre" est si tu as 100 demandes de support d'un coup, dont les 9 avant-dernières viennent de ceux qui payent xx $ et la dernière de celui qui paye xxxxx $, tu vas vraiment gérer aucune catégorie d'utilisateurs et répondre dans l'ordre d'arrivée? Perso, je suis faible, je répond dans un autre ordre, ça fait bien des catégories.

                  • [^] # Re: Bien bien !

                    Posté par (page perso) . Évalué à 2.

                    1 : c'était une vraie question et tu as de la chance de faire du développement libre payant

                    2 : tu as légèrement déplacé le terrain de la discussion, le sujet de départ était le financement communautaire (donc coopératif), pas le financement privé

                    il est certain que le modèle propriétaire simplifie bien des choses et que le modèle libre/bazar se cherche encore (financièrement) et entre souvent en conflit avec les mentalités bien établies

                    sur ce, bonne fin de we

                    Envoyé depuis mon Archlinux

Suivre le flux des commentaires

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