Remuneration de developpeurs libres

αjet · Le 02/01/2011, à 13:31

Bonjour,

Pendant une discussion en famille, une idée est survenue. Il s'agit de mettre en relation des utilisateurs de systèmes libres n'ayant pas le temps ou les compétences requises pour développer de nouvelles applications et/ou les améliorer et des développeurs souhaitant être rémunérés. Partant du principe que si 100 personnes sont pretes à investir 10€ pour un un projet, cela permet de financer un développeur ou une équipe pour le réaliser.

Je souhaiterais donc démarrer un projet permettant de mettre en relation utilisateurs et développeurs libres. Les objectifs seraient les suivantes:

permettre a des développeurs d'être rémunères et d'acquérir une expérience qui leur serait utile en vue d'obtenir un emploi ou de «se lancer». Par exemple étudiants, chômeurs, ou de manière générale toute personne souhaitant se construire une expérience dans le développement d'applications libres.
Enrichir la communauté libre: tous les développement devront être libre. Si le projet est rentable, une partie des bénéfices devront être reversé à la communauté libre (e.g. financer le projet Debian).
Démontrer qu'il est possible de combiner projets libres, rentabilité économique et responsabilité sociale. Même si l'objectif premier n'est pas de faire de l'argent, j'aimerais que ce projet soit un exemple supplémentaire d'entreprise économiquement rentable, socialement responsable et contribuant aux projets libres.

