Sommaire
- Avant-propos
- Introduction
- Rappel : produire du libre a un coût
- Intérêts de produire du code libre ou de contribuer…
- Intérêt de produire du code propriétaire
- Conclusion
Avant-propos
Ce journal est un partage d'expérience dont l'objectif est d'illustrer l'intérêt, même pour une petite société (ma société algoo, actuellement c'est 3 personnes en CDI, 1 CDD, 1 stagiaire) de produire du code libre et de contribuer au logiciel libre. Mais aussi pourquoi il est important de produire également du code propriétaire.
Introduction
Les lecteurs assidus de LinuxFR savent peut-être que j'ai créé une entreprise il y a désormais un peu plus d'un an.
Pour comprendre la suite de l'article, il faut juste savoir que le métier d'algoo (ma société) est :
- de commercialiser le logiciel libre de partage/diffusion de connaissances Tracim
- de développer sur mesure des applications web, des API REST et d'intégrer des services distants
- d'intervenir sur des missions d'architecture ou des développements spécifiques backend/python
Algoo contribue au logiciel libre et produit autant de code libre que possible.
Pour résumer et reprendre les mots d'un personnage controversé de LinuxFR : "le logiciel libre est un moyen, pas une finalité".
Rappel : produire du libre a un coût
Donc Algoo produit du code libre. Et contribue aussi. Il faut bien comprendre que produire du code, remonter des bugs, etc, c'est bien gentil, mais cela a un coût.
Prenons un exemple simple : un ingénieur payé 36 456€ pour un contrat annuel 217 jours (c'est pas légal, car pour avoir un forfait jours il y a un niveau de rémunération minimum imposé par la convention Syntec. J'invite ceux d'entre vous qui gagnent moins de 40K€ et qui ont un contrat 217 ou 218 jours à lire leur convention collective).
Cet ingénieur travaille 1519h par an, il sera donc payé 24€ brut par heure de travail. A la louche, le coût du salaire est pour l'entreprise 36€/H. A cela on ajoutera les frais fixes : location de bureau, matériel, frais administratifs, etc.
Bref, produire du libre a un coût : le même que de produire du code propriétaire.
Rappel : aucune entreprise n'est philanthrope. Le but est d'une manière ou d'une autre de gagner de l'argent. Pas forcément "gagner le maximum d'argent possible", mais en gagner tout de même.
Donc si on produit du libre, il faut que ça en vaille le coup/coût. C'est le cas, et voici pourquoi.
Intérêts de produire du code libre ou de contribuer…
Marketing et visibilité
Si vous avez déjà passé des entretiens pour des postes de développeur, on a sûrement dû vous demander de montrer du code que vous auriez écrit. L'idée, c'est d'avoir une idée de ce qu'écrit le candidat, mais aussi de s'appuyer sur ce genre de contenu pour échanger sur les problématiques techniques. Ca n'est pas un problème d'écrire du code moche, du moment que ça peut se justifier (délais, prototype, etc).
Dans le cas d'une boîte, c'est un peu différent. Peu de clients vont venir discuter de code avec moi. Ceci étant dit, les clients techniques intéressés pourront aller chercher l'info et voir ce qu'on produit.
Cela apporte de la visibilité également, tant d'un point de vue prospection / image de marque en ligne, que d'un point de vue recrutement.
Ce sera également un argument commercial, genre "on partage certains développements, en contrepartie on bénéficie des développements d'autres sociétés". Bref, le discours classique qui prouve l'intérêt du logiciel libre et de la mutualisation des coûts de développement / maintenance entre confrères.
Produire du logiciel libre a un coût, c'est donc également un argument de qualité. Si on participe à des projets libres, c'est qu'on investit sur ces projets, et en général, l'investissement sur le code est lié à la qualité et au sérieux des prestations qu'on va fournir.
Si on vend des prestations de qualité médiocre, on va simplement exploiter le logiciel libre, par exemple en utilisant un maximum de logiciels libres parce qu'on les considère gratuits. Ce genre de comportement est très courant, notamment dans les agences web qui font du e-commerce (dév. de boutiques basées sur Magento, par exemple). Toutes les agences web qui proposent ce genre de prestation ne font pas du mauvais travail, mais alors comment distinguer "bonne agence" et "mauvaise agence" ?
Nous, nous utilisons des briques libres, et nous investissons dessus. On a une stratégie long terme, donc si une brique doit évoluer, autant qu'elle évolue dans un sens qui nous intéresse. Et pour ça, rien de mieux que de contribuer. Et comme une société a en général une philosophie "unique" (on n'a pas 2 manières de penser antinomiques en même temps), si on vise le long-terme d'un côté (fournisseurs), on vise long-terme de l'autre (client). C'est un gage de confiance et de pérennité de la relation.
Qualité de code
On n'y pense pas forcément, mais produire du logiciel libre permet d'améliorer la qualité du code. D'une part, si on publie du code qui intéresse d'autres personnes, on pourra s'attendre à avoir des feedback, des remontées de bugs, des propositions de patch. Le code va devenir meilleur.
Mais c'est également un moyen de mieux coder en interne. Sachant qu'on développe également du code propriétaire, on ne publie pas tout notre code en libre. Donc on doit faire une séparation. Qui dit séparation, dit modularité et interface. Rendre du code modulaire est une bonne pratique ; qu'on ne met pas naturellement en pratique quand on produit du code sur un unique projet.
Un exemple concret : nous travaillons actuellement sur un projet sur lequel nous devons être capable d'associer codes postaux et villes. C'est le genre de fonctionnalité récurrente. Le fait de décider de publier cette partie du code en libre :
- nous force à bien modulariser nos développements
- nous permet de réutiliser le cas échéant ce module de manière simple.
C'est une factorisation "de fait" ; donc un bug corrigé pour l'un des projets qui l'utilisera sera immédiatement disponible pour un autre projet. On n'invente rien dans cette démarche ; simplement le fait de publier nous force à modulariser le code et c'est une bonne chose.
Note : cet argument fonctionne car on produit du code libre et du code propriétaire.
Ressources Humaines
C'est un fait : les développeurs aiment participer à des logiciels libres, même les développeurs non passionnés/engagés dans la démarche du logiciel libre.
Produire du logiciel libre est donc un argument attrayant pour recruter, d'autant plus que cela sera également une carte de visite pour le développeur pour le jour où il souhaitera quitter l'entreprise. Il faut être lucide : tant que les intérêts recruteur/salarié sont compatibles il n'y a pas de raison de quitter une entreprise ou de licencier un salarié. Mais une entreprise et un salarié n'ont jamais "le même projet de vie" ou simplement les possibilités / envies d'aller dans la même direction. La fin de la collaboration fait partie de la vie d'une entreprise comme de la vie d'un salarié ; si on gagne à avoir collaboré et qu'on peut se séparer en bons termes, pourquoi ne pas le faire ?
Le fait de contribuer est également dans un certain nombre de cas une nouvelle expérience pour les développeurs car beaucoup d'entre eux "n'osent pas" (ou n'ont jamais été invités à le faire). En les incitant à contribuer, on leur apporte une nouvelle corde à leur arc, un nouveau type d'expérience. C'est en général bien perçu, et c'est donc une raison de plus d'avoir un collaborateur satisfait.
Dans une petite structure un turnover important est compliqué à gérer, car recruter prend du temps et gérer des recrutements/départs est générateur de stress négatif (ce stress n'ayant pas de valeur ajoutée sur la production de l'entreprise). Donc avoir des collaborateurs satisfaits est une bonne idée.
Philosophie d'entreprise
Produire du code libre et contribuer est également fortement lié à la philosophie de l'entreprise. La plupart du temps, on pourrait avoir quasiment le même résultat sans "perdre" la moindre minute à contribuer. Lorsqu'on contribue, comme évoqué précédemment, c'est qu'on investit. On est dans une démarche long-terme ; si on agit ainsi avec les briques qu'on utilise, c'est parce qu'on a une philosophie long-terme, ce qui est également le cas avec nos clients.
On a une démarche type "d'inbound marketing" : on donne pour recevoir.
Fait intelligemment, c'est bénéfique. On ne contribue pas à tous les projets/briques qu'on utilise, mais quand on fait face à un problème, on contribue (remontée de bug, proposition de patch), parce qu'un correctif upstream sera plus facile à maintenir qu'un fork dans notre coin. Et si d'autres personnes en profitent, alors tant mieux.
Intérêt de produire du code propriétaire
Mais il ne faut pas se voiler la face. Ce qui nous fait gagner de l'argent, ce qui fait que nous sommes en mesure de se payer des salaires, ce n'est pas la production de code libre.
Produire du libre, contribuer est un moyen de gagner de l'argent, mais c'est un moyen indirect. Ce qu'on vend, ce sont des services et des développements propriétaires. Rarement des développements libres. Ca arrive, mais ça ne suffit pas pour vivre.
Sur Tracim, par exemple, on va gagner de l'argent en proposant des développements sur mesure, des co-développements, des prestations d'hébergement et de service.
Sur les développements spécifiques ou sur mesure, on va gagner de l'argent en vendant des jours/homme de développement. Le code produit sera en règle général propriétaire et deviendra la propriété de nos clients.
Mais honnêtement, quelle société gagne majoritairement sa vie en produisant du code libre ? Aucune. Les gros contributeurs tels que Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier et leurs algorithmes. Ils contribuent énormément, mais ils ne partagent pas leur avantage concurrenciel.
Alors vous allez me parler de Red Hat. Red Hat est LA référence des entreprises qui gagnent de l'argent en faisant du libre. Et ils ont des développeurs, et non des moindres. Mais leur R&D est une petite partie de la R&D sur laquelle ils capitalisent : tous les logiciels libres qu'ils intègrent dans leur distribution ne sont pas faits chez Red Hat.
Et par ailleurs, ils gagnent de l'argent avec des contrats de service. A ma connaissance ce qu'ils facturent, ce n'est pas du "temps de développement de logiciel libre" mais des contrats de maintenance (qui intègrent dans leurs coûts, de la R&D sur du libre) sur une distribution Linux fournie, complète et robuste.
Une petite entreprise a les même problématiques de rentabilité et d'avantage concurrentiel. Il faut se dévoiler pour être "sexy", mais on ne peut pas tout dévoiler parce que sinon on perd notre différence, notre avantage.
Donc voilà : on fait aussi du code propriétaire, mais finalement comme tout le monde. C'est ce qui nous permet de gagner notre vie ; et il n'y a pas de honte à gagner sa vie:)
Conclusion
Produire du code libre présente des avantages et des inconvénients. D'une manière générale quand on discute avec des gens il faut argumenter pour justifier la production de code libre. Chez Algoo, j'essaie d'insuffler une philosophie inverse : pourquoi produire du code propriétaire par défaut ? Lorsqu'on peut produire du libre et contribuer, et que ça n'a pas d'impact sur la survie de l'entreprise, on produit en libre.
Comme vu ci-dessus, il y a des cas où cela se justifie, et des cas où l'on ne peut pas se le permettre.
Le risque de publier n'est pas que notre code soit réutilisé par des individus indépendants, des associations qui n'ont pas d'argent, ou des entreprises qui seraient "réglo". Non, le risque c'est plutôt de financer de la R&D qui sera directement réutilisable/réutilisée par des concurrents directs et peu scrupuleux. Le monde de l'entreprise n'est pas un monde de bisounours.
On peut en discuter, je suis preneur de vos retours, remarques, questions.
# Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier
Posté par Tangi Colin . Évalué à 4.
Oui et non, google a jamais publié leur algo lié a leur moteur de recherche effectivement.
Mais si tu prend le cas de twitter par example, l'ensemble de leur backbone repose sur Mesos qui un projet libre et ils y contribuent énormément dessus. Ce qui a obligé Google à aussi libérer le sien (Kubernetes (ça fait bien 10 ans qu'ils ont la techno en interne et il le libère que maintenant face à la concurrence)).
Je pourrais parler de netflix aussi avec OSS (le code source de l'ensemble de leur SI basé sur Amazon).
Facebook publie aussi son matos sur opencompute.org.
Donc d'un point de vue code (je parle pas du sujet des données personnelles et des services qu'ils vendent dessus) les grosses boites font énormément de logiciel libre c'est devenue une guerre (marketing, recrutement, …) entre elles.
[^] # Re: Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 9.
C'est l'avantage concurrentiel de Google. C'est ça qu'ils ne publient pas.
C'est pas leur avantage concurrentiel. Facebook, son avantage concurentiel, c'est la base utilisateur. Twitter aussi. Pour Netflix, je sais pas trop, je connais pas assez.
Je pense que ces grosses boîtes, leur problème, c'est de recruter les meilleurs dév et d'avoir une forte influence "dans le mieux", c'est pour ça qu'ils publient du code source.
[^] # Re: Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier
Posté par Thomas Douillard . Évalué à 2.
Netflix le truc crucial c'est le catalogue évidemment (ama) : personne n'ira sur un service de VOD sur lequel il n'y a pas de contenu qui l'intéresse.
[^] # Re: Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier
Posté par djano . Évalué à 2.
Pour Kubernetes, Google a des technologies qui y ressemblent (Borg), et qui ont inspirées le design de Kubernetes. Par contre, j'écoute ce qu'ils disent dans les conférences et les articles, et Borg n'est pas la panacée: pleins de bugs, les déploiements ont des workaround dans tous les sens, … Kubernetes est une réécriture en open source en partant de zéro, et en a'appuyant sur l'expérience acquise avec Borg.
Ceci dit, à ta place j'aurais plutôt parlé de lmctfy qui est typiquement la technologie reversée en open source parce que LXC les menace.
Il y a aussi les "doubles-projets" tels que guava ou error-prone: ils ont deux repositories: un privé et un public (open source) et ils reversent régulièrement du repository privé vers le public, mais pas tout bien sûr et pas tout de suite.
Malgré tout ça, ils restent des contributeurs exceptionnels de par la quantité et la qualité de code libre qu'ils produisent.
# Société est trop général
Posté par feth . Évalué à 4.
Je pense que quand tu écris "société", tu penses "éditeur" -ça ne me semble pas du tout impossible de ne proposer que des développements en libre, à la carte : de plus en plus de marchés publics précisant que le logiciel produit sera libre.
Certains statuts de sociétés (la SCIC, précisément) sont à mon avis une piste pour développer un et un seul logiciel précis sous forme libre.
Peut-être passent-ils par là : est-ce que l'éditeur de logiciel libre cozycloud fait autre chose que du logiciel libre ?
[^] # Re: Société est trop général
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Je ne pense pas nécessairement éditeur, non.
Le fait de répondre à des marchés publics qui veulent du libre ne fait pas que ces seuls marchés sont suffisants pour vivre ni que c'est ta source principale de chiffre d'affaire.
Cozycloud est un bon exemple, est-ce que quelqu'un connaissant le type de vente faite par Cozy pourrait nous dire ce qu'ils vendent ? Des contrats de maintenance ? Du support ? Du développement de fonctionnalités ?
[^] # Re: Société est trop général
Posté par Bruno Michel (site web personnel) . Évalué à 9. Dernière modification le 26 mai 2016 à 22:56.
La réponse est sur https://cozy.io/fr/about/.
Globalement, nous vivons actuellement en partie des sous de la dernière levée de fonds et, pour le reste, des revenus via des contrats avec des grosses entreprises. Pour la suite, nous pensons surtout vendre des choses à des entreprises (grands comptes et hébergeurs), pas directement à nos utilisateurs. Pour les hébergeurs, c'est du support + des outils spécialisés pour héberger de nombreuses instances cozy. Pour les grands comptes, c'est une réflexion et du prototype d'apps cozy pour les services innovation qui veulent utiliser les données d'utilisateurs auxquelles ils n'auraient pas accès normalement. Mais on pourrait aussi imaginer des services pour les utilisateurs finaux (des boitiers cozy ou un service de sauvergarde chiffrée pour les auto-hébergés par exemple).
[^] # Re: Société est trop général
Posté par octane . Évalué à 5.
Il n'y a que moi que cette phrase choque? Un service "innovation" qui accède à des données "auxquelles ils n'auraient pas accès normalement"?
Si je met ma carte bleue, ou mes contacts, ou mon fichier privé aquaponey_2.avi, les grands comptes innovants vont y avoir accès?
[^] # Re: Société est trop général
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Je me suis mal exprimé. Non, l'entreprise ne va pas accéder directement aux données. Elle va juste pouvoir les utiliser dans le cadre du Cozy.
Avec un exemple, ce sera plus clair. EDF n'a pas accès aux données de Nest. Par contre, l'utilisateur est tout à fait légitime pour avoir les données de Nest sur son Cozy et il peut aussi faire tourner sur son Cozy une application EDF. Cette application pourra accéder ainsi accéder aux données de Nest pour, disons, proposer un contrat plus adapté à l'utilisateur. Les données vont rester sur le cozy, sous le contrôle de l'utilisateur, sur son serveur, pas celui d'EDF. Elles ne vont jamais remonter jusqu'à EDF.
Le principe de Cozy cloud est de pouvoir reprendre le contrôle de ses données et de pouvoir ainsi les faire interagir.
# [HS] Quel saut
Posté par Zenitram (site web personnel) . Évalué à 5.
Tu le dis toi même, 4 personnes c'est plus de 200k par an.
en un an… je suis jaloux (perso je pense que je ne suis pas assez doué pour pouvoir faire la même chose, ca me rend d'autant plus jaloux voire envieux)
[^] # Re: [HS] Quel saut
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Tu passes trop de temps du DLFP ;-)
[^] # Re: [HS] Quel saut
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
On n'est pas encore 4 à plein temps :)
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: En gros
Posté par mh-cbon . Évalué à -10.
j'en pleure devant mon pc tellement c'est beau d'innocence
# Au siècle dernier ...
Posté par Christophe B. (site web personnel) . Évalué à 10.
Au siècle dernier, dans les années 90 (Alzheimer quand tu nous tiens … ) une petite société française éditait un produit de gestion commerciale, basé sur un langage développé en interne.
Et le produit de gestion commerciale était livré avec ses sources, libre à nous de modifier, d'améliorer ou même d'adapter en fonctions des besoins spécifiques du client final.
Honnêtement à l'époque, nous nous sommes éclatés car on pouvait corriger les bugs qui nous pourrissaient la vie, je me souviens même d'avoir envoyé des corrections par fax, internet n'existait pas encore.
Et voici ce qu'il en est ressorti :
Un gros c.. (je trouve pas d'autre mot désolé) a pris le produit, a modifié le package et revendu tel quel … procès toussa fermeture définitive de la boîte du gros c..
beaucoup de temps et d'argent perdu
Des modifications effectuées par des informaticiens de formation saucisson/paté rendait le produit instable, et cela véhiculait une très mauvaise pub pour le produit.
( un client content peut en faire venir 3 autres, un client mécontent en fait fuir 10 )
Les nouvelles versions devenait inapplicable, en fonction du niveau de modification et difficile de faire migrer le client.
Il y a avait aussi une certaine condescendance des développeurs qui malgré l'envoie des corrections, n'effectuait pas les modifications nécessaires et laissait les bugs traîner.
Au final l’éditeur à pris peur et n'a plus fourni les sources, mais le produit a perdu en fonctionnalité et adaptabilité.
Finalement un consensus a fini par être inventé à l'époque :
- le point d'entrée : la possibilité d'intervenir sur un déroulement avant certaine action importante.
- La formation des développeurs, seule les distributeurs certifiés et ayant suivit une formation pouvaient utiliser les points d'entrées, notion de centre de compétences.
Cette technique est encore utilisée sur les versions récentes du produit issus de la gestion commerciale, qui est devenu entre temps un ERP.
Encore un fois, cela prouve que les gens honnête, de bonne foi et compétent subissent des restrictions à cause de la malhonnêteté et de incompétence de certains.
Dans le monde de l'entreprise, le tout libre est quasi impossible et le tout propriétaire une erreur.
La solution est un compromis à mettre au point avec les personnes vraiment concernées et capables
Car tout le monde peut y gagner en formant une communauté Editeur/Distributeur/utilisateurs
[^] # Re: Au siècle dernier ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Je pense que tu voulais dire "à l'époque, internet n'existait pas encore dans notre boite". Parce que techniquement dans les années 90, Internet existait. (oui je chipote)
Le premier réseau (celui de l'INRIA) raccordé à internet en france, c'est en 1988. Dans la foulée quelques centres de recherche, puis les universités vers 1993 grâce au réseau Renater (j'ai pu en profiter en 1994 quand je suis entré à l'IUT d'Orsay :-)). Ensuite les premiers FAI grand public vers 1994 (sans oublier French Data Network en 1992).
[^] # Re: Au siècle dernier ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Oui tu chipotes :)
Honnêtement, internet pour moi c'est 1995 - 96
J'avais dans l'ordre essayé MSN le réseau de Microsoft (comme quoi c'est pas nouveau leurs cochonneries … ), qui n'a jamais marché et en plus il m'a fallu des mois pour récupérer mon pognon.
Puis COMPUSERVE car il permettait un pont vers internet, mais en fait le réseau COMPUSERVE était super intéressant avec des forums de qualité, dommage que cela ait disparu.
Mais bon à l'époque tu payais les communications … et les modems faisait du bruit …
[^] # Re: Au siècle dernier ...
Posté par bobble bubble . Évalué à 1.
arf, la nostalgie c'est plus ce que c'était, même si on paie toujours nos communications et même si nos modems font toujours du bruit
[^] # Re: Au siècle dernier ...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
101355.2112[^] # Re: Ausiècledernier ...
Posté par Juke (site web personnel) . Évalué à 2.
C'est triste ton avis sur le saucisson.
[^] # Re: Ausiècledernier ...
Posté par Christophe B. (site web personnel) . Évalué à 6.
Désolé, pour être franc l'expression exacte que j'utilise habituellement est:
informaticien option boucherie/charcuterie.
Quand tu le dis, cela passe.
Mais quand tu l'écris sur un forum, c'est pas sympa pour nos camarades boucher/charcutier.
Alors dans l'urgence de la situation et le feu de l'action, j'ai écris saucisson/pâté.
Et je peu te garantir que : aucune charcuterie n'a été maltraitée, ni blessée durant le tournage.
# Et la vente de code libre à ses clients ?
Posté par Yakulu . Évalué à 3.
Si je comprends bien, vous avez des clients qui veulent que vous travailliez sur du spécifique et qui vous demandent explicitement que le code produit soit leur seule propriété et qu'il ne soit pas placé sous licence libre ?
Je ne pense pas que la production de code propriétaire soit obligatoire, car même si certains clients le souhaitent, rien n'empêche de produire du code libre spécifique qui ne sera pas réutilisé ou divulgué en l'état ensuite (bien que de fait on ne peut pas garantir au client que le code ne sera pas publiquement divulgué, puisque la licence le permet).
Je pense par exemple aux milliers d'intégrateurs de solutions type ERP en AGPL, comme pour Odoo avant la version 9.
Bon après, il faut que les sociétés éditrices de code respectent les licences, mais c'est une autre histoire.
[^] # Re: Et la vente de code libre à ses clients ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Si je comprends bien, vous avez des clients qui veulent que vous travailliez sur du spécifique et qui vous demandent explicitement que le code produit soit leur seule propriété et qu'il ne soit pas placé sous licence libre ?
C'est pas aussi marqué que ça. Par défaut, les clients demandent en général le transfert de propriété intellectuelle. Dans ces conditions, ils sont propriétaire du code et en font ce qu'ils veulent (licence, pas licence, etc). Quand on travaille sur des sujets qui ont clairement un intérêt à être réutilisé on discute sur le fait de publier une partie, mais souvent, c'est des développements tellement spécifiques que ça ne vaut même pas la peine de discuter du sujet : on ne pourra pas réutiliser, le client ne verra pas l'utilité, donc ça ne peut que brouiller les cartes.
Oui, dans ce cas produire du libre spécifique a du sens.
# Un parallèle...
Posté par aurel . Évalué à 3.
… à faire avec cet article (en anglais).
[^] # Re: Un parallèle...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Le titre est un peu racoleur mais l'article intéressant. Plusieurs points en communs avec ce que je dis, mais également d'autres aspects liés aux développeurs.
Je trouve le titre "Pourquoi les meilleures entreprises et développeurs donnent presque tout ce qu'ils font" raccoleur parce que les entreprises ne donnent pas "presque tout ce qu'elles font", même à leurs concurrents comme le dit l'auteur.
Même en terme de code tout n'est pas publié, loin de là. Ce qui est publié c'est ce qui est réutilisable, et un des intérêts est effectivement d'avoir de la QA, du développement "gratuits".
On pense souvent au code en terme de "logiciel avec ses fonctionnalités", mais de grosses boîtes comme Google, Facebook et autres ont aussi énormément de code lié au déploiement, à l'infrastructure, aux outils internes. Ces développements-là restent souvent fermés (et ça ne me choque pas).
# moi, ça me laisse pensif
Posté par mh-cbon . Évalué à -8.
Le truc c'est que tu te bats pour des idées dans un environnement qui n'en a que peu à foutre.
Tu es tout le temps tiraillé entre tes obligations de chef d'entreprise et tes désirs de citoyens participatif intelligent.
Alors la question que j'ai envie de poser est la suivante, en tant que personne responsable et réfléchie, penses tu qu'il vaille mieux se battre corps et âmes pour une idée dans un combat à l'effet marginal (selon moi hein), ou bien faut il re penser la question pour s'attaquer à la difficulté de fond afin de faire établir ces idées comme principe ?
[^] # Re: moi, ça me laisse pensif
Posté par GuieA_7 (site web personnel) . Évalué à 2.
C'est à dire ? Faire voter une loi pour obliger les gens à ne faire que du logiciel libre ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 13 juin 2016 à 21:40.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: moi, ça me laisse pensif
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Je n'ai absolument rien proposé de tel (je ne suis pas pour), je demandais des précisions sur un commentaire bien vague.
Alors c'est bon tu peux te détendre et aller chasser les crypto-communiste plus loin :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 13 juin 2016 à 23:41.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: moi, ça me laisse pensif
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Oui entièrement d'accord avec ça ; difficile de ne pas être d'accord en même temps.
Toi aussi tu veux forcer des choses ; je suis sûr que des tas de gens (très influents) vont qualifier ta proposition de dictature. C'est très relatif tout ça.
L'histoire (et les cartes graphiques) a montré que même avec les spécifications, il est parfois très difficile de développer des drivers. Et puis la frontière entre hardware et software n'est pas toujours évidente. Le diable se cache dans les détails.
Qui va décider que ce sont des bugs ? Si à chaque fois il faut une actions en justice, le code source sera libéré 15 ans trop tard (comme la sélection du navigateur dans Windows). Et forcer un logiciel développé par une entreprise étrangère qui a coulée risque d'être très complexe aussi par exemple.
Conclusion, il ne 'suffit' pas, tout ceci est très complexe (ex: il suffit de réduire le chômage, il suffit de relancer la croissance…).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
# Expérience qui diffère : on peut vivre du libre à 100% !
Posté par Vincent P (site web personnel) . Évalué à 5.
Salut,
Je ne sais pas bien dans quel contexte tu travailles, mais je n'ai pas la même avis. Il est tout à fait possible de vivre (très) correctement en ne faisant que du développement OpenSource.
Mon expérience, que je retrouve dans pas mal d'autres structures similaires, diffère complètement.
Ces structures sont largement sollicitées pour développer du code source dans le cœur de logiciels. Que ce soit pour des organismes publics ou pour des organismes privés. Et parfois on a même dans les contrats ( écrits par le client) une prime si c'est bien reversé upstream, pour garantir la pérennité et la qualité des dévs.
Dans ce contexte, la contractualisation suit le droit des contrats, c'est à dire que le développeur garde le droit d'auteur et le donneur d'ordre ( et financeur ) bénéficie des droits patrimoniaux sur le code développé. Par contre on y ajoute une clause pour que tout le code source produit soit sous licence libre.
Pour une commande donnée, on va essayer de séparer ce qui est générique du spécifique. Pour le code générique, on commite directement sur les composants upstream ( ou on crée un produit libre). Pour le spécifique, on garde la clause de licence opensource, par contre le résultat n'est pas forcément toujours distribué. Mais on peut s'en resservir si on veut, au moins en interne, et dès lors qu'on s'en ressert on améliore la généricité et on va vers la publication.
Quand un client demande fermement un outil propriétaire, le crédo est souvent de refuser tout simplement, ou alors accepter à des tarifs qui sont complètement prohibitifs ( qui en gros permettraient de redévelopper le tout en opensource dans un second temps…).
Ensuite ces structures vendent du service, et la marge permet de faire du financement de R&D sur des aspects plus prospectifs.
Globalement le marché français sur l'OpenSource est assez mature, et les clients comprennent bien les enjeux socio-économiques liés au libre, et savent que c'est dans leur intérêt de reverser.
Et en ce moment, il y a plutôt un déficit de développeurs OpenSource compétents qu'une crise économique dans l'écosystème que je peux cotoyer. Rappelons que le marché Français IT a toujours eu au moins 10% de croissance au plus fort de la crise, que le marché OpenSource c'est entre 10 et 30% et que certains domaines ( SIG pour ne pas les citer) sont également dans le haut de ces chiffres.
D'autres part, on voit apparaître de nouveaux acteurs, qui sont plutot orientés SaaS et éditeurs, et qui font de très fortes contributions libres. Leur plateforme ne l'est souvent pas ( scripts d'intégration, archi..), mais toutes les composants ou presque le sont. On peut citer CartoDB ou MapBox dans le domaine carto. Ils démontrent qu'on peut tout à fait faire de grosses contributions en libre tout en étant dans un modèle économique de startup champignon ( cf les séries de levées de fond des pré-cités).
Donc l'obligation de faire du logiciel propriétaire, je ne suis pas d'accord. C'est une question de positionnement principalement. Ça ne me dérange d'ailleurs pas outre mesure si c'est un choix, mais je trouve dommage que ce soit une position subie.
[^] # Re: Expérience qui diffère : on peut vivre du libre à 100% !
Posté par Nairwolf . Évalué à 5.
Je suis encore étudiant, c'est possible de savoir où tu travailles ? Je suis étonné quand tu dis que le marché français sur l'OpenSource est assez mature, car je n'ai pas l'impression qu'il y ait autant d'entreprises ou de clients qui souhaitent voir du libre. Je pensais que ça restait encore un peu confidentiel.
Si ce que tu dis est vrai, c'est super, les mentalités changent. Mais ça met l'eau à la bouche. C'est possible de savoir pour quel type de clients tu travailles ? Est-ce que c'est du web, de l'embarqué, ou autre ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Expérience qui diffère : on peut vivre du libre à 100% !
Posté par Nairwolf . Évalué à 1.
Tu ne t'es pas trompé de fil parent ? J'étais aussi sceptique sur le déficit de développeur "Open Source".
[^] # Re: Expérience qui diffère : on peut vivre du libre à 100% !
Posté par MCMic (site web personnel) . Évalué à 3.
Oui, même chose, franchement écrire un truc pareil sur linuxfr:
C’est ridicule. Je travaille chez OpenSides ça se porte très bien, merci.
À ce que j’ai lu on fait le même genre de choses que vous mais en libre.
On fait ça sous licence libre sur FusionDirectory et ça marche pareil.
Notre avantage c’est qu’on est bon dans ce qu’on fait, et qu’on connaît la base de code, les clients n’ont pas de raisons d’aller voir ailleurs. Et on est l’upstream (pour FusionDirectory) donc plus pérenne a priori.
Comme expliqué par RyDroid plus bas ce raisonnement peut excuser tout et n’importe quoi. Faut arrêter de croire qu’être payé à faire quelque chose vous enlève toute responsabilité, on est responsable de ses actions.
Donc si, moi je trouve ça honteux de développer du logiciel non-libre. Si toi non, c’est pas grave, mais ça n’a rien à voir avec le fait d’être payé ou pas.
# Honte à gagner sa vie
Posté par RyDroid . Évalué à 2.
Et pourquoi pas ? Si ton travail consiste à tuer des innocents, même s'il était légal, ne devrais tu pas avoir honte malgré qu'il te permette de "gagner ta vie" ? Il me semble que Stallman dans une interview avec quelqu'un de openSUSE il me semble (mais impossible de retrouver la vidéo), comparer le créateur de logiciel propriétaire à un voleur dans le sens que ces 2 activités sont pour lui nuisibles, il en concluait donc que "gagner sa vie" n'était aucunement une excuse valable pour lui pour faire du logiciel propriétaire, ce qui énervait celui qui faisait l'interview.
[^] # Re: Honte à gagner sa vie
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Pourquoi il n'y a pas de honte à gagner sa vie en faisant du code propriétaire ? Parce que je ne prend rien à personne : nous signons un contrat qui satisfait toutes les parties impliquées, n'en déplaise à Stallman (qui n'est pas concerné par les accords que je signe avec des clients).
[^] # Re: Honte à gagner sa vie
Posté par RyDroid . Évalué à 1.
Ma remarque était générale. Dans ton cas, il me semble que tu fais du logiciel libre et du logiciel privé, ce qui ne dérange pas Stallman. https://www.gnu.org/philosophy/categories.fr.html#PrivateSoftware
[^] # Re: Honte à gagner sa vie
Posté par Nairwolf . Évalué à 0.
Il y a quand même une différence énorme entre tuer des gens, et écrire du code propriétaire. Même si ce n'est pas du code propriétaire privé. Rien n'oblige les gens à utiliser du code propriétaire à ce que je crois, n'est-ce pas ?
[^] # Re: Honte à gagner sa vie
Posté par EauFroide . Évalué à 1.
Avoir moins de 40 ans et ne pas avoir de téléphone portable est-il possible sans passer pour un clochard? Ça existe un téléphone portable qui n'utilise que du libre?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Honte à gagner sa vie
Posté par RyDroid . Évalué à 1.
J'ai 21 ans, mon ordinateur de poche qui peut faire téléphone a rarement de carte SIM et le reste du temps il est presque exclusivement en mode avion, les gens que je côtoie souvent finissent par s'y habituer, j'ai l'impression qu'il me considère plus comme un mec étrange ou un hyper-privacy warrior que comme un clochard. Aucun ordinateur avec une fonction téléphone ne fonctionne sans logiciel privateur à ma connaissance.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.