nodeo.net - Blog - Pour un web libre, moderne et ouvert ! - Open Source

Lancement des forums de modxcms.fr

davidm — Thu, 14 Feb 2008 19:26:00 +0100

Les forums FR de modxcms.com resteront le lieu de référence pour le support francophone.

Cela fait quelques temps que les membres de la communauté des utilisateurs de MODx appellent de leurs voeux la création d'un site francophone dédié à MODx. J'ai décidé de prendre les choses en main et de faire avancer ce projet une bonne fois pour toute. 2008 va être riche en évènements pour MODx, et je pense une année tournant.

J'avais lancé un premier message en février 2006, puis un débat en avril 2006, enfin j'avais lancé un appel à contributions en octobre de la même année.

Entre temps, nous avions commencé à échanger sur un espace collaboratif projet sur la mise en oeuvre du projet. Une arborescence avait été proposée, et des premières maquettes aussi. Mais nous n'avons pas encore concrétisé. J'ai déjà posté une suggestion sur le forum FR concernant un Lancement progressif du site, car personnelement je pense que la clé du lancement du site modxcms.fr c'est d'avancer vite. On a bien vu que l'approche ambitieuse d'emblée n'amène à rien de concret. Concrétiser la phase 1 enverra le signal aux hésitants qu'il se passe quelque chose et que c'est en route. J'espère un effet d'entraînement qui aidera en Phase 2 et 3....

