Not much point in a monitoring system that is unstable.... On Sun, May 31, 2009 at 5:09 AM, paul <[email protected]> wrote:
> 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 > -- Ben Lutgens Linux / Unix System Administror Three of your friends throw up after eating chicken salad. Do you think: "I should find more robust friends" or "we should check that refrigerator"? -- Donald Becker, on vortex-bug, suspecting a network-wide problem
_______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/listinfo/opsview-users
