Ayant multiplié par 6 nos effectifs depuis 2007 (nous sommes passés de 5 à plus de 30 salariés), XWiki SAS a déménagé dans un nouveau (et grand) bureau plus adapté à nos besoins.

Notre nouvelle adresse est située en plein coeur de Paris :

XWiki SAS
35/37 rue Beaubourg
75003 Paris
FRANCE

Nos numéros de téléphone et fax n'ont pas changé.

Nous remercions nos clients pour la confiance qu'ils nous ont apporté dans le cadre de leurs projets ; cela nous a permet de grandir durablement au cours de ces 7 dernières années. Nous serons heureux de les aider à créer la collaboration de demain ainsi que les outils de communication de nos nouveaux bureaux.

Nous avons passé les cind dernières années dans un bureau cosy du côté de Pernety. Il nous a bien servi et nous y avons créé de nombreux souvenirs. Malgré le fait qu'il va nous manquer, nous adorons énormément le nouveau, beaucoup plus grand !

Nous aimons trois choses dans ces nouveaux locaux :

• Espace : c'est beaucoup (beaucoup) plus grand que notre précédent bureau. Nous pouvons tous mieux travailler et confortablement. Nous avons une salle pour nous reposer et nous divertir, 3 salles de réunion, une cuisine et même un espace repas ;
• Localisation : nous sommes dans un superbe endroit, à 5 minutes à peine, à pied, de Châtelet. Et c'est très facile à trouver ;
• La lampe : Ludovic a créé une impressionnante lampe qui a la forme de notre logo et qui trône fièrement dans notre salle de conférence.

Pour finir, nous voudrions un grand merci à tous ceux qui ont participé au déménagement et à l'installation/l'organisation du nouveau bureau pour en faire un espace convivial et professionnel !

Notre nouveau bureau en quelques photos :

After increasing our headcount sixfold since 2007 (from 5 to more than 30 employees), XWiki SAS has moved to a new, larger office more suitable to our needs. 

Our new address is located in the heart of Paris :

XWiki SAS
35/37 rue Beaubourg
75003 Paris
FRANCE

Our phone and telecopy numbers are still the same.

We thank our customers for trusting us with their projects, allowing us to grow sustainably for the past 7 years. We look forward to helping them build tomorrow's collaboration and communication tools from our new desks.

We spent the last 5 years in a cosy office in Pernety. This office served us well, and it was there where great memories were created. Although we’re going to miss it,  we definitely love our new, bigger office!

Two things we love about the new office: 

• Space: it is much (much!) bigger than our old office. We can all work better more comfortably: our new office features a relaxing room, 3 meeting rooms, a kitchen as well as a lunch room 
• Location: we're in a great location, just 5 minutes walk from Châtelet - it's very easy to find
• The lamp: Ludovic has built an awesome logo lamp that stands proudly in the conference room

We would like to address our resounding thanks to everyone who helped build up and arrange everything in the office.

Our new office in pictures:

As users or customers of Open Source software, we don't always see that there are different types of Open Source. The license is one key element of differentiation, since it gives the user different rights. I won't discuss the licensing per se in this post, but will discuss the different business models adopted by companies creating Open Source software.

It's been quite clear for any person analyzing the Open Source business, that releasing software as Open Source is a great way to gain traction and adoption, and that the more permissive your license is, the more adoption you can get. This is of course only true if your software is interesting in itself (I'll have another post on that).

When you create a company, you know you can't live just from creating software and releasing it for free. There will be a need to finance the development of the software, as well as the employees of the company. I'm separating these two because the development of Open Source software is not entirely funded by the company, and the bigger your community is, the bigger is the share of the software that's financed without relation to the company.

I will also look only at the business models of companies built around one software product, which is the sole business the company is in. However there are other business models built around working with multiple Open Source software products, which are different from having your sole revenue coming from one software product.

A few business models are available to companies that want to live based on the Open Source software they create:

