Je suis confronté à un problème particulièrement ennuyeux pour moi dans Libreoffice, qui me semble à vue de nez facile à régler pour quelqu'un au coeur du projet, mais pas prioritaire du tout. Le bug est ouvert depuis 10 ans et je ne suis que le 9e à m'inscrire pour le suivre, donc je comprends qu'il reste pourrir dans son coin:
https://bugs.documentfoundation.org/show_bug.cgi?id=38948
Pourtant, je serais prêt à mettre disons 20 euros (voire un peu plus si on m'expliquait comment c'est compliqué ou comment on pourrait en profiter pour améliorer encore le solveur) pour qu'il soit corrigé (et je ne me vois pas développer mes maigres compétences de progrmamation pour rejoindre un projet aussi gros que Libreoffice et toucher à un point aussi névralgique, en temps perso, ça se compterait plutôt en 20 000 euros d'investissement).
C'est là qu'une infrastructure pour collecter ces sous comme un genre d'Ulule des projets libres serait intéressant. Des idées ? C'est complètement idiot, ce que je raconte ?
# Dur…
Posté par Olivier . Évalué à 9.
Modifier le code de LibreOffice, c’est difficile. La base de code est très vaste et c’est du C++, pas le langage dans lequel on rentre facilement.
20 euros ne changeront rien.
Pour Mozilla, il y a une prime de 815$ pour résoudre un problème, et je peux te dire que ça n’a pas incité beaucoup de monde à s’y intéresser.
Donc, oui, il faut probablement plutôt une somme à 4 zéros pour que quelqu’un s’y mette.
Ça existe déjà. Ça s’appelle Bounty Source. À une époque j’en vais vu d’autres, mais à ma connaissance aucun n’a vraiment décollé. Le site de Bounty Source rame et bugue depuis quelques années, probablement un sous-investissement des propriétaires.
L’idée de faire du financement participatif pour certaines fonctionnalités de LibreOffice a déjà été lancée, mais à ma connaissance ça ne s’est jamais concrétisé pour des raisons que j’ignore. Tu devrais te rapprocher de la communauté de LO pour en parler.
L’autre possibilité, c’est peut-être de faire un peu de zèle pour intéresser des gens à ce bug en particulier, et qu’un groupe convainque un développeur de mentorer cette fonctionnalité pour l’introduire dans la liste des idées pour les étudiants du Google Summer of Code. Ainsi, peut-être que l’un d’entre eux choisira cette fonctionnalité et l’implémentera.,
Là encore, il faut que tu te rapproches des gens de LO pour leur parler.
[^] # Re: Dur…
Posté par ff9097 . Évalué à 1.
C'est là que l'idée des développeurs qui travailleraient bénévolement pendant leur temps libre est assez loin de la réalité pour des projets de cette taille.
Le problème n'est-il pas que LO est trop monolithique ?
[^] # Re: Dur…
Posté par Olivier . Évalué à 4.
Il y a quand même pas mal de contributeurs bénévoles sur LO, même si beaucoup des développeurs appartiennent effectivement à des compagnies.
L’est-il ? S’il l’était, qu’est-ce que ça changerait s’il l’était moins ? La base du code est énorme et chaque module, je crois, utilise un peu de tout dans cette base. Ce n’est que du partage de code.
Le vrai souci, c’est plutôt le manque de contributeurs. De ce côté, l’obstination inutile d’Apache n’aide pas vraiment à clarifier la situation.
[^] # Re: Dur…
Posté par ff9097 . Évalué à 2.
Si tu peux facilement identifier a quel module appartient un bug, et si il est possible de le reproduire le problème, le corriger et tester sans recompiler la totalité alors ça simplifie pas mal la chose.
[^] # Re: Dur…
Posté par Graveen . Évalué à 3.
C'est quoi l'obstination inutile d'Apache ? le fait qu' OpenOffice ne veuille pas merger avec LibreOffice ? (vraie question).
Effectivement si c'est ça, c'est dommage. Mais bon c'est aussi aux developpeurs d'OOo de quitter le navire.
[^] # Re: Dur…
Posté par Olivier . Évalué à 9.
Maintenir une base de code obsolète avec une main d’œuvre nettement insuffisante. Ça fait des années qu’il y a environ 50 fois plus de commits sur LO que sur OO. ¹
Persister à tromper les utilisateurs avec un nom de marque connu qui leur est tombé dans la bouche sans avoir jamais contribué au code avant ça. Le nom OpenOffice est devenu un genre d’appeau pour utilisateurs ignorants qui, pour la plupart, ne savent pas qu’une suite bureautique libre plus avancée existe.
Non. LibreOffice a repris il y a longtemps ce qui était intéressant dans Apache OpenOffice. Les deux suites ont déjà fusionné, mais chez LO seulement.
Le problème, c’est la marque OpenOffice. Il n’y a que ça qui fasse tenir Apache (pour les dons que ça apporte, paraît-il).
¹ Depuis le 1ᵉʳ janvier 2021, seulement 15 commits sur le code d’OO, environ 900 sur le code de LO.
[^] # Re: Dur…
Posté par legranblon (site web personnel) . Évalué à 3.
OpenOffice est stable et abouti, c'est pour ça. ;-)
[^] # Re: Dur…
Posté par Sébastien Wilmet . Évalué à 3.
Certains en profitent aussi sur le Microsoft Store, et sans doute sur d'autres App Stores (macOS etc).
[^] # Re: Dur…
Posté par ff9097 . Évalué à 2.
Manque de quel type de contributeurs ? LO m'a l'air très actif niveau développement.
[^] # Re: Dur…
Posté par Jean-Baptiste Faure . Évalué à 6.
Il n'y a jamais assez de développeurs dans un projet comme LibreOffice. De façon générale il faut des gens qui connaissent bien le C++. Il faut en particulier des gens qui connaissent bien le développement sur MacOS, c'est la plateforme la moins bien supportée. Le module Base a aussi besoin de forces vives, Impress aussi dans une moindre mesure.
Et il y a plein de bugs anciens un peu partout qui auraient bien besoin de développeurs avec beaucoup d'abnégation (c'est moins fun de corriger des bugs que de développer une nouvelle fonction que personne ne réclame à part son développeur) pour les attaquer de façon systématique.
Et puis il manque aussi des contributeurs QA pour faire le triage des bugs : essayer de confirmer les nouveaux rapports de bug, détecter les doublons, identifier par bibisection (ou bisection si on a les moyens de compiler soi-même LibreOffice) les correctifs fautifs.
Pour la QA il faut de la patience et de la rigueur, de la diplomatie et beaucoup de détachement pour supporter les "amabilités" de certains utilisateurs qui pensent que tout leur est dû. Bien sûr il faut aussi être capable de lire et écrire à peu près l'anglais international, quitte à s'aider d'un traducteur automatique en ligne comme DeepL.
[^] # Re: Dur…
Posté par azmeuk (site web personnel) . Évalué à 5. Dernière modification le 29 janvier 2021 à 14:23.
J'ai personnellement mis quelques dizaines euros par-ci par-là sur des tickets qui m'intéressaient. Quelques années plus tard, aucun n'a été résolu, si ce n'est par moi.
J'ai l'impression qu'il y a effectivement un trop grand écart entre la somme que sont prêts à payer les utilisateurs pour une fonctionnalité, et la somme qui fera qu'un développeur compétent s'attaque au problème.
[^] # Re: Dur…
Posté par orfenor . Évalué à 1. Dernière modification le 29 janvier 2021 à 15:01.
Vu le très faible coût d'un programmeur « off-shore », les bounty représentent une opportunité dans les pays pauvres. Mais je pense qu'ils manquent de visibilité :
On ne les trouve pas ou peu sur les pages que consultent les développeurs et ne sont pas non plus dans les rapports de bugs. Or la façon commune de débuter dans un projet c'est de se familiariser avec le code en corrigeant des bugs. Et puis quand on complète un rapport de bug, voir qu'il y a des bounty en cours sur ce bug inciterait à contribuer au financement. Les bounty ne remontent pas non plus assez vers les financeurs : on pourrait imaginer des relances, des propositions de regroupements, plus de dialogue avec les développeurs, et surtout confirmer que l'offre est toujours valable (sur le bouty pour un correcteurs dans Mozilla les financements datent de 2015, ça fait douter de leur validité et de la plateforme)… Et ils pourraient être diffusés vers les plateformes de développeurs freelance.
[^] # Re: Dur…
Posté par ff9097 . Évalué à 3.
En même temps ça m'a l'air un peu complexe. Comment ça se passe ? Admettons que je suis développeur indépendant et un bounty m'intéresse. Je suis payé à quel moment ? Dès que je m'engage simplement à y consacrer 1 semaine ? Ou il y a une obligation de résultat derrière et je ne suis payé que si le ticket associé est clôturé ?
[^] # Re: Dur…
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1.
1/3 à la commande, 1/3 au début des travaux, 1/3 à la réception des travaux. En l'espèce, une fois que le ticket est clôturé.
C'est un mode de paiement très courant.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Dur…
Posté par Sébastien Wilmet . Évalué à 6.
Sur BountySource le développeur est payé seulement quand le ticket associé est clôturé.
[^] # Re: Dur…
Posté par Jean-Baptiste Faure . Évalué à 6. Dernière modification le 29 janvier 2021 à 14:46.
En plus il ne suffit pas de modifier le code, il faut surtout faire évoluer le format OpenDocument, et ça ce n'est pas LibreOffice qui décide.
https://bugs.documentfoundation.org/show_bug.cgi?id=32063#c2
Si quelqu'un veut reprendre l'idée du l'autre du rapport de bug, il pourrait essayer de faire une extension qui enregistre les paramètres du modèle dans un fichier externe et permette de les recharger. Avec une extension pas la peine d'entrer dans le code C++ de LibreOffice. Savoir faire des macros Basic ou Python et se débrouiller avec l'API de LO devrait suffire.
Pourquoi ne pas proposer un stage pour explorer cette piste ?
[^] # Re: Dur…
Posté par Jean-Baptiste Faure . Évalué à 4.
J'ajoute que je n'ai jamais vu quelqu'un soulever cette question, ni sur les listes de discussions francophones, ni sur irc, ni sur telegram (du temps où j'y étais encore). En parler aurait peut-être aider à faire émerger des idées de solution.
[^] # Re: Dur…
Posté par qdm . Évalué à 4.
C'est hélas pour un usage personnel que j'ai besoin de cette fonction (d'où le budget limité). Mais en tout cas, merci à toi (et à tous les commentateurs en général), d'avoir fouillé autour de cette fonctionnalité.
Je crains donc que je vais continuer à rentrer mes paramètres de modélisation à la main à chaque fois que j'ai besoin du fichier (pour l'anecdote, j'ai comparé avec un autre tableur propriétaire bien connu et s'il sauve bien les paramètres du solveur, le solveur proprement dit a l'air moins puissant ou du moins moins adapté au problème que je lui pose puisque il dégage des solutions moins optimales que le solveur SCO de LibreOffice)
# Mon point de vue de développeur
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Bonjour,
Alors, je suis développeur de logiciels libres sur mon temps libre, et développeurs d'autres trucs sur mon temps salarié.
Le salaire d'un développeur c'est mettons 2000€/mois net (pour prendre un chiffre rond) pour 20 jours travaillés, soit 100€ par jour environ.
Avec 20€ tu pourrais donc financer même pas 2h de travail pour 1 personne (et là c'est sans compter aucune charge, etc). On est donc loin du compte, même pour un bug "simple", sur un projet comme LibreOffice il faut du temps pour trouver ou est le problème, vérifier que la solution fonctionne bien, etc. Et ensuite il faut envouer le code, qu'il soit relu et validé par un autre développeur. Probablement il faut ajouter un test automatisé aussi.
De plus, je trouve pas que c'est un très bon modèle d'être payé à la tâche comme ça. Ça encourage à faire le travail vite et mal pour pouvoir passer au paiement suivant le plus vite possible. Laissant aux autres contributeurs le soin de nettoyer derrière. Ça n'encourage pas la collaboration, puisqu'il faudrait ensuite partager les gains (ou demander de l'aide à quelqu'un et puis ne rien lui donner en contrepartie).
Donc au final, ce n'est pas une source de revenu suffisante, ni même suffisamment stable pour permettre à un développeur de se libérer du temps pour travailler sur un bug (en gros il faudrait que ça permette aux gens d'en vivre ou disons au moins que ça paie mieux que les autres possibilités, sinon, ça ne sert pas à grand chose). Et en plus ça met une ambiance pourrie dans les projets.
Et enfin, ça donne plus de pouvoir de décision aux gens qui ont des sous à donner.
Finalement dans Haiku, on a mis en place un système de vote sur notre bugtracker (chaque utilisateur peut donner un +1/-1 sur les bugs). Et on utilise ça (entre autres) pour prioriser les prochaines choses à faire. Pour le financement, on récolte des dons et on espère un jour en avoir assez pour pouvoir payer un de nos devs à plein temps de façon durable.
[^] # Re: Mon point de vue de développeur
Posté par qdm . Évalué à 2.
Je comprends tout à fait ce point de vue et d'ailleurs, la somme de 20 € était très indicative, mon idée était plus de se dire que si on groupe les gens intéressés, on pourrait accumuler une cagnotte plus conséquente. En tout cas, les arguments sur la qualité du travail qui en résulterait sont très intéressants.
[^] # Re: Mon point de vue de développeur
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Oui, c'est clair que 20€ ça n'est rien, mais si on imagine quelques dizaines ou centaines de personnes prêtes à mettre 20€ chacune, on peut imaginer que quelqu'un réussisse à se salarier en traitant quelques bugs par semaine. Mais y'a un problème de bootstrap pour en arriver là : pour que ça marche, il faut trouver beaucoup de gens prêts à mettre des sous, que les systèmes de bounties décollent, sinon tu resteras seul sur ton bug avec tes 20€. Et tant que participer à un système de bounty consiste à rester tout seul avec ses 20€ sur un bug qui n'intéresse aucun développeur, le système ne décolle pas.
Pour le financement à petite échelle, ce qui marche un peu dans certains cas c'est le financement régulier de développeur (https://www.patreon.com/, https://liberapay.com/, https://fr.tipeee.com/, …). On reste sur le principe « pas un gros budget par personne, mais ça marche si beaucoup de gens donnent », et ça permet à quelques développeurs de passer à plein temps sur leur projet favori (en général, c'est « à plein temps payé au lance pierre », mais bon). Par contre dans ces cas là, on donne en faisant confiance, et les donateurs n'ont pas plus d'impact que les autres sur la priorisation du travail du développeur.
# Finalement la difficulté c'est de convaincre quelqu'un que le bug est important
Posté par gasche . Évalué à 4.
Pour moi ce n'est pas 20€ (ou même 200€) qui vont convaincre quelqu'ajouter une feature un peu avancée "pour l'argent", mais par contre entendre cette proposition peut être une façon de réaliser que cette fonctionnalité est vraiment importante pour certaines personnes. C'est quand on est ému par une demande de ce type qu'on s'y met, en mettant de côté toutes les autres choses qu'on a déjà sur la planche. Il faut croire que les développeurs LibreOffice n'ont pas une sensibilité assez émotive, ou alors une planche trop chargée.
Ceci dit, tu dois pouvoir trouver quelqu'un sur LinuxFR qui ne contribue pas déjà à LibreOffice et qui a les compétences pour résoudre ce problème (de loin il n'a pas l'air insurmontable), et qui le ferait pour le défi.
[^] # Re: Finalement la difficulté c'est de convaincre quelqu'un que le bug est important
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
En gros, il faut bien décrire le usecase ?
"La première sécurité est la liberté"
# Sociétés de consultance autours de LibreOffice (Collabora et d'autres)
Posté par Sébastien Wilmet . Évalué à 5.
Bon dans ton cas ça ne s'applique pas, puisque budget limité (besoin perso).
Mais pour les organisations qui utilisent LibreOffice, il est recommandé de passer par une société de consultance comme Collabora, qui déjà fournit une version LTS, mais aussi s'occupe de développer des solutions pour ses clients.
Voir cette page : LibreOffice in business
Le problème de BountySource et autres, c'est qu'il y a beaucoup trop de tickets ouverts dans le bugtracker, donc les dons sont dispersés par-ci par-là, et un ticket n'atteint presque jamais assez d'argent pour intéresser un développeur.
Par contre, il est très facile de faire un don (général) au projet LibreOffice.
Pour qu'une plateforme comme BountySource ait du succès, il faudrait donc une solution entre les deux approches, par exemple (à la grosse louche) :
1. Les développeurs de LibreOffice choisissent, disons, 5 tickets dans le bugtracker (pas pris au hasard évidemment).
2. Ils font ensuite une petite campagne pour récolter des dons pour ces 5 tickets.
3. Des développeurs travaillent sur les tickets et sont payés.
4. Retour au point 1 :-)
[^] # Re: Sociétés de consultance autours de LibreOffice (Collabora et d'autres)
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
C'est tout à fait faisable avec BountySource, mais leur équipe marketing a choisi plutôt d'importer directement les tickets des bugtrackers de différent projets sans aucun filtrage, et sans implication directe des gens qui travaillent sur les projets en question.
Il y a même des cas ou un ticket est fermé et le développeur qui a fait le travail n'est pas au courant qu'il y avait une prime et ne la réclame pas.
Je pense qu'on peut reprocher à BountySource d'avoir voulu grossir trop vite. Car, effectivement, une campagne de récolte de dons un peu mieux ciblée, ça fonctionne souvent beaucoup mieux et ça permet de communiquer plus facilement (c'est quelque chose d'"actif", on présente un plan d'attaque, on dit quel(s) développeur(s) va faire le job, on a à peu près une idée du budget nécessaire).
Mais du coup on se rapproche plus des trucs de crowdfunding à la Kickstarter.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.