During his inaugural speech on Jan. 20, 1961, U.S. President John F. Kennedy uttered the challenge, ?And so, my fellow Americans: ask not what your country can do for you ? ask what you can do for your country.? Its simple meaning was to challenge society to contribute to improve the public good. But I think there?s a bigger message here, and that is that we have to work together as a society to improve our collective state. And because of that, I think the statement has a lot to tell us about community building in general and for open source communities certainly.
Publishing software with an open source license is the definitive step of creating an open source project. The creation of such collaborative licensing is Richard Stallman?s brilliant hack on the system of copyright law back in the early 1980s. If software is covered by copyright, so a user of the software must honor the copyright by adhering to its license or otherwise asking for permission, then create licenses that say, ?do whatever you will with this software, while honoring these clauses in return.? It is the perfect hack on a software copyright system that would otherwise collapse under its own weight when the dynamic nature of software encountered the friction-free publishing channel of the Internet. But while publishing software this way is the definitive step of creating an open source project, it doesn?t create a community.
While many societal norms and interactions are imposed by a choice of where you live, from the country down to your street address, on the Internet those choices and interactions play out differently. The cost of choosing your online community is far lower in the digital world than the economic friction in the world of bricks and mortar. So is the cost of leaving. As an online community you need to attract folks differently if they?re going to engage. You need to make it easy for the community to do the things they want to do. They aren?t coming to help you build your community, at least not at first. They?re coming because the project (the neighborhood) is interesting to their own needs and goals.
And there are three sorts of folks that join your community.
- There are the folks that just want to live there using your software.
- There are the folks living there that are happy to help in small ways, letting you know where the potholes that they almost hit every day are forming, or about a vacant lot that?s unsafe.
- And there are the folks living there, that let you know about that vacant lot, and that are happy to help clean it up, contribute a park bench, or organize the neighborhood party to celebrate after the cleanup is done.
And you need to make it easy in three different ways for those three sorts of folks in your community, because the groups are nested inside one another. People don?t build parks in vacant lots where they don?t live. They?re very unlikely to notice the potholes in a meaningful way if they don?t live on the street. They won?t move into your neighborhood in the first place if its cluttered, unorganized, and doesn?t provide any guidance for where the schools and shops are, or when garbage collection happens and how recycling works there. And they certainly don?t move into neighborhoods in which they can?t afford the costs (in time or money).
Growing and scaling a successful open source software project requires building three on-ramps: first for users, then for developers, and ultimately for contributors.
If it is not blindingly easy to download the software, install it to a known state, and use it in some meaningful way, you will not encourage a growing set of neighbors. If the developers in that group of neighbors can?t easily build the software to a known state so they can effect their own changes, then they will look elsewhere for easier to use solutions. They will move out and move on. If you don?t make it easy to contribute those developers?s changes back to the project, it becomes a permanent growing collection of expensive forks that doesn?t harden the way good software projects do.
In the 1990s, we had a ten-minute rule of thumb for packaged PC software from pulling the shrink-wrap off the box to doing something meaningful. When you download an app to your phone, how long do you work at it until it behaves as advertised or you abandon it? The same sort of thinking needs to apply to your software project users. So to for the developers in that group of users that will want to do things with the project to their own needs. So to for your eventual contributors out of that group of developers.
Well run successful open source software communities make the costs of using, developing, and contributing to the community easy to bear, and they work to continue to make it easier. Publishing a piece of software on the Internet with an open source license is easy. Growing a community takes work, but the value in the hardened, evolved software for all is easy to see in successful communities. So ask not what your community can do for you, ask what you can do for your community.
