Wednesday, October 04, 2006

Dana Blankenhorn: Open Source and the Mass Market

Over at ZDNet, Dana Blankenhorn has posted a bit about the dearth of open source market share for mass market software. He runs through the usual suspects: lack of scale in open source enterprises and no structure to deliver comprehensive support. He then suggests an idea for a company: "Corporate Office"

We take OpenOffice, we hire top committers to it, and we sell support packs to businesses at 10% of what they're paying for the other guys. We donate the templates and other code we create to the community. We make a ton of money.

Does this strike you as a tad naive? My theory about open source and the mass market is that there needs to be a compelling reason to switch to open source software *and* it has to be cheaper. It's simply not good enough to be either/or. Especially when we're talking about desktop software used by businesses - they'll pay top dollar for more features if they're over and above everything else that's available. What might actually work is if Dana employed his plan with a couple of changes:

1. include every feature that customers/users expect from the other stuff, *and*
2. charge less than they do.

Human beings can get very comfortable with an existing environment, and getting them to switch can be a pain, especially when you force them to make tradeoffs that don't necessarily work in their favor.

The primary problem with mass market open source software is that the perceived benefits of participating in a software development community doesn't really apply to the vast majority of people that use a computer. I think it's fun to participate in these communities, mind you, but I doubt a majority of people whose day job entails pecking around on a PC feel the same way. In fact, I would say this is the realm of a very small majority. If they get no joy from being a community participant, and they don't feel that all of the features are there, then they're not going to feel compelled to switch just because it's cheap. Look at OpenOffice - it's dog slow, it doesn't include all of the features of Microsoft Office, and oh sure, it's much cheaper, but in the grand scheme of things, paying around $200 less per person in an organization is basically peanuts. The OpenOffice experience is fundamentally broken and simply does not offer organizations a compelling reason to switch. Now if someone came along and made it at least faster and more responsive than Office... and fixed all of the buggy behavior... and kept it free. Well then, that might be a compelling reason for some people to switch, but there's still the matter of fewer features (as a sometime book editor, I can testify to the severe limitations of OpenOffice for this task).

Now let's contrast this with something like Mozilla - better user experience, no lack of features, and even then, it struggles to overcome the 10% user base barrier. This means that 10% of people have found a compelling reason to switch, and the rest have not.

Basically, what it boils down to is that in order to get mass market acceptance, you have to offer *more* than what already exists. At this point, "more" just doesn't apply to open source desktop software. Data center and enterprise software vendors can overcome this limitation because their customers enjoy the participatory process. Their users are geeks, and they thrive on the back-and-forth with ISV's that value community. Not to mention, the enterprise software market isn't necessarily about features - there's plenty of room for vendors that provide a solid platform on which to integrate other stuff in the data center. Not to mention, many IT managers and sysadmins follow a "less is more" principle, further diminishing any feature gap that may exist.

<cue rant>
...and many people wonder why I detest Red Hat. Red Hat makes its living from the soft belly of old Unix users. Red Hat seems to think it doesn't have to worry about converting old Windows users and giving them a compelling reason to switch. Red Hat also seems to think that they can simply make do from the enterprise data center sale... but I would like to point out that this strategy has definite limits and does no good in terms of priming the pump of converted Windows users. In fact, Red Hat is not giving young Windows desktop users a compelling reason to switch. One could argue that Red Hat's potential market has hard limits and that, as long as they see no reason to push desktop usability, their potential market will not grow. Oh yeah, and guess what - OpenSolars ain't going away, and Microsoft's not stupid, either. It's going to be very interesting to watch Red Hat get eaten from both ends.
</end rant>

Tuesday, September 19, 2006

Open Source vs. Closed - Another Look

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.

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 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.