When you get a new job, you often receive a handbook. Don’t open source communities also need a handbook of community values?
When you get a new job, you often receive a company handbook. The purpose of the handbook is to articulate commonly-held expectations and set forth various guidelines. These are (supposedly) intended for the common good of everyone in the company. The very existence of the handbook says to everyone, “We have some ground rules around here.” In many companies, your agreement to comply with the handbook is so important that you have to physically sign a piece of paper promising that you will join the company's culture and act accordingly.
In the land of open source, we don't all belong to a single organization. Instead, multitudes of smaller “communities” are formed. Like organizations, they have a set of cultural norms. However, they don't usually come with their own written handbook. The unique expectations and guidelines often go unspoken. And this is where the trouble can start.
In 2005, I made a rather brisk career change and left an established career centered around Microsoft technologies. Intrigued by the Rails framework, I began learning about open source languages and found myself knocking on the door of the Ruby community. I soon recognized that my behavior and approach inside an open source community was very different than the place I had come from. It was not better or worse, just different.
Fortunately, once I figured out how to adjust, I found myself in the middle of a rather exhilarating experience. At its best, open developer communities are a joy to be a part of. Unfortunately, I've also seen many folks have a hard time integrating themselves, and it can sometimes cause havoc on both the newcomer and the established veterans.
More Than Code
One of the first lessons I had to learn is that any developer who wants to be part of a community is judged on more than their code. You are not your code. You can be an awesome coder and solve difficult technical challenges, and still fall short of the unspoken expectations and unwritten guidelines held by the community at large.
Most online communities are characterized by their use of a mailing list, or Google Groups, or IRC channel. The Ruby community has had a long-held reputation of being a “nice” community. There's a cultural value that says that a developer's standing in the community is based on more than just their raw coding skills. You're expected to be nice to others.
If you choose to answer a question on the mailing list, it's to be done with professional courtesy regardless of how many times that particular question has been asked before.
The same goes if you’re the one seeking help: be considerate. By carefully watching other conversations on the Ruby mailing list, I learned that before I ask any question, I should:
First look for the answer myself.
If I can't find the answer, then I should try some experiments on my own and see what I can figure out.
If I'm totally stuck, then I can submit a question to the mailing list, enumerating everything I have tried so far.
If I need to show some of my code, I should boil it down to the smallest code sample possible that reproduces my problem.
Remember, a community's online group is not your lazyweb. Respect everyone else's time as much as you want others to respect yours.
Don't Be a Consumer
There's one aspect of my involvement with open source communities that took me a while to figure out: don't act like a consumer.
Consumers pay for products or services, and expect a certain level of support in return. They expect software releases on a predictable schedule. They expect those who are writing the software to do what their users want. None of these expectations are appropriate in open source. If you want a certain feature, don't wait for someone else to build it, complaining all the while until it's finished. Instead, write it yourself and contribute it.
Contributions go beyond just code, too. You can contribute by writing documentation. You can spend time answering questions on the mailing list, Google Group, or IRC channel. You can help that next release by going through a list of open issues, finding reproducible steps, and fixing bugs.
Open source works when those who benefit from it “pay” for it with their time and energy. When that next version of your favorite framework didn't ship when you expected it to, ask yourself: did I help get it ready for release, or was I acting like a spoiled consumer, expecting other people to work for free on my behalf?
Recently, social networking and source code control seem to have met in a particle collider, giving birth to sites like GitHub and BitBucket. These sites make it possible for individual developers to publish their code as first-class, open source projects, with the same online presence, functionality, and potential as any other project. I can upload my HockeyStats framework to GitHub this afternoon, and folks around the planet can discover it, access it, contribute to it, manage it, and fork it. My tiny project would have seemingly equal footing with the largest and most popular projects on the web. This is one of the things that makes open source so powerful, and why sites like GitHub have been a tremendous boon for the open source movement at large.
There's a growing trend nowadays for employers to judge applicants based on their quantity (and hopefully, quality) of GitHub projects. The notion that working code trumps résumé acronyms is something I think we can all get behind.
Often repositories are pushed to GitHub, but activity ceases soon after. Perhaps the project wasn't as worthwhile or as interesting as was first thought. Without active maintenance, all projects fall out of date and decay. They become incompatible with newer versions of some dependent components, or simply become obsolete in the presence of similar efforts that are more active and gain a larger following.
These two phenomena can sometimes combine. Developers want to post as many projects as they can to demonstrate their coding skills to potential employers, but they don't want to assume the role of a dedicated maintainer. Rather than enjoy the benefits of more active destinations, such projects become desolate islands, rarely visited by anyone except those perusing the developer's new “résumé.”
I think some responsibility rests on the shoulders of each developer who publishes a public repository:
When you open your code and post it publicly on a site like GitHub, be ready for contributions. If you don't want pull requests, say so in your README file.
If you will accept requests, be sure to actively maintain your project and acknowledge pull requests. You don't need to accept every request, but you do need to respond in a timely and professional manner one way or the other.
Provide documentation, at least a starter set, to help others understand your code. In turn, this will enable others to contribute improvements and new features. Remember, you'll be receiving these benefits for free.
Don't trash-talk other people's code. If you think your project is better, that's great. You can still tout your project without mentioning or criticizing someone else's hard work.
I also believe that contributing to active, maintained projects should be valued above forking and creating a near-duplicate project. If the author of the project isn't responsive to pull requests or patches, then by all means fork the project and start your own. But this should be a last resort. Everyone benefits from actively maintained and open projects; few benefit from a graveyard of similar-yet-different projects that violate the spirit of community collaboration.
Reach Out, and Reach Back
Finally, I've found that the community members I look up to follow a pattern I call “Reach Out, and Reach Back.”
Beyond coding contributions, they find ways to reach out to those who might otherwise feel excluded from the community. Minorities and women have historically had a near-impossible time finding their rightful place in open source. What can you do to bridge the gap?
They are also willing to cheerfully help newcomers. It's easy for those of us who are entrenched to forget what it was like to be new. But we were all new once, and we were helped by those who came before us.
Programming communities are made of real people, and you're invited to become a vital part. This can lead to a sense of fulfillment that goes way beyond what any company handbook could ever hope to offer.
Jeff has worked with object-oriented programming languages and application frameworks for more than 15 years. In 2008 he started Purple Workshops, conducting beginner-level workshops in Ruby, Rails, and agile software techniques. He co-wrote the book Rails for .NET Developers; speaks at technical conferences throughout the year; and is a Ruby on Rails contributor, teacher, and writer. This fall he begins a new adventure as the head instructor for Code Academy in Chicago.