• providing services and support on top of a fully open source software with a permissive license and that is downloadable for free
• providing a branded version of the open source software (not downloadable for free, but still open source) similar to the RedHat model
• providing a proprietary license of the open source software (called Dual License)
• providing an enhanced proprietary version of the open source software (called Open Core)
• or a combination of all

Each of these models have advantages and drawbacks when it comes to adoption and generating revenue streams.

In the Services model, all the software is open source, the source available on the net, and the software freely downloadable, while all the revenue is generated by services (including Cloud offerings).

In the RedHat model, the adoption is reduced, as there is no download (RedHat relies on the Fedora community for adoption), but it makes it more complicated for customers to use the full RedHat software for free, which generates more revenue streams.

The principle of the dual license is to limit the usage rights of the software by opting for a less permissive license (GPL or AGPL), use the traction of the Open Source community (so there is still adoption), while generating revenue streams when the user wants to combine the software with proprietary software. This solution also reduces competition by limiting the ability for competitors to add proprietary modules to the software, while the copyright owner can do it. This is why often this model is combined with the Open Core model explained below.

The Open Core model is about having a less featured version that is Open Source on any license, including very permissive ones, while the main developer of the software has an enhanced version of the software, which is proprietary. The enhanced version can also be serviced on the cloud.

All these models are Open Source in the sense that at least a share of the software is Open Source. A little analysis of the history of Open Source companies show that there is a tendency to start with the most open model, so that traction and adoption are high, and then later move to one of the subsequent models. This is not very different from web services being offered for free, without ads, and then offering a choice of ads, additional services or even stripping the free service all together.

So if you are a user planning to invest in installing an Open Source software, or even decide to participate in the community and help the development of the Open Source software, you need to make sure that you are investing in the right solution, namely a solution where your investments are protected. This means you hope the software will still exist, still be open source, will be actively developed and that the community will still be thriving.

There is nothing wrong in itself for a company to make its model evolve. What is wrong however is to mislead the users in thinking that the "open" model will be sustained. Users need to be informed what options are considered to monetize the open source software in the future. Businesses are not non profits, and it's normal that they look for profit, but it's not ethical to look for optimization of the revenue stream at any cost, and particularly at the cost of having mislead the users. Note that if it's a survival issue it's another story, but in most cases it is not, it is purely optimization and that was often the plan since the beginning.

Moreover, I believe that the Open Core and Dual Licensing models hold in very high risks themselves of progressively having the company direct most of its investments towards the proprietary business. With the Open Core business model the maximization of profits will mean pushing more and more to undermine the Open Core component and make it less ready to use, so that the relative value of the non open source version will look better. Even if the proprietary modules are small in size and additions on top of the base product, there are risks of slipping towards more and more proprietary. With the Dual Licensing model, there are revenue streams from OEMs and this can create significant revenue streams, like the MySQL business has shown. Unfortunately the slip towards Open Core is easy. This is visible in Oracle's latest move of creating proprietary extensions (http://monty-says.blogspot.com/2011/09/oracle-adding-close-source-extensions.html). Interestingly in this case MySQL used to have a shareholder agreement forbidding it, but this agreement didn't survive the takeover. With this model, since the rights are fully owned by the Dual License holder, the non Open Source version is not even a creation on top of the Open Source version, but it's merely a fork, for which the copyright holder is the only creator, thus reducing competition.

Moreover, what is really bad, is that when the company starts to slip it's model towards a more closed approach, the contributors either move away from the software for another more open software, or fork the code base into a competitive software. A more open approach will always bring more contributors.

The other two models I described don't have this issue of slipping to proprietary as long as the license used does not allow closing the software later on (GPL and LGPL without Dual Licensing are such licenses, while BSD or ASL type licenses allow to close the software later on). I like to say that these models are "Real Open Source", although in this case the "Real" is more about sustainability. 

