Author: JP

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.

Whenever I travel I tend to go through a goodly supply of books, papers and magazines. Yesterday was no different. And quite often, while I’m doing this, I tend to collect scraps of paper, articles that I’ve torn out of the newspapers and magazines in order to carry less.

Later, when I’m awake doing that early morning jet lag thing, I tend to read the ripped-out articles a second time and then dispose of them in the hotel room. That’s what I’m doing right now.

One such article was entitled How to destroy brand-new automobiles. Taken from the Wednesday-Thursday edition of the Wall Street Journal Europe, the article dwelt on the challenges Mazda had in getting rid of $100m worth of brand-new cars, in order to avoid the risk of brand damage via the Katrina car approach.

One particular paragraph really got to me:

It took more than a year to devise a plan that satisfied everyone. The City of Portland wanted assurance that nearly 5,000 cars’ worth of antifreeze, brake fluid and other hazardous goop wasn’t mishandled. Insurers covering Mazda’s losses wanted to be sure the company wouldn’t resell any cars or parts, thereby profiting on the side. So every steel-alloy wheel has to be sliced, every battery rendered inoperable and every tire damaged beyond repair. All CD players must get smashed.

I remembered the same thing happening during the run-up to Year 2000, when many institutions were junking computers in reasonable working condition, but weren’t able to donate the equipment to anyone or anything because of the insurance implications, or weren’t willing to donate because of the putative risk to the brand.

It just feels wrong, trashing something that still works and that still has value to someone. There is something weird about making sure someone else cannot extract any utility from a resource. It’s like putting poison in butter mountains in order to prevent someone from even thinking of doing something with the surplus.

I’ve spent a lot of time in charity shops and remaindered book sellers, and I had the same feeling when I saw covers purposely mangled (to denote remaindering). What is it about us, what is it that makes us do things like this?

And it’s not just physical resource. Sometime over the last thirty years, I worked somewhere where there was something really strange in the middle of an open-plan floor: a bunch of desks that had been chained off from the rest, with the equivalent of police tape across every possible entrance to that particular cubicle desert. Why? None of the profit centres wanted that space. So the people in Facilities figured that nobody should be able to use the space. Until that day, it was a useful ad-hoc meeting area, a place where informal meetings and workshoips took place. But the gods of Facilities decreed No Tickee No Washee.

All this made me think. For some classes of software, we need to write software that will last 200 years, as Dan Bricklin suggested. But that is not all. There are other classes of software, other classes that require different treatment. We also need to write software that does not damage “the environment” when we want to stop using it, for whatever reason.

We need to build applications where the cost of decommissioning is at least as low as the cost of commissioning them, to paraphrase Clay Shirky. [I quote his “when the cost of repair is equal to or less than the cost of damage, all is well” idea quite regularly.]

Software needs disassembly lines.

One more thing. The Mazda incident also brings out the issues and costs involved in dealing with toxic substances. I have this nagging feeling that we have something similar in social networks, from a privacy angle. Over time, social networks collect “toxic” or “hazardous” information, information that has to be disposed of carefully and securely. What happens, for example, if one of the major electronic social networks goes bust? Who makes sure that customer data is dealt with securely? We already have examples of secure disposal of physical information and of physical media.

The treatment of digital assets is still in its infancy, and we have a lot to learn about it. Like who looks after this blog when I die? Does it die with me? Should it?

Recently I spent some time considering the differences between traditional office e-mail and facebook e-mail: the lack of bc, cc and forward buttons, the way links and videos and sound files are attached, the absence of spreadsheet and document and presentation attachments, and so on.

All that got me thinking. For a while now I’ve been studying the youth of today and how they use the tools of today. For a while now I’ve been exploring the likelihood that when the youth enter their equivalent of what we call employment, they’re likely to enter it with their tools. Tools that they’re trained to use. Tools that they’re good at using. Tools that I know less than enough about.

Take cameras. Go talk to a couple of dozen people at random. Find out if they’ve ever sent each other mobile photos. Ask them if they’ve ever used MMS. Check with them if they’ve ever uploaded mobile photos.

I did just that. And it seemed to confirm what I thought. The bulk of people using their mobile phones as cameras were below 30. Try it. Let me know what you find out.

My assertion is that Generation M knows more about the usage of mobile phones as cameras than we do; that they will find ways of using it in the enterprise, ways we have not considered. I remember a time when we’d purchased one of these newfangled basketball nets; I was away at the time, my wife had asked the handyman to put it up, and he was having some trouble with it. My son had a friend who had the same equipment; a phone call, a photograph, and suddenly light dawned.

Even old fogeys like me find uses for mobile phone photographs. Take book purchases. A goodly number of the books I purchase today are based on recommendations or on collaborative filtering. [In fact, quite a few of the recommendations come from comments on this blog or via Twitter]. Which is fine, except for when I’m physically at a bookstore and I see a book I like the look and sound of. If I’d read the author before then it was simple. If I’d heard good things about the book before then it was simple. But what happens when I had no information other than what I saw in front of me?

Simple. I took a photograph of the book. A normal wander around the bookstore may yield eight or nine photographs. Later, when I was back in a connected environment, I would go through the titles one by one, check them out in a more leisurely manner, look at the reviews and recommendations and then order the titles that made the grade.

I’ve done similar things with flipchart and whiteboard sessions. Taken a photograph and then reflected on the contents at leisure. When someone is demonstrating something new to me, sometimes I do the same thing. But for all this I don’t tend to use the phone, I use a “proper camera”. And upload the photos on to Flickr.

Which brings me on to the use of Flickr and YouTube in the enterprise. I’ve now seen both used in anger within the enterprise, and I’ve been delighted to see their use. You want to share something quickly over a great distance? Take a photograph or video of what you want to share. Upload it, tagging it with something arbitrarily odd like “zv54yng31”. Send the tag to people with whom you want to share the image or video.

And bingo. It’s there, using the internet and commodity tools. Hidden in plain sight, a readily findable needle in a commodity haystack.

Like the story of the Fisher pen and the pencil, there are expensive ways of doing things, and smart ways of doing things. We’re going to see a lot of this. The youth of today are going to use everyday tools to do everyday things. It’s just that their everyday tools and techniques will differ from ours. We need to prepare for this.

New forms of etiquette will emerge to deal with these phenomena. New mistakes will be made, new lessons will be learnt. There is a lot we don’t know about this, but there is one thing we can be certain of:

The Web is normal and commonplace for the youth of today, and the web’s tools are as familiar as friends. They will use the web and its tools in ways that we haven’t dreamt of.

[An aside. About embarrassing photographs appearing on Facebook. When I was young there was an equivalent. People used to do the most amazing things on photocopiers. And then the photocopies would do the rounds amidst gales of laughter. Admittedly this was the kind of thing that happened at office parties.  I don’t remember any horror stories in the press, any calls to avoid going near photocopiers. ]