Hi All,
At some point in the future it's likely that I'm going to split Observium into free and enterprise/pro variants.
Observium has historically been developed as a fairly ad hoc project, with work being done as time permits between work projects. We've often had gaps of 6 months where there has been little work done due to other commitments.
As the user-base expands this is going to become less and less viable a way of maintaining the project, and we need to be able to devote more time to keeping on top of bug reports and feature development. To be able to devote more time to the project we need to establish a revenue stream to be able to support it.
We'd like comments from you guys about how we should go about splitting, what should be in each version, and what we should charge.
We're considering:
A hosts/ports-based licensing scheme, where you get a certain number free, and any more than that requires a license. A feature-based licensing scheme, where higher-value features such as load balancers, netapp, mac accounting, vpn tracking, etc require a license. Licensing for customer-access, where allowing customers access to the web interface requires a license.
What pricing models do you think would work?
Options for the ent/pro version include using the honour system, maintaining a separate password-protected SVN repository or distributing an ioncube-protected version.
I would prefer to go the honour system route, but I'm not sure how well that would work.
Thanks, adam.
Ports-based licensing is worst type. Hosts-based okeish.
Make unix-agent even more worthwhile, and feature based will fits perfectly, especially case for windows hosts ;). Sever 2012 have no snmp at all, so this is all make sense, and if you got money for windows license have, will probably find some on monitoring.
Customer-access type seems interested but I wonder if this really anyone willing to use.
On 4/15/13 2:58 AM, Adam Armstrong wrote:
A hosts/ports-based licensing scheme, where you get a certain number free, and any more than that requires a license. A feature-based licensing scheme, where higher-value features such as load balancers, netapp, mac accounting, vpn tracking, etc require a license. Licensing for customer-access, where allowing customers access to the web interface requires a license.
On Mon, Apr 15, 2013 at 02:53:24PM +0400, Nikolay Shopik wrote:
Ports-based licensing is worst type. Hosts-based okeish.
Seconded. I hate any licencing model more complex than 'site-wide'. There is always something which makes it awkward for a particular site. Reviewing licence costs regularly is a pain in the ass when your job is technical and not financial. As such we tend to avoid anything like this as it adds too much overhead.
Sorry, not particularly constructive I know.
Mike
Hi Adam, thanks for telling the list about your thoughts on commercializing Observium and giving us the opportunity to talk about the licensing scheme before you actually decide which way to go.
I need to agree with Nikolay, that "port-based" shouldn't be the way to go, as many devices just add tons of virtual ports. For me "host-based" sounds pretty fair.
Also I would prefer to use the "honor system" route as well. Keepeing the source code open makes it still easy for people to contribute to certain features or customize Observium for their own needs. Once a product is commercialized you will have piracy, thats what I am pretty sure of. Although I am pretty sure that this community will honor your work and what you have done. Observium is a great product and it helps me with my daily work.
Can you already outline some pricing you have in mind and/or the differences between free/pro/enterprise editions? Once there is money behind that whole thing, what would actually change? How would you deal with the support, feature requests, etc.?
Just my 2 cent and hope it was a bit helpful!
Best regards, Florian
Adam,
On 14 Apr 2013, at 18:58, Adam Armstrong wrote:
A hosts/ports-based licensing scheme, where you get a certain number free, and any more than that requires a license.
By per-host, do you mean the hosts polled or hosts doing the polling? I like the former better than the latter.
A feature-based licensing scheme, where higher-value features such as load balancers, netapp, mac accounting, vpn tracking, etc require a license.
You mean the kinds of licenses we pressure our sales critter to remove when buying hardware?
Licensing for customer-access, where allowing customers access to the web interface requires a license.
What pricing models do you think would work?
How about early access to new features/bug fixes? Let the paid version lead by 3-6 months, maybe a full year for bespoke features. Critical security fixes should still be available immediately in both versions.
Options for the ent/pro version include using the honour system, maintaining a separate password-protected SVN repository or distributing an ioncube-protected version.
I had not heard of ionCube until now--it looks interesting, but I prefer the honor system.
Michael
Hi,
Have you calculated how many dollars you need per year? Going from there and calculating backwards might be good strategy. You must have some stats from the svn repo how many unique IPs do 'svn up'. Are you today getting a lot of requests for a few hours of consultancy on an observium installation?
Earlier a remark was made that complicated licensing schemes suck, something like "costs 2500 euro per year boss - flat" is appealing, also it will make your license enforcement much simpler, as you don't have to do weird things with the code so people don't add more than X ports or X devices. A nice aspect of observium is that most people can easily tweak/finetune some parts of the code for their particular environment, binary blob distributions would take that away.
Features for paying customers could be: - heavier voting rights (paying customers priortize the todo queue) - support response within X business hours - X hours of remote support (more hours @ discounted rate) - decent alerting - API to intergrate observium with existing backend/CMDB (API to add, delete & report on devices/ports)
But to be honest, I am unsure if this is a viable model.
You could also take a look at ISC's spinoff to make BIND financially more viable: http://www.dns-co.com/solutions/bind/
Kind regards,
Job
On Apr 15, 2013, at 12:58 AM, Adam Armstrong adama@observium.org wrote:
Hi All,
At some point in the future it's likely that I'm going to split Observium into free and enterprise/pro variants.
Observium has historically been developed as a fairly ad hoc project, with work being done as time permits between work projects. We've often had gaps of 6 months where there has been little work done due to other commitments.
As the user-base expands this is going to become less and less viable a way of maintaining the project, and we need to be able to devote more time to keeping on top of bug reports and feature development. To be able to devote more time to the project we need to establish a revenue stream to be able to support it.
We'd like comments from you guys about how we should go about splitting, what should be in each version, and what we should charge.
We're considering:
A hosts/ports-based licensing scheme, where you get a certain number free, and any more than that requires a license. A feature-based licensing scheme, where higher-value features such as load balancers, netapp, mac accounting, vpn tracking, etc require a license. Licensing for customer-access, where allowing customers access to the web interface requires a license.
What pricing models do you think would work?
Options for the ent/pro version include using the honour system, maintaining a separate password-protected SVN repository or distributing an ioncube-protected version.
I would prefer to go the honour system route, but I'm not sure how well that would work.
Thanks, adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On Tue, 16 Apr 2013 00:36:24 +0200, Job Snijders job.snijders@atrato.com wrote:
Hi,
Have you calculated how many dollars you need per year? Going from there and calculating backwards might be good strategy. You must have some
stats
from the svn repo how many unique IPs do 'svn up'. Are you today getting
a
lot of requests for a few hours of consultancy on an observium installation?
There are approximately 3,500 live installations over the past 14 days.
Absolute minimum viable revenue to do Observium full-time would be ~$15k/a. For this I'd be able to pay for food, internet and electricity for laptop :)
We get a few requests per year for support and custom development, no one ever actually pays for anything.
Earlier a remark was made that complicated licensing schemes suck, something like "costs 2500 euro per year boss - flat" is appealing, also
it
will make your license enforcement much simpler, as you don't have to do weird things with the code so people don't add more than X ports or X devices. A nice aspect of observium is that most people can easily tweak/finetune some parts of the code for their particular environment, binary blob distributions would take that away.
That isn't actually a benefit IMO. Any modification of the code makes updates pretty difficult.
The downsides of the ioncubed blob is that it's really difficult to deliver timely updates the way we do with SVN. Similarly any attempt to split the codebase would have this problem too. It's an absolute nightmare to manage two trains of the same code.
We likely wouldn't do anything to the code to stop people doing things, we'd rely on them not wanting to be doing illegal stuff at work.
In terms of separating features, I was thinking of doing that by having a separate repository of poller modules for the 'enterprise' features, which were automatically included when available.
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue)
- support response within X business hours
- X hours of remote support (more hours @ discounted rate)
- decent alerting
- API to intergrate observium with existing backend/CMDB (API to add,
delete & report on devices/ports)
Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take the whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
adam.
On Mon, Apr 15, 2013 at 11:28:23PM +0100, Adam Armstrong wrote:
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue)
- support response within X business hours
- X hours of remote support (more hours @ discounted rate)
- decent alerting
- API to intergrate observium with existing backend/CMDB (API to add,
delete & report on devices/ports)
Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take the whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
A few observations of the way that people think in our instituation/sector:
In a market where there are lots of monitoring tools of various types it's much easier for me to justify paying for a product which comes with support than it is to justify paying for a product with better/different features. Our management see free tools as valuable but risky. For some arbitary reason if we pay for the free tools they appear to be happier (the management, not the tools, although it can be hard to tell the difference).
At the same time we wouldn't be able to deliver anything without the plethora of free tools - from linux to nagios. Virtually all our monitoring is done on the free versions of Nagios and OpenNMS. Historical data on Cacti and Zabbix. From a technical point of view once you start paying for something it's expected that every last gram of usefulness is extracted from the product whereas we'd like the flexibility of changing product as the environment evolves. So investing heavily in something isn't done without a great deal of consideration. And, whilst Observium is a great product, which we've adopted very quickly, it won't scale to the 120,000 ports we have. Currently we limit the devices to just a couple of hundred routers and some appliances. The Powers That Be would expect, if we were paying, that it did everything. Currently we use cacti to collect a little about everything and Observium to collect everything about a few devices. That works for me but probably not for them.
Recurring payments are harder to arrange (operation budget, updated each year etc.) than a one off payment (capital, more control). Donations are very difficult to arrange. As is anything to do with paypal. It's just down to our finance system. Obviously, the easier it is, the more likely it is to happen.
Whilst it is your perogative to do whatever you want with your product you might want to consider that we tried Observium, loved it and I showed it off to a variety of people, who also loved it. So I installed it for them as well. We could do this because it was free and easy. Honestly, I think that if I had hoops to jump through, payment-wise, I wouldn't have done. So unless your userbase has already reached a critical mass where you don't need word of mouth then taking it completely commercial might backfire.
As I said earlier, support is something we'd pay for. We'd expect something on-par with other vendors we work with though. So: hardware sizing guides, full documentation, ticket systems, escalation mechanisms, someone to talk to etc. And, not wanting to antagonise people, something more than 'read the documentation' as a response to queries. Whilst BOFH style replies are amusing, and I've done enough of them myself, they wouldn't be appropriate when money has changed hands.
Apologies if anything appears to be contradictory. That's just how it is.
Mike
2013/4/16 Mike Richardson mike.richardson@manchester.ac.uk:
On Mon, Apr 15, 2013 at 11:28:23PM +0100, Adam Armstrong wrote:
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue) - support response within X business hours - X hours of remote support (more hours @ discounted rate) - decent alerting - API to intergrate observium with existing backend/CMDB (API to add, delete & report on devices/ports)Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take the whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
A few observations of the way that people think in our instituation/sector:
In a market where there are lots of monitoring tools of various types it's much easier for me to justify paying for a product which comes with support than it is to justify paying for a product with better/different features. Our management see free tools as valuable but risky. For some arbitary reason if we pay for the free tools they appear to be happier (the management, not the tools, although it can be hard to tell the difference).
At the same time we wouldn't be able to deliver anything without the plethora of free tools - from linux to nagios. Virtually all our monitoring is done on the free versions of Nagios and OpenNMS. Historical data on Cacti and Zabbix. From a technical point of view once you start paying for something it's expected that every last gram of usefulness is extracted from the product whereas we'd like the flexibility of changing product as the environment evolves. So investing heavily in something isn't done without a great deal of consideration. And, whilst Observium is a great product, which we've adopted very quickly, it won't scale to the 120,000 ports we have. Currently we limit the devices to just a couple of hundred routers and some appliances. The Powers That Be would expect, if we were paying, that it did everything. Currently we use cacti to collect a little about everything and Observium to collect everything about a few devices. That works for me but probably not for them.
Recurring payments are harder to arrange (operation budget, updated each year etc.) than a one off payment (capital, more control). Donations are very difficult to arrange. As is anything to do with paypal. It's just down to our finance system. Obviously, the easier it is, the more likely it is to happen.
Whilst it is your perogative to do whatever you want with your product you might want to consider that we tried Observium, loved it and I showed it off to a variety of people, who also loved it. So I installed it for them as well. We could do this because it was free and easy. Honestly, I think that if I had hoops to jump through, payment-wise, I wouldn't have done. So unless your userbase has already reached a critical mass where you don't need word of mouth then taking it completely commercial might backfire.
As I said earlier, support is something we'd pay for. We'd expect something on-par with other vendors we work with though. So: hardware sizing guides, full documentation, ticket systems, escalation mechanisms, someone to talk to etc. And, not wanting to antagonise people, something more than 'read the documentation' as a response to queries. Whilst BOFH style replies are amusing, and I've done enough of them myself, they wouldn't be appropriate when money has changed hands.
Apologies if anything appears to be contradictory. That's just how it is.
Mike
-- Mike Richardson Networks (network@manchester.ac.uk) IT Services, University of Manchester *Plain text only please - attachments stripped on arrival* _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I'm with Mike, I use this for my lab and a few (little) personal projects here and there. I'm using it for my current employer, this is the biggest installation of Observium I've done. It's used mainly for server stats, some ethernet switches (Cisco/Huawei) and custom app stats.
Currently we don't use "port accounting", I assume that's for end users, so licensing by port is kind of alien where servers are more important than switch ports for end users.
This employer could probably easily pay for support (pro all features included license + support?) and new features like:
- better Huawei support - Brocade SAN switches stats - Trending (our department is in charge of Capacity Planning) - Scalability tweaks (my first installation died with 10k ports)
given there's an straightforward billing process (sometimes they prefer a local dealer), but they'll ask for a service level on par of the other providers (documentation, SLAs, etc.)
I love the application, BOFH responses are always expected in the maillist (but comercial support is another thing) and I'll continue contributing as much or as little I can...
Hope my input is somewhat useful.
-- Ciro Iriarte http://cyruspy.wordpress.com --
Hi,
That isn't actually a benefit IMO. Any modification of the code makes updates pretty difficult.
It's not that bad. I have a few local modifications that have survived many 'svn up's. I do realise that any problems caused by this are my own :)
The downsides of the ioncubed blob is that it's really difficult to deliver timely updates the way we do with SVN.
The code going closed source / ioncubed would be an immediate reason for me to stop using it. I don't mind paying, but I do mind the inflexibility.
[...]
The alternative, of course, is to just cease free development and take the whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
Yes, bills have to be paid.
Another idea: maybe add an option for a free license for people who contribute in other ways (like code)?
Cheers, Sander
Look I'm only a small home business user but this is the only piece of software (network monitoring) I've enjoyed using for a while. In saying that I would contribute/pay for greater features if that's what it took. But it would depend on what kind of 'Bang for Buck' I was getting for the feature set I was paying for. I'm not against paying anything just as long as it ment fast/quicker development, count me in. I love and assist with open source projects but sometimes you get what you pay for!!
-----Original Message----- From: observium-bounces@observium.org [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Tuesday, 16 April 2013 8:28 AM To: Observium Network Observation System Subject: Re: [Observium] Observium Enterprise/Pro licensing
On Tue, 16 Apr 2013 00:36:24 +0200, Job Snijders job.snijders@atrato.com wrote:
Hi,
Have you calculated how many dollars you need per year? Going from there and calculating backwards might be good strategy. You must have some
stats
from the svn repo how many unique IPs do 'svn up'. Are you today getting
a
lot of requests for a few hours of consultancy on an observium installation?
There are approximately 3,500 live installations over the past 14 days.
Absolute minimum viable revenue to do Observium full-time would be ~$15k/a. For this I'd be able to pay for food, internet and electricity for laptop :)
We get a few requests per year for support and custom development, no one ever actually pays for anything.
Earlier a remark was made that complicated licensing schemes suck, something like "costs 2500 euro per year boss - flat" is appealing, also
it
will make your license enforcement much simpler, as you don't have to do weird things with the code so people don't add more than X ports or X devices. A nice aspect of observium is that most people can easily tweak/finetune some parts of the code for their particular environment, binary blob distributions would take that away.
That isn't actually a benefit IMO. Any modification of the code makes updates pretty difficult.
The downsides of the ioncubed blob is that it's really difficult to deliver timely updates the way we do with SVN. Similarly any attempt to split the codebase would have this problem too. It's an absolute nightmare to manage two trains of the same code.
We likely wouldn't do anything to the code to stop people doing things, we'd rely on them not wanting to be doing illegal stuff at work.
In terms of separating features, I was thinking of doing that by having a separate repository of poller modules for the 'enterprise' features, which were automatically included when available.
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue)
- support response within X business hours
- X hours of remote support (more hours @ discounted rate)
- decent alerting
- API to intergrate observium with existing backend/CMDB (API to add,
delete & report on devices/ports)
Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take the whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi All,
We have, for the time being, decided to shelve the licensing plan and are going to try the Kickstarter route.
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!
Anyone interested in proper, commercial support and banishing those dreaded BOFH responses are still welcome to enquire about that. :)
Thanks, adam.
On Mon, 15 Apr 2013 23:28:23 +0100, Adam Armstrong adama@memetic.org wrote:
On Tue, 16 Apr 2013 00:36:24 +0200, Job Snijders
wrote:
Hi,
Have you calculated how many dollars you need per year? Going from
there
and calculating backwards might be good strategy. You must have some
stats
from the svn repo how many unique IPs do 'svn up'. Are you today
getting
a
lot of requests for a few hours of consultancy on an observium installation?
There are approximately 3,500 live installations over the past 14 days.
Absolute minimum viable revenue to do Observium full-time would be ~$15k/a. For this I'd be able to pay for food, internet and electricity
for
laptop :)
We get a few requests per year for support and custom development, no
one
ever actually pays for anything.
Earlier a remark was made that complicated licensing schemes suck, something like "costs 2500 euro per year boss - flat" is appealing,
also
it
will make your license enforcement much simpler, as you don't have to
do
weird things with the code so people don't add more than X ports or X devices. A nice aspect of observium is that most people can easily tweak/finetune some parts of the code for their particular environment, binary blob distributions would take that away.
That isn't actually a benefit IMO. Any modification of the code makes updates pretty difficult.
The downsides of the ioncubed blob is that it's really difficult to deliver timely updates the way we do with SVN. Similarly any attempt to split the codebase would have this problem too. It's an absolute nightmare to manage two trains of the same code.
We likely wouldn't do anything to the code to stop people doing things, we'd rely on them not wanting to be doing illegal stuff at work.
In terms of separating features, I was thinking of doing that by having
a
separate repository of poller modules for the 'enterprise' features,
which
were automatically included when available.
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue)
- support response within X business hours
- X hours of remote support (more hours @ discounted rate)
- decent alerting
- API to intergrate observium with existing backend/CMDB (API to add,
delete & report on devices/ports)
Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take
the
whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Adam;
I support the decision either way. I love the product you guys have made, my coworkers are enamored with it, and we're now actively monitoring our equipment in ways we never thought possible before. My server guys love the fact that they can check in real time our network traffic, and can stop bitching that the network is "slow".
If MySQL would stop being a bitch about memory and connections, I'd be a happy camper.
I'm hoping to convince my Director to throw some end-of-year funds your way as a way of just saying "fuck yeah. Also have money."
-----Original Message----- From: observium-bounces@observium.org [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: Tuesday, April 16, 2013 8:12 PM To: Observium Network Observation System Subject: Re: [Observium] Observium Enterprise/Pro licensing
Hi All,
We have, for the time being, decided to shelve the licensing plan and are going to try the Kickstarter route.
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!
Anyone interested in proper, commercial support and banishing those dreaded BOFH responses are still welcome to enquire about that. :)
Thanks, adam.
On Mon, 15 Apr 2013 23:28:23 +0100, Adam Armstrong adama@memetic.org wrote:
On Tue, 16 Apr 2013 00:36:24 +0200, Job Snijders
wrote:
Hi,
Have you calculated how many dollars you need per year? Going from
there
and calculating backwards might be good strategy. You must have some
stats
from the svn repo how many unique IPs do 'svn up'. Are you today
getting
a
lot of requests for a few hours of consultancy on an observium installation?
There are approximately 3,500 live installations over the past 14 days.
Absolute minimum viable revenue to do Observium full-time would be ~$15k/a. For this I'd be able to pay for food, internet and electricity
for
laptop :)
We get a few requests per year for support and custom development, no
one
ever actually pays for anything.
Earlier a remark was made that complicated licensing schemes suck, something like "costs 2500 euro per year boss - flat" is appealing,
also
it
will make your license enforcement much simpler, as you don't have to
do
weird things with the code so people don't add more than X ports or X devices. A nice aspect of observium is that most people can easily tweak/finetune some parts of the code for their particular environment, binary blob distributions would take that away.
That isn't actually a benefit IMO. Any modification of the code makes updates pretty difficult.
The downsides of the ioncubed blob is that it's really difficult to deliver timely updates the way we do with SVN. Similarly any attempt to split the codebase would have this problem too. It's an absolute nightmare to manage two trains of the same code.
We likely wouldn't do anything to the code to stop people doing things, we'd rely on them not wanting to be doing illegal stuff at work.
In terms of separating features, I was thinking of doing that by having
a
separate repository of poller modules for the 'enterprise' features,
which
were automatically included when available.
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue)
- support response within X business hours
- X hours of remote support (more hours @ discounted rate)
- decent alerting
- API to intergrate observium with existing backend/CMDB (API to add,
delete & report on devices/ports)
Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take
the
whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Why not create a per incident type of ticket system? If you want paid support it's per incident. If the customer is lazy and whats you to do everything (called Level 3 support) simply add on a hourly rate.
On 4/16/2013 8:12 PM, Adam Armstrong wrote:
Hi All,
We have, for the time being, decided to shelve the licensing plan and are going to try the Kickstarter route.
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!
Anyone interested in proper, commercial support and banishing those dreaded BOFH responses are still welcome to enquire about that. :)
Thanks, adam.
On Mon, 15 Apr 2013 23:28:23 +0100, Adam Armstrong adama@memetic.org wrote:
On Tue, 16 Apr 2013 00:36:24 +0200, Job Snijders
wrote:
Hi,
Have you calculated how many dollars you need per year? Going from
there
and calculating backwards might be good strategy. You must have some
stats
from the svn repo how many unique IPs do 'svn up'. Are you today
getting
a
lot of requests for a few hours of consultancy on an observium installation?
There are approximately 3,500 live installations over the past 14 days.
Absolute minimum viable revenue to do Observium full-time would be ~$15k/a. For this I'd be able to pay for food, internet and electricity
for
laptop :)
We get a few requests per year for support and custom development, no
one
ever actually pays for anything.
Earlier a remark was made that complicated licensing schemes suck, something like "costs 2500 euro per year boss - flat" is appealing,
also
it
will make your license enforcement much simpler, as you don't have to
do
weird things with the code so people don't add more than X ports or X devices. A nice aspect of observium is that most people can easily tweak/finetune some parts of the code for their particular environment, binary blob distributions would take that away.
That isn't actually a benefit IMO. Any modification of the code makes updates pretty difficult.
The downsides of the ioncubed blob is that it's really difficult to deliver timely updates the way we do with SVN. Similarly any attempt to split the codebase would have this problem too. It's an absolute nightmare to manage two trains of the same code.
We likely wouldn't do anything to the code to stop people doing things, we'd rely on them not wanting to be doing illegal stuff at work.
In terms of separating features, I was thinking of doing that by having
a
separate repository of poller modules for the 'enterprise' features,
which
were automatically included when available.
Features for paying customers could be:
- heavier voting rights (paying customers priortize the todo queue)
- support response within X business hours
- X hours of remote support (more hours @ discounted rate)
- decent alerting
- API to intergrate observium with existing backend/CMDB (API to add,
delete & report on devices/ports)
Yup, this is what I was thinking of.
The alternative, of course, is to just cease free development and take
the
whole thing commercial.
This would be our least favoured option, but 100 paying customers are better than 3500 freeloaders :)
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On Tue, 16 Apr 2013 21:46:14 -0400, List User list@redspeedservers.com wrote:
Why not create a per incident type of ticket system? If you want paid support it's per incident. If the customer is lazy and whats you to do everything (called Level 3 support) simply add on a hourly rate.
The industry standard method of charging for support is to charge a retainer, which includes a fixed number of incidents, and then to charge per-incident after that.
This is what we'd do, like everyone else :)
adam.
----- Original Message -----
On Tue, 16 Apr 2013 21:46:14 -0400, List User list@redspeedservers.com wrote:
Why not create a per incident type of ticket system? If you want paid support it's per incident. If the customer is lazy and whats you to do everything (called Level 3 support) simply add on a hourly rate.
The industry standard method of charging for support is to charge a retainer, which includes a fixed number of incidents, and then to charge per-incident after that.
This is what we'd do, like everyone else :)
+1
I think this method is much more palatable. Continue to release all features, but charge for support of the product, not the product itself. This model works great with many big-name projects.
Just my $0.02 USD...
--Tim
On Tue, 16 Apr 2013 22:51:30 -0500 (CDT), Tim Nelson tnelson@rockbochs.com wrote:
----- Original Message -----
On Tue, 16 Apr 2013 21:46:14 -0400, List User list@redspeedservers.com wrote:
Why not create a per incident type of ticket system? If you want paid support it's per incident. If the customer is lazy and whats you to do everything (called Level 3 support) simply add on a hourly rate.
The industry standard method of charging for support is to charge a retainer, which includes a fixed number of incidents, and then to charge per-incident after that.
This is what we'd do, like everyone else :)
+1
I think this method is much more palatable. Continue to release all features, but charge for support of the product, not the product itself. This model works great with many big-name projects.
Just my $0.02 USD...
No one ever paid us for support, and we had the options on the site for a year.
This method does not work for anyone except RedHat, it's fairly well documented that they're pretty much the only company making any soft of money using this model.
adam.
Well its just as simple as your code and installation process works too well for anyone too feel they need support.
I think kickstarter is a great way too stay feature driven and let the community talk with there money.
Anyway, you would have 1 or more paying customers from my end how ever you choose to do.
On 17 April 2013 05:50, Adam Armstrong adama@memetic.org wrote:
On Tue, 16 Apr 2013 22:51:30 -0500 (CDT), Tim Nelson tnelson@rockbochs.com wrote:
----- Original Message -----
On Tue, 16 Apr 2013 21:46:14 -0400, List User list@redspeedservers.com wrote:
Why not create a per incident type of ticket system? If you want paid support it's per incident. If the customer is lazy and whats you to do everything (called Level 3 support) simply add on a hourly rate.
The industry standard method of charging for support is to charge a retainer, which includes a fixed number of incidents, and then to charge per-incident after that.
This is what we'd do, like everyone else :)
+1
I think this method is much more palatable. Continue to release all features, but charge for support of the product, not the product itself. This model works great with many big-name projects.
Just my $0.02 USD...
No one ever paid us for support, and we had the options on the site for a year.
This method does not work for anyone except RedHat, it's fairly well documented that they're pretty much the only company making any soft of money using this model.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On Wed, 17 Apr 2013 08:27:09 +0200, Sebastien Guilbaud sguilbaud+sf@gmail.com wrote:
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!
a distributed mode ala smokeping would be great too...
Given the complexity of our polling, it's currently almost impossible for us to be distributed.
Smokeping collects one metric, we collect thousands :)
adam.
Given the complexity of our polling, it's currently almost impossible for us to be distributed.
That's why it would be a _killer_ premium feature :)
in large nat-ed environnements, being able to drop a small probe on many networks, and aggregating everything in one place is a huge timesaver.
Smokeping collects one metric, we collect thousands :)
true :)
-- seb
On Wed, 17 Apr 2013 09:02:23 +0200, Sebastien Guilbaud sguilbaud+sf@gmail.com wrote:
Given the complexity of our polling, it's currently almost impossible
for
us to be distributed.
That's why it would be a _killer_ premium feature :)
in large nat-ed environnements, being able to drop a small probe on many networks, and aggregating everything in one place is a huge timesaver.
Smokeping collects one metric, we collect thousands :)
It's possible that we could do this by creating some method of requesting SNMP commands and agent gets via an intermediary.
It would create issues with needing to keep the intermediary at exactly the same version (and with our rapid release, this is troublesome).
Perhaps we will look in to something like this at some point.
Though, this is not what I would call distributed monitoring. This is just proxying. Real distribution is even more complex for us :)
adam.
Sure, but it always prefer to have poller close to polling device. And then your network is really wide its helps a lot.
So this is something will be welcomed in future for more scaliblity. To support really big installation like guy who mention 120K ports
On 4/17/13 9:33 AM, Adam Armstrong wrote:
Given the complexity of our polling, it's currently almost impossible for us to be distributed.
Yeah, this is the /complex/ form of distribution. I'm not sure if this is ever going to be realistic for us to implement.
We're very database heavy, so you either have the issue of being far from the device or being far from the database. You can already distribute the poller on to nearby two systems, so long as you can share access to the rrd directory and the database.
I'm not sure what a realistic solution to wanting to geographically distribute polling is, other than running multiple instances.
adam.
On Wed, 17 Apr 2013 11:06:55 +0400, Nikolay Shopik shopik@inblock.ru wrote:
Sure, but it always prefer to have poller close to polling device. And then your network is really wide its helps a lot.
So this is something will be welcomed in future for more scaliblity. To
support really big installation like guy who mention 120K ports
On 4/17/13 9:33 AM, Adam Armstrong wrote:
Given the complexity of our polling, it's currently almost impossible
for
us to be distributed.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
I'm not sure what a realistic solution to wanting to geographically distribute polling is, other than running multiple instances.
Running multiple instances and providing an integrated view on those? Some magic for authentication sharing and loading images from the right instance and you might be halfway there :-)
Anyway, not (yet) really relevant to my tiny setup...
Cheers, Sander
Was a kickstarter project created or not yet?
On 4/17/2013 2:27 AM, Sebastien Guilbaud wrote:
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!a distributed mode ala smokeping would be great too...
seb
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Waiting for Kickstarter approval.
They seem to have gotten a little confused yesterday and tried to reject it.
Re-education is in progress... :)
adam.
On Wed, 17 Apr 2013 02:42:02 -0400, List User list@redspeedservers.com wrote:
Was a kickstarter project created or not yet?
On 4/17/2013 2:27 AM, Sebastien Guilbaud wrote:
We hope to get funding to write a functional alerting
infrastructure
within Observium, so that we can finally kick Nagios to the curb!a distributed mode ala smokeping would be great too...
seb
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
same question, i'd be glad to fund a little :)
On Wed, Apr 17, 2013 at 8:42 AM, List User list@redspeedservers.com wrote:
Was a kickstarter project created or not yet?
On 4/17/2013 2:27 AM, Sebastien Guilbaud wrote:
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!
a distributed mode ala smokeping would be great too...
-- seb
observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
We have, for the time being, decided to shelve the licensing plan and are going to try the Kickstarter route.
Great! Count me in :-)
We hope to get funding to write a functional alerting infrastructure within Observium, so that we can finally kick Nagios to the curb!
Amen
Cheers, Sander
participants (16)
-
Adam Armstrong -
Adam Armstrong -
Ciro Iriarte -
Hibler, Florian -
Job Snijders -
List User -
Mattias Gyllenvarg -
Michael H Lambert -
Michael Sweikata -
Mike Richardson -
Nicholas L. Newman -
Nikolay Shopik -
Rachid Zarouali -
Sander Steffann -
Sebastien Guilbaud -
Tim Nelson