As I said there is nothing wrong with deciding to opt for these business models, but what is wrong is to change and close progressively the model. This is why users should be aware of the model used by companies, of their commitment to these models and of the possibilities the companies have to close the software. This won't fully guarantee the sustainability, as the company can also fail, but at least they won't be disappointed when seeing the company close-source a software which was perfectly sustainable. Unfortunately many companies use the buzzword "Open-Source" to make themselves look "Open" whatever the amount of Open Source code and whatever the long term intentions are. It would be interesting for the level of commitment to be disclosed.

This has motivated XWiki SAS to publish its code using the LGPL license, without Dual Licensing, to have binary downloads of our software that are fully usable in production with a very simple installation process, to commit to our model in our Manifesto, and to support the reversibility of our cloud offering, allowing to install the same version locally as open source software. These commitments put XWiki SAS in the first category of the described business models. However, we don't exclude using part of the RedHat model for some additional modules or to package a branded version of our software, but we are committed to having this software fully open source.

Ludovic DUBOST
XWiki Founder and XWiki SAS CEO

En tant qu'utilisateur ou client de Logiciel Libres, on ne sait pas toujours qu'il en existe plusieurs types. La licence est un point clé de différentiation par le fait qu'elle donne des droits différents aux utilisateurs. Je ne vais pas rentrer dans le détail des licences en elles-mêmes dans ce billet, mais plutôt m'intéresser aux différents modèles de business qui en découlent pour les entreprises qui créent du logiciel libre.

Il est très clair pour les personnes qui analysent les modèles de business de logiciel libre, que distribuer son logiciel sous forme libre est une très bonne façon de se faire connaître et de créer l'adoption pour le logiciel en question, et ce d'autant plus que la licence est plus permissive. Ceci est bien entendu vrai uniquement si le logiciel lui-même est intéressant.

Maintenant, si vous créez une entreprise, vous ne pouvez pas juste vivre de la création du logiciel et de sa distribution gratuite. Il faudra trouver le modèle de financement du logiciel et des employés de l'entreprise. J'ai séparé les deux, car le financement du développement du logiciel ne passe pas forcément entièrement par l'entreprise. Plus la communauté de développeurs sera importante, plus une part importante du développement du logiciel sera supportée sans lien financier avec l'entreprise.

Je m’intéresse ici aussi aux modèles de business où tout le business de l'entreprise est dédié à un unique logiciel open source. Il y a d'autres modèles où une entreprise travaille avec une multitude de logiciels libres, et ces modèles sont différents d'une entreprise où son seul revenu est lié à un logiciel unique.

Il y a plusieurs modèles possibles pour les entreprises qui veulent vivre d'un logiciel libre :

• proposer des services et du support pour un logiciel libre avec une licence permissive et en téléchargement gratuit,
• proposer une version du logiciel libre sous la marque de l'entreprise (qui ne soit pas téléchargeable gratuitement, mais toujours sous licence libre) similaire au modèle de Redhat,
• proposer le logiciel libre sous double licence,
• proposer une version améliorée du logiciel libre (appelée Open Core),
• ou bien une combinaison des modèles précédents.

Chacun de ces modèles a ses avantages et défauts quand il s'agit d'adoption ou de revenus.

Dans le modèle de service, tout le logiciel est libre, la source étant disponible et le logiciel téléchargeable. Le revenu est alors généré par les services y compris les services "Cloud".

Dans le modèle Redhat, l'adoption est réduite car il n'y a pas de téléchargement (Redhat dispose de la communauté Fedora où il y a des téléchargements) mais il est plus difficile pour les utilisateurs d'utiliser les produits Redhat gratuitement, ce qui génère plus de revenus.

Le principe de la double licence est de limiter l'usage du logiciel par une licence moins permissive (GPL ou AGPL), d'utiliser l'adoption du libre tout en générant des revenus en limitant les possibilités d'ajouts de modules non-libres en permettant au créateur original d'offrir une version payante qui lève les restrictions et aussi permet au créateur du logiciel de combiner son logiciel avec des logiciels propriétaires. Ainsi ce modèle est souvent utilisé de façon combinée avec le modèle Open Core.

