Closed development?

[walterheck]

One fo the things that I've wondered abotu for a while now is why the development process is so closed from outside contributions? I think there are quite a few people who would be willing to contribute things like bugfixes and the likes (I rely on zabbix for http://tribily.com and would love to help with things).

I have read here and there that there are "difficulties" to overcome, and I was wondering what they are? <dreaming>I think if source control was moved to a place like launchpad, development could be made a whole lot more easy to contribute. Launchpad still allows for a core team to oversee everything, but it also makes contributing so much easier. Large porjects like drizzle, mysql and ubuntu all use launchpad, and for good reasons

Anyway, can anybody enlighten me? I'd like to get a discussion goign and maybe help move things forward, as I think it can greatly benefit the future of zabbix..

[Alexei]

The development process is not closed at all. I won't go into details but there are plenty of patches and bug fixes from outside contributors that have been integrated into Zabbix code.

[pdwalker]

If "open" you mean that anyone can commit changes to the source code repository, then no, it is not and thankfully so.

If "open" you mean that anyone can submit patches based on the current source code that fix problems, then yes, the development is open.

A good product requires good management and good architecture. You cannot have that if everyone and their dog is changing things according to their current needs and whims. Think of it as "too many cooks spoiling the broth".

If you want to be part of the development, prove yourself. Sign up for their jira account and look at the outstanding bugs. Fix some. Submit your patches.

Your fixes may or may not be accepting, depending on the the developers needs and their architecture decisions. If they are not accepted, they may tell you why, or maybe not. If your fixes are accepted, then you are doing something right.

You have to start somewhere.

[richlv]

my completely personal take on small part of the issue

while there's lots of excitement about developing something, quite often it does not materialise when a chance appears. and even if there's some activity, quite often only the "interesting" parts are being done - like implementing just the feature, but not making it fully operational, or not caring about whether it works on all databases.

