Mais Microsoft n’est pas le seul à se faire piéger. Le Software Freedom Law Center a constaté une violation par jour de la GPL depuis l’été dernier d’après Bradley Kuhn, Directeur du Centre. Un état de fait qui ne surprendra probablement pas ceux qui vivent aujourd’hui dans le monde l’open source.

Comment éviter ces écueils ?

Voici neuf façons de le faire tout en bénéficiant des avantages que la communauté open source peut vous apporter.

1. Demandez-vous pourquoi plutôt que pourquoi pas

Il s’agit en effet d’avoir une idée claire sur les raisons d’utiliser du code open source. Il ne faut pas juste se dire “Pourquoi pas ?”. Utiliser de l’open source ne s’arrête pas à la porte de votre service de Recherche et Développement. Cela a un impact également sur la façon dont vous concevez et menez votre activité. En résumé, n’utilisez de l’open source que si vous êtes convaincu que cela peut vous être d’une manière ou d’une autre bénéfique.

2. C’est ouvert, pas gratuit

C’est l’erreur la plus commune. L’open source ne se résume pas à avoir accès à des millions de lignes de code gratuitement. Cela ne fait pas un logiciel. Toutes les tâches classiques du développement doivent toujours être réalisées. De plus, le fait que vos concurrents aient accès au même code vous oblige à donner le meilleur de vous même afin d’obtenir de l’usage de ce code le résultat le plus créateur de valeur. C’est ce que pratique tous les jours des sociétés comme Twitter ou Facebook dont les services sont parfois bâtis sur du code commun.

L’open source et la réutilisation de ce code vous permettent de vous concentrer sur ce qui donne de la valeur à votre logiciel et pas sur les briques de bases qui le constituent.

3. Un autre modèle de développement

Utiliser du code open source ce n’est pas simplement trouver du code gratuit et l’intégrer dans votre projet. En lieu et place des méthodes de développements classiques, les projets open source utilisent les méthodes agiles ou scrum. Il vous faudra donc parfois adapter vos méthodes de travail voir en changer.

4. Définir une stratégie de contribution

Il est important de définir comment et quand vous allez donner quelque chose en retour à la communauté si vous ne voulez pas être vu comme un “FreeRider” ou “Passager clandestin“. Déterminez si cette contribution se fera au lancement du service ou après. Réfléchissez aussi si vous allez assurer de la maintenance et du soutien à l’intégration de votre contribution surtout si vous souhaitez que votre code soit repris dans le code source utilisé à la base.

Vous avez tout intérêt à ce que votre code soit repris et intégré. Sinon lors des prochaines versions vous risquez d’être obligé de le réadapter pour suivre les évolutions.

5. Choisissez votre licence avec soin

Ce n’est pas une mince affaire que de comprendre toutes les  subtilités des licences open source. Il faut tout d’abord définir ce que l’on veut faire et comment on veut le commercialiser. Ce n’est qu’en fonction de ces objectifs qu’un spécialiste sera à même de vous conseiller le bon choix. Le choix d’une licence peut par la suite vous “enfermer” dans ces obligations.

6. Ne reversez pas du mauvais code

Le conseil peut sembler évident, mais il est d’importance. L’impact sur votre image de marque peut être significatif auprès de la communauté à qui vous reversez ce code. Mais cela peut également avoir un impact sur l’image de votre société auprès de personne que vous souhaiteriez embaucher dans cette communauté ou pire auprès de vos clients.

7. Choisir le bon modèle économique

Une des difficultés avec l’open source est de savoir comment gagner de l’argent d’une façon qui soit acceptable par la communauté. Il existe plusieurs modèles qui sont en général bâtis sur le service. Le support offert à des entreprises sur un logiciel open source ou l’assemblage de composants open source pour construire des solutions sur mesure ou plus générique en sont des exemples.

8. Ne réclamez pas de rançon

Il y a aussi modèles qui vous vaudront les foudres de la communauté. Celui consistant à contribuer à un logiciel open source avec l’intention de rendre les utilisateurs dépendant de vous pour la réalisation d’évolutions ou de personnalisations que vous leur factureriez à prix d’or en fait parti. Vous seriez alors vite rejeté de la communauté malgré vos contributions.

9. Le support n’est pas gratuit

Espérer un support gratuit de la part d’une communauté d’un projet open source n’est pas une justification pour faire de l’open source. Parfois (souvent) les projets open source reposent sur la bonne volonté de leurs  membres qui contribuent parfois (souvent) sur leur temps personnel. Il est difficile dans ces conditions d’espérer des garanties de temps de résolutions d’incidents.

En conclusion, réfléchissez d’abord à là où vous voulez aller et à la façon dont vous souhaitez vous engager dans une ou plusieurs communautés de projets open source par opposition à juste choisir les composants logiciels que vous voulez utiliser. L’usage du modèle open source a des implications qui finissent par toucher la plupart, sinon toutes les parties de votre projet. L’open source n’est pas qu’une modalité pratique liée à l’ouverture du code.

Adapté de 9 Ways To Avoid Open Source Pitfalls — Open Source Development — InformationWeek.

Article original écrit par Philippe Scoffoni le 21/04/2010. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Durant ces sept années qui correspondent d’ailleurs avec ma découverte des logiciels libres et open source, j’ai eu le temps de me poser pas mal de questions et pas seulement technique sur le sujet. Le document dont je vous propose ici une synthèse a été élaboré suite à la “l’Open CIO Summit, un événement organisé et animé par des décideurs informatiques afin de débattre de l’impact de l’Open Source dans la mise en œuvre et l’usage du Système d’Information.”

Face aux études parfois “convenues” des grands groupes type Gartner et Forrester, nous avons ici un document qui me semble apporter un regard un peu plus réaliste sur la compréhension qu’ont aujourd’hui les DSI (Directeur de Systémes d’Informations) de l’open source.

Tout d’abord, voici les cinq grandes tendances qui ressortent des débats :