Pour cela je souhaiterais que cette entreprise (dans le sens d'entreprendre, pas forcement dans son acception juridique) soutienne des projets libres avec un cahier des charges exigent. Pour être rémunéré, les projets devront nécessairement remplir les exigences suivantes :

Code distribué sous licence GNU GPL.
Code documenté de manière a ce que le code puisse être facilement repris.
Les applications devrons être développées pour des systèmes libres. Par exemple, des applications même libres développées pour un environnement fermé tel MS-Windows ou Apple OS ne seront pas soutenues par ce projet.
Des paquets binaires devront être compilés pour au moins une distribution libre (par exemple Debian GNU/Linux, Arch Linux, *BSD, etc.). Des paquets pouvant également être porté pour d'autres distributions GNU/Linux telles que Ubuntu, Fedora ou OpenSUSE.
En ce qui concerne les applications web, elle devront être respectueuses des standards (html, css) en vigueur et devront pouvoir s'installer sur des serveurs libres. Elle ne devront donc pas recourir a des technologies fermées pour être mise en place.
Toutes les applications devront être pensées dans une logique d'accessibilité pour les handicapés.
Toutes les applications devront être localisable.
Je souhaiterais que la charte de développement soit le plus proche possible de la charte debian.

Pour cela j'ai l'intention de mettre en place une infrastructure pour :

héberger le code sources de ces applications (GIT, svn ou autre)
des dépôts logiciels pour les principales distributions libres citées ci-dessus, pour permettre aux utilisateurs d'installer facilement ces applications
Une application web permettant de proposer et voter des projets, de faciliter l'écriture du cahier des charges des applications à développer.
Un espace de suivi de projet
Des environnements de tests et de validation
Gérer les paiements
Mettre en valeur les réalisations pour référence.

Etant donne que je vis actuellement en Angleterre, j'aimerais que ce projets soit international. Je n'ai pas de probleme si ce projet commence en France uniquement au debut. Mais j'aimerais pouvoir aussi le developper au Royaume-Uni, dans les autres pays francophones et anglophones et qu'il puisse etre deploye dans d'autres regions du monde si les opportunuites se presentent.

Je peux mettre à disposition le capital pour démarrer le projet (location de serveur dedie par exemple). Par contre j'ai un emploi qui est extrêmement chronophage, mon investissement en terme de temps sera donc malheureusement assez limité. Je recherche des partenaires répondants aux qualités suivantes:

motive par cette entreprise
ayant du temps pour définir avec moi plus précisément les objectifs
quelqu'un ayant des compétences en administration système pour m'épauler dans cette tache. Je connais les bases mais suis loin d'être un pro !

Si vous avez des commentaires, n'hesitez pas a répondre a ce post. Toutes les contributions sont les bienvenues. Notez que pour le moment, je n'ai pas une connexion permanente a internet car je ne suis pas a la maison. Ainsi, je vous remercie de patienter pour mes réponses.

Je remercie celles et ceux qui ont pris le temps de lire ce post et je vous présente mes meilleurs vœux pour 2011.

Note: je tape ce message avec un clavier qwerty. J'ai essayé de mettre les accents mais il doit en manquer...

Dernière modification par alex63 (Le 02/01/2011, à 15:03)

darkevolution · Le 02/01/2011, à 22:16

Salut !

C'est un projet qui est bien intéressant ! En tout cas c'est bien d'essayer de trouver des solutions

Il y a quelques points qui peuvent être discutable je pense.

Déjà... comment le projets pourrait être rentable ?
Il fonctionne un peu sur le principe des dons, donc à moins que les applications elles aussi soient payantes (ce qui serait un peu dommage étant donné qu'elles sont déjà financées par des dons, ça reviendrait à les faire payer deux fois.), on ne peut pas amener plus d'argent que besoin (sauf léger excédents de dons, mais c'est assez rare je pense)... à moins de réserver un pourcentage de la somme pour le fonctionnement du "machin" ^^

Deuxième petit point, l'obligation d'être pensé pour les handicapés est une très bonne chose, toutefois un certains nombre d'application ne pourront je pense malheureusement pas y répondre. Il en faut un maximum, je suis d'accord, mais 100% me paraît bien impossible. (d'ailleurs tout dépend des handicaps visés)

L'espace suivi de projet est une très bonne idée, de même que l'appli web pour cahier des charges et autres (tout cela me faisant fort penser à launchpad et à la possibilité de faire des dons sur le software center d'ubuntu, même si l'objectif est assez différent c'est vrai)

Pour les standards html/css, c'est pareil, plutôt que 100% respectueux des standards (même si ça peut être le cas), il faudrait vérifier qu'il soit compatible avec la plupart des navigateurs, qui eux même ne respectent pas toujours les standards à 100%. (On peut faire facilement un site répondant aux standards mais qui ne fonctionne nulle part ^^)

La charte debian est un peu lourde, il faudrait sans doute imaginer quelque chose de plus léger, de plus soft ^^

Pour gérer tout ça il faudrait un bon site/appli web où tout le monde pourrait se rejoindre, voter, voire même discuter, proposer etc...

Tu as déjà pensé à la plupart des détails qui me viennent tout de suite, si j'ai d'autres idées je les posterai.

Perso je veux bien participer, à ma moindre mesure de petit étudiant voulant devenir ingé en info ^^

Meilleurs vœux à toi aussi !

Dernière modification par darkevolution (Le 02/01/2011, à 22:18)

αjet · Le 03/01/2011, à 11:45

Salut darkevolution,

Tout d'abord, merci pour avoir pris le temps de lire mon post et pour tes commentaires. Je vais essayer de répondre le plus précisément possible.

darkevolution a écrit :

Déjà... comment le projets pourrait être rentable ?
Il fonctionne un peu sur le principe des dons, donc à moins que les applications elles aussi soient payantes (ce qui serait un peu dommage étant donné qu'elles sont déjà financées par des dons, ça reviendrait à les faire payer deux fois.), on ne peut pas amener plus d'argent que besoin (sauf léger excédents de dons, mais c'est assez rare je pense)... à moins de réserver un pourcentage de la somme pour le fonctionnement du "machin" ^^

Pour préciser ma pensée sur ce point là, je vais prendre un exemple pour expliquer la logique que je voudrais mettre en place.
Supposons qu'un groupe d'utilisateurs, qui pourraient être des particuliers, une association, une PME ou une combinaison de ceux-ci souhaitent un plug-in specifique pour une application libre existante, par exemple le client mail Evolution. Pour le moment, s'ils n'ont pas la compétence pour développer ce plug-in, ils n'ont que pour seuls choix de soumettre l'idée à l'équipe de développement de Evolution et à espérer que l'idée soit prise en compte ou de mandater une société de développement.

Ce que je compte mettre en place, c'est un système permettant à des personnes de de soumettre à des développeurs des projets qu'ils pourront mener à bien. En fonction de la complexité du projet et du temps de développement à y consacrer, il faudra calculer un montant permettant de retribuer honnêtement l'équipe de développement. Supposons que en comptant les charges, une journée d'un développeur coûte 100€ (on parle ici d'un étudiant ayant peu d'expérience, qui par conséquent ne peut pas prétendre a des rémunérations élevées) et que le plug-in en question ne demande que 2 jours.personne de développement, il faut alors trouver 200€ pour financer ce projet.

Si on demande à un seul individu de financer le développement, alors le coût ne sera pas en adéquation avec la valeur ajoutée. Par contre s'il on a affaire à une PME de 20 postes ou à 20 individus, alors le coût par personne étant divisé par 20, le ratio coût/valeur ajoutée devient plus attractif.

Une fois développée, l'application devra être publiée sous licence GPL, il n'est donc pas question de charger une deuxième fois.
Le principal avantage pour les personnes qui financent le développement est d'obtenir exactement ce qu'ils ont exprimé dans un CdCF et la perenité de l'application developpée.
Pour le développeur, c'est une rémunération et la reconnaissance de l'expérience. Pour un étudiant comme toi, ça pourrait être par exemple des expériences professionnelles que tu pourras valoriser quand tu seras amené à chercher un emploi, ou encore mieux pour, par exemple, te mettre à ton compte.
Pour la communauté libre au sens large, c'est potentiellement l'enrichissement de l'offre d'applications au sens large.

Si on arrive à mener ce projet à bien c'est pour moi une preuve que le libre est une solution économiquement viable et pérenne.

darkevolution a écrit :

Deuxième petit point, l'obligation d'être pensé pour les handicapés est une très bonne chose, toutefois un certains nombre d'application ne pourront je pense malheureusement pas y répondre. Il en faut un maximum, je suis d'accord, mais 100% me paraît bien impossible. (d'ailleurs tout dépend des handicaps visés)

On est d'accord, suivant les cas, ça peut s'appliquer plus ou moins bien. Toutefois dans le cas du développement d'une appli web, je souhaite que je résultat soit suffisamment propre pour que le contenu et les menus soient accessible par des applications dédiées aux handicapés moteurs ou visuels par exemple. Pour une appli native, j'avoue que je ne m'y connais pas, mais j'aimerais que ce soit suffisamment modulaire pour que l'UI puisse se greffer dans un environnement adapté. Je suis d'accord, c'est vague mais il y a des idées à creuser.

darkevolution a écrit :

L'espace suivi de projet est une très bonne idée, de même que l'appli web pour cahier des charges et autres (tout cela me faisant fort penser à launchpad et à la possibilité de faire des dons sur le software center d'ubuntu, même si l'objectif est assez différent c'est vrai)

Bonne idée, je ne connais pas très bien launchpad. Je vais me renseigner pour savoir dans quel mesure il serait possible de l'utiliser dans ce contexte. Pour mettre en place ce projet, je souhaite réutiliser un maximum d'applications existantes, histoire de ne pas réinventer la roue...

darkevolution a écrit :

Pour les standards html/css, c'est pareil, plutôt que 100% respectueux des standards (même si ça peut être le cas), il faudrait vérifier qu'il soit compatible avec la plupart des navigateurs, qui eux même ne respectent pas toujours les standards à 100%. (On peut faire facilement un site répondant aux standards mais qui ne fonctionne nulle part ^^)

D'une manière générale, je veux que la charte de ce projet impose le respects des standards. Après à charge du demandeur d'ordre de spécifier en plus la compatibilité pour un/des navigateur(s) spécifique(s). Par contre je ne souhaite pas qu'une compatibilité pour IE se fasse au détriment du respect des standards, ce n'est pas acceptable!

darkevolution a écrit :

La charte debian est un peu lourde, il faudrait sans doute imaginer quelque chose de plus léger, de plus soft ^^

Je ne l'ai pas encore lue entièrement. C'est en cours. Certes c'est lourd mais c'est exigent et comporte beaucoup de bonnes idées. C'est en respectant cette charte que les devs de debian ont réussi à mettre en place une distro d'aussi bonne qualité. Ça doit être une source d'inspiration !

darkevolution a écrit :

Tu as déjà pensé à la plupart des détails qui me viennent tout de suite, si j'ai d'autres idées je les posterai.
Perso je veux bien participer, à ma moindre mesure de petit étudiant voulant devenir ingé en info ^^
Meilleurs vœux à toi aussi !

Merci pour ta première contribution. Si tu veux continuer, tu es le bienvenu .

En ce qui me concerne, en ce moment, je me documente sur ce qui est existant. La deuxieme etape sera de definir plus precisement ce projet et ses objectifs. Ensuite je me renseignerai sur la forme légale la plus adaptée. Toute aide est la bienvenue.

Je continuerai à poster au fur et à mesure de mes progrès en espérant que le projet prenne forme !

Le Farfadet Spatial · Le 03/01/2011, à 18:42

Salut à tous !

En passant :

alex63 a écrit :

Des paquets binaires devront être compilés pour au moins une distribution libre (par exemple Debian GNU/Linux, Arch Linux, *BSD, etc.). Des paquets pouvant également être porté pour d'autres distributions GNU/Linux telles que Ubuntu, Fedora ou OpenSUSE.

Les paquets binaires doivent être la charge des développeurs d'une distribution, pas des développeurs d'une application. Pour une application, la charge des développeurs c'est de mettre en place une procédure de compilation portable.

Maintenir un paquet pour une distribution, c'est toute une histoire : il faut s'assurer que les différentes dépendances sont présentes, dans des versions suffisante. À chaque nouvelle version de la distribution, il faut lancer des tests pour s'assurer que le paquet reste compatible. Le meilleur cadre pour réaliser cette tâche reste la distribution elle-même.

l'application devra être publiée sous licence GPL

Pourquoi se limiter à la seule GPL et ne pas s'ouvrir à toutes les licences libres ? Cela va interdire les contributions à des projets qui n'utilisent pas la GPL.

je ne connais pas très bien launchpad

Le problème de Launchpad dans ton cas, par exemple, c'est qu'il n'est conçu que pour utiliser Bazaar.

À bientôt.

Le Farfadet Spatial

Dernière modification par Le Farfadet Spatial (Le 03/01/2011, à 18:44)

darkevolution · Le 03/01/2011, à 19:14

Oui launchpad c'était un exemple, c'est pas utilisable dans notre cas (enfin, les projets pourront très bien être sur launchpad c'est un moyen assez simple de lancer une application, créer un ppa etc... je fais déjà ça avec mon logiciel)

Pour les paquets... on pourrait très bien imaginer de rémunérer, plus légèrement mais quand même, pour faire un paquet pour une distrib particulière. Il faudra alors pour un projet sans doute faire appel à plusieurs packagers différents (Par exemple moi je sais faire un paquet pour ubuntu qu'on peut mettre sur launchpad mais me demander un truc pour red-hat (rpm ?)... pas possible ^^)

L'avantage dans le cas où on fait les paquets nous même, c'est qu'on est certains que ça va pas prendre trois plombes, les devs des distributions font ça pour chaque release et aux grosses mises à jour, encore que je ne sais pas exactement comment ça fonctionne en interne, mais de toute façon, ils seront fait plus vite par les devs, ou des personnes en particulier plutôt que par les distributions directement

Pour les licences c'est vrai qu'il vaudrait mieux élargir un peu...

@alex63: IE de toute façon ne nous intéresse pas si nos projets sont pour des plateformes libres, lui ne l'étant pas... (mais mon message ne le visait pas, aussi bien firefox que les autres ont tous leurs petites particularités pas forcement 100% standards, mais bon, de toute façon c'est pour l'instant un détail !)

mydjey · Le 03/01/2011, à 19:25

Je trouve l'idée intéressante, pour tout dire on avait abordé brièvement le sujet dans une discussion avec louiz' (banni du forum depuis et renommé en bloublou ). Et la discussion de cet autre topic me conforte dans cette idée.

J'ai quelques remarques à propos de certains points mais, je n'ai pas le temps d'en écrire plus pour ce soir.

Dernière modification par mydjey (Le 03/01/2011, à 19:38)

Le Farfadet Spatial · Le 03/01/2011, à 20:38

Salut à tous !

darkevolution a écrit :

les devs des distributions font ça pour chaque release et aux grosses mises à jour, encore que je ne sais pas exactement comment ça fonctionne en interne

Ça dépend du fonctionnement interne de la distribution. Par exemple, sous Gentoo il suffit en gros de créer le paquet (ce qui est très rapide) et l'affaire est réglée (c'est l'avantage de tout faire par compilation). Sous Debian, il y a un long processus de validation, c'est d'ailleurs ce qui permet à cette distribution d'être aussi stable.

L'avantage dans le cas où on fait les paquets nous même, c'est qu'on est certains que ça va pas prendre trois plombes

C'est-à-dire que lorsque l'on fait des paquets soit-même, on passe outre le processus de la distribution. Avec les problèmes d'instabilité que cela peut poser. Surtout, l'expérience montre que ce n'est pas très pérenne : bien souvent, dans les projets qui prétendent faire eux-même leurs paquets, après la première euphorie, les paquets se mettent à accumuler du retard. Puis, les développeurs finissent par annoncer qu'ils ne maintiennent plus les paquets et qu'il faut s'adresser aux développeurs des diverses distributions. D'autant que l'on ne peut pas fournir de paquets pour toutes les distributions. Raison pour laquelle je conseille de plutôt mettre en place une procédure de compilation simple et portable, les utilitaires tels que CMake et SCons permettent de faire cela très efficacement.

Certes, un paquet peut permettre à un projet jeune de se faire connaître, mais si la procédure de compilation est bien faite, c'est à peine plus compliqué dans un tel cas de compiler le code soit même (et plus sûr).

Sponsoriser des développeurs de telle ou telle distribution pour réaliser un paquet dédié, en revanche, me semble une bonne idée.

À bientôt.

Le Farfadet Spatial

darkevolution · Le 03/01/2011, à 20:50

Le Farfadet Spatial a écrit :

Sponsoriser des développeurs de telle ou telle distribution pour réaliser un paquet dédié, en revanche, me semble une bonne idée.

Je pense que c'est une solution à retenir oui

Hedj-our · Le 03/01/2011, à 22:14

Un truc qui peut être utile aussi c'est de lister les programmes phare du libre et en manque de dev je pense particulièrement à Gimp.
Mais après cela peut être un choix aussi avoir un aspect aider au dev d'un logiciel existant et avoir une sorte de cagnotte à laquelle chacun pourrait contribuer un peu dans le but de réduire des frais bancaire ce qui permettrais de réduire la somme minimal de don pour que cela reste rentable, parce qu'un don de 2€ avec 1€ de frais bancaire pour l'obtenir ce n'est pas vraiment rentable (chiffre dit au hasard).
Avoir une adresse postale et si vous faites une association faire les démarche pour être reconnu d'utilité publique la gendarmerie et d'autre instance de l'état utilisant des logiciels libres cela devrait pouvoir s'obtenir.
Ou permettre de monter des projets de demande de subvention ceci étant chronophage à plusieurs mettre une plateforme pour se faire pourrait être utile.

magestik · Le 04/01/2011, à 23:16

Je passe vite fait pour dire que je trouve que c'est un bon projet, et je suis pret a aider (création du site, création de dépots deb/rpm, ...).

chopinhauer · Le 05/01/2011, à 00:29

L'idée est intéressante et des projets similaires ont déjà surgit : regarde par exemple CofundOS.

Malheureusement je suis assez pessimiste concernant la viabilité économique du projet, au moins aujourd'hui. De mon expérience moins de 1% d'utilisateurs d'une application libre sont disposés à payer[#], même quelque euro et les entreprises ont du mal à comprendre l'intérêt de payer pour quelque chose que leur concurrence pourra utiliser gratuitement.

Le moyens de payement ne sont pas forcement adaptés à ce type de projet non plus : PayPal devient très cher au-dessous de 5€ (plus de 10% de commission), tandis que MoneyBookers n'est pas très répandu. Le nouveau service Flattr semble assez prometteur, mais il n'est qu'au début.

[#] Pour mes développements j'ai du avoir reçu de l'ordre de 100€ en 3 mois pour 1000 utilisateurs quotidiens et 90k téléchargements.

darkevolution · Le 05/01/2011, à 11:29

C'est pas évident, c'est sûr, mais là c'est eux qui auraient une demande, ils savent pour quoi le don va être utilisé, c'est un peu différent que, comme donné plus haut comme exemple, si on fait un don à gimp, on sait pas où ça va réellement.

Pour le moyen de paiement faut voir...

jypaigue · Le 05/01/2011, à 13:00

Bonjour,

L'idée est évidement très bonne...

Deux questions :
- Une fois un programme créé, comment celui-ci sera t-il maintenu ? (correction de bugs à leurs découvertes notamment...)
- Quelle garanti possède celui qui investi dans un logiciel/fonctionnalité ? (délai de fabrication, qualité du logiciel final, etc...) C'est indispensable dans le monde professionnel.

En fait je vois mal comment ces problématiques peuvent être résolues simplement. Une équipe embauchée à plein temps dans le projet pourrait résoudre le problème. Sinon, je ne sais pas...

darkevolution · Le 05/01/2011, à 13:15

Bah, pour le problème des bugs... ça devrait être spécifié dans le contrat avec le dev.
Si le bug est une erreur de programmation, alors c'est à lui de le corriger dans la mesure du possible.
Si c'est une fonctionnalité qui manque, qui n'était pas prévue, faudra redemander un dev (beaucoup moins cher si c'est un petit truc qui manque...) pour corriger le problème.

Je pense pas que l'équipe qui s'occupera du projet aura le temps de traiter tous les bugs comme ça (sauf embauche à plein temps, mais là problème d'argent, je pense pas que ce soit le but)

Faudra creuser pour la garantie effectivement, bonne question !

mydjey · Le 05/01/2011, à 21:58

Mes quelques remarques :

alex63 a écrit :

Les applications devrons être développées pour des systèmes libres. Par exemple, des applications même libres développées pour un environnement fermé tel MS-Windows ou Apple OS ne seront pas soutenues par ce projet.

Ce point me semble en contradiction avec les principes d'interopérabilités du logiciel libre. Je pense que ce n'est pas une bonne idée. Heureusement que les devs de Firefox, Gimp etc... n'ont pas décidés de ne pas développer sur les plateformes proprio, je ne connaitrais peut-être même pas le libre.

alex63 a écrit :

j'aimerais que ce projets soit international.

Je pense que c'est indispensable qu'il soit au minimum disponible en langue anglaise.

--

Sinon, ma réflexion au départ était la suivante :

Il existe pléthore d'associations de défenses/promotions du logiciel libre, que ce soit au niveau régional, national, européen et même mondial.
FSF Europe, FSF france, FSF monde, Mozilla, les nombreux GULL locaux (plus d'une centaine en France), le CNLL, l'AFULL, l'APRIL, Framasoft...

Parmi tout ces acteurs un seul fait du code : Mozilla. Tout les autres ont comme rôle de promouvoir le logiciel libre.
C'est bien que du temps, de l'énergie et de l'argent soit investie pour ça, mais si derrière le code ne suit pas, promouvoir ne sert plus à rien.
Par exemple je trouve que ça aurait été plus utile d'investir dans du code que dans des campagnes comme celle-ci : http://badvista.fsf.org, ou celle-ci : http://en.windows7sins.org

Dernière modification par mydjey (Le 05/01/2011, à 22:01)

HP · Le 05/01/2011, à 22:55

mydjey a écrit :

Par exemple je trouve que ça aurait été plus utile d'investir dans du code que dans des campagnes comme celle-ci : http://badvista.fsf.org, ou celle-ci : http://en.windows7sins.org

Ça ne demande peut-être pas le même niveau de savoir-faire… ni le même investissement !

Le Farfadet Spatial · Le 05/01/2011, à 23:17

Salut à tous !

mydjey a écrit :

Ce point me semble en contradiction avec les principes d'interopérabilités du logiciel libre. Je pense que ce n'est pas une bonne idée.

Je ne suis pas loin de te rejoindre et je suis content que ce soit toi qui soit allé sur ce terrain (je me suis retenu de le faire).

De toute façon, il me semble important d'être indépendant du système (qui finira par devenir obsolète). Il est donc important d'utiliser des bibliothèques portables, de produire du code respectueux des standards et de mettre en place une méthode de construction du projet portable elle aussi. De plus, il est bien de s'assurer que le programme ne fait pas des hypothèses qui ne sont pas générales en s'assurant qu'il fonctionne sur différents systèmes. Du coup, il est bon de tester son code au moins sur GNU/Linux et *BSD, voir Hurd (OpenSolaris étant arrêté). Si ces principes sont respectés, le portage sur les autres dérivés d'Unix (y compris Mac OS X) et Microsoft Windows n'est généralement pas trop compliqué, surtout sous les dérivés d'Unix.

À bientôt.

Le Farfadet Spatial

jypaigue · Le 06/01/2011, à 00:30

Mouais, la portabilité d'un code est une contrainte de plus, qui dans certains cas peut être inutile ou très fastidieuse. Une contrainte de plus, c'est donc un peu plus de temps à passer pour ceux qui bosses dessus et c'est donc un peu plus couteux...

Ne serait-ce pas judicieux de laisser le choix du niveau de portabilité à ceux qui écriront le cahier des charges et qui donneront les sous ?

darkevolution a écrit :

Si le bug est une erreur de programmation, alors c'est à lui de le corriger dans la mesure du possible.

Ba si le contrat de celui qui a fait le programme est fini, non...

EDIT : En fait, il me semble qu'il serait préférable de laisser plus de choix à ceux qui écrivent les cahier des charges et qui payent : localisation, accessibilité, etc...

Dernière modification par jypaigue (Le 06/01/2011, à 01:36)

Tomzz · Le 06/01/2011, à 01:48

Bonsoir,

Le sujet m'intéresse énormément
Je marque la discussion le temps de bien réfléchir à une réponse.

Mais l'idée est dans l'air du temps, voir Mymajorcompany, sauf que là le retour sur investissement c'est l'obtention d'un outil adapté à son besoin.

darkevolution · Le 06/01/2011, à 15:04

jypaigue a écrit :

Mouais, la portabilité d'un code est une contrainte de plus, qui dans certains cas peut être inutile ou très fastidieuse. Une contrainte de plus, c'est donc un peu plus de temps à passer pour ceux qui bosses dessus et c'est donc un peu plus couteux...
Ne serait-ce pas judicieux de laisser le choix du niveau de portabilité à ceux qui écriront le cahier des charges et qui donneront les sous ?
darkevolution a écrit :
Si le bug est une erreur de programmation, alors c'est à lui de le corriger dans la mesure du possible.
Ba si le contrat de celui qui a fait le programme est fini, non...

EDIT : En fait, il me semble qu'il serait préférable de laisser plus de choix à ceux qui écrivent les cahier des charges et qui payent : localisation, accessibilité, etc...

Faut laisser du choix à ceux qui font le cahier des charges je suis bien d'accord.

Mais le but du contrat c'est d'avoir une appli qui fonctionne, s'il y laisse un bug, il a pas fini sa part du contrat... enfin c'est ma façon de voir les choses...

Le Farfadet Spatial · Le 06/01/2011, à 17:28

Salut à tous !

jypaigue a écrit :

Mouais, la portabilité d'un code est une contrainte de plus, qui dans certains cas peut être inutile ou très fastidieuse.

Généralement, réaliser du code portable, c'est produire du code qui respecte les normes et utiliser des bibliothèques portables ; c'est-à-dire, globalement, ne pas coder à la va comme je te pousse. L'expérience montre que les applications ont tendance à avoir une durée de vie supérieure aux systèmes et il est de toute façon dangereux d'être dépendant d'un compilateur ou d'un système, fussent-ils libres. Les seuls cas où une absence de compatibilité est réellement justifiable, c'est lorsque l'on touche à la programmation système, ainsi que quelque rares applications à très forte contraintes, que l'on trouve principalement dans l'embarqué.

Cela dit, ce n'est pas une découverte que la programmation consiste à faire avec des contraintes. Cependant, je suis surpris de voir des réticences à la portabilité chez des libristes, vu que respecter les standards et utiliser des bibliothèques appropriées est un principe largement diffusé dans le libre. En réalité, sans norme, interopérabilité et portabilité, le libre ne peut tout simplement pas exister. D'habitude, c'est plutôt ceux qui viennent du monde propriétaires qui sont tout surpris de voir leur code refuser de compiler parce qu'ils ont utilisé une bibliothèque non standard, alors qu'il existe un équivalent portable qui fait très bien la même chose.

À bientôt.

Le Farfadet Spatial

darkevolution · Le 06/01/2011, à 17:53

C'est clair que c'est une contrainte et une bonne, de toute façon le code ne peut réellement pas être indépendant de tout système, à moins que personne n'utilise de fichier temporaire (le fichier n'est pas au même endroit selon le système) et même si ce n'était pas le cas, il y a toujours la contrainte de l'architecture des dossiers, beaucoup de logiciels en dépendent beaucoup, y'a de toute façon des retouches à faire.

jypaigue · Le 06/01/2011, à 20:05

darkevolution a écrit :

Mais le but du contrat c'est d'avoir une appli qui fonctionne, s'il y laisse un bug, il a pas fini sa part du contrat... enfin c'est ma façon de voir les choses...

Bon, je n'insiste pas... De toute façon sa rentre dans la case "Garantie" que j'ai déjà cité...

Le Farfadet Spatial a écrit :

Généralement, réaliser du code portable, c'est produire du code qui respecte les normes et utiliser des bibliothèques portables ; c'est-à-dire, globalement, ne pas coder à la va comme je te pousse. L'expérience montre que les applications ont tendance à avoir une durée de vie supérieure aux systèmes et il est de toute façon dangereux d'être dépendant d'un compilateur ou d'un système, fussent-ils libres. Les seuls cas où une absence de compatibilité est réellement justifiable, c'est lorsque l'on touche à la programmation système, ainsi que quelque rares applications à très forte contraintes, que l'on trouve principalement dans l'embarqué.

Euuhh... Quand il s'agit d'ajouter une fonctionnalité ou de créer un plug-in pour un logiciel existant, on va pas s'amuser à faire plus portable que le logiciel lui même... C'est idiot mais bon... Et tu as aussi cité la programmation système et l'embarqué, qui sont deux domaines à ne surtout pas négliger.

Bref, je suis d'accord sur le principe. Mais il faut juste bien distinguer quand c'est nécessaire ou pas... Et il faut notamment définir jusqu'à quel point on veut la portabilité et séparer les différents cas de figures (ceux cités dessus, mais il y en surement d'autres...)

Et la portabilité ne se résume pas encore à ce que tu décris. Même si ça y tend...

Cela dit, ce n'est pas une découverte que la programmation consiste à faire avec des contraintes. Cependant, je suis surpris de voir des réticences à la portabilité chez des libristes, vu que respecter les standards et utiliser des bibliothèques appropriées est un principe largement diffusé dans le libre. En réalité, sans norme, interopérabilité et portabilité, le libre ne peut tout simplement pas exister. D'habitude, c'est plutôt ceux qui viennent du monde propriétaires qui sont tout surpris de voir leur code refuser de compiler parce qu'ils ont utilisé une bibliothèque non standard, alors qu'il existe un équivalent portable qui fait très bien la même chose.
À bientôt.

Waou ! J'ai beau me relire, mais je ne vois pas où tu as vu que j'étais réticent à la portabilité... Et bien sur qu'il y a toujours des contraintes, seulement ça sert à rien de s'en rajouter inutilement.

Le Farfadet Spatial · Le 06/01/2011, à 21:16

Salut à tous !

jypaigue a écrit :

Quand il s'agit d'ajouter une fonctionnalité ou de créer un plug-in pour un logiciel existant, on va pas s'amuser à faire plus portable que le logiciel lui même...

Non, bien sûr. Cela dit, s'il y a un intérêt à développer un plug-in pour un logiciel suffisant pour qu'il y ait du monde près à payer, il est à peu près certain qu'il va s'agir d'un logiciel portable (par exemple Firefox). Dans ce cas, de toute façon la structure est telle que le plug-in sera portable. De toute façon, oui, un plug-in doit rentrer dans le cadre du logiciel qu'il doit modifier.

tu as aussi cité la programmation système et l'embarqué, qui sont deux domaines à ne surtout pas négliger.

Je ne les néglige pas, mais cela reste néanmoins deux domaines minoritaires. D'ailleurs, il est intéressant de noter que la portabilité fait son chemin aussi dans l'embarqué, par exemple avec Qt Embeded.

Waou ! J'ai beau me relire, mais je ne vois pas où tu as vu que j'étais réticent à la portabilité... Et bien sur qu'il y a toujours des contraintes, seulement ça sert à rien de s'en rajouter inutilement.

Hé bien, tu dis que la portabilité peut-être une contrainte inutile, c'est bien une réticence. Appelle cela une réserve si tu préfères.

Mon point de vue, c'est que la portabilité, dans le cas des logiciels libres, est dans la grande majorité des cas, nécessaire. En effet, même en admettant que l'on refuse par principe les développements sur des systèmes propriétaires, l'hétérogénéité des plateformes est pour ainsi dire garantie. Pour peu que le projet suscite un minimum d'intérêt, il y aura des développeurs utilisant diverses distributions GNU/Linux – et, l'air de rien, les différences entre Archlinux et Debian, par exemple, sont fortes –, mais aussi sans doute certains utilisant *BSD. Rien que cela implique de ne pas faire n'importe quoi. Ensuite, il faut voir que la portabilité est aussi une garantie de pérennité, un point trop négligé dans le développement de logiciel. Enfin, généralement, ce n'est qu'une contrainte très légère, car cela signifie simplement sélectionner avec soin ses bibliothèques et s'assurer que le code produit est standard, ce qui fait de toute façon partie des bonnes pratiques de programmation.

Surtout que, de toute façon, les cas où il est justifié de faire du code non portable sont très rares. À l'opposé, les cas où la compatibilité est souhaitable sont très largement majoritaires. Des codes qui ne sont pas portables, je dois régulièrement en reprendre. C'est très désagréable et à chaque fois une source de temps perdu considérable. Le plus terrible, c'est qu'à chaque fois je finis par mettre en évidence que cela n'aurait pas pris plus de temps de faire quelque chose de portable au lancement du projet – par contre, quand on repasse derrière, le travail est extrêmement chronophage.

Donc, oui, mon intervention a un message : je voudrais que l'on se rende compte que ça ne prend pas plus de temps et que ce n'est pas plus compliqué de créer des codes portables dès le départ. En revanche, c'est très utile lorsque le projet commence à avoir une certaine durée de vie. Du coup, je suis très favorable lorsque l'on demande de la portabilité et, au contraire, lorsque j'entends dire que ça peut être une contrainte superflu, je fais remarquer que non seulement ce n'est pas vrai dans la très grande majorité des cas, mais en plus qu'elle est généralement nécessaire.

À bientôt.

Le Farfadet Spatial

Dernière modification par Le Farfadet Spatial (Le 06/01/2011, à 21:19)

jypaigue · Le 07/01/2011, à 17:39

Hé bien, tu dis que la portabilité peut-être une contrainte inutile, c'est bien une réticence. Appelle cela une réserve si tu préfères.

Tu vas essayer de me faire croire que c'est la même chose ? Et je ne suis même pas sur que le mot "réserve" soit bien approprié. Encore une fois, je demande juste qu'on fasse basiquement du cas par cas... Et d'imposer une certaine portabilité uniquement quand celà à un sens, même si ça arrive souvent.

Après, il y a des choses qui sont pour toi évidentes et qui le sont beaucoup moins pour moi : je liste

il y a un intérêt à développer un plug-in pour un logiciel suffisant pour qu'il y ait du monde près à payer, il est à peu près certain qu'il va s'agir d'un logiciel portable (par exemple Firefox).

Il pourra peut-être arrivé que non...

Je ne les néglige pas, mais cela reste néanmoins deux domaines minoritaires. D'ailleurs, il est intéressant de noter que la portabilité fait son chemin aussi dans l'embarqué, par exemple avec Qt Embeded.

Les smartphones ? On en vois de plus en plus quand même.

Tu as peut-être raison, mais je ne suis pas aussi bon devin que toi quant à la teneur des demandes qui seront faites.

même en admettant que l'on refuse par principe les développements sur des systèmes propriétaires

?

Enfin, généralement, ce n'est qu'une contrainte très légère, car cela signifie simplement sélectionner avec soin ses bibliothèques et s'assurer que le code produit est standard, ce qui fait de toute façon partie des bonnes pratiques de programmation.

Si ce que tu dis est vrai, je ne comprend vraiment pas pourquoi il y a autant de programmes qui ne sont "pas portables". Mais soit...

Surtout que, de toute façon, les cas où il est justifié de faire du code non portable sont très rares. À l'opposé, les cas où la compatibilité est souhaitable sont très largement majoritaires.

Encore une fois, si tu sais ce qui va être demandé, c'est très bien.

Du coup, je suis très favorable lorsque l'on demande de la portabilité et, au contraire, lorsque j'entends dire que ça peut être une contrainte superflu, je fais remarquer que non seulement ce n'est pas vrai dans la très grande majorité des cas, mais en plus qu'elle est généralement nécessaire.

Et bien, puisque tu n'as visiblement pas compris ce que je disais, je le répète, je demande juste que l'on distingue les différents cas... Si tu penses que les cas où le code devrait être portable sont largement majoritaires, et bien c'est très bien ! Tu fais des suppositions sur la répartition des différents cas, je demande juste qu'on les distingues...

EDIT : Bon, je crois que je vais personnellement arrêter là pour cette histoire de portabilité, c'est un débat qui n'a même pas lieux d'être, ou s'il devait avoir lieux, ce serait un détail. Il y a des questions autrement plus importantes à résoudre...

Dernière modification par jypaigue (Le 07/01/2011, à 17:46)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/01/2011, à 13:31

Remuneration de developpeurs libres

#2 Le 02/01/2011, à 22:16

Re : Remuneration de developpeurs libres

#3 Le 03/01/2011, à 11:45

Re : Remuneration de developpeurs libres

#4 Le 03/01/2011, à 18:42

Re : Remuneration de developpeurs libres

#5 Le 03/01/2011, à 19:14

Re : Remuneration de developpeurs libres

#6 Le 03/01/2011, à 19:25

Re : Remuneration de developpeurs libres

#7 Le 03/01/2011, à 20:38

Re : Remuneration de developpeurs libres

#8 Le 03/01/2011, à 20:50

Re : Remuneration de developpeurs libres

#9 Le 03/01/2011, à 22:14

Re : Remuneration de developpeurs libres

#10 Le 04/01/2011, à 23:16

Re : Remuneration de developpeurs libres

#11 Le 05/01/2011, à 00:29

Re : Remuneration de developpeurs libres

#12 Le 05/01/2011, à 11:29

Re : Remuneration de developpeurs libres

#13 Le 05/01/2011, à 13:00

Re : Remuneration de developpeurs libres

#14 Le 05/01/2011, à 13:15

Re : Remuneration de developpeurs libres

#15 Le 05/01/2011, à 21:58

Re : Remuneration de developpeurs libres

#16 Le 05/01/2011, à 22:55

Re : Remuneration de developpeurs libres

#17 Le 05/01/2011, à 23:17

Re : Remuneration de developpeurs libres

#18 Le 06/01/2011, à 00:30

Re : Remuneration de developpeurs libres

#19 Le 06/01/2011, à 01:48

Re : Remuneration de developpeurs libres

#20 Le 06/01/2011, à 15:04

Re : Remuneration de developpeurs libres

#21 Le 06/01/2011, à 17:28

Re : Remuneration de developpeurs libres

#22 Le 06/01/2011, à 17:53

Re : Remuneration de developpeurs libres

#23 Le 06/01/2011, à 20:05

Re : Remuneration de developpeurs libres

#24 Le 06/01/2011, à 21:16

Re : Remuneration de developpeurs libres

#25 Le 07/01/2011, à 17:39

Re : Remuneration de developpeurs libres

Pied de page des forums