"A leader is someone who steps back from the entire system and tries to build a more collaborative, more innovative system that will work over the long term."
Robert Reich
Many open source projects start with a single developer trying to scratch an itch by making a new tool for their own use. But what if the need to be addressed is bigger, and affects more people? How can the creation of open source software involve a whole community?
At the start of 2008 I decided to build a solution to an ongoing problem in my hometown of Portland, Oregon. Portland's growing technology scene was having trouble tracking all of the user groups, meetups, and events that people were planning. I started a central calendar using Google Calendar, but found it hard to maintain. People planning the events needed the ability to make their own updates without me having to add them individually as users. A single, central information source that would be completely open to the community at large was needed. The solution became an open-source calendar aggregator called Calagator. The process of creating that solution became a very rewarding community-building effort.
By trying different things along the way, we learned how to organize an open source project to encourage community development, used code sprint practices for group work sessions, and worked with a number of tools to make collaboration easier.
Have a Unique Goal
The first step to any successful community project is to define a goal that clearly summarizes to other people what you're trying to accomplish. Create a description that can be condensed into a short statement. Calagator's goal is "to build a calendar that is collaboratively edited like a wiki".
When talking to people about a new project, a common question will be "why not use something that's already out there?" While some people might be drawn in by the ability to create something shiny and new, most want assurance that a new project is necessary. When recruiting people to help, a new project is competing against all of the other existing projects. Possible contributors want to be sure they aren't wasting their time duplicating an existing solution.
What Resources Will You Need?
Open source projects have a number of free project hosting options to choose from, such as Google Code, GitHub, and SourceForge. All three offer a source code repository, wiki, and bug tracking. Other kinds of hosting, such as that needed for a web application, are affordable and can often be donated by a hosting company or fellow developer. Given this, the biggest need for any new project is finding people to contribute and determining what contributions are needed. Contributions may involve code, user interface design, documentation, the project web page, or finding space to meet. Contributors should be enthusiastic about solving the problem that has been defined.
In my initial group-building attempts, I reached out to user group leaders, the people who had been updating the existing Google Calendar, developers I knew, as well as people with other skills I considered helpful. CubeSpace, a coworking space in Portland, donated a meeting room for code sprints. I made a point of talking to people one-on-one, inviting them directly to join the mailing list and come to a code sprint. Some only attended one or two meetings to talk about what they'd like to see in a new calendar, while others continued to help over a period of several months. When seeking contributions, invite more people than you think you'll need. Not everyone will have a large amount of time to contribute, but you can always find ways for everyone to help.
Do the Simplest Thing That Could Possibly Work
Starting simple makes it possible to have immediate success. We chose to write Calagator in Ruby on Rails, a framework that can create the initial functionality quickly. This choice allowed other experienced Rails developers to participate, guaranteeing that others could help write code from the start. We picked a very small initial feature set consisting of a pair of web forms for creating new events and new venues. At the end of the first code sprint, there was a working web application, deployed to a donated server account, and a Wordpress.com hosted blog for telling people what we were doing. Having something to show publicly at the end of the first day helped build the interest and momentum needed to extend functionality through future code sprints.
Why did we focus on development through code sprint meetings? The problem we wanted to solve was centered on a specific geographic area so it made sense to invite people to talk in person about what we would build. But it was important that we didn't just sit around and talk, so we borrowed agile development techniques for doing a single-day code sprint. We started by writing ideas on index cards, and sorting them into development, documentation, and research tasks. People broke off into 2-3 person groups to tackle a single card for 45 minutes. The host made sure everyone had a partner and a card in order to keep all participants actively involved. At the end of 45 minutes, everyone regrouped to discuss what we had accomplished or learned, and took a short break before starting the next mini-iteration.
This strategy proved effective for keeping people interested and engaged, even with a dozen people with different types of skills. The host role is crucial: the more people involved, the more important it is to have someone in charge of the process. If you aren't comfortable doing this yourself, recruit someone. The host should be outgoing enough to talk to people about what they're interested in working on, offer them tasks to take on, and make sure each part fits into the bigger project goal.
Another agile technique we used was test-driven development (TDD). TDD uses short development iterations to produce code that meets a pre-defined improvement or new functionality. TDD ensures confidence in each incremental addition to the code base. It also provides an opportunity for mentoring, by allowing a less experienced member of a programming pair to describe what functionality needs to be tested and built, while their partner directs the code needed to make it work. The tests help developers to understand functionality written by others as well as code they haven't worked on in a while.
Having this kind of reliable code base and stable software increases credibility to less technical community members. As a programmer, it can be easy to get caught up in the details of the implementation. Everyone else tends to only see whether or not the product works. The more reliable the product, the more a project is viewed as successful and the more others want to be involved.
As Calagator development continued over several months, tools and structure were added to keep everything working smoothly. The first piece of infrastructure was a mailing list which was created before the project even had a proper name. The mailing list was used to invite people to join the planning discussion online. After every code sprint, an update is sent to the mailing list so that people who can't attend can still follow the work.
On the day of the first code sprint, Google Code was used to host the project code in a public repository. Google Code also provided a wiki to keep track of documentation and useful information as well as a simple issue tracker. It is important to provide a way for people who don't write code to report problems they encounter, and receive a response. End users should be considered as contributors to your project. They will be motivated to help if they see a friendly response, including patches or documentation that show their comments are having a useful effect on the project.
Later that day we created a blog; you can see the first post. While just a quick introduction, it gave us a link to send to people who wanted to know what we were up to and how they might help. The blog provides an access point for people who aren't involved enough to track the project on the mailing list. We also use the blog to talk about the big picture: How does Calagator fit into other open source efforts? What does a calendar aggregator do?
Keeping it Going
Over time, a project's needs will change. Keep it simple: wait until a problem needs to be solved to address it. In our case, we had initially debated whether to use Subversion or Git for version control. We started on Subversion because it was familiar to more people and we needed to make it easy for people to contribute to the project. Toward the end of the first year, we realized that our needs had shifted. We now needed a way to better manage patches from different contributors and to make it easy for people to submit code outside of a code sprint. We switched to Git and wrote a guide for new contributors on how to submit a patch.
Being open to new participants is an important part of keeping a project alive. People may drift in and out as they have more or less time to contribute. A project's core development team should not turn into a closed group that other people find difficult to interact with. For Calagator's first birthday, we had a code sprint that focused on showing people how they could contribute to the project and introduced them to the types of issues we were currently working on. Something similar can be achieved through blog posts and screencasts if in-person meetings aren't possible. Even if developers live in different places, consider meeting at a conference once or twice a year to let everyone hang out, chat, and show off what they are doing.
We've kept the structure of Calagator's supporting group informal, collaborative, and welcoming. Decision making happens through a discussion and consensus process: there is no dictator, benevolent or otherwise. These practices have been crucial for maintaining community goodwill, and making it a fun project to be a part of. New participants don't want to fight their way in. They need mentoring and support.
Building anything from scratch is an act to be proud of, and doubly so if it turns into a community effort. Encourage your community to take time to step back and enjoy their work. Community-built software requires equal parts technical and social contribution. The reward is not just a piece of useful software, but the social connections made, and the benefit to the community the software serves. Technology is created for people, to solve real human needs, and community-built software provides an opportunity to put that idea to work.