Open-source Sunday School: Milk before meat
Open source is best when it's gradual.
Whom shall he teach knowledge? and whom shall he make to understand doctrine? them that are weaned from the milk, and drawn from the breasts.
For precept must be upon precept, precept upon precept; line upon line, line upon line; here a little, and there a little:
For with stammering lips and another tongue will he speak to this people. (Isaiah 28:9-11)
Anyone that has tried to ramrod open source into an organization will appreciate this counsel from Isaiah. As a market phenomenon, open source - be it Linux, Apache, MySQL, SugarCRM, MuleSource, or another project - almost always has begun on the fringes of IT. With Linux it was the edge-of-the-network server at first, until it eventually claimed the data center. With many commercial open-source projects, the first entree into an enterprise is at the departmental level (and even before that, with the individual developer's desktop).
Milk before meat. Here a little and there a little. Start small (as with my two youngest daughters to the right) and grow into greatness. Getting there depends on patience, as Marten Mickos and Larry Augustin have individually written:
When I see the fantastic growth MySQL is experiencing now, I never forget that it took us 12 years to get here. I like to call it a "get rich slow" scheme. Of course, it is easy for us to say now that we followed the right path to success. But over the past 12 years, there were many times when it wasn't evident that this would happen.
For the first six years, the team focused exclusively on perfecting the product. It takes time to create precision instruments - that's why the Swiss are best at watch-making - and we spent a lot of time on our product. During this time, MySQL had no sales reps, no marketing staff, no consultants, and only a small number of paying customers.
Startups wanting to copy our success need to be aware of the significant ramp-up we invested in. Because the MySQL database is an infrastructure product, that growth probably took longer than it would have for an application or consumer product. But the growth phase of the company really did not start until after the product was fine tuned and I was brought in as CEO after five years.
Instead of pushing an open-source business too fast, Larry suggests:
...[I]f the product does not have the adoption and usage to generate pull, the model won?t work. The initial temptation is often to fix this problem by creating "push" (i.e. spending money on BMW-driving sales reps to push the product). While push may be an answer, the real answer needs to come from an understanding of why the adoption isn't there. Why aren't people downloading, installing and using our product? How can we better understand the needs of the user, and make our software more useful to them so they will want to use. After all, we're making the software and source code available for free. Price is not a barrier. If people won't use our software for free, how much good is push really going to do?
Open-source projects must be precept-upon-precept businesses. Zimbra got rich pretty quick, showing that there are ways to accelerate the open-source commercial process. But not too fast. For one thing, the market is still discovering open source. For another, the faster you try to flog an open-source project, the more inclined you are to do things that end up destroying the spirit of a project.
Milk before meat. That's the way open source continues to grow in the market.
Sleepy jack the fire drill.