Open For Business: Open source for sale

No readers like this yet.
Open for business

I have been asked to turn "Open for Business" into a monthly column, focusing on applying the open source way to business. Let the reader beware that I am not a millionaire. I don’t own multiple houses or drive a new car, but for the past eight years I have made a living running a business focused exclusively on open source software (and that’s without needing outside investment). The suggestions offered in this column fall in line with our business plan of "spend less than you earn." I hope others will find them useful.

First, I'd like to dispel the myth that everyone in the free and open source community is eager to live a life of monastic minimalism. Yes, the open source way does result in a different view of the world—one based more on cooperation than competition—but most of us have certain material needs, and we want financial security for ourselves and our families. For the most part, these require money, which leads us to the inevitable subject of sales. (In this column I’ll discuss pricing; in next month's column I’ll examine the sales process.)

Open source businesses differ from commercial software businesses in that the focus is on selling services as opposed to software licenses. This presents the first sales challenge, as people are more conditioned to buy products than they are to buy services.

At OpenNMS, the solution we’ve found is to “package” the services we offer—to turn them into products, if you will. For example, there’s the OpenNMS Greenlight Project. The client pays a flat fee that covers a week of on-site services plus a year of support. I love these engagements. Not only do we get OpenNMS up and running, but we also get to learn about the client's environment and corporate culture, which makes it that much easier to support their future needs.

Are all Greenlights the same? Far from it. Sometimes I show up, the client hands me a list of requirements, and I sit in the corner doing implementation for a week. Other times, we gather in a conference room and spend the week both solving problems and learning about OpenNMS. Usually, it is somewhere in the middle, but the point is that while each Greenlight Project is different, they are all covered under a single product and a single price. It gives the customer something with which to identify.

When it comes to pricing your products, I have to admit that that can be difficult, but there is one steadfast rule: do not try to compete on price. Let me repeat that—open source is not about competing on price.

By its very nature, open source licensing provides software with a lower acquisition cost. But the true power of open source comes from its ability to solve problems, usually complex problems, and there is value in that. Open source provides free software, it does not provide a free solution.

Determining a price for consulting and custom development services was fairly simple. I had spent over a decade doing network management consulting, and I knew the hourly rate that the market would support for basic projects.

I decided to charge 35% more.

Why the premium? Well, we're the experts when it comes to OpenNMS. We are the best people to address any issues in a timely manner, and if we can't solve the problem through configuration, we are the fastest to come up with a software fix. And, while we may charge more per hour, we get the job done so much more quickly than our competition that the overall cost is sure to be less.

Determining the right price for support, however, was a different matter.

When we started offering support for OpenNMS, we aimed to replace a large competitor’s functionality. That product came with a pretty high up-front cost, so we priced our support the same as theirs. The logic was that the customer would save on the initial licensing costs and pay the same for support.

Then, too, as we'd point out, there was no vendor lock-in. When you buy a proprietary commercial product, you have to buy support in order to get software updates, including bug fixes. This has always seemed a little strange to me. Paying for bug fixes is like saying, "You sold me a product that you said did X, but due to a bug it doesn't, so I have to pay more to get it to do what you said it would do in the first place."

Open source doesn't have this issue, since the code is always freely available. Thus we, as a support vendor, have to work harder to keep a client's business. If we don't provide the expected level of service, the client can always continue to use the product without being forced to pay for support just for bug fixes.

This price strategy worked fine in the beginning. But as OpenNMS grew, we set our sights on more robust competitors, and as the OpenNMS software became more powerful, the support tickets got more complex. It was taking us longer to address them and, for some clients, the support we provided was costing us more than we were charging—a sure recipe for disaster.

So we introduced a new product: Advanced Support. The original support offering became Basic Support. We spelled out what topics were not included in Basic Support, while any OpenNMS-related question was covered with Advanced Support. Advanced Support was priced at three times the cost of Basic Support.

It was a disaster.

Looking back now, I see that I violated one of my cardinal business rules: don't make things easier to sell—make them easier to buy. I had introduced some extra stress into the buying decision. The client now had to ask, "Do I really need Advanced Support, and if so, how do I justify the price difference to my boss?" Besides, those who’d purchased only Basic Support still asked Advanced questions, and how do you deal with that?

To address this, I bit the bullet and got rid of Basic Support. Advanced Support became Standard Support. I figured that even if we lost two clients for every one we kept, we’d still maintain the same amount of revenue. Plus, with our original competitor quadrupling the price of their product, OpenNMS support was still a bargain, especially since it could also replace other, even more expensive products.

We didn't lose a client. I'm not saying it was an easy sell to everyone, but we had finally found a fair price point that both fit within our target market's budget and still allowed the OpenNMS Group to stop living hand to mouth. With solid profits I was able to grow the company, which both improved the product and improved our support offerings.

This was key, because my business has to focus on customer renewals. Each renewal is a sale that I don't have to make from scratch. In fact, our mission statement (which we hang on the wall) is "Help Customers, Have Fun, Make Money"—in that order. If we help customers and have fun doing it, they'll find value in our services and keep using them. This means that my revenues can grow year over year, and I can drive that right back into making the business stronger.

A few final points on pricing.

Remember to make things easier to buy. At OpenNMS we now have three levels of support: Standard, 24x7, and Ultra. This makes the buying choice easy. If you think you might have need for emergency after-hours support, buy 24x7. If you are integrating the data that OpenNMS creates with customer-facing applications (such as a customer portal) such that if OpenNMS goes down, clients notice immediately, then you need Ultra. Simple.

We also publish our prices online. Some, perhaps better, salespeople would argue against this, but it serves a couple of purposes for us.

When people think free software, they think free solution. While our prices are very inexpensive compared to the products OpenNMS can replace, they can be outside the budget of smaller organizations. It saves a lot of time that we would have to spend dealing with companies only looking to spend a couple of hundred dollars.

Also, publicizing our prices appeals to our sense of fairness. We don't staff any full-time salespeople, so we don't have time to go through a long negotiation process. Everyone pays the same.

The only change we may make in the future is localized pricing. We are planning to open a European office where we can provide services during their business hours, and for that we'll have to hire at European wages. But for now the system works.

So remember: focus on spending less than you earn, don't underprice your products, and make them easier to buy.

And never forget about serving your clients. Once your customers start down the open source way, they won't turn back.


1 Comment

kudos for publishing your pricing. That definitely makes your product "easier to buy". I can't tell you how many times I've been evaluating products and have nixed those that didn't publish their price, or worse yet, didn't publish it and then put a lead followup form but then never followed up!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.