• L’intérêt premier de l’Open Source n’est pas la réduction du coût, mais l’innovation : « l’Open Source est avant tout un levier d’innovation métier ». La possibilité d’assembler, de tester, d’expérimenté sans limite sdes assemblages ou des modifications de logiciels open source est une opportunité pour construire de véritables innovations aux métiers de l’entreprise.
• L’intérêt n’est pas l’ouverture du code, mais les standards et la flexibilité : Les DSI se posent de nombreuses questions sur la gestion et le reversement des contributions aux communautés. Les différentes approches possibles (participation, donation,…) deviennent ainsi un débat émergeant. Le principe de la contribution semble enfin apparaître et faire partie des préoccupations des DSI utilisatrices de logiciels open source. C’est une approche saine, car c’est comprendre que sans cette étape, la boucle vertueuse de l’open source ne peut pas fonctionner.
• Le premier frein à l’adoption de l’Open Source n’est pas la pression des éditeurs commerciaux, mais la réticence des utilisateurs finaux. L’ergonomie, le look restent des points incontournables pour l’utilisateur final. Les logiciels open source souvent conçus par des informaticiens pour leur propre usage sont parfois un peu trop “rustique”. C’est donc sur le poste utilisateur que se joue le dernier obstacle à une adoption plus massive de l’open source. Coté serveur, la partie semble bien plus facile à jouer, car plus transparente.
• L’Open Source exige davantage une nouvelle approche RH qu’une nouvelle expertise technique : l’utilisation de logiciel open source passe aussi par une modification des habitudes de travail et d’organisation des équipes informatique qui doivent faire face des situations plus mouvantes et moins rigides qu’avec les logiciels propriétaires. Esprit d’initiative, autonomie, débrouillardise,sens du travail d’équipe, curiosité et veille permanente… autant d’éléments qui deviennent essentiels.
• L’Open Source est plus une opportunité qu’un risque pour les DSI : Ce vieux mythe qui veut que les logiciels open source représentent un risque pour l’entreprise semble enfin toucher à sa fin.

L’open source ce sont aussi des mythes qui ont la vie dure. Mais ceux-ci sont remis en cause par les DSI participants :

• La pérennité : le risque n’est finalement pas évalué comme supérieur aux logiciels propriétaires. Je crois que pas un DSI n’échappera à la disparition ou à l’arrêt d’un logiciel propriétaire ou à la remise en question d’un offre tarifaire durant sa vie professionnelle. Exemple tout récent, l’abandon par Microsoft de son offre Windows Essential Business Server.
• La sécurité : les acteurs de la défense sont les premiers à adopter massivement l’open source pour leur système d’informations.
• Le risque juridique : encore une fois les DSI présents jugent que le risque lié à la “viralité” des licences est faible, car ils utilisent souvent les logiciels pour leurs besoins internes. Le sujet des licences demande par contre de l’attention dès qu’il s’agit d’intégrer ce code dans un autre logiciel. Il convient alors de bien étudier les interactions des différentes licences en présence. Le plus simple restant évidemment de faire des logiciels open source.
• L’instabilité des mises à jour d’origine perpétuelles. Elles ne semblent pas ressenties comme un problème et sont plus contrôlables qu’avec les solutions propriétaires. L’open source apporte au contraire plus de stabilité et parfois moins de pression à la mise à jour. Il est possible de rester sur une ancienne version plus longtemps que dans le monde propriétaire où l’on fait souvent tout pour vous pousser vers la nouvelle version.
• L’absence de support : c’est une époque désormais révolue. Nombre d’éditeurs open source, de SSLL proposent un support avec plus ou moins de proximité aux entreprises.

Quels sont alors les vrais freins à l’open source ?

• La résistance des développeurs certifiés sur du propriétaire : ces profils peuvent voir dans l’open source un obstacle à leur rente de situation acquise au travers de formations parfois très couteuses. L’open source et son coté ouvert va à l’encontre de cette démarche, même si le spécialiste existe toujours bel et bien.
• La résistance des administrateurs et exploitants : Il n’est souvent pas facile de remettre en question les habitudes et les compétences acquises par les équipes techniques d’un service informatique. Mais l’open source va aussi demander un peu plus de travail pour intégrer toutes les briques et obtenir un ensemble cohérent fonctionnant avec fiabilité. Cette perte d’homogénéité apparente peut être fortement ressentie par des équipes habituées à des gammes logicielles propriétaires faites pour fonctionner entre elles.
• La résistance des utilisateurs finaux : on en a déjà parlé plus haut, mais ce point représente souvent la pierre d’achoppement d’un projet open source. Il faut y porter une attention toute particulière, ne pas réduire la présentation des logiciels open source à la possible économie qu’ils pourraient procurer, mais pour les avantages qu’ils apporteront à l’utilisateur.

Au travers de ces trois derniers points ont voit bien que tout se joue sur l’humain et qu’au final, les obstacles ne sont pas réellement techniques, ni juridiques. Il s’agit bien de volonté et de capacité à conduire le changement de culture qu’imposent les logiciels open source pour le plus grand profit de l’utilisateur.

Le document complet est disponible en teléchargement après demande d’informations personnelles.

Illustration page d’accueil cc licensed flickr photo shared by e-magic

Article original écrit par Philippe Scoffoni le 08/03/2010. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

1: Les clauses de la licence open source sont-elles compatibles avec mes objectifs commerciaux ? L’argument qui consiste à dire que les logiciels open source posent des problèmes du fait de leur licence est assez courant. De fait, leur diversité appairait souvent comme un facteur pouvant entraîner des risques pour les entreprises. Pour cela il faut considérer deux cas de figure :

• L’usage d’un logiciel open source a des fins purement interne. Exemple : un logiciel de gestion d’entreprise (ERP). Dans ce cas il n’y a aucun risque à utiliser des logiciels open source. Leur licence ne peut être un facteur limitant de votre activité. Bien au contraire, vous pourrez facilement faire évoluer et sans coût de licence supplémentaire votre nombre d’utilisateurs. De plus, l’ouverture du code peut vous permettre de réaliser des développements spécifiques à vos objectifs commerciaux
• L’usage de logiciel open source dans un produit que vous allez commercialiser. C’est le cas de figure qui nécessite le plus d’attention. Selon la  licence du code source embarqué dans votre produit et sa “viralité” (l’obligation de mettre à disposition votre produit sous la même licence), vous pouvez vous trouver confronter à un dilemme si  le logiciel que vous voulez commercialiser  doit être propriétaire. Dans ce cas de figure vous devez abandonner et remplacer ce code source ou en trouver un équivalent dont la licence open source ne contienne pas de clauses virales. Le plus simple est évidemment de faire un logiciel open source en prenant soin de choisir une licence compatible avec le code d’origine. Il sera bon de faire appel à un spécialiste en cas de doute.

