James Peel wrote: > Please read this post and let us have your feedback, either on this list > or privately via my email account.
Both. > As a result of feedback from our customers, we are considering a move > towards providing two editions of Opsview, Community and Enterprise. I spent some time considering this rather than 'knee-jerking'. My conclusion: If this happens I will probably stop using Opsview and return to Nagios. Rationale: 1. Your website says: 'Fully Open Source with a single flavour "Opsview Enterprise" ' This clearly shows that you have understood that the 'single flavour' is a merit, and will appeal to users. So why are you considering scrapping it? Would you not expect a consequence of doing so? 2. The reason I have for using Opsview rather than say Groundworks is because you DO have one version only. Yes, and also because I believe Opsview works better, because it is closer to base Nagios. 3. The principle reason I use Opsview (for some tasks) rather than Nagios is the accessible configuration and the improved reporting and graphing. The improved configuration is a benefit for non-command-line colleagues, rather than for me. I have no interest in other features currently. But there are disadvantages as well: it is significantly less flexible than Nagios base, and the dependencies supported are far less comprehensive than Nagios base (see my forum posting 03/03/2009 13:04 - 'JR> Thanks for the reply. JR > But they are not the same thing in Nagios... TV You know, I never realised this existed.... TV Sorry, you've right, I didn't look at your original query enough.') The configuration and reporting/graphing improvements can be facilitated by many add-ons for Nagios, so they are not sufficient reason to continue using Opsview if I am forced into a second-class-citizen position by a two-level release structure. 4a. I have no interest whatsoever in bleeding-edge Network Monitoring solutions. I use Debian (and CentOS) rather than Fedora because they are NOT bleeding-edge. We are RedHat resellers, and RedHat is what I sell to people that need commercial support contracts. RedHat is antithetical to bleeding-edge (it's so old that the cobwebs blow in the wind) but it is reliable. So I find it difficult to believe in the first of your stated reasons for the change: "To address the often conflicting needs of our community and our enterprise customers (e.g. stability of code vs introducing new features)" Who exactly *wants* an *unstable* network monitoring system? Who *wants* 'early and often' in their monitoring? Not me. 4b. The second reason is more germane, and I support your need to do this, we all need to find a decent revenue stream from O-S. However, potentially pissing-off your existing users is perhaps not the best way to start. Is there not a better way? Please note that the original author never took this step - and Opsview lives on his code base. 4c. As to the final reason given: "To provide a stable, mature and predictable code base to larger users, so that they can plan and execute upgrades more efficiently" - I reiterate that stability and maturity are what is required for the product to be useful *for all users*. This is not the Linux kernel! Overall, I would see this as a very bad move. I have of course been expecting something of the sort (am I a cynic? Yes) ever since Opsera bought Altinity. The potential of this sort of complication is also why we turned down earlier overtures from Altinity... Of course, there is no reason why this project could not be forked. Is there? Um. Do you really want to go there? Best wishes, -- James Roberts Stabilys.com _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/listinfo/opsview-users
