No. That was not my intent, but I agree with you (and others that/msg'd me) that it could be read that way.

My intent was to suggest a mechanism whereby the users of a module could collaborate to fork a version of the module that would allow them to pool there efforts into producing and maintaining something that met their needs and requirements.

The intention was to avoid having 20 individually forked versions, whether on cpan or local production systems, whilst relieving the pressure on the original module author from having to either feel obligated to react to user pressure for new features and bug fixes, or abandon all control over the direction his code went in.

I felt that if a few, long term users expended their time and effort coming up with one or more patches that met their collective needs, and demonstrated both their commitment and collaboration to getting something that worked for more than a single application, the author my feel more inclined to see their point of view and incorporate those patches back into the original module. I did not envisage any mechanism for forcing him to do so.

I felt that if a few, long term users expended their time and effort coming up with one or more patches that met their collective needs, and demonstrated both their commitment and collaboration to getting something that worked for more than a single application, the author my feel more inclined to see their point of view and incorporate those patches back into the original module.

Or, hopefully, feel more confident to relinquish control. (Or, if s/he starts maintaining her/his version again, have the forkers merge back upstream and phase out the fork.)

(I think the free software world is poorer for not having sufficiently good distributed source control systems that everyone can effortlessly branch/fork projects locally while still tracking upstream patches. The lack of technical solutions turns questions like these into huge social headaches.)

Makeshifts last the longest.

... not having sufficiently good distributed source control systems ...

Agreed. I think that most if not all SC/VC software still have interfaces geared around the mechanics of what they do, rather than around the needs of the user.

For example, the need to go through a 3 stage process of setup to move existing code into them combined with the need to explicitly PUT after modifications.

A system that used the OS change notify mechanism to detect and record changes automatically could be so much better. Setup would be a case of telling it to monitor a subdirectory (tree) for changes. That's it. No copying involved, just a crc check of each of the files and register them for change notifications.

Anytime the file gets changed, it receives a notification and immediately records the deltas in the background; locking the file against writes until it is done. Reads (eg. compiler) continue whilst it works.

DARCS is meant to be good for the distributed side of things; allowing greater flexibility and less traffic for localised changes that only get merged if the need arises. I'll get around to checking it out one day.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.