2: Quelle est l’importance de la communauté ? Le code seul n’est rien sans une communauté pour le porter. L’importance de cette dernière est un bon indicateur de la santé d’un projet. Mais l’importance de la communauté ne fait pas tout. Dans certains cas, notamment celui des éditeurs commerciaux open source, le développement du logiciel est financé à 100% par l’éditeur. A tel point que contribuer au projet est un processus long et complexe. L’ouverture du code ne fait donc pas tout.

3: Quelle est l’étendue de l’adoption de ces produits par les utilisateurs ? Un point a étudier certes, mais qui n’est guère spécifique aux logiciels open source. Une base d’utilisateurs large et variée est toujours un gage de qualité. Des propos que je vais modérer tout de suite, car cela reviendrait à dire que les produits Microsoft sont incontournables, car largement utilisés. La loi du grand nombre n’est pas forcément la plus juste. C’est  parfois un raccourci qui peut vous faire passer à côté du logiciel peu connu, mais aux fonctionnalités particulièrement attrayantes et efficaces.

4: Puis-je obtenir des garanties ou un support commercial si nécessaire ? Dès que l’on parle de l’usage d’un logiciel en entreprise se pose la question du support qui reste indispensable si l’on souhaite offrir une disponibilité importante à une application.

5: Existe-t-il un processus qualité ? L’existence de processus qualité au sein d’un projet open source peut servir d’indicateur pour estimer sa maturité. Il faut cependant être en mesure aussi de vérifier sa bonne application. Tout sera ici encore une fois une question d’ouverture au niveau de projet. Sur le sujet de la qualité des logiciels open source vous pouvez vous reporter au site Scan.coverity que je vous présentais lors de la sortie d’une de leurs études.

6: Quelle est la qualité de la documentation ? Elle peut prendre bien des formes : depuis un simple fichier texte placé au milieu des sources à un Wiki complet et détaillé. Tous les projets ne sont pas égaux devant la documentation bien souvent. La possibilité de la consulter apporte un plus évident, car elle peut permettre dans une certaine mesure de se rendre compte de la facilité de mise en oeuvre du logiciel ou de vérifier la couverture fonctionnelle.

7: Est-ce que le système peut-être facilement personnalisé pour répondre exactement à mes besoins ? La question peut paraître saugrenue dans le cadre du logiciel open source. Pourtant, elle a un sens si l’on considère non pas le simple fait d’avoir le droit de modifier le code, mais la façon dont le logiciel a été développé pour le permettre (extension par plug-in, API, etc). Il faut aussi considérer les compétences nécessaires, le langage utilisé ou les framework de développement qu’il faut maîtriser. Ceci peut parfois réduire le nombre de prestataires capables de réaliser ces modifications à peau de chagrin et vous retrouver dans une situation quasi-similaire à l’emploi d’un logiciel propriétaire.

8: Comment le projet est-il dirigé et est-il possible d’influencer la roadmap ? Lorsque l’on étudie certains projet open source, souvent porté par des éditeurs commerciaux (mais pas uniquement), on constate qu’il est difficile de contribuer au code et que l’avis des utilisateurs ou les remontées d’anomalies ou de demandes d’évolution sont peu suivies dans les faits. C’est un point qu’il n’est pas forcément simple d’évaluer, car il demande d’observer le projet durant une période de temps assez longue pour pouvoir en tirer des conclusions. L’aspect communautaire revêt ici toute son importance, car n’oublions pas que les logiciels open source sont censés être “pilotés par l’utilisateur”.

9: Le produit pourra-t-il évoluer avec la croissance de mon entreprise ? La capacité de montée en charge du logiciel afin de répondre à une forte croissance ponctuelle ou continue est bien sûr indispensable. Mais ce n’est pas un aspect exclusif aux logiciels open source

10: Y a-t-il des mises à jour de sécurité régulières ? La sortie régulière de version mineure apportant des correctifs de sécurité est bien sûr importante et encore une fois pas seulement pour le logiciel open source. Mais on sait que l’ouverture du code permet un audit externe de ce dernier et peut donc grandement faciliter le “déminage” d’un logiciel.

En synthèse, tous ces points ne sont pas spécifiques aux logiciels open source. Il font cependant partie de la liste de contrôle indispensable avant de prendre une décision.

Article original écrit par Philippe Scoffoni le 02/02/2010. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

On pourrait voir dans cette succession de rachat une success story des temps modernes. On pourrait aussi y voir  l’exemple type de ce qui pourrait arriver à d’autres sociétés commerciales éditrices de logiciels open source.

Cette pétition en 12 langues dont le français serait-elle l’ultime chance pour MySQL ? Elle présente en cinq points les arguments pour empêcher ce rachat :

Extrait de l’argumentaire du site de la pétition

1. Les utilisateurs vont payer l’addition : Si Oracle acquiert MySQL il aura alors un pouvoir de contrôle total sur cette base de données, projet phare du logiciel libre.
2. Fonctionnel, évolutif et crédible : Utilisé dans de grands projets de référence et par de grandes organisations telles que Google, Facebook, l’Organisation des Nations Unies pour l’alimentation et l’agriculture, la police suédoise, les banques, les compagnies aériennes, etc …
3. Le loup dans la bergerie :  Deux choses qu’Oracle ne fera jamais: sérieusement améliorer MySQL de manière à gêner le business à haute valeur ajoutée d’Oracle, vendre et promouvoir agressivement MySQL aux clients comme une alternative aux bases de données pour lesquelles Oracle est en général utilisé.
4. La GPL n’est pas une réponse : Un changement avec la licence Apache 2.0 pourrait permettre des flexibilités pour démarrer un nouveau projet non-GPL incluant MySQL ou de le développer sous une licence Apache ou n’importe quelle autre licence, incluant même l’intégration du code dans des produits propriétaires.
5. La dernière chance pour sauver MySQL du rouleau compresseur Oracle est que les autorités de la concurrence bloquent l’accord à moins que Oracle fasse de réelles concessions, pas un semblant.

Je ne vous retranscris ici qu’une partie de la pétition que je vous conseille de lire dans son intégralité pour vous faire votre opinion. En ce qui me concerne même si les arguments de Michael Widenius me semblent recevables, je ne pense pas que cette pétition puisse changer grand chose au cours des évènements à venir et je le regrette.

On pourra néanmoins s’interroger sur les choix fait pour le développement de MySQL et la situation actuelle. S’ils ont permis à MySQL de se développer rapidement, de trouver un modèle économique rémunérateur et de se protéger d’une certaine manière des risques de fork, cela a aussi contribué à bloquer le développement d’une communauté de développeurs prêt à reprendre le projet.

