[Asterisk-Dev] benevolent dictatorship, or inclusive developper community?

[Steven Critchfield]

On Wed, 2004-01-07 at 14:34, Martin Kihlgren wrote:
> On Wed, Jan 07, 2004 at 01:32:41PM -0500, John Todd wrote:
> [snip]
> > 	4) Branch Asterisk to a new CVS server somewhere else that is 
> > then more exposed to various programmers
> > 
> > Number 4 is the least likely and "worst" option in the tree, but I 
> > include it as an option to be complete.
> [snip]
> 
> Im not that convinced.. I believe it would do * good to finally accept that
> it is in fact a split project allready - one digium-non-gpl-branch payed for
> by digium customers, and one gpl-branch for everyone else.
> 
> More importantly, however, it would allow for more contributions, and more
> evenly split workload for the participating developers.
> 
> Solution 3) does this also - and is perhaps better, since it wouldnt
> alienate the digium folks, who have done one heck of a job so far.
> 
> But solution 1) or 2) would in the long run have the same problems we have
> today - and are only superior if combined with 3) or 4) (IMHO).

Lets identify a couple types of users. 
1. Users who couldn't care less who provided the software as long as it
works and have no commercial intent, and no intent on doing coding.
2. Users who are open source advocate/zealot who thinks all should be
open source, may or may not do real coding.
3. Users who want to keep an eye to the ability to purchase a non-GPL
license, may or may not contribute code.
4. Users who pay for work to be done and or their own non-GPL license to
deal with proprietary secrets.

A fork only really benefits groups 1 and 2 as they are only going to
have GPL software and all contributions fall under the GPL. Groups 3 and
4 are the ones with money to spend. Group 4 will not follow a fork and
group 3 will have to weigh the cost/benefit of following the fork.
Groups 3 and 4 are also likely to not worry so much about the speed of
development as they can purchase the speed they need.

IF I am right with the above section, Digium may not participate in the
forked version as they wouldn't maintain a license to all patches. So
you would end up with a new CVS server and still having to track
Digium's GPL changes so as to bring forward anything they did until the
point where the code diverges too much to be of help. At this point you
will have successfully divided the contributers and both sides will be
hurt by it.

So lets take a step back and think about working within the system for a
moment. Lets look at the linux kernel for a moment. You will find many
branches/forks of the kernel. RH does some freaky things to their own
version. Alan Cox used to maintain his own set of patches and had his
own releases. This keeps the developers all together, but allows mini
branches.

Here is where I need someone with CVS admin experience to step in and
confirm or deny the ability to make some mini forks that specific
maintainers could then administer. Something along the lines of maybe a
fork that Jeremy administered all the H323 stuff and if you needed it to
be bleeding edge, that is the fork you track. As that subset feels it is
stable, a diff is merged back to the main code. Similar maintainers
could take responsibility for their sub branches, and then we might have
moved Mark into coordinating releases and maintainers as well as guiding
the project. This also allows Mark and group to maintain the main stable
branch and only bring in patches that have been tested and work. Having
the patches in the CVS tree will make testing these patches a bit easier
than the bugtracker. 

Of course the trouble there could be that you will have a couple of
branches you want to track together. Someone recently was discussing
SIP-H323 stuff, and would possible have to try and merge the 2 trees
together. OF course it should be too bad as if you break it along those
types of lines, the core doesn't get changed too much if at all in any
of the branches.

I'll leave this alone now and allow someone to comment specifically on
feasibility of my proposal on technical terms, then lesser so on
organization.

 

-- 
Steven Critchfield  <critch at basesys.com>