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.
8 thoughts on “People make shoes, not money: Part R0804”
Of course it’s difficult to make money on open source, just as it’s difficult for a factory to make more than one type of car and in more colours than black.
It’s all about the mindset. And I think that of legal practice hadn’t yet kept up with all the new options the last 10-20 years brought.
Exactly the discussion is good about making money via open source and etc….
We have never met, ‘tho I have heard your name mentioned by various IdM people in BT.
As web services develop, I begin to think that the whole debate about open source is missing the point. What people and organisations will pay for, when they buy a web service is a good service, not software per se. They couldn’t care less about the origin of the software used to provide the service. And thus the choice of software procurement model for the web service vendor – inhouse, proprietary, or open source – is simply a matter of expediency: how can they get hold of excellent software and support at acceptable prices ?
Or was that your point ? It’s the quality of the software / service /shoes that matter, not the business model ?
Peter, agree with your comment, although I had to read it twice to make sure I did!
John, I was trying to make a number of points. One, opensource people fix problems, they don’t build business models. If you provide value then someone will pay for it.
Separately, I have argued that the choice between build, buy and opensource is itself a tractable problem. If the problem is generic, go to opensource. Others will have solved it. If the problem is vertically constrained, go to commercial. Someone will have solved the problem for a price. If the problem is unique to your business, build it. No one else will.
I’ve had an excellent experience with the combination of open source and custom development to implement unique process using generic building blocks as foundation. So that works too. The approached saved the company a lot of money, and added quite a bit functionality for use of the community. That is your proverbial Win-win.
JP: I like your comment on when to buy vs build vs use open source; struck a chord with my own experiences.
One thing that I have been thinking about a lot recently (and not yet come to any satisfactory conclusion on) is how to deal with the increasingly overwhelming proliferation of open source products. Many competing solutions to the same problems; as many solutions as there can be communities of contributors.
In commerce the survival and leadership (in terms of market share at least) of a product is driven by the consumer pull. In open-source it seems driven by the producer push for most of a product’s life; at least until a tipping point of consumption is achieved. Products live and die based on the interest, ability and quality of contribution and then at some stage flip to a more traditional model that can then be commercialised.
Not sure yet how we tell where or when that flip for an individual product will be (or if its hapenned already).
Reading your blog entry reminded me about The Cathedral and the Bazaar by Eric Raymond. Though the book is a few years old, there are many things in there that are still related to Free and Open software business models.
Totally agree with the fact that adding value should be the first concern, and the economics should follow right after.