Chris Messina posted his framing of open source via the metaphor of spinning plates. In a nutshell, volunteer efforts help keep the plates spinning. How well a project can leverage their help (to actually spin the plates) and reward that help will determine how well the project will retain and recruit volunteer effort.

Here’s some more food for thought on that line…

  • It’s not just open source projects that follow this metaphor — pretty much any volunteer program does, whether that volunteer effort is backed solely by other volunteers (like most open source projects) or is backed by some non-profit or for-profit enterprise (like church fundraisers or get-out-the-vote political activities).
  • However, there is some threshold of visibility before this metaphor really applies. To paraphrase a hackneyed aphorism, if a spinning plate fell in a forest and nobody was there to hear it, was the plate really spinning in the first place? So, the vast majority of open source projects on SourceForge, for example, have either one person spinning a plate, or have an image of a spinning plate emblazoned on the project’s tombstone. Only once some community notices and values the project might others decide that plate-spinning sounds like fun.
  • The advantage that open source projects and other online-based volunteer efforts have is a wider potential set of volunteers (not limited by geography) and a lower switching cost (it’s fairly cheap for people to give the plate a love tap and see if they like the spinning process). Of course, the lower switching cost for volunteer time is also a disadvantage. In contrast, local volunteer efforts, like helping with your town’s 150th anniversary celebration, have a limited set of volunteers and a high switching cost into the project.
  • Project efficiency should, in theory, help determine long-term winners. I believe this is what Mr. Messina refers to as “build[ing] infrastructure to harness the additional marginal effort that is contributed as social capital”. Since I have a physics undergrad degree, I tend to think of this in terms of friction — the more energy that is lost to friction and not applied to the project, the less likely it is that the volunteers will feel their contributions are worth their effort and the more likely it is that they will switch. Friction can arise from many sources, such as requiring copyright assignment, constant flamewars on project discussion lists, and a slow release cycle. Lubrication too can come from many sources, such as facilitating many venues for code contribution (develop the core, develop something distributed as a contrib/ item, develop against an API or standard and be a “friend of the family”, etc.).