and then comes the question of maintenance. it is easy to dump a piece of code. it is hard to maintain it. one example might be snmp builder (http://www.zabbix.com/forum/showthre...=15088&page=15) - nice proof of concept (even though it depends on snmp tools being available on the webserver) etc - but who would maintain it if, let's say, it was just merged to zabbix ? we can see that the thread is full of different updates, patches... that users have to piece together themselves. kudos to fmrapid for trying to put it all together, but a long term stable maintainer seems to be missing for that addon.

sometimes it's also about the details of a patch
for example, zabbix frontend had issues with php 5.3 initially, there were lots of warnings etc. so somebody... sort of provided a patch. unfortunately, all that patch did was just hide the warnings. i don't think anybody here would like to have that merged.

ideas on how to improve situation could be helpful - maybe some centralised repository of all the patchsets ? that would still not solve maintenance question, everything in there would have to be maintained anyway.
at least that would make it easier to update them for all contributors, and would also nicely show what amount of interest each component gets - and would work as a way to show their commitment to maintenance.

eventually it could turn out in some interface for frontend "modules" where you could just drop something in a specific directory, frontend would pick it up and add to the zabbix menu. the module would only use api, no direct db connections. well, but that's a different topic, something more for the future to ease contributing

[walterheck]

When I talk about contributing, I don't mean right now. We're a self-funded startup, so we need to make break-even before we can contribute. One of the first things I'd like to do once we do get to break even though, is hire a decent C-coder who can implement missing functionality in the zabbix binaries. It would be great if that could be done working _with_ zabbix SIA, not parallel to them.

If you look at a project like drizzle (http://launchpad.net/drizzle) for instance, they make extensive use of the blueprints feature of launchpad: https://blueprints.launchpad.net/drizzle

A blueprint is pretty much a proposal for some atomic piece of functionality. The maintainers can approve them and they can request feedback, link them to branches, etc. By having those public, everyone can see what needs to be done and can pick up any part of it. When it is implemented by someone, it can be merged into the main tree by any of the main maintainers after a good code review.

Right now it is not very handy to work on new featurs for zabbix, as we have no idea of what is being planned.

Open Source imho is also about transparency, and I find it hard to see that with zabbix. That said, please understand that I bring up this issue out of love for the project, not for the sake of bashing on someone. Overall I'm extremely happy with zabbix and I think a good job is being done (I wouldn't be building a company around zabbix if I wasn't )

[mtier]

Why you don't pay Zabbix SIA for the enhancements you want see? For me it looks like more you want add functionality which you need to run you own business.

You should be happy that the source code is free but from my point of view there is no reason that the business model from Zabbix SIA should be changed to make some users happy.

I am sure some paid development (from your site) can also help to get some missing features done, which are usefully for a wider user base ;-)

[richlv]

One of the first things I'd like to do once we do get to break even though, is hire a decent C-coder who can implement missing functionality in the zabbix binaries.

as noted, additional functionality can be discussed for development by the zabbix company - and then the issue with maintenance is also not as problematic. if some feature is fully developed externally, it's an additional maintenance burden, which would be less of an issue if some entity had an excellent track record of developing and maintaining a wonderful piece of code...

Open Source imho is also about transparency, and I find it hard to see that with zabbix.

while transparency could indeed be better, another issue is overpromising - for example, published roadmaps happen to have some features removed, which is more disappointing than not seeing them on the roadmap in the first place

as for other transparency aspects, all the code is out there in open, including development branches. while not all new development is hugely advertised, some people still manage to find these dev branches and give early (and usually very valuable) feedback - for example, recent gettext implementation got several issues reported even before it was merged to trunk

i guess more development process transparency could be achieved by publicly announcing dev concepts even before they are anywhere close to finished, although that again brings us back to the overpromising.

talking about interest in development and dedication to maintaining what is developed, another example is... zabcon. while there have been some additional contributors to it, they have been pretty short, and nelsonab is still the only person actually working on it. if anybody feels like doing some development work, i'm sure he'll be glad to get that help (sure, sure, you can't just throw a php dev in a basement and force them to work on ruby code. usually.)

[nelsonab]

I'm glad to see this thread getting some good discussion.

I would say though that the one area Zabbix SIA has not been good over the years is at communication with those who are interested in helping. It's a two way street, and I would love to see a greater effort to communicate and work closer with those who are willing to give their time freely to Zabbix SIA. There are some great people who are fired up with Zabbix, I would love to see their passion encouraged and fed by Zabbix SIA.

Also yes there is an issue of transparency, I think both Walterheck and Richlv are right, but I think there is a better way if the Open Source way is more tightly embraced. What if the road map were moved to a wiki? Software road maps are guides, not promises. I think it's also important to state that in a road map document. We're in a new dev cycle it's understandable that some things will make it into the next revision and some won't. Take a look at how Trac is developed, they're very open about moving things which were promised for the next version to a future one when they begin their initial development of the next major revision.

I think though that Richlv is correct, though short of the mark, with regards to the developers being more open. I wish there was much more discussion of a feature that is being developed before and during it's development. A perfect example of this is the API. When it was finally released there was no consideration for the difference between a hash or an array because in PHP it's all the same. Had there been a discussion earlier then perhaps there could have been much greater consistency between the calls and perhaps a much easier to understand interface for those who do not know Zabbix intimately. Don't get me wrong I think the API is great, but I think some better discussion before it was implemented would have been the secret sauce to make it not only good, but awesome or fantastic.

For a better idea of what I talk about when I talk about doing things in a more Open Source manner check out the following link on "The Open Source Way." For my present employer this mentality is at the core of just about everything they do, and they've been quite successful. :-)

http://theopensourceway.org/book/

[zalex_ua]

I noticed this thread yesterday, and there is my duty to answer.

as for other transparency aspects, all the code is out there in open, including development branches. while not all new development is hugely advertised, some people still manage to find these dev branches and give early (and usually very valuable) feedback - for example, recent gettext implementation got several issues reported even before it was merged to trunk

As I understand you says about me.
Did you like my early feedback? And I did it because this development has been registered as ZBXNEXT, which the tracker has been described - what goals and objectives.
On this occasion, I would say such a huge [DEV-491] - where a description?
I can not understand what you are developing. And maybe I would once again gave useful feedback for you.
The same thing about [DEV-480] low level discovery. Only after I asked for - you gave me the documentation, I tried and gave useful feedback for you.
My question is - why all this has not been registered as ZBXNEXT with an elementary description of the idea?
This is my little hands-on look at your openness, that correlate with the roadmap thoughts.

talking about interest in development and dedication to maintaining what is developed, another example is... zabcon. while there have been some additional contributors to it, they have been pretty short, and nelsonab is still the only person actually working on it.

one example might be snmp builder ...... - but who would maintain it if, let's say, it was just merged to zabbix ? we can see that the thread is full of different updates, patches... that users have to piece together themselves. kudos to fmrapid for trying to put it all together, but a long term stable maintainer seems to be missing for that addon.

Yes, this is a problem that some good, well-developed idea can stop its development, support, and eventually die.
This is where you should provide some support to this process. For example why do not you make a platform (a special branch in SVN) for placing the code from community? For example in relation to the snmp builder, the code is on github.com, is not accessible to those who would like to continue to develop the idea. Why do not you do hosting for this code?
Let this be not the official repository, but under your control.

It's a two way street, and I would love to see a greater effort to communicate and work closer with those who are willing to give their time freely to Zabbix SIA. There are some great people who are fired up with Zabbix, I would love to see their passion encouraged and fed by Zabbix SIA.

I do not want to speak specifically, but despite that I'm quite contribute to the project, unfortunately I realized that I have no chance that you will fulfill my ask for performing a single easy (imho) ZBXNEXT. He clearly demanded by many people, has a certain amount of votes. But I have to wait and not know how much time is annoying.
But that's not stopping me in the desire to free aid for Zabbix project. Yet

I understand that there is an internal policy (business model) which ensures the existence of the Zabbix SIA. We understand that this is important for you and for us as well, but I fully support nelsonab about "love to see their passion encouraged and fed by Zabbix SIA".

Do not worry, we are with you.

p.s. sorry for my English

[troffasky]

from my point of view there is no reason that the business model from Zabbix SIA should be changed to make some users happy.

How is not having a publicly visible roadmap a 'business model'?

Making contributions easier is a net win for everybody - Zabbix SIA and Tribily have a better product to sell to their customers, which means more money coming in that can be invested into Zabbix, and the cycle continues.

A publicly visible roadmap increases confidence in the project for potential users, which means more users [and of course more customers for Zabbix SIA].

There is nothing to lose by opening up development.

[Alexei]

A publicly visible roadmap increases confidence in the project for potential users, which means more users [and of course more customers for Zabbix SIA].

I am absolutely with you. It is in interest of all of us to keep it publicly available. Please give us a few days, I am sure it will appear on our website very soon.

[nelsonab]

I am absolutely with you. It is in interest of all of us to keep it publicly available. Please give us a few days, I am sure it will appear on our website very soon.

This is good news! I think the Documentation wiki is a great place to put something like this. I also think the roadmap should be a be as descriptive as possible. Especially when it comes to proposed features down the road. This can give people a chance to provide feedback. One idea might be for future feature ideas (ones not slated for the next revision cycle) might have a link to the public wiki for people to discuss how to solve or implement said features. Thus when the Zabbix teams get's around to implementing said feature it is hoped that less initial effort is required on their part.

Now if we can open up SVN to some trusted community members... ;-)

[zalex_ua]

Now if we can open up SVN to some trusted community members... ;-)

