We were contacted this week by a company in Sweden asking about “per incident” support. We don’t offer per incident support and I thought this would serve as a good example to explain why.

OpenNMS is free and open source software, so we make no revenue on software licenses. Thus there is no financial incentive for us to spend time installing it and trying to convince people to use it. Commercial (and open core) companies sell software licenses, so they can afford to send people out for non-paid “proof of concept” engagements since there is a calculated chance they would make the money back when and if the software was purchased. We can’t.

We view ourselves more along the lines of doctors. Everywhere I’ve lived the local physicians were some of the most affluent people around, but no one walks around saying that doctors can’t make any money since they don’t sell the medicine they prescribe. Likewise, no one would go to a doctor and say, hey, why don’t you treat me for this ailment and if I like the degree and speed by which I get better I’ll pay you.

We charge around US$1750 for a day of consulting, so this is the yardstick by which I have to measure our time. With our support subscriptions this is pretty simple. We spend a lot of time with the customer for the first few weeks, but it quickly drops off as their OpenNMS installation is completed and moved to production. Since it renews each year, the investment we make in Year One pays off in later years.

This doesn’t happen with per incident support.

While we encourage our clients to become well versed in how OpenNMS works (one reason for both COVER and our training programs) we also want them to rely on us for questions. There is no reason to spend two days searching the list archives for a solution that we can provide in a few minutes. This benefits the client by having their question answered quickly, but it also benefits us by demonstrating our value.

Now, when someone wants per incident support this usually means that they have spent time exhausting the free resources of the wiki and the mailing lists. Chances are that they have uncovered a real problem.

Let’s say that the average bug takes us two man-days to fix. At US$1750/day I would have to charge US$3500 per incident to break even. That seems a little extreme, but let’s say that I do it. The client might be happy if it solves there problem.

However, suppose someone calls up, buys an incident and the answer is “Oh, just change that flag from ‘true’ to ‘false’ – that’ll be $3500 please”. They’re going to be angry. With a support subscription we love questions like these, which actually make up a good portion of our trouble tickets. But you can bet that per incident support clients wouldn’t like it – they’ll only be happy if they have reported an issue that is difficult to resolve. Those issues cost us a lot in terms of time and it is hard to turn that effort into a recurring revenue stream.

So we only offer support subscriptions. For us, it is the best balance of being able to help our clients as well as to stay in business.

This week we got a call from a company in Sweden asking about per incident support. As expected, they had posted their question on the mailing lists but had not received a satisfactory response. They were sure it was just a configuration issue and it shouldn’t take us much time to resolve. Famous last words.

We’d determined that the problem was a bug that had been addressed in OpenNMS 1.6.1 and suggested they upgrade. They were under a time pressure and so we sold them a day of consulting where we would ssh in to their system and upgrade it.

It was a good thing we were there. Not only was the upgrade difficult (it was from 1.5.90) another problem had been introduced in the process. The client had made some changes to their firewall and it was slamming the OpenNMS system with a tremendous number of traps. While OpenNMS can handle a large number of traps, this was about 17,000 traps every 5 seconds. OpenNMS was running on a lower-end system that just couldn’t handle the load, but it wasn’t immediately apparent why the OpenNMS performance was so poor.

Like a doctor, we have the experience to troubleshoot such things and once Jeff identified the issue we were able to configure OpenNMS to discard many of the uninteresting traps. Once OpenNMS was performing well again he spent a lot of time cleaning up the configuration files to make sure all of the customer’s issues were addressed. It took most of the day.

Thus the reason we don’t have per incident support can be summarized with it is too hard to price fairly and most “incidents” are more than a single problem.

Since this was a paid engagement we can add Sweden to the list of countries where The OpenNMS Group has clients – bringing the total to 18. I know of many more countries where OpenNMS is used, so perhaps in early 2009 we’ll break 20 or more. The client in Sweden seemed real happy with our services so I’m hoping that they’ll consider a support contract, and now with COVER you couldn’t find a better time to sign up.