I'd agree, after reading Ton's latest message it makes me feel much
better about this.

Regards

Dave Sykes
Head of Engineering
+44 (0)1252 740721


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of paul
Sent: 31 May 2009 11:10
To: Opsview Users
Subject: Re: [opsview-users] [opsview-announce] Moving towards two
Opsview editions - Community and Enterprise

Hi All,

Reading this, I'd say go for it. For us nothing changes, for the users 
wanting to have a rock-solid stable monitoring system, they can choose 
wheter or not they want the paid version.

Regards
paul


Ton Voon wrote:
> Hi,
>
> I want to clarify some of the basic principles that we are adopting  
> with this strategy.
>
> Firstly, some background:
>
> 1) We want to continue developing Opsview to make it a fantastic  
> monitoring system. In retrospect, considering the size of the  
> development team, we've done an amazing job in 3 years (an MVC web  
> framework, a simple configuration GUI, powerful distributed  
> monitoring, database backend, configuration API, automatic performance

> graphing, simple SQL historical reporting). But we acknowledge that we

> cannot stay still - you have to continue to innovate or die
>
> 2) We want to be good open source citizens. As many of you know, I am

> project lead for the Nagios Plugins and I have spent an inordinate  
> amount of time on making that core project better (Opsview make very  
> few changes to the base Nagios Plugins distribution). I've calculated

> the number of patches that we've made to Nagios and in Opsview 2.14  
> (Nagios 2.10), we had 40 patches . By Opsview 3.0 (Nagios 3.0), this  
> dropped to 30 patches because Ethan accepted a lot of our changes and

> put them in Nagios 3, while we kept them in the Nagios 2 branch. With

> my new commit access for Nagios, when we sync with Nagios 3.1, this  
> will drop to 22. This number will keep dropping, which means everyone

> in the Nagios ecosystem benefits from our enhancements. (BTW, as an  
> exercise, count the number of patches provided by other companies to  
> Nagios or the Plugins - I can tell you the number right now from  
> Groundwork)
>
> 3) We don't want to do the "open source is some crippled version" with

> less features - this is just demoware under a marketing name
>
>
>
> So what is our proposed solution? We've turned the "less features" on

> its head.
>
> Opsview Community actually will actually have **more** features than  
> Enterprise because it is bleeding edge. It will be the latest code,  
> with all the newest enhancements and performance tweaks. It will  
> contain all cumulative fixes.
>
> This is what you have now with Opsview. We make changes, we enhance,  
> we find mistakes, we fix.
>
> Opsview Enterprise, on the other hand, is about minor changes. Only  
> changes absolutely necessary, because Enterprise is about stability.  
> When there is an upgrade, people want to know the exact features and  
> the exact upgrade path involved.
>
> The difference in future is that we are going to restrict access to  
> Opsview Enterprise to paying customers.
>
> Maybe the numbering will make this clearer. Opsview 3.1 is going to  
> come out in a few weeks. That will be Community. We'll do a new  
> release every time we add a major feature, so that features are  
> available straight away to the community. This will also include all  
> bug fixes.
>
> At some chosen release schedule, we'll cut an Opsview 3.2, which **is

> based on 3.1** and that will be Enterprise. We'll also start  
> development work on Opsview 3.3, which will be the next community  
> release.
>
> So odd numbers are the community editions, with even numbers as the  
> enterprise editions.
>
>
>
>
> Dave Sykes says "The reason that we chose opsview over the competition

> was that there was only one version"
>
> There will still only be one version of Opsview, but even branch  
> numbers are not publicly available. We plan on the upgrade path being

> as smooth as it currently is - that you can upgrade all the way  
> through to the latest versions.
>
>
>
>
> Steven says "I can imagine many customers wanting to run the  
> Enterprise version because of the extra modules/features"
>
> For core Opsview, community will have more features, because of the  
> development cycle.
>
> For modules, we are not stripping out any existing Opsview features.  
> By the very nature of it, modules could be replaced by other  
> technologies - some people have done that already themselves. We think

> there is value in how we integrate modules with Opsview.
>
>
>
>
> Paul says "Personally, I would go for an Opsview-stable release and an

> Opsview-unstable. Stable as in rock solid, dummy-proof version, where

> the unstable provides for the added/modified features. These features

> would then gradually move into the stable release. "
>
> That's what we are doing. Think of Opsview-unstable as 3.1 and
Opsview- 
> stable as 3.0. But unstable is as polished as it is now (it is just a

> label).
>
>
>
>
>
> Ben says about Splunk "Now, if I suddenly decide to start indexing 300

> more servers worth of logs... then I will have to increase my license

> (if i go over my limit). But the neat thing is it doesn't _stop_ any  
> indexing or flow of log data to your boxes,  you just can't search on

> it =P"
>
> We are deliberately not doing that. We don't put arbitrary limits on  
> our software. We don't limit the number of browsers accessing Opsview,

> we don't limit the number of hosts, we don't limit the number of  
> slaves. When Opsview is on your system, its yours. (By the way, Splunk

> is *not* open source - their licence forbids you to change their
code.)
>
> But what is interesting is that Ben has highlighted "restrictions" -  
> there has to be some restriction to get someone to pay. We choose to  
> restrict based on access to new releases of older branches.
>
>
>
>
> j.roberts says "there is no reason why this project could not be  
> forked. Is there?"
>
> Correct. Opsview is licenced under the GPL so forking is permitted.  
> Our licence allows you to make changes to Opsview, so if you want to  
> maintain your own version of Opsview, you can (though you would be in

> breach of trademark if you called it Opsview).
>
>
>
>
> j.roberts says "Who exactly *wants* an *unstable* network monitoring  
> system? Who *wants* 'early and often' in their monitoring? Not me."
>
> Then I'd argue you are exactly the type of person that would benefit  
> from the Enterprise edition.
>
> If not, well, when a new release comes out, there's nothing stopping  
> you from *not* upgrading. So stick with your working system.
>
> By the way, this is not an excuse for shoddy code. We will only  
> release when we think features are ready, using the same process we  
> currently do. We have a responsibility to maintain an upgrade path for

> *all* our users, because you are entrusting us with your data. Putting

> in rubbish code jeopardises this.
>
>
>
>
> In summary, Opsera are open source advocates. We firmly believe in the

> freedom of software: that when it exists on your servers, that you  
> have the freedom to make changes to it as you see fit. We think this  
> solution still gives those freedoms, while supporting continued  
> development in Opsview.
>
>
> Ton
>
>
> _______________________________________________
> Opsview-users mailing list
> [email protected]
> http://lists.opsview.org/listinfo/opsview-users
>
>   

_______________________________________________
Opsview-users mailing list
[email protected]
http://lists.opsview.org/listinfo/opsview-users

The information contained in this e-mail is confidential. If you are not an 
intended recipient of this e-mail please notify the sender immediately and 
delete all copies from your system. You must not read, copy, distribute or take 
any further action in relation to or reliance on this e-mail.

Elateral will not, to the extent permitted by the law, accept responsibility or 
liability for the timeliness, accuracy or completeness of this e-mail or any 
attachments to it (unless specifically stated) nor for the presence of any 
virus, worm or similar malicious or disabling code in it or in the attachments. 
Please be aware that e-mail is not a secure form of communication.

Elateral Limited, Registered in England No. 3036315. Elateral House, Crosby 
Way, Farnham, Surrey GU9 7XX. VAT No. GB 742 577710
_______________________________________________
Opsview-users mailing list
[email protected]
http://lists.opsview.org/listinfo/opsview-users

Reply via email to