Michael Widenius défend vigoureusement les choix réalisés sur le site de la pétition. Il invoque même le soutien implicite de Richard Stallman, ce dernier notant que MySQL ne pourrait pas dépendre des seules contributions d’une communauté basée sur un projet sous  licence GPL. Concernant ce passage du site les versions française et anglaise différent. La version française comportant des indications supplémentaires et des références à des vidéo (sans lien) tout comme à un article de Greg Stein (toujours sans lien).

Alors MySQL est-elle victime de son modèle ou ce modèle n’existe-t-il plus comme le prétend Matt Asay dans un article traduit par l’équipe du Framablog ? Je le cite : “Sun a tenté de se transformer en entreprise open source, mais une fois que son acquisition par Oracle aura été finalisée, cette dernière ne va certainement pas prendre ce label.  Pas parce que c’est un mauvais label, mais simplement parce qu’il n’est plus pertinent.”

C’est une question que je me pose en tout cas et vous ?

Article original écrit par Philippe Scoffoni le 29/12/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Je croyais que le but de la licence GNU AGPL était justement de résoudre le problème potentiel ?!

Déjà, commençons par rappeler ce qu’est la licence AGPL ou GNU Affero General Public License :

C’est une licence libre dérivée de la Licence publique générale GNU avec une partie supplémentaire couvrant les logiciels utilisés sur le réseau.

Elle a été écrite par Affero pour autoriser les droits garantis par la GPL à couvrir les interactions avec des produits propriétaires à travers un réseau comme Internet, ce que la GPL ne fait pas.

Affero Inc. est une société fondée en 2001, qui gère un site Web destiné à permettre la présentation, l’évaluation et le financement de projets à but non-lucratif. La première version de cette licence n’était pas compatible avec la GPL. La version 3 est en revanche compatible avec la version 3 de la GPL.

[Source Wikipédia]

Le décor est posé, la licence AGPL a été créée pour prendre en compte l’arrivée des services en ligne construit sur la base de logiciels open source. Autrement dit, une offre de could computing utilisant un logiciel sous licence AGPL doit rendre public les modifications effectuées sur le logiciel en question. Cette obligation n’existe pas sur la licence GPL par exemple, mais aussi sur d’autres licences. Un manque qui est souvent mis à profit par les grands du cloud computing.

Revenons-en à la question de Nico.P et voyons en quoi cette licence ne résoudrait pas tous les problèmes. Matthew Aslett, encore lui, a publié un billet dans lequel il évoquait au moins trois raisons :

1/ Si MySQL avait été publié sous licence AGPL, Google aurait simplement décidé de ne pas l’utiliser et aurait cherché une autre solution plutôt que de fournir son propre code. Il fait allusion au refus de Google de permettre cette licence pour les projets déposés sur Google Code.

2/ La licence AGPL n’empêche pas le déploiement des logiciels open source sur le réseau , elle implique juste le reversement des modifications. Dans le cas de Microsoft et de son support de MySQL et Tomcat dans son offre Azure, on peut se poser la question de l’intérêt des modifications apportées. Car si modification il y a, elle doivent être très spécifiques à Azur ou dans le cas d’Amazon à sa plateforme AWS. Si c’est le cas, les modifications ne seraient probablement d’aucun intérêt pour qui que ce soit. Cela ferait alors perdre son intérêt et son effet repoussoir à l’AGPL pour ces acteurs.

3/ La licence AGPL ne convient pas aux fournisseurs de services qui veulent encourager des tierces parties à la mise à disposition d’applications en ligne conjointement à la leur. En effet, l’adoption de l’AGPL pour un logiciel devant en intégrer d’autres peut potentiellement forcer le partenaire à publier son propre code sous cette licence.

Les objections 1/ et 2/ à l’intérêt de l’AGPL résident dans la part de modifications qui apportent une réelle plus-value au logiciel et celles qui relèvent simplement de l’adaptation technique à l’environnement d’hébergement. Dans le point 1/ les améliorations peuvent procurer un avantage au fournisseur de service. On se trouve donc face à des stratégies différentes.

Pour le cas 1/ le fournisseur a l’intention de fournir un service pour lequel il a besoin de logiciels open source pour les économies de licences et pour l’ouverture du code. Ce sont des avantages pratiques. La finalité est de délivrer un service le plus performant possible au moindre coût. Les modifications apportées ici relèvent bien de l’amélioration du logiciel. Mais ces améliorations doivent rester “secrètes” pour ne pas permettre à  un concurrent d’en profiter. La licence influera donc naturellement sur le choix du logiciel. Les logiciels sous licence AGPL ne seront par retenues.

A l’inverse dans le cas 2/, la finalité est juste de mettre à disposition le logiciel en l’état, car l’offre n’existe pas. Alors, la licence AGPL ne représente pas un obstacle. Mais les retours en terme de reversement de code resteront faibles. C’est le cas de tous ces services qui proposent d’héberger des applications open source. La plus-value est dans l’hébergement et ces conditions financières.

L’AGPL est censé protéger les éditeurs de logiciels open source contre les “cloudificateurs” d’application indélicats. Mais dans les faits il semblerait soit qu’elle représente un obstacle soit qu’elle ne protège en rien. Dans les deux cas, c’est une source de revenu potentiel qui disparaît. La démarche la plus certaines pour un éditeur souhaitant commercialiser une offre Saas pour son logiciel consiste à prendre le problème en main et à s’assurer par un partenariat efficace avec un spécialiste de l’hébergement d’application afin de s’assurer une part de revenue sur l’offre.

Comme souvent la vérité est sûrement à mi-chemin et des exemples concrets vous viendront peut-être à l’esprit. Pour l’instant je resterais sceptique sur l’apport de l’AGPL même si je ne remets pas en cause  ni l’intérêt ni la nécessite de son existence. Mais je ne suis pas sûr qu’elle contribue à changer le paysage des services en ligne.

Article original écrit par Philippe Scoffoni le 03/12/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Je m’étais à la fois étonné et d’une certaine manière réjoui que Chrome OS soit basé sur une Debian. En fait, il y a une explication possible à cela : ce sont des ingénieurs de Canonical l’éditeur de la distribution GNU/linux Ubuntu qui participeraient au développement du dernier OS de Google.

Ubuntu est en effet elle-même basée sur Debian dont elle reprend la branche dite “testing”. Les ingénieurs de Canonical sont donc en toute vraisemblance de fins connaisseurs de Debian. Quoi de plus naturel qu’ils aient repris cette distribution pour construire Chrome OS.

