In 2002 I was working for Oculan, a company that founded an open source network management application platform called OpenNMS. Oculan used this platform as the basis for a network management appliance, but my job was to create a services and support business around the platform itself.
In May, just after the release of OpenNMS version 1.0, Oculan got new investors, who decided to focus on the appliance and to stop working on OpenNMS.
I knew that without at least one person dedicated to OpenNMS it would die, and I wasn't ready to give up on it. So I went to the CEO and asked to become the administrator of the project. We talked for a bit, and then he looked at his watch and said that if I was off his payroll by Friday, he'd give me a couple of servers, the OpenNMS domain names, and his blessing to continue on with OpenNMS.
That was the easy part. Explaining to my wife that I had quit my job was much, much harder.
You might think that I was motivated by some sort of idealistic love of open source software. Nothing could be further from the truth. At the time, I was still running a Windows desktop. I undertook the OpenNMS project because I believed one thing: in the area of network management, open source represents the best business solution.
This is important. I don't want to denigrate the efforts of those open source volunteers who work on projects because they enjoy it. I feel a strong attachment to OpenNMS, so I understand. But there is a difference between doing something for love and doing it to make a living.
When I was working with commercial management products like HP's OpenView, I would attend sales training for Value Added Resellers (VARs). In those sessions, HP would point out that for every dollar spent on software licenses, a VAR could expect eight dollars in services revenue from software implementation. In my experience this was true, if not a little on the low side. At one job, I worked for a company that did nothing but provide services on commercial management products, and they refrained from selling any software licenses at all on the grounds that they wanted to remain vendor neutral.
The following scenario was unfortunately not unusual: I'd schedule a week at some far off client, and I'd fly out on Sunday. On Monday I would install the software, and that usually went pretty smoothly. But then sometime on Tuesday, I'd find a bug that would bring my entire project to a halt.
I'd call the vendor who, more often than not, was aware of the issue. Great! When can I have the patch? Their answer: four to six weeks.
(Sigh.)
Another scenario that was even more common is that the client would have some sort of unique business process that needed to be monitored, but the default monitors that shipped with the tool couldn't handle it. Instead of being able to tweak it as needed, we were stuck trying to fit the business process to the tool.
Enter open source.
My early experiences with OpenNMS caused me to understand that open source offered a better alternative. Since the code was available, patches could be applied immediately. Also, this enabled me to fit the tool to the business process and not the other way around. Both of these things would radically reduce the time to deploy and, without licensing costs, clients could even save more money.
The reason I decided to start an open source business came down to providing a better solution—nothing more. Instead of paying a dollar for the software license, the client could keep their dollar. Instead of spending eight dollars on services, the client could deploy a solution for, say, half as much. I got to do something I loved, get paid well for it, and still save my clients money.
As I thought more about this, it dawned on me how revolutionary open source could be in the enterprise software market. Here's a little thought experiment:
Suppose one could divide a software market—say network management—between two products. One did everything possible and cost $1 million, and the other only did 10% as much, but was free and open.
The price tag of the commercial solution would automatically filter out a large number of users, and those people would have to turn to open source. But some users would be satisfied with the 10% functionality and choose it outright.
For example, I have an original Macintosh computer on my desk. It runs a word processor called MacWrite. It does everything, with the exception of spell check, that I need a word processor to do. I can format paragraphs, choose fonts, make text bold or italic, and even paste in pictures and graphs. All in a "what you see is what you get" user interface.
It takes up 76K of disk space. That's "K" as in "kilobyte."
Compare that to Microsoft Word. I think the last time I installed just Word it was around 30MB, many times larger than MacWrite, but I don't use it for much more than I use MacWrite. Like me, many users are happy with basic functionality. They don’t need all the bells and whistles.
But back to my analogy. In the beginning, the commercial company would probably ignore the open source project. It represents no threat to their revenue stream, so why should they pay attention to an upstart?
If this project is healthy and sustainable, however, in a year or so perhaps it does 15%-20% of what the commercial product does. This should bleed a few more users from their business, and maybe now they start to pay attention.
Most likely, this attention would take the form of marketing against the project. They would claim it is too small or too underpowered to take seriously. And in the short run this would probably work. But the mere fact that they acknowledged the project would pique interest. Some people would determine for themselves that it was neither too small nor too underpowered and would start using it.
Another year or two goes by and now the project is up to 50% of the functionality of the commercial product. People start joining the project in droves. The commercial company now has to do something. What do they do? They add more features.
Remember, the commercial product already did 100% of what people needed. So what kind of features could they add? Unnecessary ones. They might change the look of the user interface or add features outside of network management. In any case, this development will cost money, and that will start to eat into the company's margins.
Finally, with a healthy community and this influx of new users, the open source project will eventually approach 80%-90% of what the commercial product does. Having exhausted all avenues of generating revenue, the commercial company still has one final option: put the screws to their remaining customers. Find ways to charge them more, to eek out what they can from their investment, which ultimately will drive their clients away.
Farfetched? I don't think so. There are only two main requirements:
First, find a market where open source provides a compelling alternative, such as network management.
Second, build a sustainable community around the open source project.
This latter bit is not easy. I'll write more about that in my next two articles.
In conclusion, I should add that the first year I spent as the admin of OpenNMS cost me $5,000 of my savings. I've made money every year since then, and currently the commercial arm of the project has a dozen employees in three countries and seven-figure revenues. Oculan closed its doors in 2004.
Open source isn’t just a good design philosophy; it’s good business.
This is the first in a series of articles that will explore starting and running an open source business.
10 Comments