Je suis bien conscient que pour les membres de la MODx team et un certain nombres de freelance qui s'appuie sur MODx, le temps manque et vous devez vous dire : c'est intéressant (enfin j'espère ) mais cela va prendre du temps ! A cela je répondrai oui probablement mais certains d'entre nous (à commencer par moi) ont aussi la possibilité de faire un peu moins de support "basique" qu'avant (ce qui est le plus consommateur de temps !) grâce aux membres intermédiaires et avancés sur les forums de supports francophones qui sont tout aussi capables de répondre et résoudre les problèmes. Ce temps gagné je vais le ré-investir sur modxcms.fr. C'est la décision que je prend pour 2008. Moins de temps à faire du support de premier niveau et plus de temps à la fois pour le marketing de MODx mais aussi pour le site FR.

Dans mon esprit, ce forum est une première étape afin de donner vie à un site MODx francophone. Il est grand temps ! Nous sommes après tout l'une des communautés les plus influentes si on regarde le nombre de membres FR dans l'équipe officielle, mais aussi le dynamisme de notre communauté en terme de production de addons, de messages postés sur modxcms.com... il n'y a pas de raison que les italiens, les allemands et les russes y arrivent et pas nous !

Les forums de modxcms.fr ont selon moi (mais je vous invite à vous exprimer pour affiner les choses !) une triple vocation :

donner voie au chapitre aux membres de la communauté francophone concernant modxcms.fr, que ce soit au stade de sa conception, mais par la suite pour que nous ayons toujours un feedback actif sur le contenu du site, ses orientations... etc. Ce site n'est pas la propriété de quelques uns, mais la voix de tous (non non je vous rassure je ne suis pas candidat aux municipales )
fournir un moyen de co-ordination aux membres de l'équipe MODx FR. L'équipe officielle sur modxcms.com dispose de forums privés pour la MODx team, nous avons aussi besoin d'un lieu équivalent afin que les choses se concrétisent. Dans un premier temps, pour que nous puissions co-ordonner les efforts pour la création du site modxcms.fr. Dans un deuxième temps, pour discuter des aspects éditoriaux du site, faire passer les drafts de tutos, discuter des actions de promotion autour de MODx dans la sphère francophone...etc. D'une manière générale, je pense qu'il est important qu'on ai une identité en tant qu'équipe FR et pas seulement en tant que membres de la team officielle ici.
faciliter le développement d'un écosystème d'affaires autour de MODx : nous sommes maintenant quelques professionnels à avoir des références significatives et des réalisations assez poussées construites avec MODx. Nous travaillons par ailleurs de plus en plus ensemble : Perrine a collaboré régulièrement avec Frédéric (Heliotrope) et quant à moi je bosse avec Laurent et Gildas en ce moment. Le but est de favoriser les contacts entre professionnels de MODx et à terme mettre en place une véritable "marketplace" d'offres et demandes de services autour de MODx. Le forum Offres et demandes de prestations de services MODx est un début. Par ailleurs, j'ai quelques idées pour développer MODx, que j'aimerai partager, tester dans Faire du business avec MODx

J'espère que vous serez nombreux à réagir, partager vos idées et faire des suggestions sur ce que sera modxcms.fr !

Le modèle POSS : le meilleur de l'open source et du propriétaire ?

davidm — Mon, 15 Oct 2007 10:32:00 +0200

C'est au détour de mes nombreuses lectures sur le web que je suis tombé (par hasard) sur une modélisation du business model du logiciel propriétaire (commercial) et du logiciel libre.

Dans "La Cathédrale et le bazar", Eric S.Raymond avait déjà abordé la comparaison des deux modèles en s'appuyant sur l'exemple du développement de Linux pour montrer comment un modèle fondé sur la reconnaissance pouvait être tout aussi efficace que celui fondé sur la rareté.

La métaphore du bazar (sans organisation formelle, fondée sur le partage et récompensée par la reconnaissance) par opposition à la cathédrale (structurée, fondée sur la hiéarchie et le paradigme de la rareté, récompensée par une valorisation financière), était un plaidoyer en faveur du bazar comme mode de développement plus adaptable et au final plus efficace que celui de la cathédrale.

L'expérience montre que les choses ne sont pas si simples et que le modèle économique autour du développement du logiciel libre est fondé sur un équilibre difficile à maintenir, qui se cherche encore. C'est là que l'essai de James Dixon vient enrichir le débat, avec une métaphore différente, celle de l'Apiculteur (Beekeeper),pour nous proposer une modélisation originale nommé POSS (Professional Open Source Software) à l'intersection des deux modèles. Alors, le POSS, le meilleur des deux mondes ? C'est la question que nous allons poser ici...

Les limites des modèles traditionnels

Limites du business model open source

Absence de support commercial / de services commerciaux
Fréquence de mise à jour élevée
Absence (ou faiblesse) de la roadmap
Contraintes liées aux licences open source
Pas de réseau de distribution structuré
Ecart fonctionnel

La plupart des freins pour les entreprises succeptibles de choisir une solution open source sont donc liés aux risques potentiel : disparition du logiciel (d'autant plus élevé que la communauté est jeune), manque de support (si aucune structure commerciale pérenne n'existe), absence de contrôle sur le développement... etc.

Comme on peut le voir sur le modèle, ce qui manque au modèle open source, c'est un réseau de distribution, un service après-vente et un réseau de partenaires.

Limites du modèle propriétaire

Coût de développement plus élevé (absence de communauté)
Peu de feedback des utilisateurs (implication moindre)
Coût de marketing élevé (du fait du manque de transparence)

Les limitations du modèle commercial sont liées à une moins bonne adaptation au marché, à une plus faible capacité d'innovation et à un coût supérieur au modèle open source.

Comme on peut le voir sur ce schéma, ce qui manque au modèle propriétaire c'est une communauté.

Le modèle POSS

L'idée du modèle POSS est de combiner le meilleur des deux mondes en quelque sorte : conserver ce qui fait la force des projets open source, à savoir la dynamique communautaire qui améliore la créativité et l'innovation ainsi que le rythme de développement, tout en mettant en place une structure de support, de distribution et un réseau de partenaires. James Dixon part d'une analogie assez intéressante avec le modèle économique de l'apiculteur :

En rapprochant cela de notre business model logiciel cela donne :

Chaque ruche dispose d'une Reine. Pour commencer une nouvelle ruche l'apiculteur doit attirer une Reine et suffisamment d'abeilles pour que la ruche soit viable. De la même manière les projets open source ont souvent un fondateur unique qui est le leader principal du projet.

Plus l'apiculteur investi de temps et d'efforts dans la ruche avant de vendre son miel, plus la croissance de son activité va être importante. De la même manière l'open source professionnel doit d'abord bâtir une communauté qui aide à développer une application commercialement viable. Plus une communauté peut se focaliser sur l'adoption de sa solution par une base solide de développeurs, designers, testeurs, plutôt que de chercher un retour financier rapide, mieux ce sera.

Les abeilles sont libres de partir quand elles en ont envie. L'apiculteur ne peut donc pas les contrôler, il doit s'occuper de ses abeilles en leur donnant un environnement favorable à la production du miel. Dans notre cas, cela signifie que l'élément clé pour qu'une communauté se porte bien, c'est qu'on lui fournisse un environnement propice aux échanges d'informations. Tout comme les abeilles peuvent piquer, les membres de la communauté peuvent critiquer un projet voire même décider de "forker" autrement dit de démarrer une communauté ailleurs.

La croissance d'une apiculture dépend de la quantité de miel et de cire qu'il peut vendre à ses clients, à ses distributeurs et partenaires. La quantité qu'il peut vendre dépend quant à elle de ses qualités de gestionnaire et de la quantité de cire qu'il laisse aux abeilles. L'enjeu pour l'apiculteur est de trouver l'équilibre entre la croissance de sa population d'abeilles et celle de sa clientèle. De la même manière les leaders d'une communauté open source doivent veiller à conserver un équilibre entre la croissance de leur communauté et la clientèle professionnelle qui utilisent l'application. Faute de quoi, ils risquent soit de ne pas avoir les moyens de financer l'environnement nécessaire à la communauté soit de ne pas disposer d'une communauté suffisante pour répondre aux besoins de leur client.

Les clients n'ont aucune envie d'avoir affaire aux abeilles. Les abeilles ne peuvent pas satisfaire les besoins des clients de l'apiculteur. C'est le travail de l'apiculteur qui transforme les efforts des abeilles en un produit utile pour les client. Le miel dans la ruche est le même que celui dans le pot, mais seul le miel en pot intéresse les clients. De la même manière les entreprises ne souhaitent pas avoir affaire aux communautés open source. Ils veulent un produit "fini".

L'argent des clients ne sert à rien aux abeilles, mais l'apiculteur peut s'en servir pour acheter d'autres ruches, de la nourriture, des médicaments... De la même manière la motivation des clients qui utilisent des solutions open source n'est pas d'aider la communauté mais bien d'acheter un service.

Chaque abeille apporte une contribution au système. Il faut un grand nombre d'abeille pour que la ruche soit productive. De la même manière la contribution des membres de la communauté est dans la plupart des cas marginale.

Les clients ne sont pas des abeilles et les abeilles ne sont pas des clients et il est impossible de convertir l'un en l'autre. Il n'est pas possible pour une abeille d'acheter un produit, et pour le client de fabriquer du miel. On pourrait penser que l'analogie ne s'applique pas au modèle POSS mais ce n'est pas le cas. Les clients sont des entreprises, les commaunautés sont des individus. Ils ont des besoins différents. C'est une distincition importante à garder à l'esprit lorsque l'on tente de transformer les membres d'une communauté en clients. Dans la plupart des cas, cela n'est pas possible. Par contre il est possible de transformer l'employeur d'un membre de la communauté en client. Pour cela, la meilleure méthode est de communiquer sur les services commerciaux disponibles (support, développement custom, etc...).

Evidemment, cette idée n'est pas nouvelle et c'est même la base de l'activité économique qui s'est développée avec l'offre de service autour de solutions open source (des exemple comme Linagora sont parmi les plus connus). A l'heure où les applications open source sont de plus en plus prégnantes dans l'activité économique et où le modèle propriétaire montre ses limites dans un monde qui rationnalise les coûts et dont le rythme d'innovation est de plus en plus rapide, le challenge pour ceux d'entre nous qui travaillent à l'intersection des communautés et des entreprises est de réussir à trouver le business model adéquat. Cette modélisation originale contribue certainement à clarifier les clés de l'équilibre entre dynamique communautaire et dynamique du marché.

Nouvelle interview sur txpmag : Le marketing des projets open source

davidm — Wed, 16 May 2007 10:14:00 +0200

Il y a quelque temps déjà, txpmag publiait m'avait interviewé sur le sujet des Les facteurs clés de succès d'un projet open source. La suite de cette première interview vient d'être publiée (avec un peu de retard) sous le titre "Do Open Source projects need marketing?". J'y aborde ma vision du marketing des applications open source, et notamment le cas concret de MODx.

Encore une fois, en anglais... j'essaierai de traduire les deux articles en français et de les publier ici, mais peut-être pas tout de suite, un peu chargé en ce moment...

Les facteurs clés de succès d'un projet open source, interview publiée sur txpmag :)

davidm — Fri, 01 Dec 2006 15:55:00 +0100

Textpattern Magazine vient juste de publier une interview de votre serviteur titrée "What are the grounds of a successful Open Source project ?". J'y répond aux questions d'Alexandra Labudda sur ce qui détermine le succès d'un projet open source.

Cette interview est en anglais, sorry, j'ai de nombreuses activités online dans la langue de shakespeare... j'essaierai de fournir une traduction française d'ici peu sur ce blog.

Business Readiness Rating : un modèle pour l'évaluation des logiciels Open Source

davidm — Thu, 30 Nov 2006 15:04:00 +0100

Je me souviens avoir entendu parler de l'Open Business Readiness Rating, une intiative ouverte visant à développer un modèle d'évaluation des applications open source. Je n'avais jusqu'ici pas eu le temps d'approfondir la question, c'est désormais chose faite avec la lecture du Whitepaper (PDF, 236Kb) et du modèle d'évaluation (xls, 100ko) lui-même. Bien que ce modèle n'ai rien de révolutionnaire, il apporte un point de vue intéressant et très bien structuré sur l'évaluation des applications open source.

Autant dire, vu mon activité, que ce modèle va me servir à affiner les critères de sélection des applications que je suis amené à proposer à mes clients.

Je vous propose une analyse rapide du modèle

Un constat : le choix d'un logiciel open source est complexe et est trop souvent la résultante d'une évaluation "ad hoc"

Le fondement de l'initiative lancée par Open BRR est fondé sur un constat : malgré les qualités des logiciels open source (coût potentiellement moindres, transparence et ouverture du code, utilisation de standards ouverts) un certain nombre de facteurs freinent leur adoption par les entreprises :

la sélection d'une solution : pour certaines catégories de logiciels (notamment les CMS), le choix est extrêmement étendu (rappelons qu'au total, il y a plus de 135 000 projets référencés sur SourceForge).
le support : le support technique est souvent limité à un support communautaire, gratuit mais sans engagement contractuel comme pourrait l'être un support payant
la longévité : la continuité d'un projet dépend du bon fonctionnement de la communauté qui le soutien, ce qui est souvent difficile à évaluer.
la volatilité : les équipes de développement sont souvent entraînées dans un cycle de développement rapide pour satisfaire la demande des communautés en terme de nouvelles versions. La plupart des entreprises hésitent à s'engager vis à vis d'une solution de peur de se retrouver dans une situation de mise à jour perpétuelle.

