A recent post by Matt Asay got me thinking about the real vs. perceived benefits of open source. In the past, it has been taken for granted by open source supporters (myself included) that the more open the process, the more easily one could build a community, fix bugs, add features, and trample the competition. However, I'm beginning to wonder if software need not necessarily be open source to actually derive the same benefits usually associated with the open source process. I've never been sold on open source as a means to get developers to write code for free. Rather, I always chalked up open source's continued success to a couple of factors: the more open process usually wins because the bar to access is lower and the internet has driven down the price of commodity software, thus creating an environment conducive to open source proliferation (read "There is no Open Source Community"). Now I'm wondering if software vendors can actually create a community, engage with it in an open process, and derive benefits from an active (and activist) community without actually making any of the software open source.
Let's engage in a little thought experiment. Let's say a software company makes a widget that greatly enhances the IT experience (and we'll focus on the data center IT market, because that's the devil I know). Let's also assume that it doesn't have any funky proprietary protocols that won't play nice within an existing environment - all interfaces are standards-based (RSS, HTTP, DAV, SMTP, SNMP, etc. etc.) We should also assume that the API's are thoroughly documented and easily accessible, perhaps with an open source dev kit thrown on top to ease the developer curve, although even that need not be open source. And of course, given this market, they have to have a free, usable download that potential users and customers can take and deploy - and when I write "usable" I mean capable of doing real work without having to buy a product. Given all this, what possible benefit would this company derive by taking an additional step and making it open source?
Given the above, a software company can release stuff, build a user base, encourage participation, engage with their community via forums, bug trackers, blogs, the whole bit. Users can download, extend the software via a dev kit, test for bugs, and most of all, use it for everyday work. Theoretically, they will become so enamored with it that they will someday buy the supported product or recommend someone else to purchase. Potentially, this software vendor would lose the benefits of a security audit or contributed patches and extended features. However, this type of contribution is so rare, that one might take the view it can be discounted, since one can never depend on that type of collaboration.
To take this thought experiment one step further, let's say there are two competing software platforms/products/suites/whatever-you-want-to-call-it. Let's say that the differentiation between the two is a toss-up in terms of features, reliability and support. The difference is that one is open source, and the other is merely "an open process", but you can't see the code. I suppose you could argue that it's more difficult to support multiple platforms with closed software. However, my experience with commercial open source is that the impetus for supporting more platforms comes from the software authors, not outside contributors. In my experience, outside contributors overwhelmingly use commodity Windows, Linux or FreeBSD on x86 hardware, and the decision to support other platforms comes at the behest of customers that need HPUX, Solaris SPARC, or AIX. You could argue that customers can take open source and make it run on their platform of choice without support from the vendor, but that's not usually the way procurement works. Usually, the customer looks at what platforms are supported and make their choice from there.
In the past, I argued that a small edge in openness would make a difference in the long run, simply because the more open the software, the lower the bar to entry. However, I would say that the bars to entry rest more on usability and ease of deployment than anything. You would, of course, lose free software advocates, but I would argue that this comprises a small minority of IT staff or management. From this thought experiment, it would seem that you can derive the benefits once thought to be the domain of open source without actually going open source. When most open source supporters think of closed software, they immdiately jump to the image of oppressive EULA's that severely restrict the freedoms of the end user. However, a software vendor need not construct an oppressive EULA just because they are closed source. Proprietary software can be freely redistributed with few restrictions on software usage. I suspect that the arguments on open source and proprietary have been a bit too skewed to the extremes. There seems to be an unexplored middle ground that vendors can use to their advantage - make it free enough to use and distribute, but not open up the code.
Now for the flip side of the argument: if company X is going to be that liberal with their licensing, what advantage do they maintain by not going full monty open source? The old bugaboo FUD about open source - that competitors can copy your features, steal your IP, and subvert your development process, have not reallly turned up in the real world. In the software market, these tactics can be spotted, and there are IP laws that can enforce compliance (assuming a GPL-like license, of course). Furthermore, the framework and platform for separate software products, even if they're direct competitors, are most likely vastly different, and the amount of work needed to shoehorn one algorithm or feature into another platform will most likely be just as costly, if not more, than developing a feature in-house. And let's face it, even with the most closed software, features are open to everyone's eyes. You don't need access to the source code to see new features.
In conclusion, I don't see any clear advantage of releasing software under an open source, GPL-like license. However, I don't see much disadvantage either, so in a crowded market, it's probably best to err on the side of being more open than your competitor.
I have a suspicion that Microsoft is looking at this very argument - they probably feel that they only need to be "open enough" to stave off much of the open source competition. Given their market position, they're probably right.
My company, Hyperic, has taken the view that it's best to err on the side of openness, especially given the crowded market for IT software. Another company with a similar target audience but different type of product, Splunk, has taken another view: that they only need to be "open enough". It will be interesting to see which tactic is more successful over the long term.
Tuesday, September 19, 2006
There is no Open Source Community - the Original Article
So a while back, I had an epiphany that allowed me to answer the question, "Why do open source companies exist?" and "How do they stay in business with a freely available core product?" The answer I came up with is that companies released software because they had to - that the internet had some interesting effects on the software market as a whole, resulting in depressed software prices, thus creating an environment conducive to an open source ecosystem. The folks at onlamp.com were kind enough to post it, and it stimulated some interesting arguments on Slashdot and various blogs on the net. I think I was mostly right in that article, but there are a couple of conclusions I reached about which I have some doubts. You'll see some of that expressed in the post after this.
In any case, I have enough thoughts on the subject, that I've decided to make this a blog on its own right, and leave my personal stuff on my main blog.
In any case, I have enough thoughts on the subject, that I've decided to make this a blog on its own right, and leave my personal stuff on my main blog.
Subscribe to:
Posts (Atom)