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.com side of things have been in network management for years, and if you want help on how to solve a particular monitoring problem, or want someone to call for help if something goes wrong, that's how we continue to be able to pay people full-time to make OpenNMS better.
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.;)
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...
And this is why we (OpenNMS) don't play the per-node. It's not any harder to run OpenNMS when managing 1000 nodes than when managing 100, you only need to scale hardware appropriately. Per-node pricing is an artificial limitation.
We also don't play the "you get a special price behind closed doors" game, our support prices are public, fair, and the same for everyone -- and that's only if you need commerical support -- our prices are $0 if you don't need or want support.
If you do the math, it's $0 for the software, plus $14,995/year for support for any number of nodes, and the software is 100% open-source and fully capable of replacing or exceeding OpenView.;)
This Just In: Many FOSS Businesses Started by People Who Assume You Can Apply a Support Model to Any Business
Just because people hopped on the bandwagon and forgot the "plan" part of business plan doesn't mean it's a broken model, only that it's a model that can't be applied to all things.
I work for The OpenNMS Group, a commercial consulting company based around the OpenNMS network management platform. We do the "traditional" open-source business model, and it works quite well. I guarantee it won't work for everyone, but in our specific case, network management is a very large discipline that tends to need custom configuration (and sometimes even code) for most environments. Everyone's network is different, and there is no one-size-fits-all solution.
That makes it ideal for the Free Software model; you'll end up spending $50k easy on solutions from HP and their ilk, and then twice that again to get consultants to actually make it do what you want. Making the software free still leaves plenty of room to add value, help scale, and teach NOC operators how to get the most out of it without screwing hobbyists and small companies willing to put the man-hours into doing it themselves when they can't afford the budget on consulting services.
Just because someone's trying to start a company selling support for the Gimp or something doesn't mean it's a good idea, but just because the service model doesn't work for some open-source software doesn't mean it's a bad one. You still have to have a business plan, and you still have to provide value to your customers. Just because the software itself is freely available and/or Free doesn't change that. That didn't stop a bunch of companies from popping up, riding the "open source" wave...
In the end, the companies that came out with a poor strategy will fail, and others will remain, and open source will be just another boring old business strategy like all the others.;)
The original copyright of the OpenNMS 1.0 code was created by Oculan (they had a dual strategy: open-source OpenNMS, commercial packaged OpenNMS-as-appliance). They have since gone out of business, and Raritan bought the intellectual property to sell as another product, so they don't have much reason to give us copyright to the grandfather of our shared code, they still have a vested interest in it. =)
However, OpenNMS pure-open-source development has continued on quite a bit since (2002?) when Sortova went off on his own to keep the open-source product alive. A large part of the code is now copyright The OpenNMS Group, which is our for-profit company supporting OpenNMS training/support/custom-dev, along with plenty of code copyrighted by tons of other committers.
The OpenNMS Group is certainly viable, and has written plenty of the code in today's OpenNMS codebase, but like many small "don't charge for a stupid enterprise version of free software" companies, legal funds to go after such things are slim. We're profitable, and growing, but we're not VC funded; would we rather fund our developer's conference or pay a bunch of lawyers to enforce something that folks Doing The Right Thing should be doing anyways?
It seems, however, that to enforce that copyright, we need to be more organized. We'd love to create an Apache-like not-for-profit "foundation" to own the copyright so we can be proper stewards of the code and not have things fragmented between us, other community members who have submitted code, and Raritan/Oculan. With the history of the original codebase, though, it's not terribly possible to do it 100% at the moment. We're doing what we can.
Believe me, there's nothing we'd love more than for this to not be an issue of The OpenNMS Group "controlling" the code. We believe in doing things right by way of the GPL, and just want to make sure others using the code do the same.
Well, that link says they're running OpenNMS 1.0.2, which, given the questions Cittio employees have asked on the OpenNMS mailing lists in the past, seems very unlikely (although technically possible). If they *are* using 1.0.2, they very likely *have* made modifications, 'cause that code has plenty of bugs that have been fixed in later OpenNMS releases.;)
One thing that Tarus didn't really mention is that we (The OpenNMS Group) have had a few folks come to us wanting quotes to compare us to Cittio, and they've been rather surprised that Cittio is in fact already using OpenNMS under the covers. The problem is not with them using OpenNMS, OpenNMS is all about sticking not only to the letter but also the spirit of the GPL, and they can do whatever they want with it as long as they're complying with the distribution requirements of the license. The problem is whether Cittio *is* upholding their side of the GPL, and it's unclear whether they are -- and there are some signs that they might not be.
As for them not having to offer the source until they distribute the software, yes, that's true, but from what we've heard from existing Cittio customers, that is not being made clear to them. Not only that, but while the wording of the GPL may not make it obvious, the FAQ does:
The difference between this and "incorporating" the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.
If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs--but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.
It seems likely that they've incorporated OpenNMS into their software at a lower-level than just screen-scraping it's output and stuffing it into their own UI. At that point, they should be prepared to provide the modified OpenNMS source to their customers. Not only that, but considering how tough companies are on open-source developers accidentally "tainting" open-source code with IP from their closed-source employers, it's more than a tad annoying that many closed-source companies taking advantage of open-source software are happy to use it, but ignore the spirit of sharing that is part of being in the community. "We won't say anything, but if you do ask us for the source, we'll fax it to you.";)
Again, all this is unproven, and that's part of the reason Tarus posted, the question is -- what's the next step?
If I actually had a more than 50% chance of receiving my luggage in the same condition I gave it to them, and wouldn't have to be at the airport an extra 45 minutes to pick up my luggage, I would. All your solution does is trade a little bit of time boarding for a lot of time after landing. Assuming your bags actually got transfered on your connection, then it's a s**t-ton time after landing.
Considering these folks were doing it *anyways*, I don't see how that could be the case.
I work on Fink and we've gotten little, if any, official support or thank you's from Apple, but that doesn't stop us from making OSX usable by porting *NIX apps to it.;)...Not that I would say no to some new hardware, I maintain KDE and it takes me nearly a week to do a full test-build from scratch.
Of course, the bits "based on FreeBSD" have nothing to do with architecture support, and everything to do with updating NeXT's headers to something modern.
Darwin is where you can see what hardware is supported, and it's not much.:)
He's lived off in a closet somewhere since enlightenment was big... uhh... how many years ago? E development is essentially a sandbox that people play in, but it never gets a stake in the ground where they say "there, it's something to build on, let's tell people about it."
How the heck can you be surprised that no one considers using your stuff in the real world when you've been in eternal pre-alpha for years?
My girlfriend went to the convention with a friend of hers (who was actually teaching there).
There's some more pictures of some of the models that were on display here, some of them are really quite amazing (I especially like the white dragon with all the pleats for scales, impressive...)
I'm suprised at how much press this has been getting, it's kind of nice, since I couldn't go with her I can at least hear about it some.:)
Slashdot Mirror
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 .com side of things have been in network management for years, and if you want help on how to solve a particular monitoring problem, or want someone to call for help if something goes wrong, that's how we continue to be able to pay people full-time to make OpenNMS better.
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... :)
And this is why we (OpenNMS) don't play the per-node. It's not any harder to run OpenNMS when managing 1000 nodes than when managing 100, you only need to scale hardware appropriately. Per-node pricing is an artificial limitation.
We also don't play the "you get a special price behind closed doors" game, our support prices are public, fair, and the same for everyone -- and that's only if you need commerical support -- our prices are $0 if you don't need or want support.
If you do the math, it's $0 for the software, plus $14,995/year for support for any number of nodes, and the software is 100% open-source and fully capable of replacing or exceeding OpenView. ;)
This Just In: Many FOSS Businesses Started by People Who Assume You Can Apply a Support Model to Any Business
Just because people hopped on the bandwagon and forgot the "plan" part of business plan doesn't mean it's a broken model, only that it's a model that can't be applied to all things.
I work for The OpenNMS Group, a commercial consulting company based around the OpenNMS network management platform. We do the "traditional" open-source business model, and it works quite well. I guarantee it won't work for everyone, but in our specific case, network management is a very large discipline that tends to need custom configuration (and sometimes even code) for most environments. Everyone's network is different, and there is no one-size-fits-all solution.
That makes it ideal for the Free Software model; you'll end up spending $50k easy on solutions from HP and their ilk, and then twice that again to get consultants to actually make it do what you want. Making the software free still leaves plenty of room to add value, help scale, and teach NOC operators how to get the most out of it without screwing hobbyists and small companies willing to put the man-hours into doing it themselves when they can't afford the budget on consulting services.
Just because someone's trying to start a company selling support for the Gimp or something doesn't mean it's a good idea, but just because the service model doesn't work for some open-source software doesn't mean it's a bad one. You still have to have a business plan, and you still have to provide value to your customers. Just because the software itself is freely available and/or Free doesn't change that. That didn't stop a bunch of companies from popping up, riding the "open source" wave...
In the end, the companies that came out with a poor strategy will fail, and others will remain, and open source will be just another boring old business strategy like all the others. ;)
The original copyright of the OpenNMS 1.0 code was created by Oculan (they had a dual strategy: open-source OpenNMS, commercial packaged OpenNMS-as-appliance). They have since gone out of business, and Raritan bought the intellectual property to sell as another product, so they don't have much reason to give us copyright to the grandfather of our shared code, they still have a vested interest in it. =)
However, OpenNMS pure-open-source development has continued on quite a bit since (2002?) when Sortova went off on his own to keep the open-source product alive. A large part of the code is now copyright The OpenNMS Group, which is our for-profit company supporting OpenNMS training/support/custom-dev, along with plenty of code copyrighted by tons of other committers.
The OpenNMS Group is certainly viable, and has written plenty of the code in today's OpenNMS codebase, but like many small "don't charge for a stupid enterprise version of free software" companies, legal funds to go after such things are slim. We're profitable, and growing, but we're not VC funded; would we rather fund our developer's conference or pay a bunch of lawyers to enforce something that folks Doing The Right Thing should be doing anyways?
It seems, however, that to enforce that copyright, we need to be more organized. We'd love to create an Apache-like not-for-profit "foundation" to own the copyright so we can be proper stewards of the code and not have things fragmented between us, other community members who have submitted code, and Raritan/Oculan. With the history of the original codebase, though, it's not terribly possible to do it 100% at the moment. We're doing what we can.
Believe me, there's nothing we'd love more than for this to not be an issue of The OpenNMS Group "controlling" the code. We believe in doing things right by way of the GPL, and just want to make sure others using the code do the same.
"So what's all this then?"
Well, that link says they're running OpenNMS 1.0.2, which, given the questions Cittio employees have asked on the OpenNMS mailing lists in the past, seems very unlikely (although technically possible). If they *are* using 1.0.2, they very likely *have* made modifications, 'cause that code has plenty of bugs that have been fixed in later OpenNMS releases. ;)
One thing that Tarus didn't really mention is that we (The OpenNMS Group) have had a few folks come to us wanting quotes to compare us to Cittio, and they've been rather surprised that Cittio is in fact already using OpenNMS under the covers. The problem is not with them using OpenNMS, OpenNMS is all about sticking not only to the letter but also the spirit of the GPL, and they can do whatever they want with it as long as they're complying with the distribution requirements of the license. The problem is whether Cittio *is* upholding their side of the GPL, and it's unclear whether they are -- and there are some signs that they might not be.
As for them not having to offer the source until they distribute the software, yes, that's true, but from what we've heard from existing Cittio customers, that is not being made clear to them. Not only that, but while the wording of the GPL may not make it obvious, the FAQ does:
It seems likely that they've incorporated OpenNMS into their software at a lower-level than just screen-scraping it's output and stuffing it into their own UI. At that point, they should be prepared to provide the modified OpenNMS source to their customers. Not only that, but considering how tough companies are on open-source developers accidentally "tainting" open-source code with IP from their closed-source employers, it's more than a tad annoying that many closed-source companies taking advantage of open-source software are happy to use it, but ignore the spirit of sharing that is part of being in the community. "We won't say anything, but if you do ask us for the source, we'll fax it to you." ;)
Again, all this is unproven, and that's part of the reason Tarus posted, the question is -- what's the next step?
If I actually had a more than 50% chance of receiving my luggage in the same condition I gave it to them, and wouldn't have to be at the airport an extra 45 minutes to pick up my luggage, I would. All your solution does is trade a little bit of time boarding for a lot of time after landing. Assuming your bags actually got transfered on your connection, then it's a s**t-ton time after landing.
Yeah, as of the next snapshot I want to have ktorrent packaged as well. I've had a number of folks request it.
Considering these folks were doing it *anyways*, I don't see how that could be the case.
;) ...Not that I would say no to some new hardware, I maintain KDE and it takes me nearly a week to do a full test-build from scratch.
I work on Fink and we've gotten little, if any, official support or thank you's from Apple, but that doesn't stop us from making OSX usable by porting *NIX apps to it.
They weren't to me. I kept getting timeouts after getting about 5 meg of it.
FYI, I've put up a torrent for iTunes6 here
...we could get lucky. :)
Of course, the bits "based on FreeBSD" have nothing to do with architecture support, and everything to do with updating NeXT's headers to something modern.
:)
Darwin is where you can see what hardware is supported, and it's not much.
Sounds like Bruce Byfield is offering to do the development himself.
Exactly.
He's lived off in a closet somewhere since enlightenment was big... uhh... how many years ago? E development is essentially a sandbox that people play in, but it never gets a stake in the ground where they say "there, it's something to build on, let's tell people about it."
How the heck can you be surprised that no one considers using your stuff in the real world when you've been in eternal pre-alpha for years?
The site's slashdotted now, so I can't see how good of a job they did, but the one I did from the stencil is reading... a-duh-email.
My girlfriend went to the convention with a friend of hers (who was actually teaching there).
There's some more pictures of some of the models that were on display here, some of them are really quite amazing (I especially like the white dragon with all the pleats for scales, impressive...)
I'm suprised at how much press this has been getting, it's kind of nice, since I couldn't go with her I can at least hear about it some. :)