Okay, I’ve been heads down on 1.1.3/1.2 and ignoring the list, but I hear talk that folks are looking for a “roadmap”. This is something I sent around internally, and it is subject to heavy changes, but I thought I’d share it for what it is worth.

Here is a draft of the roadmap for OpenNMS, represented by pairs of version numbers reflecting the development/production cycle for each release.

Note that this list is by no means exhaustive, and represents the main points I want to cover.

Version: 1.1/1.2
Timeframe: As soon as possible

• This is almost complete. All the features are basically in, but many things are broken.
  I have been spending time in Bugzilla cleaning things up so that I can set up a “blocker”
  bug that will track when we can release 1.1.3.
  (Bug 804)

• Installer: We need to fix the installer to handle the install more cleanly.
• Documentation: The documentation needs a lot of work. I want to sequester myself for a week
  and fix this.

In the “would be nice” category:

• Performance enhancements to data collection
• Support for the latest Java: 1.4.2, as well as IBM’s SDK.
• OpenNMS on a disk: Using White Dwarf, support OpenNMS as a single CD iso.

Version: 1.3/1.4
Timeframe: release stable (1.4) in December

• Internationalization. By having versions of OpenNMS available worldwide, not only will we see increased adoption, but since people overseas tend to have a more open attitude toward open source it is important to allow them to use OpenNMS in their native tongue.
• Path Outage: The idea here is to implement a method of detecting network outages (at the beginning limited to layer 3) and handling sympathetic events to limit the number of notifications that get sent. For example, if we are monitoring ten servers on the other side of a router, and the router goes down, we will get at least 11 events: 10 nodeDown events from the servers and one from the router. Instead, we should get a single “path outage” event that the router is down.
• Nessus Integration: Network management is often defined by FCAPS: Fault, Configuration,
  Accounting, Performance and Security. We currently handle Fault and Performance, and I would like to add Security. Nessus is a vulnerability scanner. Much like our capsd process, vulscand scans the network, not for services, but for security holes. Much of the groundwork has been done on this, it just needs to be completed.

• Java: OpenNMS is mainly a Java product that requires some external code to handle various tasks. We need to make OpenNMS as pure Java as is possible. Not only will that provide performance and code management benefits, it will look more professional to the open source world and will result in greater consideration of the product.
• webUI Redesign: Leveraging the design team at Blast, we need to look into improving the webUI.
• Installer improvements: Create a professional looking installer that can help new users get OpenNMS installed painlessly.
• webUI configuration: Increase the amount of configuration done via the webUI to reduce the reliance on hand editing of XML files.
• Availability report improvements: OpenNMS currently has poor availablility reporting. Since availability is based on the outages table in the database, we could use something like Crystal Reports to really improve on how the outage information is displayed. I believe there are open source Java alternatives to Crystal Reports that we can leverage.
• User-based views and security: The ability to segment what part of the network can be seen by an OpenNMS user, and the ability to customize, for that user, how information is presented.
• Top Ten: We also need to look to the community and take their top ten enchancement requests into consideration as possible features.

Version: 1.9/2.0
Timeframe: 1.9.0 available by the end of the year.

The idea of OpenNMS 2.0 is to provide a truly scalable management platform where resources can be added and removed from the system as needed. This also includes the ability for third parties to plug their technology into the framework, as well as redundancy and failover.

Here are some examples:

A large corporation needs to monitor a large number of devices that are spread out worldwide.
For remote offices they have instances of OpenNMS that do locate polling and performance
measurement and send that information to the center Network Operations Center (NOC).

At headquarters there are a large number of servers to be monitored, so locally there are a number of pollers to help manage the load. If a poller starts to get behind, OpenNMS can instruct another system to take part of the load. A similar thing will happen if a poller should fail.

The architecture should support “n” tiers, meaning that I can consolidate information at multiple levels. So countries can consolidate their sites and roll that up into a region, regions can be consolidated into, say, continents, and continents can be consolidated into a single world view.

In addition, there should be a set API for integrating other vendors products into OpenNMS. Thus as OpenNMS reaches out for world domination, companies such as IBM and Cisco can easily use OpenNMS instead of their current platform.

Finally, the system should be self healing.