Elveos.org, est un site Web de financement collaboratif pour les logiciels libres dont la version bêta vient d’être lancée. Ce site a été créé afin d’offrir une nouvelle source de financement aux développeurs de logiciels libres. Le principe est simple : Elveos permet à plusieurs utilisateurs de se grouper pour acheter une fonctionnalité dont ils ont besoin sur un logiciel libre.
Chaque utilisateur peut ainsi créer une demande de fonctionnalité, ou proposer une contribution financière sur une demande déjà existante. Une fois que la somme des contributions sur une demande est suffisante, un développeur peut réaliser la fonctionnalité demandée, puis récupérer l’argent. En fait, n’importe quel développeur peut faire une offre de développement, en indiquant quelle somme d’argent il attend, en combien de temps et comment il compte répondre à la demande.
Un développeur peut aussi utiliser Elveos pour financer certaines évolutions de sa feuille de route : il crée une demande de financement sur le site Elveos et précise le montant nécessaire pour effectuer le développement.
En un mot, c’est un système de « bounty ». Vous pouvez trouver plus de détails sur le fonctionnement du site dans la suite de la dépêche ou dans la documentation. L’équipe d’Elveos attend vos retours, demandes de fonctionnalités, rapports de bogues et contributions.
Elveos, financement collaboratif pour les logiciels libres
Elveos fournit un nouveau moyen de financement et la possibilité pour les utilisateurs d’acheter les fonctionnalités dont ils ont réellement besoin.
La communauté
Elveos a été conçu de manière à ce que la communauté puisse être capable de s’organiser autour d’un projet de financement :
- s’il y a plusieurs offres de développements sur une seule demande, alors les contributeurs sont appelés à voter pour choisir l’offre qu’ils souhaitent voir réalisée ;
- après un développement, il faut s’assurer que la réalisation correspond à l’offre annoncée par le développeur. Pour cela un « mini bug tracker » a été mis en place. Les utilisateurs ont 7 jours pour y déposer les bogues qu’ils ont pu voir, et le paiement du développeur ne sera fait qu’après la correction des bugs critiques ;
- Elveos utilise un système de réputation appelé karma. Quand les personnes apprécient (ou n’apprécient pas) quelque chose que vous avez créé sur le site, ils peuvent l’indiquer au moyen de boutons + et - disponibles sur de nombreuses pages. Ainsi, chaque utilisateur gagne, ou perd, du karma au fur et à mesure qu’il utilise le site. Ce karma servira par la suite à déterminer l’impact d’un utilisateur lors d’un vote. Ainsi, s’il faut choisir parmi deux développeurs, un vote sera organisé, dans lequel les vétérans auront (légèrement) plus d’impact que les comptes récemment créés.
Elveos sert de garant
Pour la satisfaction des contributeurs et des développeurs, il n’y a pas de système de promesse de dons dans Elveos : le risque de non paiement est trop élevé, et le développeur ne saurait donc jamais combien il serait payé.
Pour éviter ceci, l’argent est prélevé dès la contribution. Le contributeur garde cependant la possibilité d’annuler sa contribution jusqu’à ce qu’un développeur soit sélectionné. L’argent est versé au développeur dès que son travail est validé.
Un service centralisé
Comme beaucoup sur ce site, l’équipe d’Elveos est plutôt partisane des services décentralisés. Pourtant, Elveos propose un service centralisé. Dans ce cas, cela apporte un réel avantage :
- les solutions de paiement décentralisées ne sont pas encore au point ;
- Elveos se pose en tiers de confiance. Le site n’a pas d’intérêt particulier lors de la validation ou non d’un développement. C’est très différents sur les systèmes similaires proposés directement par les développeurs ;
- une plate‐forme unique permet d’améliorer la visibilité des projets (enfin, une fois qu’Elveos sera suffisamment gros…).
De plus, Elveos est un logiciel libre, et donc fournit un certain nombre d’assurances :
- si le service qui est proposé ne vous convient pas, rien ne vous empêche d’ouvrir un site concurrent en utilisant le même code ;
- Elveos fait de son mieux pour protéger les données personnelles qui lui sont confiées, et vous pouvez vérifier comment elles sont « traitées » en lisant le code ;
- l’équipe d’Elveos fait du logiciel durable, et est ouverte à vos demandes, commentaires etc..
Et si je ne veux pas être payé ?
Bien entendu, une part importante des développeurs de logiciels libres contribuent sur leur temps libre, et ne souhaitent pas de rémunération.
Vous pouvez malgré tout répondre à une demande :
- utilisez l’argent sur d’autres demandes qui vous plaisent ;
- faites votre offre au nom d’une équipe. C’est l’équipe qui va gagner l’argent.
L’état actuel d’Elveos
Le service est aujourd’hui proposé en bêta ouverte. L’équipe d’Elveos espère avoir de nombreux retours, aussi bien concernant des bogues, des traductions erronées, que des suggestions de fonctionnalités ou d’amélioration de l’interface utilisateur.
Quelques points dont il faut être conscient concernant la bêta :
- les CGU et les CGV ne sont absolument pas définitives, et seront amenées à évoluer. Vos retours sur ce sujet sont par ailleurs les bienvenus ;
- les « brainstorms » ne sont pas encore développés. Ils permettront à un utilisateur qui a un besoin flou de passer par une étape de collaboration de type Wiki avant de créer une vraie demande en bonne et due forme ;
- le karma n’est pas complètement fonctionnel.
Par ailleurs, quelques autres fonctionnalités sont peut‐être en cours de développement. Si vous voulez découvrir les prochaines fonctionnalités, vous pouvez jeter un œil sur le dépôt du projet.
À propos de l’équipe d’Elveos
L’équipe d’Elveos est constituée de trois libristes. Ayant tous une formation d’ingénieur, ils ont souhaité, après quelques années, travailler en entreprise, combiner leur intérêt pour les logiciels libres et leur vie professionnelle, d’où la naissance d’Elveos. Elveos est géré par l’entreprise Linkeos SAS.
Aller plus loin
- Le site elveos.org (801 clics)
- L’annonce du lancement (53 clics)
- FAQ d’Elveos (41 clics)
- Une vidéo de présentation (68 clics)
# Pérénnité du développement
Posté par flagos . Évalué à 9.
Deja bravo pour votre initiative, c'est vraiment quelque chose qui aidera le logiciel a se développer.
Une petite question par rapport a la pérénnité du developpement: si on veut ajouter et que cette feature soit integree upstream histoire de la péréniser, vérifiez-vous que la contribution a bien été acceptée ?
Le problème, c'est que ce genre de developpement risque d'etre faits par des gars qui seront pas dans l'équipe de développement du projet initial, et donc sans garantie sur l'integration upstream.
[^] # Re: Pérénnité du développement
Posté par Frédéric Bertolus (site web personnel) . Évalué à 7.
Lorsque l'on fait une demande sur le site, il est demandé d'indiquer si l'intégration upstream est une exigence. Un développeur qui propose de réaliser la demande s'engage à faire se qui est demandé à moins qu'il indique le contraire dans son offre.
Avant le paiement, les contributeurs doivent valider la réalisation, et l'absence d'intégration upstream peut être vérifiée à ce moment.
# Ensemble de questions stupides
Posté par Jérôme Asseray . Évalué à 2.
N'existe-t-il pas d'autres projets du même genre? un état de l'art? concurrence?
Le système de "bounty" n'est pas nouveau, est-il possible (ou prochainement)de fédérer les demandes? ex. Google Summer of Code
Je plaide coupable, j'ai lu rapidement la dépêche. Quelles sont les charges/prix pour le service? quelle est le modèle économique de la société Linkeos SAS?
[^] # Re: Ensemble de questions stupides
Posté par Kerro . Évalué à 5.
Il existe d'autres projets du même type depuis longtemps.
Aucun n'a vraiment donné de bons résultats.
L'idée est excellente. Alors pourquoi ça ne prends pas ?
En tant que responsable de l'informatique d'un groupe, j'ai eu recours à des prestations de développement sur du libre. Par exemple sur vnc afin que le mot de passe stocké ne soit pas réversible, que l'authentification ne fonctionne pas lors d'un rejeu, et pour limiter les tentatives d'authentification. Ca n'a pas été accepté upstream (même si pour vnc ça ne veut rien dire). Je n'ai pas mis en place un dérivé de vnc ni un site web avec les patchs. j'avais autre chose à faire que de maintenir ce genre de chose. Gâchi (surtout pour les autres, vu que moi j'avais ce que je voulais).
Pourquoi une entreprise (ou un particulier) paierait pour finalement aider les autres ?
La réponse est: pour s'aider soi-même. Car ce développement, une fois en upstream, ou disponible en patch, ou sous forme de fork ou autre, sera utile à l'entreprise également avec les futures versions. Des efforts en moins.
Et en plus on se "cotise" pour le développement. Donc le coût est bien moindre.
Cela ne fonctionne que pour des logiciels non stratégiques. Et encore, peut-être même dans ce cas.
Je rêve toujours d'un logiciel libre de comptabilité qui tienne la route.
Et de paie.
M'en retourne rêver.
[^] # Re: Ensemble de questions stupides
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
OpenConcerto?
[^] # Re: Ensemble de questions stupides
Posté par Kerro . Évalué à 2.
Qui tienne la route = moyen
Il y a quelques mois OpenConcerto n'était franchement pas terrible.
Question paie c'est le meilleur en libre que j'ai vu (facile, les autres sont archi-nuls).
[^] # Re: Ensemble de questions stupides
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
Je suis preneur en MP de ce que tu lui reproches et de tes attentes.
Nous finalisons la version 1.1 et commençons la roadmap pour la 1.2, c'est donc le bon moment.
[^] # Re: Ensemble de questions stupides
Posté par ZeroHeure . Évalué à 2.
quels autres?
et que reproches-tu aux programmes de compta (pros)?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Ensemble de questions stupides
Posté par Yoann Plénet (site web personnel) . Évalué à 4.
Nous n'avons trouvé de projets équivalents au notre. Il existe bien quelques alternatives, aucune ne nous semble capable aujourd'hui de répondre aux besoins du logiciel libre :
Les systèmes de bounty ne sont certes pas nouveaux, mais sont généralement associés à un projet donné. N'étant pas le cœur de métier des équipes de développement, c'est généralement développé rapidement, et assez peu d'énergie est allouée à animer le système.
Elveos n'a pas ce problème étant développé par un acteur extérieur aux équipes de développement de logiciels libres.
Pour google summer of code, c'est certes une super initiative, mais qui ne s'adresse qu'aux étudiants, et qui ne propose pas de système d'appel public aux contributions comme elveos. Il nous semble donc difficile d'essayer de fusionner elveos et GSOC. Cependant si certains d'entre vous ont des idées à ce sujet nous sommes preneurs.
Enfin pour répondre à ta dernière question, nous prélevons une commission de 10% + 0,30€ lors de chaque transaction bancaire.
Pour plus d'informations (en particulier sur toutes les problématiques d'argent ...) n'hésite pas à consulter la FAQ ou à poser d'autres questions !
[^] # Re: Ensemble de questions stupides
Posté par Kerro . Évalué à 3.
Au cas où cette idée fonctionne enfin, ce que je souhaite à tous, il y a fort à parier qu'une offre alternative voit le jour avec moins de frais.
Mais jusqu'à présent, cette idée n'a jamais pris :-(
[^] # Re: Ensemble de questions stupides
Posté par BAud (site web personnel) . Évalué à 1.
peut-être faudrait-il - comme toute société de portage abusant un peu - prendre 20% + 1000 euros de compta annuelle ? (plus c'est cher, mieux c'est, ça marche bien avec apple...)
# Présentation de l'entreprise
Posté par Mali (site web personnel) . Évalué à 5.
typo/ortho sur cette page
-Linkeos SAS est une entreprise française créee pour géré la plateforme elveos.org.
+Linkeos SAS est une entreprise française créée pour gérer la plateforme elveos.org.
PS : Sinon cela me semble être une bonne idée, bonne chance à vous !
[^] # Re: Présentation de l'entreprise
Posté par Thomas Guyard . Évalué à 3.
Je viens de le corriger dans le commit : a4bdd8bc8
Ce sera déployé avec notre prochaine release (très prochainement).
Merci !
# Une excellente initiative
Posté par ddevito (site web personnel) . Évalué à 1.
C'est vraiment une initiative excellente !
J'en ai révé : "Revisiting donation/funding for open source projects - let's talk about FDD (Feature-Driven Development)" et vous l'avez fait (ce qui est, de loin, le plus important).
Merci
# Impôts taxe…
Posté par Anthony Jaguenaud . Évalué à 1.
Salut,
le système semble intéressant, mais cet argent devra être déclaré. Quid des cotisations… je ne connais pas suffisamment la loi pour savoir ce qui est possible et ce qui ne l’est pas.
Je n’ai rien vu sur elveos qui donne une idée des status possibles pour les développeurs.
[^] # Re: Impôts taxe…
Posté par claudex . Évalué à 3.
Pour moi, c'est au développeur qui reçoit l'argent de gérer ça. Vu qu'il peut très bien ne pas avoir d'impôt s'il fait ça au nom d'une association ou à l'étranger où ce ne serait pas taxer (ou d'une manière différente).
« 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: Impôts taxe…
Posté par Frédéric Bertolus (site web personnel) . Évalué à 2.
Oui, cet argent doit être déclaré. Ça serait en effet une bonne idée d'ajouter cette question dans la FAQ.
Je ne connais pas en détail les statuts des étrangers, mais pour les développeurs Français :
Dans tous les cas, comme quand on vend des pommes, c'est à celui qui vend d'être dans son droit pour toucher de l'argent et de le déclarer.
Pour ce qui est de la facturation, il y a sur le site un générateur de facture qui permet au développeur de générer une facture par contributeur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Impôts taxe…
Posté par Frédéric Bertolus (site web personnel) . Évalué à 2.
Effectivement, il faut déclarer la rémunération au impôt. Je crois que ce qui est possible de faire un travail à titre exceptionnel sans créer d'entreprise (Je ne trouve pas de source écrite donc à confirmer tout de même).
[^] # Re: Impôts taxe…
Posté par Larry Cow . Évalué à 2.
Il est possible d'obtenir un statuts d'autoentrepreneur en cumul avec un emploi actuel. La seul contre indication est une interdiction explicite dans le contrat de travail ou un close de non concurrence.
Non, il y a une autre contre-indication : être fonctionnaire. Dans ce cas, le cumul dure au plus deux ans (après, il faut choisir), et l'autoentreprise ne doit pas opérer dans le même domaine que la fonction "publique" de l'autoentrepreneur. Sauf s'il bosse dans la culture, allez comprendre...
# Cela arrrive au bon moment : l'idée est dans l'air du temps
Posté par ddevito (site web personnel) . Évalué à 1.
Récemment a été publié sur linuxfr: Commercial Co-financement d'un logiciel de transfert vers machine-outil sur un sujet analogue.
# LINKEOS SAS
Posté par Philippe Scoffoni (site web personnel) . Évalué à 2.
bonjour,
Question peut-être indiscrète mais le projet est porté par une société de type SAS. Quel est son modèle économique, autrement dit comment comptez-vous gagner de l'argent ? Si ce n'est pas le but pourquoi ne pas avoir choisi un statut associatif ?
[^] # Re: LINKEOS SAS
Posté par Frédéric Bertolus (site web personnel) . Évalué à 7.
Nous nous sommes vraiment posé la question il y a quelques mois sur le statut juridique à choisir.
Nous avons finalement choisis une entreprise pour les raisons suivantes :
Si notre site marche mais que nous abusons du logiciel libre avec des dividendes délirants, il est possible de lire cette doc INSTALL puis d'aspirer notre base via l'API REST. :)
[^] # Re: LINKEOS SAS
Posté par Frédéric Bertolus (site web personnel) . Évalué à 5.
J'ai oublié une partie de la réponse !
Nous nous rémunérons en prélevant une commission de 10% à moment du paiement d'un contributeur (une fois sur le site, l'argent peut circuler librement sans autre prélèvement). Ça peut paraître élevé, mais une fois les frais bancaires et les différents coûts payé, il faut essayer de payer des salaires, qui même au smic coûtent cher ... Il y a un peu plus d'infos là dessus dans la faq : https://elveos.org/fr/documentation/faq
# connexion aux forges et systémes de tickets
Posté par pilouche (site web personnel) . Évalué à 4.
C'est intéressant, mais en tant que développeur d'un projet libre, la première question qui me vient à l'esprit concerne la connexion aux forges des projets en question.
Par exemple, je vois une demande pour VLC sur votre site actuellement.
Comment savoir si cette demande est issue d'un ticket déjà déposé par le projet VLC ?
En effet se pose la question de la légitimité de la fonctionnalité à développer. En général, la valeur d'une fonctionnalité, son besoin, et surtout la technicité nécessaire à son développement (et donc son prix!) sont discutées au sein du projet.
Enfin, une connexion directe aux forges et systèmes de tickets me paraîtrait être un plus afin de construire la base de votre site. Pourquoi ne pas imaginer que vous importiez les tickets ouverts de nombre de projets libres ?
[^] # Re: connexion aux forges et systémes de tickets
Posté par Thomas Guyard . Évalué à 2.
En fait quand un développeur fait une offre de développement il peut décrire comment il souhaite résoudre la demande, mais il peut aussi détailler quelles sont ces relations avec le projet etc.
Le coût comme le délais sont fixés dans l'offre du développeur.
Quant à la connexion directe aux forges et systèmes de tickets, on y a pensé, mais n'a pas encore eu le temps de l'implémenter (ni même de voire précisément comment faire ça ...)
[^] # Re: connexion aux forges et systémes de tickets
Posté par pilouche (site web personnel) . Évalué à 2.
En tant que développeur, mon intuition est que vous avez besoin de plugins pour au moins redmine et trac, et encore mieux, pour gitorious, github & googlecode. Pour ces trois derniers je ne sais pas si c'est faisable.
Pour les deux premiers, ca l'est et je pense que c'est urgent. J'avoue que je suis sceptique sur la dissociation entre le système de tickets d'un projet, et le site de répunérarion. Mais j'espère que vous réussirez d'une façon ou d'une autre!
# Plan de communication?
Posté par david.g . Évalué à 3.
Bien le bonsoir. Tout d'abord je souhaite très sincèrement que la mayonnaise prenne pour vous et votre projet. Si il peut donner un coup de pousse à certains développeurs et aux projets libres alors ce serait génial pour tout le monde.
J'imagine que la clef du succès d'un tel projet est d'arriver à réunir sur votre plateforme une large communauté de contributeur et de "demandeur", voir de lier des partenariat avec des sociétés qui intègre et/ou utilisent du logiciel libre.
Pour cela il faudra arriver à vous faire connaitre assez largement (au delà de DLFP, Cl**ic etc ..) et ensuite être capable de réunir ses gens sur votre plateforme. Comment comptez-vous vous y prendre ?
Bonne chance pour la suite!
[^] # Re: Plan de communication?
Posté par Yoann Plénet (site web personnel) . Évalué à 4.
Bonjour
Tu as bien cerné toute notre problématique ... maintenant que le site est développé le plus important est d'arriver à convaincre les gens de l'utiliser (et de le réutiliser).
Nous n'avons communiqué que sur DLFP pour le moment car nous avons confiance en la communauté pour faire des retours pertinents. Les retours que nous avons eu vont nous permettre de finaliser le site avant le véritable lancement où nous ciblerons plus de sites.
Pour attirer des utilisateurs, nous comptons en-effet nouer des partenariats avec des développeurs de logiciels libres :
Par ailleurs pour faire venir les utilisateurs, nous aurons une communication plus classique, en ciblant des sites/blogs voire des communiqués de presse dans des magazines/journaux et on ne s'arrêtera pas à DLFP.
Un point à noter, le site est conçu pour être entièrement traduit dans différentes langues. Nous ne nous restreignons pas aux utilisateurs français. Ceci aidera à atteindre la masse critique permettant aux projets d'arriver à leur terme.
[^] # Re: Plan de communication?
Posté par Olivier Renaud . Évalué à 5.
Comment gérez-vous l'aspect multilingue d'Elveos ? Je vois qu'il y a déjà des demandes en français et des demandes en anglais. Je vois plusieurs cas de figure :
Si il existe d'autres alternatives, je suis curieux de les connaitre.
De mon point de vue, seule la dernière alternative est viable, pour un site communautaire comme Elveos.
[^] # Re: Plan de communication?
Posté par Frédéric Bertolus (site web personnel) . Évalué à 1.
Ce n'est pas encore en plus, mais l'objectif est de tester la solution suivante :
Le titre et la description des demandes pourront être traduite pour toucher la cible la plus large possible. Le reste ne sera pas traduit, et l'anglais sera sûrement fortement incité pour des débats techniques.
[^] # Re: Plan de communication?
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 11 septembre 2011 à 21:36.
une manière simple de le faire est de demander aux inscrits quelles langues ils souhaitent lire :
Pour les traductions en libre, regarder du côté de http://www.apertium.org/?id=whatisapertium&lang=fr qui me semble intéressant, au besoin en demandant des améliorations de l'API... Il serait dommage de se limiter à l'anglais lorsqu'une extension semble envisageable...
# Super idée.
Posté par hocwp (site web personnel) . Évalué à 3.
Il y a eu récemment une campagne pour améliorer SBCL (un compilateur Common Lisp). L'auteur est développeur sur ce compilateur depuis pas mal de temps et il fixait un premier objectif à $3000. En trois jours il a été atteint ! Il en a profité pour ajouter d'autres objectifs (7 pour $16000) qui ont été atteints en 15 jours. Reste à voir ce qui en sortira (je n'ai pas trop de doute vu le bonhomme), mais il semble qu'il y ait de la demande pour ce genre d'actions.
# financement de projet libre
Posté par fredix . Évalué à 3.
Super projet intéressant, cependant j'ai l'impression que vous n'êtes pas allé au bout de votre idée. Si j'ai bien testé, il n'y a qu'un seul sens pour l'instant, c'est à dire une demande de feature vers le développeur; il n'est pas possible pour un développeur de présenter son projet pour obtenir des financements globaux au projet. Exemple il y a vlc https://elveos.org/fr/softwares/55?name=vlc que parce qu'une personne a créé une demande de feature.
C'est dommage car cela permettrait de financer un peu un projet, surtout si les utilisateurs l'aiment sans forcément vouloir demander une feature en particulier. Et ça permettrait au dev de présenter son projet et d'expliquer pourquoi il recherche des fonds et comment il en fera l'usage.
Ensuite en créant une API on pourrait même imaginer de pouvoir faire un don en un clic si le logiciel intègre l'API dans son interface, un espèce de flattr dédié au libre quoi.
[^] # Re: financement de projet libre
Posté par Yoann Plénet (site web personnel) . Évalué à 3.
Merci pour le retour !
Ce que tu décris correspond en partie aux principes des dons, et nous n'envisageons pas vraiment de concurrencer les dons. Ils présentent un certain nombre d'avantages (fiscalité avantageuse, décentralisation, pas d'intermédiaire nécessaire) et sont déjà utilisés par de nombreux développeurs de logiciels libres.
Par ailleurs le concept principal d'Elveos est de payer pour le développement d'une fonctionnalité, pas de payer pour ce qui a déjà été réalisé dans le passé (ce qui se fait avec les dons).
Nous avons par contre en tête d'ajouter (quand nous aurons le temps) une fonctionnalité permettant de payer de manière récurrente pour la maintenance d'un projet.
Par ailleurs un développeur a toujours la possibilité de demander de se faire financer un ou plusieurs items de sa roadmap via elveos (il peut tout à fait faire une demande de financement incluant les fonctionnalités qu'il a prévu de développer au cours des 1 ou 2 mois à venir) permettant ainsi de coller au principe d'Elveos.
Enfin pour l'API, nous avons créé une API REST. Elle ne permet actuellement de faire que de la consultation, mais l'idée à terme est bien de permettre d'intégrer les services d'Elveos au sein des sites de développeurs, voire d'un bug tracker.
[^] # Re: financement de projet libre
Posté par fredix . Évalué à 2.
Ok, en tout cas je rejoins ce que dis Philippe plus bas, il faudrait sans doute revoir le concept pour que ça prenne. Pouvoir créer une équipe est bien, mais si c'est une équipe de dev et qu'elle ne peut pas créer son projet ca marchera pas à mon avis.
Sinon par curiosité pourquoi avoir créé votre propre framework Bloatit et ne pas avoir utilisé playframework ?
[^] # Re: financement de projet libre
Posté par Frédéric Bertolus (site web personnel) . Évalué à 2.
Il me semble qu'a l'époque (il y a un an) nous n'avons pas du trouvé de framework qui collait à toutes nos exigences et qui compensait à l'attrait de réinventer la roue. Il est possible que nous soyons passé à coté de Play surtout que avons commencé initialement à codé en python, jusqu'au premier besoin de faire du refactoring ...
Il faudrait tester Play, ou d'autres framework sur des problématiques complexes, mais pour le moment je ne regrette pas notre choix. Si ça n'était pas forcement le plus efficace, ça été très enrichissant. De plus je pense qu'une fois isolé du code d'Elveos, ça peut être un bon framework pour de gros sites web.
[^] # Re: financement de projet libre
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
C'est à dire, vous avez rencontré quoi comme problème lors du refactoring ?
[^] # Re: financement de projet libre
Posté par Frédéric Bertolus (site web personnel) . Évalué à 1.
Je ne me souviens plus exactement, mais le couple java + eclipse/netbeans est, il me semble, inégalé en outils de renommage, auto complétion et génération de code. De plus compter la détection d'erreur en temps réel fait gagné beaucoup de temps et elle est très limité en python par exemple.
# Ca doit partir du développeur
Posté par Philippe F (site web personnel) . Évalué à 10.
Je ne crois pas trop au modèle où les utilisateurs arrivent à mutualiser un besoin et l'exprimer suffisamment clairement pour que ça deviennent un sujet de développement rémunéré. Les utilisateurs ont rarement une vision suffisamment claire de ce qui leur manque et de comment y arriver et combien ça coûterait.
Ou bien alors on parle d'utilisateurs institutionnels et professionnels, et vous vendez de la prestation de développement comme une SSII.
En revanche, les différents exemples dans les commentaires parlent de succès dans le cas où le besoin et le but partent du développeur, qui cherche alors un financement. Je l'ai vu utilisé, pour Python, pour KDE (Krita, Quanta), pour mercurial. Là, c'est un développeur, en général indépendant, qui dit ce qu'il a envie de faire, combien il lui faut pour le réaliser et les utilisateurs peuvent se grouper pour l'aider. L'intérêt dans ce cas est multiple:
- comme ça part du développeur du projet, on sait que ça sera intégré au final dans le projet
- garantie de sérieux, puisque c'est le développeur lui-même
- la visibilité du projet est utilisée comme vecteur de communication vers les utilisateurs donc bonne chance de toucher ceux qui ça intéresse.
Bref, dans ce deuxième cas, j'y crois plus...
[^] # Re: Ca doit partir du développeur
Posté par Stéphane Klein (site web personnel) . Évalué à 0.
+1
[^] # Re: Ca doit partir du développeur
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
Comme par exemple le modèle économique de Ardour http://ardour.org/development
[^] # Re: Ca doit partir du développeur
Posté par Yoann Plénet (site web personnel) . Évalué à 2.
Nous sommes entièrement d'accord avec ça !
Nous présentons encore Elveos sous l'angle d'une demande venant de l'utilisateur parce que c'est plus simple à expliquer (et parce que c'était le concept initial) mais nous croyons plus dans les demandes qui sont créées par un développeur.
[^] # Re: Ca doit partir du développeur
Posté par claudex . Évalué à 2.
Je pense que ça dépend du besoin. Je prend un exemple que j'ai vu sur le site :
Ça me semble suffisamment clair comme proposition. Maintenant, c'est au développeur qui fait la proposition de précision s'il doit détecter les bandes noire dans le film ou juste s'occuper des bandes noires ajoutées par VLC.
« 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: Ca doit partir du développeur
Posté par fredix . Évalué à 2.
Le problème fondamental c'est que les utilisateurs ne sont pas capable d'imaginer toutes les features que des développeurs ont en tête. Or baser les financements de fonctionnalités uniquement sur ce que les utilisateurs souhaitent est à mon avis voué à l'échec. Le pire est que tant qu'un premier utilisateur ne créé pas une demande de fonctionnalité, le logiciel ne peut tout simplement pas apparaître sur le site ...
Après ce n'est qu'une version bêta.
[^] # Re: Ca doit partir du développeur
Posté par ZeroHeure . Évalué à 2.
Pour qui l'échec?
Où est le problème? jusque-là, en tant que développeur de libre, je ne suis pas financé et je m'en acomode. Si quelqu'un me demande un truc particulier et propose des sous, très bien, ça s'appelle un client. D'ailleurs c'est déjà ce qui se passe.
Il est évident que seul des gens avertis vont se rendre sur Elveos, je veux dire des informaticiens, à tout le moins des geek capables de formuler le problème. Je vois mal la boulangère de Ploum aller réclamer qu'on code un truc coupant l'iphone des clients qui font la queue.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Ca doit partir du développeur
Posté par Kerro . Évalué à 3.
Justement, là où les choses deviennent intéressantes est lorsque "le grand public" peut financer.
3000 dons de 5 € sont mieux que 50 dons de 30 € (10 fois mieux sans tenir compte des 30 cts par transaction).
Comment "démocratiser" cette idée ?
Elle ne prend pas avec les geek (les expériences précédentes n'ont pas durées), comment aller plus loin ? Je pense qu'il y a quelque chose qui manque, mais quoi ? Car je suis persuadé que c'est vraiment une très bonne idée.
[^] # Re: Ca doit partir du développeur
Posté par ZeroHeure . Évalué à 2.
Excuse-moi mais le grand public il attends des satisfaction immédiates. Et pas plus qu'il n'a envie de faire des rapports de bug, il n'aura envie de demander qu'on lui code un truc. Si jamais il y en a un qui le fait, traitreusement poussé par un geek sans doute, il reviendra une fois ou deux voire si c'est fait et puis s'enfuira parce ça ne va pas assez vite.
Ce n'est pas une question de prix, mais d'interlocuteur.
Par contre je pense qu'il pourrait acheter une fonction en cours de codage, mais il faudrait pouvoir le contacter ce grand public.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Ca doit partir du développeur
Posté par BAud (site web personnel) . Évalué à 2.
j'ai comme l'impression que tu n'imgines pas ce que peuvent faire les utilisateurs :)
l'exemple de 2mandvd me vient à l'esprit (malgré les utilisateurs, malgré le développeur), sans critique, simplement un constat que parfois cela peut bien marcher et cela fait plaisir (factuellement, il y a un logiciel dispo pour tout le monde, malgré tous les coups de gueule de part et d'autre, tant mieux, chacun a fait ce qu'il pouvait, s'est tenu à une ligne directrice, malgré les aléas...). Comme quoi se parler fait évoluer le logiciel (s'écouter marche mieux àmha)
[^] # Re: Ca doit partir du développeur
Posté par ZeroHeure . Évalué à 2.
C'est vrai mais 2mandvd est un cas spécial AMHA: je ne pas trop comment mais Stéphane Gibault, l'auteur, a su créer une communauté autour de lui. Mais tu avoueras que monter un DVD c'est quand même un truc de passionnés presque geek, non? Mais après tout, si ça peut déjà réussir avec les geeks, tant mieux.
Pour les autres, disons le grand public et les boulangères de Ploum, si je suis bien d'accord que "se parler fait évoluer le logiciel", c'est bien là tout le problème. Puisque pour se parler il faut des lieux de rencontre et du temps libre.
Par exemple, j'ai affaire à des utilisateurs (dont beaucoup sont des femmes) qui sont pris par le boulot, et n'ont pas le temps d'aller fouiner. Il ne me signalent même pas les problèmes, ça les emmerde de le faire. De temps en temps ils gueulent. Et je les comprends, ils ont la même attitude que mon petit frère, pourtant bidouilleur et programmeur de choc, qui me rappelle de temps en temps qu'il ouvre son Mac pour bosser (il est archi) et ne penser qu'à son boulot. Pour ce grand public là il faut trouver autre chose.
Flute, je suis super confus - je m'en vais dormir.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Ca doit partir du développeur
Posté par fredix . Évalué à 2.
Echec parce qu'il n'y aura peu de demande utilisateur.. Or si le développeur peut lui même créer son projet et proposer des features à financer c'est à mon avis plus viable car la plupart des features dans un logiciel sont imaginées par les dev.
Exemple, "Vous aimez notre logiciel et vous voulez nous aider ? allez sur la page elveos de notre projet et financez nos dev !"
Ca change un peu tout et ca n'a rien à voir avec un simple don car l'utilisateur est beaucoup plus impliqué.
# Bravo
Posté par Hugo Mercier (site web personnel) . Évalué à 1. Dernière modification le 11 septembre 2011 à 21:55.
Bravo pour l'initiative. Ca fait quelques temps que je réfléchissais un concept similaire, et vous l'avez fait.
Une question que je me pose (vous vous l'êtes peut être déjà posé) : pourquoi des projets comme Cofundos ou feu Micropledge qui ressemblent beaucoup (et en plus sur un marché international), sont soit morts, soit moribonds, alors que Kickstarter fonctionne très bien ?
Sinon, quelques remarques :
[^] # Re: Bravo
Posté par Thomas Guyard . Évalué à 2.
À mon avis, il y a plusieurs facteurs :
# Contribution
Posté par Émilien Kia (site web personnel) . Évalué à 1.
Belle initiative de votre part.
Par rapport à votre statut, comme vous l'avez précisé plus haut, j'ai bien conscience que la forme d'une SAS permet l'accès à certains financements non accessibles aux associations mais n'avez-vous pas peur de vous couper de petits contributeurs ? N'aurai-t-il pas été plus judicieux d'avoir deux structures : une associative pour les petits contributeurs à titre personnel et une société pour les grosses contributions de sociétés ?
N'avez-vous pas peur du revers de la médaille du libre: qu'une association se monte en reprenant le code de votre site web (en licence Affero) pour proposer le même service en ne prélevant que les frais de gestion, sans faire de bénéfices ?
Par rapport au système de contributions, est-il possible de verser de l'argent en une fois (genre 50€) et le dispatcher sur plusieurs demandes (genre 10€ pour chaque) ?
Ou d'avoir un pot commun d'argent à répartir sur plusieurs projets et où les premiers projets réalisés sont réellement financés ?
Un jour libre ?
[^] # Re: Contribution
Posté par Frédéric Bertolus (site web personnel) . Évalué à 5.
Il y a un risque de perdre quelques contributeurs à cause de la structure juridique.
Nous n'avons pas peur qu'une association se monte en reprenant le code. Il est publié justement pour que nous ayons cet "menace". Le but d'elveos est d'être un acteur neutre, fiable et de confiance dans le logiciel libre. C'est une partie de notre valeur ajouté. Il me semble que tant qu'elveos respect ses engagements, il me semble qu'il n'y a pas de raison que les développeurs et les contributeurs décident de forker.
Il est possible de verser de l'argent en une seul fois et de le dispatcher en plusieurs demande. (clicker sur son nom en haut une fois loggé, puis il y a un bouton pour charger son compte dans la colonne de droite).
Le fonctionnalité du "pot commun" n'a pas été encore implémenté mais elle est depuis le début dans la liste des fonctionnalités importantes que nous avons prévu d'ajouter (elle devrait permettre d'augmenter très fortement la probabilité qu'une demande soit réalisée).
# xkcd
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Vu les illustrations du site, j'imagine que vous avez parmi vous des amateurs des dessins de Randall Munroe ?
[^] # Re: xkcd
Posté par Frédéric Bertolus (site web personnel) . Évalué à 1.
Oui, c'est la source d'inspiration initiale.
Au vu de nos piètres qualités artistique, c'était difficile de viser plus complexe que des bonhommes bâton pour rendre le site plus vivant :)
# Coût sous-estimé
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Comme indiqué dans un autre commentaire, les utilisateurs n'ont pas idée du temps que prend un développement. Je vois par exemple une demande "Montrer les photos géolocalisées sur une carte" pour 5€ (logiciel Shotwell). Bon. Disons qu'un développeur gagne 1500€ net/mois (environ 24 k€ brut / an, c'est plutôt mal payé). Disons qu'en plus il bosse 40h/semaine le pauvre, ça donne environ 9,38€ de l'heure. Bah pour 5€, il peut bosser environ 30 minutes.
Peut-être qu'il y a des développeurs capables d'entrer dans un projet de la taille de Shotwell en 10 minutes, coder la fonction en 10 minutes et trouver un fond de carte les 10 minutes restantes. Perso, je met plutôt 1 jour à 1 semaine pour entrer dans un projet, et pour la fonctionnalité, je pense qu'il faut bien 1 à 2 semaines de développement (estimation certifiée pifomètre). Pour le fond de carte : je suppose qu'il en faut plusieurs. Je doute qu'une planisphère convienne à un français par exemple (toutes les photos feraient un énorme tas). J'estime qu'il faut au strict minimum 10 jours de travail, et par expérience, je multiple arbitrairement par deux : donc 20 jours. 20 jours, ça donne un salaire => 1500€.
5€ ça fait donc 0,3% du coût que j'ai estimé. Je pense qu'il est vital que des développeurs indiquent leur estimation de la charge de travail (en "jours-homme" par exemple). Quitte à indiquer plusieurs estimations, ou calculer une moyenne des estimations. Il faudrait peut-être redécouper une fonction en plusieurs étapes, et peut-être permettre de financer chaque étape.
Quand je vois "Reconnaissance faciale dans le gestionnaire de connexion" pour 0€ ça me fait doucement rigoler. Je ne vois pas l'intérêt de faire une liste des rêves des utilisateurs. Vous pouvez voter autant que vous voulez, ça ne motivera pas un développeur à s'y mettre (en tout cas, perso je n'en tiens pas compte).
Bien sûr, le site permet à plusieurs personnes de financer une demande de fonction, mais sans indicateur, ça laisse penser au "client" qu'il aura sa fonction pour 5€. J'attend qu'il y a une demande à 100€ pour considérer sérieusement ce site.
[^] # Re: Coût sous-estimé
Posté par Émilien Kia (site web personnel) . Évalué à 1.
D'un autre côté, il est possible que les développeurs qui voudront contribuer le font sur leur temps libre, sur la base du volontariat/bénévolat, qu'ils auraient peut-être contribué de toute façon. Il faut donc peut-être voir ces sommes d'argents comme une compensation et non une rétribution salariale, donc pas avec les mêmes taux horaires.
Le montant alloué à chaque demande reste - même s'il est très faible par rapport au coût réel d'un développement industriel équivalent - un bon indicateur des envies des utilisateurs, qui est AMHA un moteur majeur des directions à prendre pour le développement passe-temps libriste.
Un jour libre ?
[^] # Re: Coût sous-estimé
Posté par Frédéric Bertolus (site web personnel) . Évalué à 2.
C'est un système d'achat groupé. Il n'est pas ici proposer de développer "Montrer les photos géolocalisées sur une carte" pour 5€, il faut attendre d'autres contributions.
Un élément important du site, les offres, n'est pas encore visible. Si un développeur peut développeur la demande, il peut faire un offre ou il décrit ce qu'il va réellement faire et à quel prix.
Le vote n'est pas là pour inciter les développeurs à le développeur les demandes gratuitement, mais pour mettre en valeur les demandes intéressantes et réaliste et au contraire masques les demandes peu pertinentes.
# Un exemple en rapport avec le sujet financement de PyPy pour compatibilité Python 3
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
Un exemple en rapport avec le sujet financement de PyPy pour compatibilité Python 3 :
http://mail.python.org/pipermail/pypy-dev/2011-September/008288.html
Les commentaires à ce sujet sur Reddit : http://www.reddit.com/r/Python/comments/kd38b/pypys_python_3_plan/
# Autre projet similaire
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
Autre projet similaire : http://fr.ulule.com
Exemple de projet en rapport avec le libre financé par cette plate-forme : http://fr.ulule.com/debian-handbook/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.