Here is the article that got me thinking today. The community of devs working on Mambo have split off to create Joomla – the same product on a forked code base with a different future direction. The big beef was over the control of the project being asserted by the core maintainers at Miro. The team at Miro claim to be the originators of the project and have spun off a non-profit (the Mambo Foundation) “…whose mission is to manage the Mambo project, will ensure the security, longevity and success of Mambo and its community of users.” Except the community has decided to work on its own strategy for longevity.
This situation strikes at the heart of the commercialization of OSS. A GPL-licensed project, with commercial intent from the creators who are now being vilified for wanting to control their project. Matt Asay from Novell commented to me a long ago that it is not the source code that you should worry about, it is about being the source of the code that allows for free software to be used in a commercial sense. I’m not sure that the folks at Miro would concur with that analysis now. I’m not saying Matt is wrong, I think that the team at Miro forgot a critical rule in collabdev projects goverend by the GPL.
Among the many catchy phrases from the Free Software/OSS glossary is the idea of a “benevolent dictator.” The maintainer of the project, the owner of the copyright, the person calling the shots (think Linus, think Miguel) should be adept at listening to the community, but deciding who to listen to. They should guide the project with a firm hand but know that the community can, at any time, fork away from them and build a new community away from the originating team.
As I see it, Miro has two choices now. They can bid farewell to the departing crew (the sepratists) and decide to generate some healthy competition, thus having the innovation premium be the deciding factor in which implementation is ultimately the more successful. The second choice is to apologize for their behavior, change their point of view, modify the bylaws of the Mambo Foundation, console the community and merge the two projects back together. In a world of commoditized software (which they are by definition playing in due to the GPL as the governing license), there may not be a viable path in having 2 implementations.
The customers are in a different boat. If you have implemented Mambo, what do you do? Which project is going to have the momentum, where will choice abound (in terms of add-ons, utilities, consulting firms with available talent to help me…), and how does this affect the decision about production deployments? Of course, in the traditional commercial software space, small companies come and go, and this is always a challenge. The OSS argument, of course, is that at least the customer always has source available if they have to go it alone.
But I see this all in a different light. If I had a draw-string on my back and it were pulled each time I got on stage at an OSS conference or panel, it would be the same message. The more open source is commercialized, the more closed it must become. The effects of competition, the realities of contractual requirements in support contracts, the basic rule of economics that scarcity increases value, etc. all have the same effect. If you want to be a commercial player, you are going to have to figure out where your control points are, what makes you unique, and how that uniqueness will be converted into a revenue stream.
Miro was doing exactly that. I am sure they looked at other successful OSS-based companies and thought about the ways in which a business can be built. Mambo is clearly some compelling technology (the community participation and download numbers speak for themselves), and the core team at Miro should be proud of their baby. MySQL, Sugar, JBOSS, SleepyCat and others provide one set of examples while the Apache, Python, and Eclipse Foundations another. Somewhere in there is a balance to be struck for a small player to establish a strong services practice. But the real multiplier for your billable rate is if you are the project owner. Back to Asay – be the source of the code.
This situation will not be the last of its kind. As an open source project becomes successful and moves into broad use it begins to represent significant economic opportunity. The natural tension between the tenets of free software and commercialization will come into conflict. Collabdev project maintainers have a hard road and these factors only make it more challenging for them. The question that occurs to me out of all of this is: do software companies engaged with OSS projects know why they are doing it? In other words – is the marketing bang of an OSS release worth the risk to the commercial opportunity?