Options other than a fork?

[Steven D. Morrey]

Hello World,

I realize that I'm a Johnny-come-lately to the Nagios community, as the current maintainer of DNX I see myself as somewhat connected to the debate, but frankly I don't have a pony in this race, so I hope that my opinion comes off as a concerned observer.
I've been following the Nagios is dead, lets make a fork thread, and while I commented heavily in the beginning, I've tapered off so I could take some time to think.
This is not by any measure the first time, all or part of a community have made the decision to fork, so lets take a look at some case studies of successful open source software, those that have forked and those that only sort of have, and see what lessons we can learn from them.

The first one that comes to mind, and actually the one I think that forked for reasons closest to ours (I'm neither for nor against a fork, when I refer to ours I refer simply to the matter at hand).

Mambo / Joomla

According to Wikipedia...

http://en.wikipedia.org/wiki/Joomla.
Joomla was formed in 2005 in response to Mambo being trademarked and effectively owned by a private corporation, Miro Intl Prvt Ltd.
This appears to have caused a great deal of stress within the community and most of the developers left to found opensourcematters and later Joomla, which oddly enough means "all together".
Joomla is inarguably a very successful project, and by all accounts is more well known and more widely adopted than Mambo at this stage.
That said Mambo still has a pretty strong following and most of the doomsayers have at least thus far been proven wrong.

I call this a 50/50 amicable split, but the primary reason behind the fork was that the community or at least part of it felt disenfranchised when Mambo made a change of licensing / ownership.
I think the lesson to learn from this is that it's very important to listen to the community, but the community also needs strong, involved leadership, whose primary interest is the further development of the product.  I think history will show that this should probably be separate and apart from the commercial interests of the product.

Now lets look at another example.

Compiere / Adempiere

Again according to Wikipedia...
http://en.wikipedia.org/wiki/Adempiere
In September of 2006 Adempiere was founded due to a long standing disagreement between ComPiere Inc. and the community that sprung up around it.
The community believed that Compiere was placing too much emphasis on commercial development and had effectively closed the source by not improving on the public code base in quite sometime.
http://red1.org/forum/viewtopic.php?t=931

Now this in anecdotal, but I would say this split was not what I would call amicable, and most of the Compiere "Partners" that I worked with back in my consulting days eventually dropped Compiere in favor of other solution(s).
Again it looks like the split occurred because the community felt ignored, there was very little feedback, no back and forth, very little if any development in the publicly visible code base.
Adempiere appears to be growing, the community appears to be large and vibrant and releases are taking place on a fairly regular basis. 
Compiere on the other hand appears to be doing ok in spite of the fact that a large portion of it's community disappeared.  This is partly because the primary users of Compiere are large enterprises that have heavily invested in Compiere infrastructure, and also partly because of the company has moved to a cloud based system that is more appealing to the small and medium sized enterprises vs having to setup and install their own CRM/ERP solution.
So the outcome is one that appears to be mutually beneficial for all involved.  The community got their "community developed CRM/ERP product", and Compiere gets to focus on their mostly commercial offering, while still maintaining some of the warm fuzziness of open source.

Here is another example of a fork.

Mozilla / Firefox
According to Wikipedia...
http://en.wikipedia.org/wiki/Mozilla_Firefox

Firefox was created as a fork of the open source Mozilla browser.  The purpose of this fork was to "trim the fat" so to speak and produce a lean and mean browser that didn't have a kitchen sink approach to development.
In April of 2003 the Mozilla foundation decided to throw their full support behind Firefox.

In this case, the fork ended up supplanting the original product with the blessing of the parent company.  Firefox is one of the most popular open source projects ever and has a HUGE install base, much larger than Mozilla ever had.  It is a recognizable brand and I have been surprised that even in my role as neighborhood IT nerd, when little old ladies ask me to replace the Internet Explorer with Firefox so they can be safe on the Internet.
This I think is one of the few good reasons to fork an open source product.  Here the developers encountered something architecturally different from what they believed a browser should be, and set about fixing it.  Since this difference was not compatible with the direction the overall project was going, they created a separate product, a fork, that is now the more well known product.

If you would like more reading there is a fascinating article on forks in general at http://linuxmafia.com/faq/Licensing_and_Law/forking.html 

At this time it appears that at least some fraction of the community would like to fork Nagios development, not because of anything they see architecturally wrong.  
Not even anything as grandiose as idealogical differences.  
It appears to me those that want to fork, want to do so because they feel disenfranchised.  
Is that correct?

If so, wouldn't it be better to attempt to bring the community back into the fold by allowing for deeper involvement, give the community some sense of ownership and maybe have the corporate interests focus more on the potential commercial aspects and allowing the community, or a community board to have control of both the overall direction of the codebase and responsibility for the day to day operations of maintaining the code.  (Note:  I am not volunteering for this duty, my day job prohibits it.)
If this is as I suspect, a problem where we have strong differences of opinion as to what constitutes community involvement, maybe the board could be comprised of people from both sides of the issue(s) including Ethan and whomever else has a pony in this race, and hammer out an agreement on what exactly we mean when we say community involvement.

Anyways these are my thoughts.  I don't think a fork is necessarily the best option even though that statement is like trying to close the door after the cow is already out of the barn.  
But the grass usually does look greener on the other side doesn't it?
Does anyone else have thoughts on these matters?  
Is there a way we call all sit in peace and harmony and sing Kumbia so I can get back to DNX development ? :)

Sincerely,
Steve 


 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.



------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com