We had a meeting a couple of weeks ago to lay out the roadmap for OpenNMS in 2008. I thought I’d share a few thoughts that came out of that meeting.

First of all, a little history. OpenNMS has always had at least two releases available at a given time. The “stable” or production release is identified by having an even number after the “dot” in the version, i.e. 1.0, 1.2. This is a release with very little code churn, and it is designed to be used in production environments where one would sacrifice features for stability.

The other release is the “unstable” or development release. It’s identified by an odd number after the “dot” in the version, i.e. 0.9, 1.1, 1.3. This is code that could have significant changes between releases, and thus it is not necessarily for use in a production environment. However, there is an exception which I’ll describe in a bit.

When we released 1.3.2, over a year after 1.3.1, large portions of the OpenNMS code had been changed and in some cases totally rewritten. We realized that the next stable release would be a large change and (we hoped) a large improvement over 1.2 and we decided to call it 2.0 instead of 1.4.

In our minds, 2.0 became something of a holy grail. This would be the release with full configuration via the webUI, easy distribution, documentation out the wazoo (grin) and all kinds of other stuff.

We’ve been at it for a year and while closer we’re still not close enough. One has to remember that OpenNMS is still largely a community driven project and it grows as fast as the community will allow it, and we just haven’t had the time and people to implement all of our ideas.

But now we find ourselves with an “unstable” release, 1.3.9, that is more robust that our current “stable” release of 1.2.9 and the twin pressures of getting a new stable release out and trying to squeeze in just one more feature are mounting. So, we thought, why not release a 1.8 based on the current development branch? That became the plan.

However … while a number of daemons have been rewritten and optimized, our capabilities scanner, capsd, could benefit from that treatment. The downside is that it is probably a couple of months worth of work, and I want a new stable soon. We ran into this same situation with the transition from 1.1 to 1.2 – we want stable releases to be perfect but if we have to wait until every feature we can think of is included we’d never release anything.

So we came up with the following roadmap:

We’ll release a 1.3.10 and perhaps a 1.3.11 which will focus on cleaning up all of the current work in the 1.3 branch and polishing it to make it ready to bear the name of a “stable” release. This will be called OpenNMS 1.6. This timeframe for this is in the next 6-8 weeks or so. Maybe not 1.6 proper but definitely a release candidate.

Then the focus will switch to capsd. Once that daemon has been rewritten and tested in the 1.7 development branch, it will be christened 1.8. The timeline for this is rapid for us – middle of next year. By this time we should have the platform needed to seriously work on our 2.0 goals.

The plan for the 1.9 development branch is to focus on a subsection of OpenNMS for each release. For example, 1.9.0 might focus on notification features, the 1.9.1 release could emphasis distribution, etc.

And 2.0 will be out … when its out. (grin)

Our plan for 2007 was four major releases and we’ve had six, so lets hope we can meet if not exceed this plan in 2008. Thanks again to everyone who makes OpenNMS possible.