La création d'un modèle d'évaluation répond donc à un besoin, celui d'un cadre d'évaluation structuré permettant de faciliter et rationnaliser le choix. Comme le souligne les initiateurs d'Open BRR, la plupart des évaluations sont actuellement conduite "ad hoc", sans méthodologie et par conséquent risquées.

Principe fondateurs du modèle Open BRR

Le modèle d'open BRR se défini comme :

exhaustif : le modèle doit prendre en compte toutes les caractéristique du produit, qu'elles soient favorables ou non, de manière à éviter les biais.
simple : l'adoption d'un modèle, et son utilité, sont largement fondées sur sa simplicité. Le modèle doit être compréhensible et orienté utilisateur sans sacrifier l'exhaustivité.
adaptable : du fait des changements rapides dans l'industrie du logiciel, il est impossible de garantir sa pertinence future. Il est toutefois possible de laisser le modèle aussi ouvert et générique que possible pour permettre une évolution dans le temps.
cohérent : les échelles de mesure doivent être cohérentes quelque soit le type de logiciel.

Une première évaluation rapide

Côté méthodologique, le modèle suggère une première phase d'élimination, via un ensemble de question :

Quelle est la licence du logiciel ?
Le logiciel est-il conforme aux standards ouverts ?
Quels sont les organisations qui l'utilisent ?
Une ou plusieurs entreprises soutiennent-elles les efforts de développement ?
Quelles sont les langues proposées et aussi le logiciel est-il localisé et internationnalisé ?
Existe t-il des test du logiciel par des tierces parties ?
Des livres ont-ils été publié sur le logiciel ?

