pt
Moulé à la louche depuis 1999
Les trucs qui m'énervent... et je vais pas prendre de pincettes
Internet, informatique, logiciel libre, économie, politique, vie courante et tout le reste...

Petits cons

Mardi 08 avril 2008

Putain, y'a vraiment de ces petits cons. Ça me donne envie de baffer.

:-) Opensource et payant

Mardi 08 avril 2008

Sur un forum, un internaute s'est posé la question de l'intérêt pour une entreprise de participer à un projet opensource. Voici ce que je lui ai répondu:


Des développeurs payés

« Le problème que je vois, c'est que généralement, créer des logiciels libres tiens plus du bénévolat, que de l'activité rémunéré »

C'est une erreur.
En fait, une bonne partie des développeurs de projets opensouce sont payés.
Par exemple, Sun paie des développeurs pour travailler à temps plein sur OpenOffice.org et Java.
Apple paie des développeurs pour travailler sur CUPS (le système d'impression de Linux).
La fondation Mozilla paie des développeurs pour travailler sur Firefox, Thunderbird.
La fondation Apache paie des développeurs pour travailler sur Apache, Tomcat...
etc.

Sans parler de sociétés comme RedHat qui basent tout leur business sur de l'opensource et paient donc des gens à temps plein sur différents projets (dont les sources sont en grande partie reversés).

Et ce phénomène de répand de plus en plus.


3 modèles de développement

« Si tous les logiciels étaient libres, pensez-vous que vous seriez en mesure d'avoir un travail rémunéré? »

Sans problème.

Malgré tout ce qui existe comme logiciels dans le monde opensource, les entreprises ont toujours des besoins spécifiques et paieront toujours des gens pour le faire.

Prenons 3 scénarios:

  1. L'entreprise fait développer (par ses employés) un logiciel adapté from scratch.

  2. L'entreprise fait appel à de la prestation pour faire faire un progiciel (propriétaire et fermé).

  3. L'entreprise prend un logiciel opensource existante et l'adapte à ses besoins (en payant ses employés pour le faire, ou en prestation).

Le cas 1) était très courant, mais non seulement ça prend du temps, mais en plus c'est coûteux. Et ça oblige à avoir une grosse équipe d'informaticiens.

Le cas 2) est également très courant, et allège l'entreprise du boulot d'analyse, développement, tests, maintenance, déploiement... et ne nécessite qu'une équipe réduite d'informaticiens. Mais les SSII font payer ce genre de service très cher.

Le cas 3) ?
Le coût du logiciel de base est nul. Le développement est moins couteux, puisque qu'il ne s'agit pas de refaire un logiciel complet, mais juste d'adapter un logiciel existant (voir juste de le configurer !).
L'adaptation peut se faire avec des employés en interne, ou en prestation.
Avec un développement interne, pas de support technique ou de boite externe à payer dans la plupart des cas. Et on peut obtenir du support professionel pour pratiquement n'importe quel logiciel opensource en cas de besoin: il suffit de payer une SSLL (Société de Service en Logiciel Libre).


Redistribution des sources

Pourquoi l'entreprise reverserait les sources ?

  • Comme le logiciel ne lui aura pas coûté grand chose (par rapport aux solution 1 ou 2), le fait de reverser le sources modifiés n'est pas un problème majeur.

  • C'est excellent pour l'image de marque de l'entreprise (il suffit de voir IBM)

  • En fait, les améliorations du logiciel peuvent attirer encore plus de monde sur le projet, et donc attirer des développeurs qui amélioreront encore l'application. En sponsorisant un projet opensource (même juste en reversant du code), l'entreprise pourra bénéficier des améliorations apportées au logiciel par les développeurs bénévoles: C'est encore un bénéfice.

  • En prime, puisque l'entreprise aura des employés qui connaissent bien l'application, elle peut même envisager de vendre du support technique pour ce logiciel (puisqu'elle a les compétences en interne). Et donc rentabiliser son investissement initial.

  • Enfin, si le logiciel ne sort pas de l'entreprise (utilisation interne), rien n'oblige l'entreprise à redistribuer le code (même en GPL).

Beaucoup d'entreprises (et non des moindres) se rendent compte que le modèle 3 a des avantages, même si les mentalités sont difficiles à changer.

L'exemple le plus frappant est quand même IBM, qui était vu comme le monstre absolu du logiciel propriétaire et fermé (bien plus que Microsoft), et qui maintenant vend des solutions Linux et paie des dévelopeurs à plein temps pour bosser sur OpenOffice.org.



Pérennité

Et enfin, en tant qu'entreprise si tu achète un logiciel propriétaire et fermé, et que l'éditeur met la clé sous la porte, tu fais quoi ?
Rien, tu es le bec dans l'eau.
Et ce genre de chose est arrivé plus d'une fois.
C'est un risque non négligeable.

Avec un projet opensource, ce risque est minimisé: Si le projet intéresse assez de monde, il y aura assez de dynamique pour qu'il vive.
S'il n'y a pas assez d'intérêt, l'entreprise a au moins la possibilité de corriger les bugs (puisqu'elle a les sources).


J'oubliais encore un autre bénéfice d'utiliser un projet opensource et de reverser les sources: Il est tout à fait possible que d'autres entreprises conçoivent un logiciel en se basant sur le vôtre (puisque c'est opensource, hein).

L'avantage ? Et bien cette nouvelle entreprise a tout intérêt à ce que votre logiciel vive et évolue, puisque le sien est basé sur le vôtre.
Vous avez donc un allié, voir un sponsor.

Et cette chaîne de réutilisation peut aller loin.

Prenez SQLite, un petit moteur de base de données qu'un type a bricolé dans son coin parcequ'il en avait besoin pour stocker des données.
Maintenant le projet est sponsorisé par Adobe, la fondation Mozilla et Symbian (le fabricant de téléphones). Et on retrouve SQLite dans les téléphones Symbian, dans Adobe AIR (le nouveau Flash), dans les iPhones d'Apple, dans Firefox, dans MacOSX, dans les antivirus McAfee...

Toutes ces entreprises ont besoin de votre logiciel. Elles ont franchement intéret à ce que le projet ne meure pas, et à ce que les bugs soient corrigés. Un bug dans votre projet, ça veut dire un bug ou une faille de sécurité chez eux. Alors ça les motive pour corriger le bug. En fait, je pense même qu'elle feront le boulot de corriger le bug pour vous, sans problème.

Et comme leurs besoins évoluent, elles auront sûrement envie de faire évoluer votre projet, par exemple en payant des développeurs à plein temps pour le faire évoluer, voir même de vous payer pour le faire...


Contrairement à une idée reçue - et tenace - le logiciel libre n'est pas un passe-temps de hippie ou une forme de communisme ou d'anarchisme: C'est au contraire parfaitement compatible avec le capitalisme.



Liens complémentaires

Complémentaires ou parallèles: