True Community-Driven Development
I watch what people like Brian Aker and Brad Fitzpatrick do very carefully. As developers go, they're among the best at making little problems go away so as not to distract them from developing, releasing, and maintaining software.
Brian wrote recently about encouraging very easy commit access to contributors. I can't add anything more to what he said, except to echo his concerns about the implications for making a new release of software.
I've seen this pattern of open repository access in the past few years, first with the Pugs project, and then with Brian and also Adam Kennedy and Michael Schwern. It's a model that works in certain cases.
As Brian mentions, a release has certain implications. The best way to know that your software works on the platforms you care about is to test it on those platforms -- and I know all of these developers believe in the value of automated testing.
The great mass of developers might just now be hearing about distributed source code systems. That's fine. Plenty of them will realize how valuable it is to commit without network access or to branch cheaply and locally, or to have the project history instantly available, changeset by changeset, when they need it. The problem isn't a trivial one, nor is it a completely solved problem, but we're beginning to understand it better, and the solutions we have now are decent and robust and continue to improve.
Now it's time to figure out the next problem. As Brian described it:
I want all open source projects being filtered into a network where users can run slaves that do regression testing for them.
We'll likely discover that on platforms so exotic that available developer support and expertise is minimal (Windows, anything non-x86) that the next bottleneck is people who can fix problems, but being able to track which patch broke support for a platform is highly useful. Maybe for now even the minimal ability of being able to submit a patch to a farm of EC2 instances to get back "Everything passed!" or "Something failed!" results in seconds, rather than minutes, would be an improvement.
Alternately, opening up commit access might mean that we can say "If you want this to run on your favorite platform, you're going to have to get involved." Maybe making it even easier to contribute to a project will finally let us be clear about the true cost of free software: if you rely on it, you must help the community support its long-term health.