(...)

Une évaluation en 12 points

Le modèle défini 12 catégories à évaluer :

Fonctionnalités : le logiciel satisfait-il les besoins principaux des utilisateurs ?
Utilisabilité : Que donne l'interface ? Quelle est la facilité d'utilisation ?
Qualité: Existe t-il une équipe de testeurs ? Quelle est la qualité du code (respect des bonnes pratiques) ? L'application génère t-elle des erreurs ?
Securité : Quelle est la sécurité de l'application ? Combien d'alertes et quelle est la rapidité des réponses (patch) ?
Performance : Quel est la performance du logiciel ?
Scalabilité : Comment le logiciel répond t-il à la montée en charge / un déploiement à large échelle ?
Architecture : Quelle est l'architecture du logiciel ? Est-il modulaire, flexible, extensible, ouvert et facile à intégrer à d'autres applications ?
Support : Le logiciel et ses composants font-ils l'objet d'un support technique ? Si oui, quelle est sa qualité (garanties, délais de réponse) ?
Documentation : Quelle est la qualité de la documentation ?
Adoption : Quelle est la diffusion du logiciel sur le marché ? Communauté, marché, industriels ?
Community : Quel est le degré d'activité de la communauté ?
Professionalisme : Le développement du logiciel est-il professionnel et organisé ?