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 Misc (site web personnel) . En réponse au journal Succès de l'extension de mesa en financement participatif. Évalué à 7.
Ç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".
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.
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 ).
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.
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.
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 ?
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 ).