Le point de départ de cette information se trouve sur le blog de Canonical dans un article rédigé par Chris Kenyon VP of OEM Service où  Canonical félicitait Google de la sortie de son nouvel OS. Il en profitait pour annoncer qu’en toute transparence, des ingénieurs de Canonical travaillaient chez Google sur Chrome OS.

Chris Kenyon éclaircit également le positionnement d’Ubuntu  par rapport à Chrome OS. Bien que les deux OS partagent certains composants, Ubuntu restera un OS complet et généraliste alors que Chrome OS fournira une “expérience” très différente. Le principal objectif de Google était de ne pas réinventer ce qui existait déjà. Il indique également que Canonical continuera de travailler avec Google sur les terminaux basés sur Chrome OS.

Voilà donc une façon d’officialiser ce partenariat qui vient s’ajouter aux rapprochements avec Amazon. Canonical fait en ce moment feu de tout bois et on commence à voir l’ébauche d’une stratégie d’alliance avec des poids lourds du secteur. Google et Amazon ont la particularité d’être présents à la fois sur :

• le secteur du grand public : Google avec ces innombrables services web et Amazon en champion de la vente de produits en ligne.
• le secteur des entreprises : avec les Google Apps en version professionnel et Amazon avec ces services de cloud computing.

Au passage, j’en suis à me demander si l’une des cibles de Chrome OS ne serait pas les entreprises utilisant les Google Apps en version professionnel. Google serait alors en mesure de leur fournir des petits terminaux parfaitement sécurisés dont le prix serait probablement très faible.

A ceux qui se demandaient si Google Chrome OS pouvait être un concurrent pour Ubuntu, cette nouvelle semble indiquer que non. Si Canonical a accepté de participer au développement, il s’est aussi probablement assuré que cela ne serait jamais en sa défaveur.

Pour finir, je vous laisse ce petit sondage.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Article original écrit par Philippe Scoffoni le 22/11/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Sans même en avoir vu le contenu, j’ai réagi au nom qui contenait le mot magique et médiatique “Store”. Un terme qui renvoie immédiatement à la notion de magasin et d’achat en ligne. Ma réaction fut sur le moment “On y est !”. Mais où en fait ?

Où en est Canonical ?

Ubuntu n’est pas une distribution communautaire au sens classique du terme. Bien sûr, elle s’appuie et existe grâce une communauté d’utilisateurs et de contributeurs estimée à 12 millions de personnes. Cependant, le projet a été initié au travers d’une société commerciale : Canonical qui emploie aujourd’hui environ 280 personnes à travers le monde.

Canonical fait donc parti de la famille des éditeurs commerciaux open source tout comme Red Hat, Mandriva, Suse ou Novell. Cette société a donc adopté le  modèle économique classique qui consiste à vendre des services sous diverses formes autour de leur système d’exploitation.

Mark Shuttleworth avait clairement annoncé sa stratégie de développement alors axée sur les services :

« We can’t make money selling the desktop that’s why we focused on a zero licensing cost business model,” Shuttleworth said. “The only way to build a business on Linux is to focus on services. »

« Nous ne pouvons pas faire d’argent en vendant les licences, c’est pourquoi nous nous concentrons sur un modèle sans coût de licence. Le seul moyen de faire des affaires avec Linux et de se focaliser sur les services »

Une stratégie déclinée à l’image de Red Hat, avec comme cible principale les entreprises. Quoi de plus naturel, celles-ci sont plus enclines “naturellement” à acheter du service. Ainsi, Canonical a développé une gamme de services à leur attention :

• le support 7 jours sur 7, 24heures sur24 ,
• le packaging ou le développement d’applications,
• la mise à disposition de contacts dédiés ou Premium Service Engineer facturé environ 50 000 dollars par an et qui permet d’obtenir une réponse sous 60 minutes à une question prioritaire
• des prestations de services spécifique à la mise en place de “nuages” privés,

Si les entreprises sont une cible privilégiée, les particuliers peuvent aussi en constituer une autre pour laquelle Canonical a commencé à développer une offre dédiée. Ainsi est apparu Ubuntu One, un service qui permet de sauvegarder les données de son PC sur Internet moyennant un abonnement.

Le Software Store vient donc s’inscrire donc dans cette logique de services.

Une démarche qui selon moi devrait s’accélérer. La roadmap prévisionnelle du Software Store est précise et je suis certains qu’elle sera tenue voir peut-être même accélérée. La raison pourrait bien tenir à une simple question de rentabilité et de viabilité de Canonical.

N’oublions pas que Mark Shuttleworth n’est pas qu’un gentil mécène. C’est aussi et surtout un homme d’affaires qui a déjà connu le succès par le passé avec la société Thawte qu’il vendit en 1999 à Verisign pour la somme de 575 millions de dollars. Nul doute que l’objectif de rentabilité n’est pas un vain mot pour lui. Ce qui ne m’empêche pas de le croire sincèrement engagé en faveur de la cause des logiciels libres.

On ne connaît pas grand-chose de la situation financière de Canonical. Les chiffres de la société ne sont pas communiqués. Toutefois, en octobre 2008, Mark Shuttleworth avait admis que sa société n’était toujours pas bénéficiaire. Cepedant un objectif avait été fixé : la rentabilité pour 2009 voir 2010 au plus tard.

Inutile de nier qu’aujourd’hui pour exister d’un point de vue marketing tout système d’exploitation se doit d’avoir son Store. Le choix de Canonical n’est donc pas innocent et est bien dans l’air du temps et j’oserai presque dire en retard…

Pas innocent non plus le choix de piloter ce magasin à partir de Launchpad qui regroupe en son sein les sources et les outils de gestion de bon nombre de projet de logiciels libres. Une façon aussi d’attirer les développeurs vers cette plate-forme afin de simplifier la publication de son application sur le Software Store.

Des logiciels payants à partir d’octobre 2010

Le mot est lâché : payant. Il va falloir payer pour télécharger des logiciels. Mais quels logiciels ? Rien n’est dit à ce sujet.

