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
