Open Source Software Apprentice
Learning through experimentation and tinkering is one of the best ways to proficiency in any field. Combined with a feedback loop from an experienced mentor, it is almost a guaranteed path to success. This model of apprenticeship first pioneered in the Middle Ages by numerous craft guilds exchanged masters time for inexpensive labor from the apprentice, and by all accounts, gave us thousands of accomplished individuals who may not have made it otherwise. Trade tricks and regional specialties were passed on and methods were evolved and improved. I think there are a few things we (the open source community) can learn from that past.
Listening to the frameworks panel at GoGaRuCo (Rails, Merb, Sinatra, Adhearsion, RAD, Shoes) the message was abundantly clear: distributed version control systems (DVCS - Git, Mercurial, Bazaar) are changing the game in the open source world. Every project attributed at least part of their success to the new "easy fork, branch and merge" model, which both lowers the entry barrier and encourages experimentation. Visualization of Ruby on Rails contributions is a great example of this trend (with a big explosion in new contributors after the switch to Git, circa April '08).
Social Coding & Distributed Version Control
It is hard to scientifically measure the impact of a switch to DVCS, since there are a number of hidden variables in the equation. For example, at least one reason why the number of contributors rises dramatically is due to the fixed attribution model: distributed version control allows to trace code and patches back to the original author instead of having the commit guardians merge changes under their own name. Let's face it, we all like to see our name and get recognition, there is nothing wrong with that, and in fact, it should be encouraged.
"Social coding, community, and switch to DVCS" is the new mantra in the open source world. But while definitely a step in the right direction, it also strikes me as a passive strategy: "put it in DVCS and they will come, community will grow". This approach hasn't worked for many companies in the past when it comes to product development, nor do I think it will work wonders in the open source world. After all, while building a community and contributing code are not mutually exclusive, they are very different tasks. Some developers can successfully juggle both roles, some can't, and majority doesn't even think about it. A source tree with one contributor is a personal itch, two is a project, and three is a tribe. We need to build tribes.
Fostering the Role of the Software Apprentice
Every field has a rockstar (or a few), it may be the original author of a successful project (Linus: Linux, Monty_Widenius): MySQL, Rasmus: PHP, Matz: Ruby), or a core contributor who knows the source tree inside out. Their time is scarce, but I am always amazed how approachable and willing to help most of them are. Databases tickle your fancy? Did you know that Drizzle team (one of the most promising DB initiatives) is looking for people to mentor? In fact, I think it is more than a curious coincidence that any successful open source project today is also one that is actively engaging in apprenticeship programs. Master-Apprentice model is an incredible community builder.
Like most Ruby developers, I am a big fan of GitHub as it allows me to track and contribute to dozens of projects in a fraction of time I would have spent previously. However, I think some of the tooling is missing. Launchpad which uses bazaar DVCS and hosts projects such as Ubuntu and MySQL is already tapping into the master-apprentice community (ex. Drizzle mentor projects). But we can do better. Those roadmap and todo txt's in our source trees or a hijacked bug-tracker as a roadmap tool is pointing to one thing: they need to be social artifacts. If the author publishes his wishlist and offers his time to mentor and guide the contributor, everyone wins. Instead of guessing and bickering over the features, I can learn from the best, and together we can start a tribe. Let me vote on features, propose new ones, let's discuss them - hardly revolutionary concepts for the social web.
Mentors, please stand up!
Have a project? Let the community know what you want, put yourself out there, offer your time. Google Summer of Code is a fantastic initiative to pair students and mentors (Rails + GSoC '09 projects), but I don't think it's the money that ultimately motivates either side to contribute. Of course, this is no magic bullet, and make no mistake, as a mentor you'll have to invest just as much, if not more of your time to make a feature come true. Outside contributors will make 'newbie mistakes', and they will try your patience, but the endgame is worth it.
I want to help, I want to learn, I want to see roadmaps, I want to discuss wishlists, I want to build tribes.
Ilya Grigorik is a web ecosystem engineer, author of High Performance Browser Networking (O'Reilly), and Principal Engineer at Shopify — follow on Twitter.