HBR Case Study on Open Source

In this month’s Harvard Business Review, a case study takes a look at how a company tussles with open source. In this post, I shall try to save you the $17 required to buy the magazine and talk about what open source is, why it’s so powerful, and why to be careful with it.

What is Open Source exactly?

If you’re that way inclined, you can read the official definition. Here’s the short version.

• Open Source is “free as in beer”. This means that you don’t have to pay for it. You may have to cover the cost of distribution – e.g. the cost of getting a CD burned and mailed to you – but most people who are in this century use the internet to distribute software. So, you can go to a website and download a full working version of an operating system, an office suite, a browser, and so on.
• Open Source is “free as in freedom”. The Open Source movement is full of, and was founded by, lots of suspicious looking bearded people like this one. These folks say that when an open source program is distributed, you must also distribute the source code (hence the name). You also give away the right to modify and redistribute your software, and you keep the right to get props for your code.

The second part of that definition is probably more important. People in Open Source believe that innovation is so important for society that we shouldn’t restrict it in any way by keeping it proprietary. People in business believe that they can innovate, and make money from those ideas.

Both are right. This is the basic conflict inherent with Open Source.

The Open Source case study in HBR

The HBR study illustrates a very simple situation. In a nutshell, a computer game company’s star product, which includes both software and a hardware controller, has become aware of two open source projects which replicate both of these elements.

As is usual in HBR, four experts weigh in with their opinions. Some write adverts for their own companies, some give warnings without a plan, and some answer the problem. I’ll break down the main points for consideration.

The Open Source Community

If you’re getting open source replicas for your product, this should tell you something – there is a reasonable sized community of technology badasses who love your product. You probably know about user communities already, but be aware that user communities are full of segments just like anything else. A basic segmentation might look like this:

• I just want to play the game, and then leave.
• I like this game! I’ll chat about it on a web forum.
• I’ll skin my MySpace page! I might also download a mod for the game to see if I can get more play out of it, or explore hidden areas!
• I love this thing. I’m going to spend hours tinkering with the hardware or hacking the software just because I can. Maybe another little community will build up around my efforts.

This list is roughly in order, from zero to hero. You need to figure out where your user community lies, and then think about how to engage them. If you have a bunch of open source people all over your product, they will not be satisfied with skins and a user forum. They believe in free, and are willing to pay anything in time and effort to make it so.

Using Open Source

There are a pretty dry set of pros and cons for having an open source user community.

The Good:

• Faster development: You have access to more developers, so your product development curve can go up sharply. This depends on you being able to bring enough good people to the project. If you have open source copy projects already, you know this is the case.
• Love: Open Source developers are spending their spare time on the project, and they’re probably seriously geeky. They do it because they love it. This means that it’s likely you’ll be able to create high quality code. This is a fine balance, and depends on the community being managed well, and is also affected by your branding. For example, Apple’s hacking community are phenomenal at what they do, because they love Apple products. Apple don’t clamp down too hard, because they don’t want to sue their biggest fans for the negative network effects.
• Product Direction: Most Open Source developers become that way simply to scratch an itch of their own. This means that you’re getting the best type of connection between consumer insight and product development, as both are coming from the same person. Isn’t that cool? A caveat – you do need to be careful that your developer is writing something that’s generally useful and not too specific.

The Bad:

• Product Direction: You’re trying to make cash, they’re just having fun. Make sure one doesn’t kill the other. Also, because they’re volunteering their time to code, they can be tough to steer in your direction. Think about why they’re coding – to scratch an itch, or just because they love you?
• Kissing in the Ear: If your brand isn’t strong enough for them to just code for the love (Apple, Google) then you’ll need to kiss up to them a little. Developer conventions, invitations to visit company people and so on.
• History: If you have a bad rep, you may have a very tough time convincing people to love you. It’s highly unlikely Microsoft will go big on Open Source for this reason (amongst many others).

The Ugly:

• Patent trolls: These companies can just be watching for your source to come out and then sue you for infringement on some broad patent they hold. It has happened before, but also some large companies (Sun) have managed to open a lot of code without incident. Solution: make sure you’re lawyered up, prepared to use them, and everyone else knows it.

Models for interaction

So what’s the solution? To the surprise of absolutely noone, the answer is “it depends”. Here are your options.

• Sue them, and throw resource at keeping your system proprietary and protecting your IP. This is the default choice for many business types. Pros: you’ll be in a stronger position if you ever get into IP litigation with another company or a patent troll. Cons: you’re suing your biggest fans. This should be an absolute last resort.
• Open up a little way. Cons: you need to ensure your code is modular, and the user created modules are prevented from misbehaving. An example might be allowing VST or AU processing plugins into an audio sequencing application.
• Open source most of the way, but keep an essential part of your product closed. Google’s a reasonable example of this – the search algorithm is proprietary, but the backend is all running on a customised version of Linux.
• Open source the whole shebang, and forget completely about getting value from the product. If you’re all open source, everyone and their mother can copy your product, fork the code and compete with you. You can trademark things (e.g. Linux is a trademark) but in terms of functionality, you no longer have a source of advantage there. The only way to make cash here is complementary products or services. IBM supports Linux in a big way, because it’s now a services business. Perhaps a better example is Canonical, the business behind Ubuntu. It gives away an open source operating system, but makes money from support and similar services.

The Special Case of Sysadmins

We’ve talked a lot here about a straight Company -> Consumer B2C chain. What happens if you have a Company -> Expert -> Consumer B2B chain?

Let’s consider an example – network management applications. Let’s say you have a data centre and you want to monitor whether everything is staying online. You can go and buy a monitoring application from someone like Symantec, or you can download something from Open Source – nagios might be a good example.

From the company’s point of view, they just want the data centre to stay online, they don’t care how. They are offering a pile of cash, and they want a solution.

The cool part is considering the expert’s point of view. After all, this is either the purchase decision maker or influencer. If they are skilled up in using a proprietary product, some of that pile of cash will go towards product licensing, and some will go to the expert salary. If they are skilled up in using a free product that’s just as effective, all of that pile of cash will go to the expert salary. The solution is delivered either way.

So that gives experts like sysadmins real incentive to skill up on free or open source products. This is the kind of bet that Sun is making, and the kind of bet Symantec is making against. Time will tell!