I have just returned from the Tranformation & Innovation conference in Washington, D.C.
I was accepted to talk about "How to evaluate open -source communities" (download slides) and invited Daniel Hinderink of Typo3 fame to join me as a Co-Speaker.
We are coming from opposite directions regarding Open-Source - Typo3 is community driven, where Magnolia is vendor driven.
Initially, we thought that this was a great distinction in the context of evaluting communities. However, preparing for the talk we realized that there the difference between the two approaches are smaller than you might think. This has pretty profound implications, as I shall outline below.
While at first (see slides) the projects are of very different nature, a vendor-driven Open-Source project is soon under pressure to build up its community, else it will not be perceived as "real open-source" and be deprived of many of the opportunities and benefits real open-source brings with it.
A community-driven project on the other hand is "real open-source" from the start. This brings many challenges - the main one being that the project is "project-driven" i.e. contributions are always based on projects undertaken on behalf of customers. Lacking an entity that defines and finances fundamental (architectural) changes to the project, there is no "long-term thinking" possible. To overcome this challenge (and overcome it must be else the project will ultimately fail) some governing body must be founded and financial means must be available. Typo3 for instance has founded the Typo3 association, which is financed by its members, and thus has the means to do long-term planning.
Once such an organization is in place, structure and planning can be imposed on the project - very similary to what a vender-driven project has from the beginning. And once a vender-driven-project has gained sufficient traction in the community, the lines between the two start to blur.
On the other hand, a vendor-driven project might sooner or later choose respectively be forced to found a governing non-profit. Once that happens, the difference between the two approaches is gone. This is the most logical step to avoid the risk of a revolution, although it sometimes back-fires (see Joomla!).
Why "be forced"? We are all in a transition in the Open-Source economy, and nobody really knows where the journey will take us – think of Calvin and Hobbes "Transmogrifier". One thing is for sure: there is no going back. Open Source is one of Friedman's 10 flatterners of the world. In the long run, software companies can either embrace it or vanish - here is why:
- The "standing on the shoulder of giants" principle is especially true if these giants are readily available around the world for free
- whatever you do, if the value of your product lies in proprietary code, someone out there will build an open-source version of it – because of (1) that gets easier and cheaper every day.
- To meet that challenge, either you go down with your prices until you are out of business or go open-source fast, else any possibility to gain significant community mindshare is getting harder every passing day (especially if you are going from proprietary to open-source, where the community always suspects you of potential misuse of their contributions)
- Once you are "infected" by the open-source virus, and build up a great community, a lot of value will be created by the community. In the long run, that value will be higher than anything you can provide code-wise.
- Open-source is based on meritocracy. Once most of the (core-)code is written outside your company, the likelyhood of a revolution increases significantly unless you release most of the initial influence to a governing body that takes the real power distribution of the committers into account. (by the way this is why sugarCRM or mySql do all coding themselves, und therefore are no "real open-source" projects)
- If there is a revolution, you are either dead or part of it.
- If you give over control to a governing body, nothing is left of your crown jewels, so look where your value is. If there is none, the project might survive, but you won't.
This is a transition that will take place over time, and time is money. Hence the different approaches enterprises take today to make use of and possibly prolong that time:
- writing code themselves to buy time
- trying to keep control of the project
Thats the power of open-source – it is a truly transforming force. It forces us to ultimatively think about value, and who would argue that this is not a good thing?