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
