Open-source freeloaders, inventions and replacements
Much has been made of open-source disruption. But what does it take to be successful as a stand-alone open source company?
Over the last several months I've changed my opinions on open source any number of times. I like to think I'm not just being fickle and instead it's market dynamics that are shifting focus and opinion.
I was recently quoted in an article about open-source "leeches", and in many situations I stand behind the comments. As it turns out, one of the companies I mentioned is now paying, though many others are still not. Freeloaders will always be part of the open-source game, and I think we all accept that, even if it gets under your skin occasionally. At this point, I don't really care--I'd rather see more unpaid open source than expensive proprietary software in use.
In the past I've had bewildering conversations with CIOs and VPs where they told me that they wouldn't contribute code back because they had "created IP--why would we give it to you for free?" while generating hundreds of millions of dollars on top of open-source software that someone, somewhere had given to them for free. I guess that's the sticking point. Not the freeloading, but the assumption that what they created is somehow more valuable than the product that they built on top of.
This brings up a whole world of issues for those trying to build open source companies. Lately, I'm becoming less convinced that you can build a pure-play open source company if you don't fall into two broad categories: direct replacements or inventions.
Direct replacements for proprietary offerings
Replacement products need to be close in functionality and solve the same problem as the software being replaced. In the early days, this is more a function of brand and messaging but over time the functions have to be very similar. A very broad generalized example of this is how Alfresco initially targeted Documentum very heavily or how SugarCRM went after Siebel and then Salesforce.com.
It's very difficult to have a product that's almost the same but requires users to learn something new or change the way they think about the software they currently have. Take the Spring App Server as an example--it's a strong challenger to Weblogic and JBoss but the company still has to do a lot of education to potential customers (though arguably not to developers.)
The same challenge exists for most categories. If your network management product sort of acts like OpenView but isn't really a direct replacement (even if yours is better) then you have to find some differentiation to rely on versus the competition.
Inventions, or something that doesn't otherwise exist
An example of an open-source project that could become a successful business is Puppet. Without debating the technical merits, Puppet is a tool that can drive the next-generation data center and make life easier for system administrators. By the same token, you could also consider the Eucalyptus project an invention (even though it replicates the functionality of Amazon EC2) as there are no other pieces of software you can get to do the same thing.
The fact that both projects are open source is important to the distribution of the product, but people seem likely to pay for the software in some context, provided they perceive some kind of value from it.
The specifics of the value are unfortunately unique to the organization using the software and might be support or additional features or whatever. The important thing from the business perspective is to have some kind of differentiation that encourages people to give you money.
I don't believe that you can build more than a "lifestyle" business just based on support or professional services. Purity is all well and good until you want your business to grow.
Follow me on Twitter @daveofdoom.