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