Le modèle Open Core permet d'avoir une version "light" sous licence Open Source, pendant que le développeur principal du logiciel propose une version avancée qui est propriétaire. La version avancée peut aussi être proposée en mode "Cloud".

Tous ces modèles peuvent être qualifié de "logiciel  libre" car au moins une partie du logiciel est du logiciel libre. Cependant une analyse de l'histoire récente des entreprises de logiciel libre, montre qu'il y a une tendance à démarrer avec le modèle le plus ouvert, pour que l'adoption soit importante, et ensuite se déplacer progressivement vers un des modèles moins ouverts. Ceci n'est pas très différents avec les services Cloud qui sont dans un premier temps offerts gratuitement et sans publicité pour ensuite offrir des services additionnels payants ou même réduire ou arrêter l'offre gratuite.

Si vous êtes un utilisateur qui prévoit d'investir en installant un logiciel libre, ou même un développeur qui souhaite participer à une communauté de logiciels libres, vous devez vous assurer que vous faites le bon investissement, c'est-à-dire un investissement qui soit protégé. Ceci veut dire qu'il faut vous assurer de l'importante probabilité que dans le futur, le logiciel existe toujours, soit toujours libre, soit toujours en développement actif et avec une communauté active.

Il est normal qu'une entreprise fasse évoluer son modèle. Cependant il n'est pas correct de tromper les utilisateurs en leur faisant penser que le modèle "libre" va être maintenu. Les utilisateurs doivent être informés des options qui seront considérées dans le futur pour monétiser le logiciel libre. Les entreprises ne sont pas des associations et il est normal qu'elles recherchent le profit, mais il n'est pas éthique de chercher l'optimisation des revenus à tout prix et en particulier au prix de décevoir les utilisateurs. Il est à noter que si la survie du logiciel ou de l'entreprise est en jeu, c'est une autre histoire, mais dans la plupart des cas, il s'agit avant tout d'optimisation et ce plan était prévu dès le départ.

Personnellement, je pense que les modèles Open Core et Double Licence ont, en eux-mêmes, un risque important de voir les entreprises diriger leurs investissements vers le code propriétaire. Avec le modèle Open Core, la maximisation du profit va pousser l'entreprise à minorer l'importance de la version Open Core et la rendre moins prête à l'emploi, pour que la valeur relative de la version propriétaire soit augmentée. Même si les modules propriétaires sont petits et sont des ajouts sur le produit de base, il y a des risques de glisser progressivement vers le propriétaire.
Avec le modèle double licence, les revenus viennent d'OEM et cela peut générer des revenus importants (comme pour MySQL par exemple). Malheureusement le shift vers l'Open Core est facile comme cela a été montré par les dernières décisions d'Oracle (http://monty-says.blogspot.com/2011/09/oracle-adding-close-source-extensions.html). Il est intéressant de voir que dans ce cas il y avait un pacte d'actionnaires chez MySQL, mais que celui-ci n'a pas survécu aux fusions successives. Dans ce cas, comme le code est entièrement la propriété du détenteur de la licence double, il ne s'agit même pas d'une version "au-dessus" de la version "Open Core" mais c'est un "fork" (un dérivé du code) et cela réduit d'autant plus la concurrence.

En plus, en choisissant un modèle plus fermé, les contributeurs externes vont soit quitter la communauté soit faire un "fork" séparé. En gardant une approche plus ouverte, on aura toujours plus de contributeurs.

Les deux autres modèles que j'ai décrits n'ont pas ce problème de la dérive vers le modèle propriétaire à condition que la licence utilisée ne permette pas la fermeture du code (la licence GPL ou LGPL sans double licence sont dans ce cas, tandis que les licences BSD ou Apache permettent de fermer le code). Je dirais que ces modèles sont du "vrai logiciel libre", même si dans ce cas "vrai" est plutôt une question de durabilité du modèle.

