Some time a go I was talking to Freddie. We were talking about my previous article discussing open source : Open source, fashion or commodity. He asked what has changed in the last two years in open source landscape. One of the things that came to my mind is that I got the feeling that open source is becoming more professional. Together we started thinking whether this was good for open source in general or not.
The result of that conversation is this blog item, read on if you are curious …
When talking about open source, what are we talking about? I am not talking about the sources of my samples that are online at google code. Yes, these sources are open for all to use. But there is more to open source than that. For me open source is about the community behind open source projects. A lot has been written about what drives these communities. An excellent, and now classic, ￼book is “The Cathedral & the Bazaar” by Eric S. Raymond. In his book Eric describes the foundations of what open source has become today. The first thing that struck me in the book is not written by Eric however. There is a foreword by Bob Young, working for Red Hat. He is talking about freedom. In his eyes, open source in bringing freedom to the software world. I’ll get back to it later on. The book itself is about the differences between two development styles. [amtap book:isbn=0596001088]
Two development styles
The Cathedral style, used mostly in the commercial world, and the Bazaar style, mostly used in the open source world. The cathedral style is based around the perfect release. Each release should be feature complete and without bugs before the actual users see the end product. The bazaar style takes a complete separate approach. The mantra for bazaar style development is “Release early and release often”. Releases can be buggy, but the users are mostly developers themselves that can tackle problems, provide fixes or at least concise error reports. Of course there is a danger in this as well with some users. Not all users want these bugs, therefore you should educate them and help them in making the right choice of version of your project. Smells like rules, less time for developing those nice new features. So it is negative to have non developer users that do not want the latest and greatest, or not?
The community is the secret
The predecessor to open source software was, free software. While open source reflects better what the community wants to achieve, free software reflects better what a lot of users think about. A community should consist of a number of different users. You need the developer type of users that are on the bleeding edge. They give immediate feedback on new features and if you are lucky they will come up with new features. The other users need more stability. These are the non-technical and the enterprise users. They require more stability. The question you need to ask is, does a community need these non-technical and enterprise users?
What does a community need?
Eric has done a lot of research into open source communities. His findings are of course related to software development. I believe however they are generic group dynamics. An effective group needs a strong leader. The leader is respected for his deeds. Think about a soccer team, the captain does not have to be the best goal keeper, or the best striker. It is the player with a lot of experience and a player who is highly respected by the team members. There are a lot of other examples to find, but we’ll return to software development. Great communities are led by great leaders. The well known examples are Linus thorvalds, Rod Johnson (oke, only if you are a java developer) and lots of others. They all know how to bind people to their projects. It is pretty amazing that people will spend a lot of free time to create some code they will at most get credit for. No money or what so ever, just the honer.
Next to a strong leader, the community needs passionate users. These users feel that the project can help them take away an itch. Sometimes just to have an open source alternative to a commercial product. In other situations, because there is no solution yet. Sharing the source and helping each other out is very important in the community.
There are some lines a community of open source should not cross. Always be respectful to the actual creators of code (though shall not steel). The community must be open to new members. New members must be willing to prove there ambitions and capabilities before receiving commit rights.
The communities want to spend time on creating cool software. Anything that prevents them to do so will be demotivating with the risk of losing valuable resources for the project.
Steps an open source project goes through
A project usually starts with a developer having an itch (again from Eric S. Raymond). The developer starts finding a cure for his itch. If he found the cure, he’ll try to find others with the same itch. The community grows, other (core) committers are added to the project and a large user base is testing every single release. The initiator loses detailed control and starts doing only marketing. Big companies are becoming interested but they need a release strategy and longer support for older versions. More people need to do maintenance kind of jobs. They want to get paid and therefore more money is needed. More marketing budget is needed. More customers, commercializing the new features. No innovation from the community, no credit to the community, no fun for the community. All rules from the Bazaar style software building are broken. The following image gives a schematic overview. It is all about innovation, no innovation means no community.
If the owner is lucky he’ll earn a lot of money when selling his company. Money he can use to start working on his new idea’s. Hope he did not loose his credibility and he will again find a vibrant community. His old product now under the hood of one of those big companies dies a silent death. Again a nice open source project with a good community is killed.
This might be a bit exaggerated, there are a lot of projects out there that prove that big projects that are highly supported by a big company do not die. Maybe the user base becomes less developer minded and more user minded. A few examples are Openoffice backed by Sun, MySql backed by Sun, JBoss application server backed by Redhat and lots of others. Most of the downloads for these kind of products are done by users not interested in the source. Still the products are very interesting, with a vibrant community. You can also say that these projects are backed by companies because there is a large non-developer user base. It is this community that makes it interesting for companies to get involved.
There are a lot of open source projects out there that are backed by companies. What does that mean for Enterprise involvement in open source?
The past years were very important for getting open source software between the walls of the bigger enterprises. There are a few directions that are important. In the end it all comes down to the same thing, money. Creating software takes man hours, more software, more hours. When a project has become successful, the owner(s) feel they deserve to make some money. These owners also believe they can spend more time making next versions of their excellent projects if they earn some money. There is a catch however. Getting money for software gives you some rules. Just a few of them are, bug fixes in old releases, answering questions and strange problems of your paying users. An even harder problem is keeping your community alive. Why should people help you if you get paid and they don’t?
Another often used business model is setting up a consultancy firm backing up an open source project. These companies earn there money by offering training and consultancy for there products. You will also see that a lot of these companies provide enhancements to there products that are commercial. I think this is a dangerous model. It is hard for your users to grasp that they can have the core parts, but the nice additions are only for the paying customers. Again why should they contribute if it might disappear into the commercial part.
A recent example of using this strategy is the company Spring Source. They are the company behind the very big java framework called “Spring framework”. Rod Johnson managed to create a very large community. Spring source is becoming more and more commercial. A lot of employees of spring source are creating high-end software and they need to be paid. The guys are doing there best in creating a business that remains very open to the community. Still they have been openly criticized by the community. Of course the competing projects, and companies backing these projects, are leading the attack, but still it hurts the community to create a dual license for open source usage and enterprise usage. Recently they have come up with a new maintenance license. I really did not like it at the beginning. After reading it closely and reading the response of Rod Johnson on the serverside I do understand it better. In the end they keep on doing what they did, deliver a high quality new release every quarter and maintain that version until the next version comes out. Within the enterprise world a more demanding version support is requested. They need a release to be supported for at least a number of years. A good point of view on the spring source licensing is written down by Ben, one of the co-authors of this blog. Check the full blog item here: When good guys start looking like bullies…. Will they succeed in keeping their community? Time will tell.
A lot of companies have started with open source in their business model. ￼If you are looking for more information on earning money with open source, I recommend the book “Open source for the enterprise” by Woods and Guliani. [amtap book:isbn=0596101198]Do not forget to cherish your community and keep innovating.
Does a professional approach kill open source
In my eyes professionalism can hurt the community. The open source project will remain to have their sources open. Still the community will be endangered. This can mean that a professional approach to an open source project leads to a project with open sources and a killed community.
Of course there are exceptions, in the exceptional cases, professionalism requests come out of the community itself. This tends to happen when de user base becomes very big and lot of the users have become non-developers. Still it are the developers that need to have the ambition to come up with a things like a release strategy and a long term support. Some of the open source projects that have done this successfully are a linux distribution like Ubuntu, the whole apache organization and the Openoffice community. Companies that back open source projects need to find a way to take these professionalization steps without frustrating the developer community. Most of all the companies must keep innovating.
“Open source, fashion or commodity” by Jettro Coenradie
“SpringSource Announces Enterprise Maintenance Policy” by SpringSource
“New Spring maintenance policy” by different authors on the serverside
“When good guys start looking like bullies…” by Ben Tels