Domingo, what you're suggesting sounds very pleasant in
theory. It would indeed allow people to freely explore their own
paths without the burden of a centralized repository.
The problem with this approach is related to Metcalfe's Law: the
complexity of a network grows with the square of the number of
nodes. After all, if you want to have a repository of "uncommitted"
changes, I suspect you'll still want that code to function as a
whole, otherwise it's useless. So you'll need to set some
standards for what code can be checked in, maybe standards
not as stringent as those we use on the core tree. Then
someone else will come along and decide that they want more
freedom than you are offering, and branch yet another tree. And
eventually, we have to coordinate N source trees, a coordination
which has a complexity of N*N.
Organized work means some level of flexibility is lost. The
open-source model and the relatively open CVS policy we have
makes this project quite flexible already. Making it any more
flexible would make the overhead of coordination significantly too
high.... Not to mention that you are suggesting (as Don points
out) that this overhead should be handled by the module
owners, who are already the bottleneck!
Now, what you may be suggesting is some sort of source code
control that would be more hierarchical, meaning where module
owners can delegate some chunks of their code to people below
them... much like Linus does with the Linux source tree. I think
that if OpenACS were a larger project, this would be interesting.
Given that the scope is relatively limited, I think the overhead
outweighs the gains here.