Comme je l'ai indiqué il n'y a rien de mal à se décider pour ces modèles, mais ce qui est incorrect est de changer de modèle progressivement. C'est pourquoi les utilisateurs doivent être informés du modèle choisi par les entreprises et leur engagement vis-à-vis de ces modèles, ainsi que des possibilités pour les entreprises de "fermer" le logiciel. Cela ne garantira pas le futur à 100% car l'entreprise peut aussi échouer, mais au moins on ne sera pas déçu de voir une entreprise fermer le code d'un logiciel qui était pour autant tout à fait viable. Malheureusement, beaucoup d'entreprises utilisent le buzz-word "logiciel libre" pour se donner un air "plus ouvert" quelle que soit la quantité de code réellement libre et quelles que soient les intentions dans le futur. Comme le "greenwashing", c'est de "l'open source washing". Pour le combattre il serait intéressant que le niveau d'engagement soit public.

Pour ces raisons, XWiki SAS a choisi de publier son code sous licence LGPL, sans licence double, d'avoir des binaires téléchargeables de notre logiciel utilisables en production et de nous engager sur ce modèle par notre Manifesto ainsi que de supporter la réversibilité de notre offre Cloud (on peut retrouver en Open Source la même version que notre version Cloud). Ces engagements font d'XWiki SAS une entreprise qui utilise le premier modèle de business décrit. Pour autant nous n'excluons pas le modèle Redhat pour des modules additionnels ainsi que de faire une version sous notre marque de la version libre, mais nous nous engageons à ce que notre logiciel reste libre.

Ludovic Dubost
Fondateur d'XWiki et Président d'XWiki SAS

Depuis la fin de l'année 2011, Ludovic Dubost a rédigé plusieurs articles sur la naissance d'XWiki, sur la création de l'entreprise, les choix qui ont été faits et partagé son point de vue d'entrepreneur et de manager. Si vous avez manqué l'un de ces articles, en voici la liste :

• Pourquoi faire du Logiciel Libre dans le nuage ?
• Entreprises de technologies, le rachat
• Choisir un modèle d'entreprise et s'y tenir jusqu'à nouvel ordre
• Construire pour durer : les objectifs
• Construire pour durer : Pourquoi XWiki SAS sera toujours une entreprise indépendante

D'autres suivront ! :)

Since the end of 2011, our CEO, Ludovic Dubost published several articles on XWiki, on the creation of the company, on the decisions and choices that were made and he shared many times his vision as an entrepreneur and a manager. If you missed them, here is the list!

• Why Open Source in this Cloud World?
• Tech companies, the buyout
• Choosing a business model and sticking to it until further notice
• Chasing the future at XWiki
• Building to last: The Objectives
• Building to last: Why XWiki SAS will remain an independent company

More to come!

Il y a à peu près un mois, le YaJUG de Luxembourg a invité notre Directeur Technique Vincent Massol pour venir présenter XWiki auprès d'afficionados de Java. Cette présentation, non seulement nous a apporté des pistes pour des nouveaux utilisateurs et clients, mais en plus Yannick Kirschhoffer a crée un poster contenant un concept de design d'une lampe murale représentant le X de notre logo.

Nous avons adoré ce design à XWiki SAS et l'immédiate réaction de l'équipe était de vouloir construire cette lampe.

About a month ago, the Luxembourg YaJUG invited Vincent Massol, our CTO, to present XWiki to a crowd of Java specialists. This presentation not only brought us some great leads, but on this occasion Yannick Kirschhoffer created a very cool poster containing a concept design of a lamp representing the "X" in our logo.

Everyone at XWiki SAS loved it and the immediate reaction of the team was to want to build the XWiki Lamp.