Firstly, we asked for write access to the documentation - we got it, although I did not believe that this will turn out.
We now have the bold idea of write access to SVN - I wonder to see what the outcome of this idea.

[nelsonab]

Firstly, we asked for write access to the documentation - we got it, although I did not believe that this will turn out.
We now have the bold idea of write access to SVN - I wonder to see what the outcome of this idea.

I would expect this to be something earned. Also I could see a multi-tier solution to it. Where people are more likely to be given write access to the branches section than the trunk. Same is true for tags. Palmtree is one person who comes to mind for something like that. However I think first svn should be setup to work over https using DAV, which it currently isn't. It looks like either svn or Jira would need to be moved to either separate computers or different IP addresses, so there is definitely some systems administration work needed first.

In time I would like to see things be even more open to where even more people can be entrusted to contribute.

[richlv]

On this occasion, I would say such a huge [DEV-491] - where a description?
I can not understand what you are developing. And maybe I would once again gave useful feedback for you.
The same thing about [DEV-480] low level discovery. Only after I asked for - you gave me the documentation, I tried and gave useful feedback for you.
My question is - why all this has not been registered as ZBXNEXT with an elementary description of the idea?

would it surprise you a lot if i said that... i FULLY agree ?

Yes, this is a problem that some good, well-developed idea can stop its development, support, and eventually die.
This is where you should provide some support to this process. For example why do not you make a platform (a special branch in SVN) for placing the code from community?

would it be a surprise again ? =)

although some things take more time, i'd like to hope that overall it is improving. on the other hand, there's this circle of not investing lots of time and resources into what might not pick up. for example, look at just a handful of people commenting on 2.0 documentation thread, and there doesn't seem to be a huge enthusiasm in writing the docs - which is understandable, as that is hard and everybody has lots of other things to do already...

hopefully, taking some simple and small steps will help, and maybe we all will see some of those in near future