I read extensively, trying to make every effort to “filter on the way out, not the way in”. I try and tell myself that by doing this, I avoid painting myself into heretical corners, I make sure I am aware of other opinions; in effect, I seek to minimise undue bias by scouring the works of people whose views oppose mine.
I’m sure I still have a bunch of biases. And maybe that bias shows in the rest of this post.
Where shall I begin? I was reading a recent issue of Harvard Business Review, the April 2008 one. And in it they had one of their regular fictional case studies, this time on open source.
Headlined Open Source: Salvation or Suicide? I guess it was designed to capture the attention of people like me. And the designers succeeded.
I can’t quote the entire article: as you will see, it’s stuck behind a firewall. So here’s the blurb that HBR place in front of the firewall, provided here on a “fair use” basis:
Amp Up, a wildly popular electronic-music game, is the brainchild of KMS’s cherished programmers, who now spend their time trying to keep customers dazzled with upgrades. But a couple of start-ups have ripped off the idea using their own code–which is open source. Now they’re demanding that KMS float with the rising tide and join the open-source community. How could the company make money without its IP? And why should it try? Four experts comment on this fictional case study in R0804A and R0804Z. Jonathan Schwartz, the CEO of Sun Microsystems, says that if KMS is confident it knows what its customers will want next–and if it’s content with a small corner of the market–it should stay proprietary. But it will pay a reputational price. Eric Levin, the executive vice president of Techno Source, suggests that KMS take a middle path: license its software to third-party companies and add features to promote community building. This approach could fund itself through royalties or fees and would allow KMS to approve or veto third-party products. Gary P. Pisano, of Harvard Business School, points out that an open-source strategy could increase Amp Up’s rate of improvement, enhance users’ satisfaction with the game, and reduce KMS’s development costs. But if the company stops competing on the basis of its code, it had better be sure of the strength of its downstream capabilities. Michael J. Bevilacqua, of the law firm WilmerHale, warns that KMS risks greater liability for intellectual-property infringement if it joins the open-source community, where code carries no guarantee that it doesn’t infringe on someone’s IP rights and providers offer no indemnification.
The authors, Scott Wilson and Ajit Kambil, do well with the basic fictional case study; it is designed to make you appreciate at least some of the pressures and challenges one faces when considering open source.
Similarly, three of the four commentators do reasonable jobs in responding to the case study.
Jonathan Schwartz, as you would expect, does a good job. He takes the line that companies should figure out what kind of company they want to be before working out their stance on open source, and cites Apple and Nokia as taking valid positions at opposite ends of the spectrum … One wants to build great product …The other wants to be a great company. He seems to suggest, though, that closed source is necessary for buulding great product while open source is necessary for building great companies. I think you can do both with open source, but I can see where he’s going and I need to give it further thought.
Eric Levin from Techno Source provides a more closed perspective, understandably so. It’s a position I appreciate even if I don’t agree with it. He believes that the risk of losing control of the product life cycle (and with it the company brand) is too high, and tries to develop a middle way. I don’t think he quite gets open source as yet, but it doesn’t mean he won’t ever get it, he’s just out of his comfort zone.
Gary Pisano from Harvard Business School then does a fine job drawing out the value of community implicit within the open source model. He exposes a number of the key benefits derived from the adoption of open source (speeding up the rate at which the core product improves; providing users with greater choice as a consequence of community-driven development; reduction of the firm’s cost base in development as well as in maintenance). He also points out some of the prerequisites: the way the software needs to be architected, and the importance of knowing how to get traction in a community.
And then I got to the fourth commentator. And read his commentary. Now I’m a passionate person, and I get passionate about the things I believe in. I’ve been known to laugh out loud while reading in bed, cry while watching a tear-jerker, I don’t have a problem showing my emotions. But it’s rare for me to show emotion while reading HBR. No, not rare. Unheard-of.
I felt like a harrumphing retired major, moustaches twirling in disgust, monocle clashing with the fountain pen as it flew across watermarked linen-enriched writing paper, preparing to return my medals in pompous prepaid envelopes. Disgusted from Denham. That’s how I felt.
This fourth commentary was written by Michael J Bevilacqua from Wilmer Hale. Here are some excerpts from his piece:
“open source code comes from an amorphous community of unknown people, and parts of it are much more likely than homegrown software to have been copied from someone’s proprietary code”
“unlike software that is available for purchase, open source coe carries no guarantee that it doesn’t infringe on some third party’s intellectual property rights”
“Nor do most open source providers offer the indemnification — that is, legal protection — that vendors of proprietary software do”
By this point I was mildly irritated.
He then went on to warn about what happened to Autozone in 2004 when they got sued by SCO. [At least he bothered to mentioned that it was SCO that eventually filed for bankruptcy protection. Having irked me by using the AutoZone example to show the dangers of open source, he then had the temerity to bring up patent trolls as a reason to consider open source software as risky. That’s like saying living at home is dangerous because burglars exist.
So I went from “mildly irritated” (moustaches vibrating metronomically) to “somewhat irked” (moustaches twirling in terrible tandem). More was to come.
The article ended with this sentence:
Most software companies, however, are in business to make money, and it is very difficult to make money on open source.
[The Major’s moustaches were by now in open revolt, Daliesque in their disgust.]
What utter and absolute tosh. And in the HBR, no less. I am appalled.
Mr Bevilacqua may never understand open source. But maybe he needs to understand Peter Drucker, at least a little bit. [And I get to trundle out my favourite Drucker quote yet again!]
People make shoes, not money.
Or, in this context….. People make software, not money.
And when the shoes are good, they make money. And when the software is good, they make money.