Last week I linked to a quote by Zach Holman on getting people interested in your projects. His original text included a link to an excellent post by Ryan Tomayko , which argues for structuring your team in an opt-in format, much like open source projects. I've been reading more and more to this effect recently, but Tomayko makes a really great case. A few excerpts (n.b., I've reformatted a few of these due to weirdness while composing this post {grr...}. The spirit should be unchanged. Also, emphasis is mine.):
What we're learning at GitHub is that opting in to open source project constraints often results in better natural survivability characteristics for many types of business, product development, and operations activities. That is to say, processes designed to conform to open source constraints results in a project that runs well, attracts attention, and seems to be self perpetuating where the same project structured more traditionally requires much more manual coordination and authoritative prodding.
Tomayko excerpts the GitHub product development documentation at length:
The processes and basic rules for communication on github.com projects are roughly the same as those of an open source project. Mainly, that development and operations follows these constraints where sensible: Discussion, planning, and operations process should use a high fidelity form of electronic communication like email, github.com, or chat with transcripts wherever possible. Avoid meatspace discussion and meetings...Work should be visible and expose process. Work should have a URL. It should be possible to move backward from a piece of product or a system failure and understand how it came to be that way. Prefer git, issues, pull requests, mailing lists, and chat with transcripts over URL-less mediums...Almost no part of the product development process requires that one person interrupt another's immediate attention or that people be in the same place at the same time, or even that people be in different places at the same time. Even small meetings or short phone calls can wreck flow so consider laying it out in (a thought out) email or sending a pull request instead.
And then goes on to "predict the decline of the office as the center of planning, coordination, and communication for software development organizations," while acknowledging their utility in developing strategy and celebrating milestones & victories:
Lastly, working face-to-face in meatspace has proven extremely valuable in matters of strategic thinking and, obviously, for developing personal relationships, two things which are vital to a company's success.
I suspect that more and more product development cycles will move this way in the future, and think that the results will be overwhelmingly positive.