Des logiciels propriétaires ? C’est la première idée qui vient à l’esprit. Donner de la visibilité aux logiciels propriétaires pour attirer des éditeurs et faciliter le passage de certains utilisateurs vers Ubuntu. Un sujet délicat, car il soulève souvent des débats houleux. Pourtant, il existe un public qui serait prêt à utiliser des logiciels propriétaires sur un système d’exploitation libre. Si Adobe décidait de porter Photoshop par exemple, je pense que bon nombre d’infographistes seraient incités à passer sous GNU/Linux. Dans le même ordre d’idée, il y a les jeux qui sont souvent présentés comme un manque majeur de GNU/Linux. Mais est-ce la bonne façon de les faire venir au libre ?

Des logiciels libres ? Pourquoi pas, rien n’empêche de vendre des logiciels libres. A ce sujet voici la position de la FSF :

« Logiciel libre » ne signifie pas « non commercial ». Un logiciel libre doit être disponible pour un usage commercial, pour le développement commercial et la distribution commerciale. Le développement commercial de logiciel libre n’est plus l’exception ; de tels logiciels libres commerciaux sont très importants. Vous pouvez avoir payé pour obtenir une copie d’un logiciel libre ou vous pouvez l’avoir obtenu gratuitement. Mais indifféremment de la manière dont vous vous l’êtes procuré, vous avez toujours la liberté de copier et de modifier un logiciel et même d’en vendre des copies.

En l’absence d’informations plus complètes sur le sujet, inutile de s’alarmer ou de s’inquiéter outre mesure. Il faut attendre pour voir comment ce software Store va évoluer. Au mieux c’est une excellente nouvelle qui permettra aux développeurs de logiciels libres de disposer d’une source potentielle de revenus. Il s’agira en effet ici de rémunérer le canal de mise à disposition du logiciel et l’auteur du logiciel. Il reste néanmoins souhaitable que le paiement soit une option pour les logiciels libres. Un peu comme on le voit aujourd’hui sur le site d’add-ons de Mozilla.

Au pire, c’est l’invasion des logiciels propriétaires avec l’aide de Canonical. Je ne crois pas trop à cette dernière hypothèse qui reviendrait à un suicide en bonne et due forme.

Peut-on conclure ?

J’ai un peu de mal à le faire, tant l’annonce et ce que l’on a pu voir est pour l’instant incomplet. Le projet n’en est pour l’instant qu’à ces débuts et n’est qu’une alternative aux solutions d’installation classiques qui n’en doutons pas, si elles ne sont plus installées par défaut pourront toujours être ajoutées.

Je pense que le Software Store s’adresse à une catégorie de client que Canonical rêve de capter. Les utilisateurs de Windows qui achètent leur anti-virus et leur firewall ou encore leur logiciel de gravage de DVD sans discuter 30 jours après avoir allumé leur nouvel ordinateur portable. Si ces derniers pouvaient utiliser leur carte bancaire pour acheter des services Canonical, Marc Shuttleworth pourrait alors atteindre son objectif de rentabilité.

Article original écrit par Philippe Scoffoni le 09/09/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Sam Ruby

Le 3 mars dernier dans un article sur son blog, il évoque une offre que Microsoft se préparerait à lui faire. Cependant, après plusieurs contacts l’affaire ne semble toujours pas conclue d’autant que Sam Ruby affirme être parfaitement heureux chez IBM. A ceux qui l’accusent de fréquenter le mal absolu, il répond que lorsqu’il est renté chez IBM en 1981, la firme n’avait guère meilleure réputation que Microsoft.

Alors bonne ou mauvaise nouvelle ?

Microsoft se rend compte qu’il est attaqué sur ses marchés par de multiples acteurs dont certains comme Google ont atteint des tailles plus que respectables. L’open source et son éco-sytème est également perçu un concurrent de poids.

Microsoft peut tenter de lutter contre tous ses adversaires en même temps ou se concentrer sur le plus dangereux. Et c’est à mon avis Google qui a gagné ce rôle. Microsoft est donc en train d’intégrer l’open source comme une composante de sa stratégie comme le montre encore la récente petite phrase de Bob Muglia président de la division Microsoft’s Server and Tools Business.

Stratégie à rapprocher aussi des annonces faites autour d’Office 14 et de l’existence possible d‘une version gratuite de la suite bureautique.

Doit-on se plaindre de cette évolution ? Comme Sam Ramji, patron de l’open source chez Microsoft qui déclare “Faire de l’Open Source au sein de Microsoft, ça demande de l’optimisme à long terme”, je prends donc toutes ces annonces comme de bonnes nouvelles, car elles semblent confirmer  la pertinence du modèle de l’open source  et sa viabilité à long terme.

[Source]

Article original écrit par Philippe Scoffoni le 05/03/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

1. Définir une stratégie de gouvernance : Il est important que chacun au sein de l’entreprise sache qui utilise des logiciels open source, pour quels usages et avec quels résultats.
2. Créer un comité de revue des besoins : Ce groupe évalu les besoins exprimés au sein de l’entreprise  pour déterminer ceux auxquels les logiciels open source peuvent répondre.
3. Tester “copieusement” les applications. Chaque composant (widget, thèmes, nouveau code) doit être testé de façon isolée. Si des outils de tests automatisés existent, il faut les utiliser.
4. Maintenir des environnements distincts de test et de production. Un environnement de développement peut aussi être ajouté pour les entreprises qui développent beaucoup de spécifiques.
5. Choisir les solutions les plus répandues. Elles offrent le plus de support et sont celles qui ont le plus de maturité.
6. Tenez-vous au courant des mises à jour. La plupart des logiciels open source sont fréquemment mis à jour. Vous devez rester informé pour avoir connaissance des nouvelles fonctionnalités ajoutées.
7. Faites des mises à jour uniquement lorsque c’est nécessaire. Il n’y a pas d’obligation à faire de mises à jour systématiquement. Concentrez-vous sur les points essentiels et  procéder à des mises à jours uniquement lorsque vous en avez réellement besoin ou pour des raisons de sécurité.
8. Soyez actif au sein des communautés. Le succès de l’open source est dû au fait que chacun travaille à l’amélioration du logiciel. Avoir des utilisateurs qui sont actifs est important pour le succès du projet.
9. Collaborer avec les responsables du projet open source. Chaque mise à jour doit être soumise à la communauté avant d’être incluse dans le code de base du logiciel.
10. Partager les “success stories”.  Partager les stratégies gagnantes aide à renforcer la communauté. L’adoption avec succès de l’open source est basé sur les bonnes pratiques et la mutualisation des expériences.

J’avoue que cette liste me laisse un peu sceptique. En fait on peut appliquer la plupart des 10 points aux solutions propriétaires. Le point 4 est même surprenant tant il est non significatif.

