Mercedes Profitable

A few weeks ago I commented on a Paul Graham post about being “Ramen Profitable” with a reply that at OpenNMS we were “Sushi Profitable“. I also speculated that one day we would be “Mercedes Profitable”.

Well, I wouldn’t say we were there yet, but I did buy a Mercedes.

To be honest, I didn’t pay all that much for it (I bought it from friends) and a C230 isn’t exactly the best example of the marque (as this “Overhead in New York” points out) but I like it.

I can’t see spending a lot of money on a car. I mean, I could pay myself a bonus or get a company car, but we try to plow all of our profits into making the company stronger. One way to do this is to hire more people and, as we are having a good year, I am happy to announce that Jason Aras has decided to join our team.

Jason has been involved with OpenNMS for years now. He is a member of the Order of the Green Polo and can often be found on the IRC channel as “fastjay”. He even came out to Germany, on his own nickel, to present at our first OpenNMS Users Conference. We are very excited to have him on board.

I am often asked how one gets a job working on OpenNMS, and the best way is simply to show us what you can do by getting involved. It may sound a little self-serving, but we’ve been successful by attracting people who really enjoy what they do. It is the second part of our mission statement: Have Fun. If you wouldn’t spend some of your time on the project “for fun” you probably wouldn’t enjoy it as a job, either.

When I was in college the big thing was to co-op. The co-op program let you take time off from school to work, preferably in a field you were hoping to enter, both to earn some money and to see if you liked it. I think open source provides an even better opportunity, as it allows people to really hone their skills, both in things like programming as well as working in a team, through the simple act of showing up. It can provide experience that one can put on a resumé which shows initiative, talent and the ability to work remotely and with others.

And who knows, there might even be a paying job in it.


The roads in San Antonio are something to behold. Immense concrete leviathans that snake above the ground, surrounded on both sides by access roads that are superhighways unto themselves. My GPS goes crazy because it is simply not accurate enough to tell if I’m on the frontage road or on the highway above.

Think I’m kidding? In downtown on I-10 they actually have signs indicating “upper level” and “lower level”. That’s right, they built an interstate on top of the first interstate. I almost wrecked looking at it, as it is quite the engineering feat. The upper deck is cantilevered way out from the supports. It’s amazing.

I was downtown to meet up with Eric Evans. Eric is also amazing: Debian maintainer, OGP Emeritus and a self-taught developer who has probably forgotten more about code than I’ll ever know.

I met Eric back in April of 2002 when I first started doing work for Rackspace. He is now working on the Rackspace Cloud, where Rackspace has dedicated full time resources to the Apache Cassandra Project (I knew I loved these guys for a reason).

During the meal the topic of roadmaps came up. Someone on the Cassandra IRC channel had asked about a roadmap and Jonathan Ellis replied with a list of things they had targeted for the next few releases. This didn’t sit well with the questioner. He wanted something a little more solid, with firm dates, etc.

The answer was: that doesn’t exist. The development team is dedicated to moving Cassandra forward, but needs and priorities are very fluid. They are more focused on doing new, useful, and interesting work and not in meeting some sort of artificial deadline.

[Note: this is my interpretation of the story and may not accurately reflect the thoughts of Eric, Jonathan or others within the Cassandra project.]

This reminded me a lot of how OpenNMS is developed.

We always have at least two releases of OpenNMS going at any one time. The stable, or production, release experiences as few changes as possible and most new code is designed to address bugs. The second number in the version is always even: 1.0, 1.2, 1.6, etc.

Then there is the unstable, or development release. The term “unstable” has nothing to do with the robustness of the code, but that whole chunks might change from release to release, which in turn can introduce bugs (although the main goal is that any outstanding bugs in an unstable release are minor or cosmetic). The second number in the version is always odd: 1.1, 1.3, 1.5, etc.

We have various feature targets for each release. For example, 1.8 has two main features: a new provisioning system and access control lists. Thus 1.8 will be done when those features are complete. When we believe that the main coding has been done for 1.8, version 1.7.90 will be released. Chances are there will be a 1.7.91, 1.7.92, etc. Once we are happy that it is worthy of production use, it will be christened 1.8.

There is one more feature coming in 1.8: documentation. OpenNMS is really an amazing piece of software worthy of the name “network management application platform” but more than half of the features are undocumented or at least underdocumented. This will change.

So, when will 1.8 be released? The smartass answer is “when it is done” but the truth is I don’t know.

There is one other factor in the mix, and that is the commercial company behind OpenNMS. While we have a very active community, most of the code comes from people who get paid to work on it, simply because they can work on it full time. With our business plan of “spend less than you earn” we have to focus on the bottom line, and a good portion of that income is the result of custom programming projects. Right now we are in the middle of two big projects with two more waiting in the wings, and thus we are pretty much at capacity when it comes to working on the main features in 1.8. This doesn’t mean we’re not working on them at all, but other things take precedence so it goes more slowly than I would like.

I’m sure there are people out there who will advise me that this is the wrong way to go about it. You need a firm roadmap, they’ll say, and they may be right. But I have to rationalize what I want with what I can afford to do, and something has to give. I could focus all of our resources on getting 1.8 out, but then there might not be a company around to support it when it is done. Plus, one of the things I go on and on about is the flexibility of open source software, and if I am not able to provide custom solutions to clients how true can that statement be?

There are others who might say that this focus on client code isn’t “open source”. Fully 100% of the code we write is published under an OSI approved license. Heck, you can even see what we are up to by browsing the subversion repository or subscribing to the opennms-cvs mailing list. We are completely transparent in that regard.

Finally, we plow all of our profits back into the project by hiring more people. I’ll have an announcement along those lines next week.

Some might say that the lack of a roadmap means less releases and thus less press to entice new users. That may be true as well, but at least we’re at a point where a large number of people don’t even know OpenNMS exists and, once they do, find that 1.6 is more than adequate to address their management needs.

So, to summarize: yes, we have a roadmap for OpenNMS but it can change over time depending on custom development we get paid to write. The upside is that most of that development is of benefit to other users, and often comes with a timeliness that a static roadmap couldn’t match.

The OpenNMS roadmap evolves in a way that both addresses the needs of our clients and keeps us in business. That’s a nice road to be on.