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.