Seul les points 8 et 9 reste spécifiques à l’open source. Les communautés, impliquant partage de connaissances, d’expériences, de bonnes pratiques n’existent que peu dans le monde des logiciels propriétaires. Je fais abstraction des “gros” où l’on trouve malgré tout pas mal de forums très actifs. Mais il est vrai que la notion de partage de connaissance est moins naturelle et moins organisée par les éditeurs.

En fait cela plaide plutôt en faveur des logiciels open source en montrant qu’il existe en fait peu de différences avec les logiciels propriétaires dans le cadre de leur mise en place en entreprise. Il faut chercher ailleurs les bénéfices liés à leur utilisation.

Un potentiel encore peu exploité par les entreprises pourraient résider dans la mutualisation de certaines leurs efforts de développement logiciel plutôt que de reproduire chacune de leur côté des fonctionnalités similaires. Il leur faut cependant franchir la barrière constituée par la crainte en reversant du code de perdre un éventuel avantage concurrentiel.

Un rôle que pourrait peut-être tenir des organismes comme les Chambres de Commerce avec la mise en place de “Forge” où les entreprises pourraient déposer leurs contributions au sein de projets clairement identifiés.

Pour l’instant ce rôle est souvent joué par des SSLL (Société de Service en Logiciels Libres) qui apportent leur collaboration à certains projets open source en reversant les codes développés pour répondre aux besoins de leur clients.

Article original écrit par Philippe Scoffoni le 10/02/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

A l’arrivé le XO-1 coûtera dans les 200 dollars. La promesse du prix ne sera donc pas tenue. Coté technique la machine utilise un système d’exploitation basé sur Linux : SugarOS de Red Hat, ne consomme que 2 à 3 Watts, 1Go de mémoire flash.

Depuis l’année dernière on peut néanmoins disposer de Windows XP sur les XO-1, certains pays comme l’Uruguay s’étaient montrés réticents du fait de sa non compatibilité avec les produits Microsoft.

Les objectifs en terme de ventes ne sont pas au rendez-vous. Seul 600 000 Xo ont été vendus au lieu du million prévu. La Fondation OLPC est touchée par la crise économique et par la concurrence des Netbook dont les prix sont terriblement proches du XO-1. Elle vient d’annoncer le licenciements de 50% de ces effectifs soit 32 personnes.

Quelle stratégie adopter et comment rebondir ?

Nicolas Negroponte responsable du projet OLPC a rendu public plusieurs informations sur la version 2 du XO. Son prix tout d’abord : 75 dollars seulement. Deuxième annonce le XO-2 sera un projet hardware open source. La plus grande partie des spécifications des différents composants devraient être mises à disposition sous une licence libre. Le processeur devrait cependant faire exception  car provenant de chez Intel.

Le XO-2 aura la particularité de disposer d’un clavier virtuel utilisant son double écran tactile. Il ne devrait consommer qu’un unique Watt.

Richard Stallman avait lancé un appel à la communauté lors de l’annonce de la disponibilité de windows XP pour l’OLPC. Ce revirement complet de stratégie par rapport à la première version suffira-t-il à la convaincre de s’investir d’avantage dans le projet ?

Nicolas Negroponte souhaite que le XO-2 soit conçu comme s’il était fait par Google. L’ambition de trop ?

Article original écrit par Philippe Scoffoni le 31/01/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Son approche de l’open source dépasse le simple cadre de la technologie. Il s’intéresse à la façon dont les entreprises peuvent utiliser l’open source et aux gains qu’elles peuvent y trouver.

Jonathan a bien voulu répondre à quelques questions que je lui ai soumis.

Peux-tu nous présenter le Master que tu es en train de faire, je ne connaissais pas ce type de formation ?

Jonathan Le Lous : Pour être exact j’ai terminé mon Master 2 et je suis actuellement en doctorat en science de gestion dans le département stratégie de l’IAE de Toulouse.
Je travaille sur l’innovation dans les services. Mon sujet d’analyse est les SSII et l’intégration de l’open source dans leurs stratégies.
Le Master 2 management de l’innovation a vocation a formé des professionnels de l’innovation d’un point de vu stratégique, juridique et économique.

Comment es-tu venu à t’intéresser à l’open source, à priori rien dans ton cursus ne semblait te diriger vers l’information ?

J.L.J : Le boulot ! Je travaillais dans la formation professionnelle, plus particulièrement dans le conseil. J’ai intégré pendant 4 ans Libenti, qui propose du conseil en RH et est, de plus, un organisme de formation spécialisé dans l’open source. J’ai ainsi découvert, entre autres, Mandrake sur mon poste de travail et on partageait un open space avec une start-up du libre, Ovéa. Libenti est aussi membre de l’Adullact, de All…
J’avoue avoir accroché tout de suite avec la philosophie de la communauté.

En quoi consiste le projet Intelli’N, quel sont ces objectifs ?

J.L.J : Intelli’N est un Cluster. C’est un groupement d’entreprises, d’associations et d’experts des TIC qui se regroupent pour travailler sur les problématiques de l’open source.

Pour citer son président Alain Crémont :

“Intelli’N est avant tout un projet d’entreprises, il a vocation à structurer l’activité économique autour de l’open source. Il doit permettre aux acteurs du secteur informatique de développer leurs activités, de s’unir pour faire face à un enjeu majeur du marché de l’informatique de demain. Le cluster doit être un outil de mutualisation d’expériences, de compétences, être un lieu d’échange et permettre ainsi de créer une dynamique positive et constructive dans la période difficile qui s’annonce.”

Il représente aujourd’hui une dizaine de structures pour un CA cumulé de 20 millions d’euros et 200 collaborateurs.

Intelli’N se développe autour de deux axes:

• Le pôle économique qui a pour vocation de développer l’activité des membres autour de l’open source,
• Le pôle R&D qui intègre ma thèse ainsi que des recherches sur des projets open source et (un projet qui me tient particulièrement à cœur) un travail sur la mise en place d’une certification qualité.

Intelli’N est soutenu par La Région Picardie, Le Conseil Général de l’Aisne, la communauté d’Agglomération de Soissons et la CCI de l’Aisne, entre autres.

Quels sont tes meilleurs arguments pour convaincre quelqu’un de l’intérêt des solutions open source ?

J.L.J : Alors, il va me falloir au moins 10 pages
Pour le client:

