That might appear to be a very large-scale collaboration, but it's not, he said. If you graph the contributions, you soon see that the most active contributors are doing the bulk of the work, with the top contributor doing around 500 edits of their own. The tenth highest contributor did 100 edits, and the 100th did 10 edits. Around 75% of contributors did only one edit ever.
That same pattern shows up in many different places, he said, including Linux kernel commits. These seemingly large-scale collaboration projects are really run by small, tight-knit groups that know each other and care about the project. That group integrates lots of small fixes that come from the wider community. Once we recognize that, we can plan for it, Shirky said.
But, at the same time, us core CDK developers have to accept this, and live with it. This is one of the reasons that code must be peer reviewed, because after the patch is supplied, the maintenance is mostly on the shoulders of these core developers. I learned that the hard way. It's a bit like the learning process used by StackExchange also outlined in the LWN.net write up.
Therefore, it's up to the core developers to educate potential contributors and make the contribution as simple as possible. GitHub, also discussed in the write up, does great work indeed. Fixing spelling errors (or adding missing period after first JavaDoc sentences) is as simple as getting a GitHub account, and hitting the 'Edit this file' button on the page showing a CDK source file, and start working.
Otherwise, the CDK community is very helpful in creating patches. You just have to ask, e.g. on our #cdk IRC channel. And, if there is enough interest, I am more than happy to organize a 'Making a CDK patch from scratch with Git and Ant' crash course.