Open-source freeloaders, inventions and replacements
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.
Dave Rosenberg dishes up "Software, Interrupted" with nearly 15 years of technology and marketing experience that spans from Bell Labs to multiple start-up IPOs to open-source enterprise software companies. He is co-founder of MuleSource and currently serves as the general manager of Hardy Way. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can contact Dave via e-mail at softwareinterrupted@gmail.com or follow him on Twitter @daveofdoom. 
If you're disappointed that users are not contributing code to your open-source project, then you should solicit feedback and adapt the project to meet the criteria that would encourage your users to contribute code. Using your media pulpit in an attempt to induce guilt in your users will only make potential users run away faster.
Of course, if you want it both ways, then you're kind of wedged. Something to think about before your next trip to Sand Hill Road.
Great article.
I think some of the comments here reflect two things...
1. The bitter "cold war" that is developing between commercial software providers and software users, and;
2. A misunderstanding of open-source software licensing.
The only reason I bring up the "cold war" statement, is to illustrate how the distrust and hatred of for-profit software organizations often the catalyst that drives many software users, "free-loaders" or otherwise, to use open-source software.
Which leads me to my main point... "Free software, is not license-free software." (Through my work, and my firm, I have said those words no less than 10,000 times.)
Copyright law is such that a work, in this case a piece of software, is subject to the usage constraints set-forth by the author(s). These constraints are governed by contract.
For commercial software, the contractual consideration is typically pretty simple...
-- bring money
-- don't change anything
-- don't share any copies.
Open-source is often the opposite (in so many words)...
-- keep your money
-- change anything you want...
-- BUT if you change anything, you must share the changes.
There is obviously a COB with both. Whether it be cash, labor, resources, time, etc....
Thus... "free" is subjective, and typically a false impression.
The important thing to remember is that open-source is not "good," nor is it "bad." It is simply a form of licensing. It has its advantages, and it has its disadvantages.
Ultimately, all software is governed by copyright law. The dollars spent to use the software is immaterial, to the bigger constraints of statute.
G.C. Hutson
Chief Executive & Senior Partner
Sadien Intellectual Property, Inc.
http://www.sadien.com
It's evident that open source has been leverage to springboard great technology solutions that make it into mainstream, licensed profit models.
So, the more interesting question would be: what marks the transition between an open source solution and one that is licensed for profit? The world of open source solutions has typically drawn the line at customer support - you get the solution for free but you need to pay for support. Then, some solution providers have gone a step further and said that not only should one pay for support but certain enhancements would be paid for as well because they are not essential to core functionality of the solution.
There are shades of gray in this space that are of benefit and do not hamper community-based development.
One way around this is to go with a license that forces any derivative products to adopt the open source methodology. Of course, that means that businesses are far less likely to use such products... which would be counterproductive to your stated desire.
How does the saying go? A rock and a hard place?
- by hymanroth June 4, 2009 1:45 PM PDT
- I can't see any conflict between open source (ie. publically viewable code) and the developer(s) making money from the code itself.
- Like this Reply to this comment
-
(7 Comments)All other business models for open source either don't scale (support) or are incongruous (proprietary add-ons).
The beauty of digital content is its negligible marginal distribution cost - OSS should leverage this.