• Transférer le coût d’achat des licences en services et développer un produit sur-mesure tout en bénéficiant d’une solution disposant d’un large réseau de contributeur,
• La transparence de la technologie
• Ne plus être un simple “Utilisateur Final” mais devenir acteur de ses applications,

“Nous envisageons le marché de l’informatique sous l’angle industriel et productiviste (on produit avant tout) alors même que nous devrions l’analyser sous l’angle du service. Ce qui fait la valeur ajoutée d’un logiciel, d’une application c’est le sur mesure, l’individualisation, la relation de service créée entre le client et le prestataire et non pas le produit industriel formaté.”Pour le prestataire:

• Une stratégie de R&D pertinente surtout pour les petites et moyennes entreprises !,
• La possibilité de puiser dans un patrimoine logiciel important,
• Le suivi de la qualité grâce au retour de la communauté et des utilisateurs, les clients en ont marre de passer pour des “entreprises pilotes”, qui doivent se farcir tous les bugs avant que la solution soit viable…

Je suis effaré de voir la perte d’énergie qui existe dans l’informatique. A chaque fois que je rencontre une entreprise, je m’aperçois qu’elle développe de son côté, avec plus ou moins de talent, ce que d’autres ont déjà fait… Ce serait tellement plus simple de mutualiser…

Mais bon, il n’y a pas non plus que des avantages….

Sur quels points l’open source doit-il s’améliorer selon toi ?

J.L.J : C’est complexe…
La lisibilité: C’est le bordel et il faudrait y mettre un peu plus de coordination. Beaucoup d’effort sont faits et continueront grâce, en grande partie, aux entreprises qui gravitent autour de l’open source et qui travaillent à une vision plus gestionnaire.
S’éloigner d’une démarche parfois trop militante: Elle joue contre l’open source. C’est l’analyse poussée, la discussion constructive qui impose l’open source et non pas les guerres de clochers !

Le modèle open source peut-il remplacer le modèle propriétaire ?

J.L.J : Je pense sincèrement que le modèle open source est un modèle économiquement viable, qu’il est capable de montrer sa suprématie dans beaucoup de projets. Personnellement je milite pour qu’il prouve son efficacité en amenant les entreprises à choisir l’open source d’un point de vue stratégique !!
Par contre le modèle propriétaire a encore de belles heures devant lui ! Tout simplement parce qu’il reste très efficace dans certains domaines tel que les logiciels métiers hyper spécifiques, dans des secteurs proches de l’industrie…
De toute façon ce n’est pas nous qui choisirons qui doit rester ou pas mais le fameux “Marché” (et surtout les clients et leurs volontés d’adoption pour une bonne ou mauvaise raison)…..
De plus la nature a horreur du vide, c’est d’ailleurs pour cela que le libre est apparu alors ne faisons pas l’erreur de croire en une vision techno-centrée idyllique.

L’avantage concurrentiel d’une solution repose parfois sur une innovation technique. Comment garder son avantage si on le rend public ? Est-ce une limite du modèle open source ?

J.L.J :Tu veux me faire écrire un livre !!!! Je pense que nous sommes encore dans une logique industrielle alors même que nous avons passé le cap de l’industrie il y a plus de 50 ans !

Nous envisageons le marché de l’informatique sous l’angle industriel et productiviste (on produit avant tout) alors même que nous devrions l’analyser sous l’angle du service. Ce qui fait la valeur ajoutée d’un logiciel, d’une application c’est le sur mesure, l’individualisation, la relation de service créée entre le client et le prestataire et non pas le produit industriel formaté.

Cela ne veut pas dire qu’il ne faut pas de développement technologique, ni de recherche appliquée ou fondamentale mais seulement que l’enjeu final sera le positionnement sur le marché et non pas la maîtrise technologique surtout dans le domaine du logiciel ! Combien d’exemples avons-nous de technologies dîtes “révolutionnaires” qui n’ont rien données et qui dorment dans un placard ? Pourquoi parce qu’elles n’ont pas rencontrée de “marché” comme disent les personnes du marketing.
L’avantage concurrentiel se fera donc par la capacité qu’aura l’entreprise d’offrir la solution la plus pertinente à un moment donné à partir du besoin client ! C’est d’ailleurs ce qui fait le succès du libre: la flexibilité de son mode de production, le libre part du besoin à l’inverse du modèle classique.

Ce qui ne doit pas empêcher de standardiser, de structurer, de générer du process et permettre un déploiement simplifié et des économies d’échelle mais le temps du programme packagé hyper rigide est bientôt fini (quand ?); On le voit bien avec l’arrivée du cloud computing.

En mutualisant, on limite le risque d’erreur et on répartit l’investissement sur plusieurs entreprises. En échange on perd l’avantage du premier entrant. Avec l’inflation logiciel de ces derniers temps, l’avantage issu de l’innovation disparaît très vite, voire est parfois nulle car rapidement les concurrents arrivent derrière. Personnellement, je pense que les lois concernant l’adoption des techno, la captation…vont petit à petit disparaître car nous sommes dans un marché plus mature et de que le mode de production des logiciels est beaucoup plus flexible, et moins coûteux, que celui d’un bien industriel.

Encore une fois ce modèle n’est pas valable partout, je pense aux logiciels spécifiques à l’aviation, à l’industrie de pointe, à des domaines qui incluent que l’innovation soit intégrer dans une stratégie industrielle forte et non pas sur un marché de service.

La limite du modèle repose actuellement sur sa pérennité: Comment peut-on (doit-on) rémunérer les éditeurs ? Les développeurs ? La limite actuelle du libre est là et on s’aperçoit que les SSLL ne jouent pas toujours le jeu du libre justement parce qu’elles sont les seules à supporter le développement et qu’il faut le rentabiliser. En voulant, pour certaine, monopoliser l’intégration et le déploiement, elles jouent à l’encontre du modèle et se rapproche d’une pratique propriétaire….

Après ta thèse comment envisages-tu la suite de ta carrière ?

J.L.J : Grande question:
J’aimerai devenir enseignant-chercheur au sein d’écoles d’ingénieurs, de gestion ou à l’Université. Il est probable que je travaillerai aussi dans le conseil. J’aime les challenges, donc je serais peut-être amené à gérer des projets innovants…

Merci Jonathan pour le temps consacré à ces questions !

Retrouver Jonathan sur son blog : IT, service et open source: questions précises et réponses vagues.

Lisez également cet article sur les Business Model de l’open source.

Article original écrit par Philippe Scoffoni le 13/12/2008. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).