You can't just mix and match patches automatically. Someone has to resolve merge conflicts. There is a cost to this: developer time.<p>Distributed version control systems are being so successful because they allow developers to more easily do what they have been doing all along anyway (take Linus' job, for example).<p>I don't think there is a major paradigm shift here; just a revolution in tooling. There will still always be a main line. That main line will not be "distributed", even if the way that changesets get there might be.<p>Most of us will only be using releases taken from the main line. Forks will carry on happening from time to time, but just like now most will work to avoid them because of the inefficiencies that result.
About the only useful thing the Apache Software Foundation can lend your project is their imprimatur of enterpriseyness, though that comes with a lot of bureaucracy to back it up.<p>"Nobody ever got fired for buying IBM", and the ASF practically <i>is</i> IBM!
"Fork" is a poor choice of verb for what I think he is describing/dvcs/github allows. More like experimental branch this dudes gonna do his thing on and if it's good we'll absorb it into the "main" project. Which, btw, has been going on forever, git[hub] just makes it easier.<p>A Fork means there's irreconcilable differences and the dev base is splitting into 2-3 camps, old mainline, new forkers, people who leave in disgust over lack of coop.