I don't do the books, so I don't know the revenue numbers, but I know we're profitable, and so far profit is always turned around into more growth -- generally developers or support.
As for our prices, we don't charge for software licenses at all, so we're infinitely less expensive than the big guys in that regard.
When it comes to support, ours is insanely cheap compared to HP OpenView, IBM Tivoli, or any of the other big players we compete with, especially when you scale up. Of course, you can't comparison shop because HP and IBM and their like hide their (per-node) licensing and support prices behind channel partners and "have a salesperson call you," generally billing small customers with no clout a multiple per license what they charge for large customers for "volume discounts," despite the fact that it doesn't matter to the software itself how many nodes there are.
If you don't need support, OpenNMS is free, and always will be. Many people don't need it; there's a healthy community who can help. But the people who work for the
Jinx!
(Disclaimer: I'm one of the OpenNMS developers.)
Depends on what you do in your enterprise. OpenNMS does a lot of useful stuff out of the box, but is a platform first, and an application second. OpenNMS's biggest strength is the breadth of ways to integrate it with other tools, and huge scalability (we have installations collecting millions of data points every 5 minutes, and monitoring devices with 50k interfaces each without breaking a sweat, replacing failing OpenView installations in large telcos). New features are new features, and we're pretty conservative in the scope of features that get put into the even (stable) releases. If you're running unstable, well, they're new features, and sometimes there are bugs... All a part of developing in the fish bowl.
And you don't need an account manager at the other end to yell at when you can get immediate support from someone with intimate knowledge of the system, that's how we've survived as a company while remaining true to being 100% open source software. No BS, just support which is all "level 3." Not that we typically have things that just cease to function without provocation, but without a bug report it's hard to answer that particular comment.
In your haste to sell out, you also removed my copyrighted material that I posted myself. Thanks for "helping" an aspiring independent artist like me!
The unstable version (what will be come stable 1.8) does have a RESTful API for adding nodes. Additionally, 1.6.x and higher have an API for specifying your nodes manually, which can be called from external tools. This feature has been enhanced in what will be 1.8 to still scan interfaces on the nodes you specified, and such.
It may not have default configs for everything, but it should be able to monitor just about anything available through SNMP through configuration, or the SNMP poller, or the BGP monitor.
FYI, I work for OpenNMS, so I can't answer for all systems, but I can tell you how we stack up against your requirements:
Many solutions out there seems to have been developed in what can only be described as an "organic" process. I.E. a few scripts were used from start, were hooked up with some other scripts, were slammed into a web-interface, got some more features, then something central were ripped out and replaced to allow yet more features and so on and so forth.
OpenNMS was started by guys who did OpenView, NetCool, and other consulting for years and were tired of crappy tools that were hard to integrate with, so it was designed with scalability and "enterprise-ness" from the start. We've got folks monitoring hundreds of thousands of data points every 5 minutes from a single box. At this point the biggest bottleneck is not the code, but the I/O capabilities of your monitoring host, and how much data it can save to disk in a given amount of time.
Does anyone know a solution that can both receive from syslog and decode traps with a given MIB, and then do some simple logic, like squashing repeats, displaying on a web-page with archival-options, and dispatch to mail/sms based on configurable rules?
OpenNMS can do this, with a combination of our syslog daemon (which turns syslog messages into events), the event translator (which can parse those events and let you look for certain patterns to make more specific/different events), and alarms, which collapse multiple events of the same type into a single thing which you would then use to send notifications (which can span various groups, duty schedules, and notification types).
Modularity/Seamless Integration
OpenNMS has a number of ways to integrate external systems:
* traps - OpenNMS can receive SNMP traps and turn them into events internally
* event socket - OpenNMS has an event socket that you can push XML to that become events internally
* syslog (as mentioned earlier)
* "passive status" which lets you essentially "push" polled data instead of querying it from a remote device
I'm a coder, I don't do any of our field-implementation consulting, so there are probably more ways to integrate that I've forgotten, but basically at this point, there's nothing you'd want to integrate that couldn't be integrated with just a little glue scripting.
That said...
The Perfect Monitoring System
There is no perfect monitoring system. Everyone (including me... <g>) starts out thinking "eh, network management can't be that complicated" but it turns out everyone has wildly different networks, different needs, and in the end, will get the most out of different solutions. Any network management tool that says it can solve everyone's problems is lying. There are absolutely situations where some tool would work better for your specific needs than OpenNMS, but we've worked hard to provide a platform that eases integration, to cover as many of those needs as possible. So far, all of the stuff you've mentioned is doable in OpenNMS. Not all of it would happen out of the box, but all of the things you're wanting are possible due to our flexible integration points.
Honestly, I'm not very familiar with SMARTS, but we don't do a ton of root cause analysis out of the box.
We do have an integration with Drools to be able to do correlation and root cause analysis, but we don't have much in the way of default configuration for it at the moment.
Yeah, the web UI code is the cruftiest part of OpenNMS, and it's next on our list to tackle/modernize. It's last in the list since the most important part is the backend, and notifications. Day-to-day, the web UI is more important to managers that want to see pretty graphs, and the notification system is for the folks doing real work responding to issues.
We've already started taking steps towards that, implementing a RESTful interface for the backend parts of the system. Now we need to make a nice UI that takes advantage of it...
That would definitely be a bug. I'll look into it...
Never tell people how to do things. Tell them WHAT to do and they will surprise you with their ingenuity. -- Gen. George S. Patton, Jr.
