My CodeConf Talk: Your Community Is Your Best Feature

Had a blast this weekend at GitHub’s inaugural conference, CodeConf, where I got to give a new talk on building community around open source software based on my experience at Expert Labs running ThinkUp. CodeConf didn’t record audio or video of any of the talks, so I’m posting a transcript of mine here. Enjoy. Photo by faunzy.

I used to think that the process of making open source software went like this: you write software, you apply your open source license of choice to it, and you publish the source. Ta-da. Open source. But if you’re building something you want people to use and developers to enhance, that’s only the beginning. At the heart of open source is one thing: public collaboration. Collaboration between humans who care about your software—your community. Your open source community will build, improve, tear down, rewrite, document, criticize, test, stretch, redefine, and give your software legs and a life that exists way beyond the original authors or any one person. Because of that, your community is your software’s best feature. Your community is your software’s best feature. That’s what I’m here to talk about today.

Hi. I’m Gina Trapani, and that’s my username on GitHub and Twitter, so I hope you’ll follow me there. As I talk I’ll be referencing things on the web. Rather than recite URLs at you, I’ve compiled a list of links you can get to by visiting http://ginatrapani.org/codeconf/. Go to that page now on your laptop or smartphone or tablet, and you can click around and follow along as I talk.

Now, I’ve got to be upfront with you. Public speaking is not my favorite thing. But when Chris asked me to be here and speak to you all, I couldn’t turn him down, because GitHub has been a transformative tool for me, and I came to it thanks to an open source community member. In fact, the reason why I’m standing here now, and why my full-time job is leading an open source software project, is because of one powerful moment that happened on a mailing list just over two years ago, in February of 2009. I want to start by telling you about that.

Back in early 2009 I’d just finished a four year stint writing a web site about productivity software called Lifehacker. I’d always been an open source enthusiast. I wrote about OSS on Lifehacker and in magazines and in my books; I idolized open source hackers like Torvalds, Behlendorf, and Mullenweg. But, I didn’t really understand how open source is made.

I only had this vague notion of what went on behind the scenes. This is how it went: really smart, technical people, who, in my mind, had beards, set up really complex version control systems that let other really smart, technical people who probably also had beards check out code, work on it, and check it back in, and out popped some of my favorite software. Whenever Firefox or WordPress had a new release and I really thought about that process, it blew my mind. Even though I’m a perfectly good programmer with plenty of version control experience, open source was mysterious and inaccessible, and working software projects like those seemed beyond my grasp.

So it’s February of 2009, and I’ve written this simple script, a to-do list manager, and posted it on Lifehacker, and people really like it, and it’s a command line tool, so it’s attracting open source hackers who have a lot more experience than I do. So we spun off this mailing list, and people start sending me patches, and discussing upgrades and changes, and I’m trying to keep on top of all the patch files and conversations via email and I’m zipping up files and FTP’ing releases to the web site and creating bugs and it’s a complete mess. I know I should set up version control, but I don’t know where, and I’ve heard this new GitHub app is pretty cool, but it still seems scary and beyond me because I don’t know git and I’m not even experienced enough to know what I need in a version control system to make everything run smoothly.

That’s when the powerful moment happened.

A guy named Greg Borenstein who’s at NYU ITP in New York, sends a message to the Todo.txt mailing list.

Greg wrote:

I’d like to volunteer to help in whatever way I can in the git/github transition and any other git integration you end up doing.

That email that opened up a whole new path for me. At the time, we were more than ready to start using a VCS like git, but it wasn’t till Greg offered up his time and expertise did that feel possible. I knew of Greg and I knew that he was trustworthy, and could communicate technical ideas clearly, and that if he said he’d help he would. And he did. I took the leap and created the app’s repository, and Greg followed up with another email subject line “Greg’s Guide to GitHub Collaboration.”

The community took to GitHub instantly and off we went. Everyone started to experiment, ask questions, and tease out what our workflow would be like. The project saw a huge revival because things were so much better using this new, first-class tool. In the end, Greg’s crash course was my entryway into running an OSS project. Years later the Todo.txt project is still in active development, with an Android app in the Market and and iOS app and other client apps being built and hosted on GitHub as well.

Now, the point of that story was not to talk about how great GitHub is—if you’re here, you already know that—it’s to make another point: these moments of goodwill and collaboration and knowledge sharing are what drive your project forward. If you can create a culture of teaching and learning within your community like what went on when Greg showed us git, your project will take off. Those moments are more important to the humans involved than any app feature.

Looking back, I’m less proud of the fact that my todo list app supports projects, and more proud that the app inspired someone like Greg, who gets paid to transition people from Subversion to git at work, to volunteer his time and expertise, and also that the community was ready to use that knowledge productively.

Today we’re going to cover four ways I’ve found to create those powerful collaborative moments, when your community enables itself to take the next step and do something that feels beyond their reach.

First I want to give you a sense of my background and experience, because I know there are a lot of OSS hackers in this room, and you should know where I’m standing in the ecosystem. I work full-time for a non-profit called Expert Labs. I’m a project director there, and I lead development on an open source project called ThinkUp. ThinkUp is a relatively small, new open source project—at about 14 months old, we’ve got a mailing list of about 500 subscribers, and we’ve accepted commits from about 30 programmers. Compared to the big projects, that’s nothing, but as someone taking this on with fresh eyes and the most modern tools, I’ve learned a whole lot in the past 14 months of growing this project, and that’s what I want to share with you. Everything that I talk about today will be based on my experience growing ThinkUp, and different approaches work better at different sizes, so take the size of your project and community into consideration while you think about the best ways to apply some of this advice.

My thesis is this: Growing community is just as important as growing code. I see four main approaches to it.

1. Enable peer consultation.
2. Convert newcomers into contributors.
3. Cast a wide net.
4. Help your community fulfill its destiny.

1. Enable peer consultation.

Many projects like ThinkUp begin with a lone programmer who writes the initial version and publishes the source code. So at first, when users and developers show up, that founding programmer is the only person who knows the project front to back, and that founding programmer is the single point of contact for answering questions, reviewing and accepting patches, and defining what the application IS or should be.

But one person does not scale.

As a project founder your job is just as much to build and lead the app development as it is to enable the community to become self-sufficient, to reduce yourself as a bottleneck for decisions and review.

My friend Paul Ford published a fantastic essay called “The Web Is a Customer Service Medium,” which I think is one the most insightful things written about the web this year. In it, Paul asserts that the fundamental question of the web is “Why Wasn’t I Consulted?” Think about your community members asking that question. Why wasn’t I consulted? Paul writes:

Humans have a fundamental need to be consulted, engaged, to exercise their knowledge (and thus power), and no other medium that came before [the web] has been able to tap into that as effectively.

The web lets people consult with their peers, not the people in charge, to get things done. As an open source leader, you’re like a doctor or a teacher. If you’re doing a good job, then your community needs you less and less. Give your community the tools they need to get things done without you.

At ThinkUp, GitHub is our primary tool for consultation and collaboration. We host the code there, we do code review inline there, we use the issue tracker and hosted our documentation in the wiki. Beyond GitHub we use Google Groups for our mailing lists, Freenode for IRC. We encourage folks to share code snippets, screenshots, and wireframes using things like like Skitch, Pastebin, and Mockingbird. (Now, tools like Pastebin and Skitch and even IRC are familiar to people who are in this world, but in a little bit we’re going to talk about how you want people who aren’t familiar with this world. So don’t automatically assume people know about Pastebin or what the current best IRC client is.)

For a long time at ThinkUp, we suffered from the single point of contact problem when it came to pull requests. Whenever there was a pull request to the project on GitHub, I was the only one who received the notification, so nothing got done until I saw it and reviewed the patcth. That slowed down progress, which made me a bottleneck to getting new code merged, and it left an important task—code review—in one person’s hands, which is a terrible idea. More eyes means fewer bugs.

So what we did to solve this problem is set up pull request email notifications to the developer mailing list. Whenever a pull request comes into the project, all the developers get asked, specifically, code review that patch.

This method has several advantages:

* One person is no longer the bottleneck.
* When people know that their work will get reviewed in public, they do higher quality work.
* When you give all your developers the power to review incoming patches, you get more thorough and thoughtful reviews and fewer bugs.
* Code review becomes a way veteran programmers can contribute to the project without a long-term time commitment.

One of the satisfying experiences I’ve had so far as a project leader is to wake up and find that while I slept, contributors in other timezones have not only issued pull requests, but other contributors tested it, reviewed, commented, and added fixes to that patch before I got out of bed. That’s the sign of healthy peer collaboration.

Make opportunities for peer education within your community, and be specific—create frameworks in which they can happen. We found that a mentor program, which pairs up veterans with newcomers, is very effective for creating bonds and getting things done and converting new members into longtime contributors.

Last year ThinkUp participated in Google Summer of Code, which gives mentoring organizations a pool of university students to choose from who are interested in getting open source experience for the summer, and Google pays them for passing the program.

This year we’re doing in-house summer mentoring, and we’re not paying Google money, but we’ve got plenty of interest. For awhile I was tempted to let people pair up on their own time, but the advantage of a formal mentor program is that there are predefined timelines and expectations for collaboration: you say, this mentor program is 8 weeks. Mentors should plan to spend 2-3 hours a week on meetings and code review; Mentees should plan to spend 5-10 hours a week on the project, and each pair will pick a specific project to get done by the end of that 8 weeks. Incentives like public recognition and small prizes go a long way.

Within the mentor program and in general, encouraging pair programming sessions, even just using Skype or iChat screen-sharing is a strong way to build bonds and enable collaboration. I pair with one of our lead developers who lives on the East coast twice a week on Skype, and it’s some of the most enjoyable time of my week. Even if it’s not a pure pair programming in that code is being written, it’s really effective to demo code and talk through problems on a voice call versus in IRC or via email. Likewise, virtual or in-person meetups—like IRC office hours, weekend-long hackfests, all give people a time and date to show up and work on a specific problem.

This is a very effective way to

2. Convert newcomers into contributors.

Pretty much everyone who shows up at your project’s front door WANTS to contribute in some way, they just don’t know how. You want to hook in newcomers, and a warm welcome plus a specific ask for help goes very far.

When I first started ThinkUp, I was laser-focused on finding programmers to help me build the application. That made sense at first, but as the community grew, I had to internalize something really important: Code is not the only contribution, and on many days, it’s not the most important contribution, either.

ThinkUp has a contributor based in France named Randy, and Randy isn’t a programmer but he’s a huge open source enthusiast. He hangs out in OSS communities in IRC and runs OSS software, and he’s also a podcaster, and big into SIP software and VOIP technology. Randy joined ThinkUp early on, and when he saw that we were so young and certain conversations were difficult to have on the mailng list, he set up our official IRC channel, and helped people who haven’t used IRC before get started. He also set up a monthly podcast, which he hosts—a live, conference call where developers and users call in and do Q&A sessions, which we then publish on our blog.

Looking at what Randy did for ThinkUp was a huge perception shift for me. At the time, those contributions were way more effective at growing ThinkUp than the code I was writing. He was able to see a need in the community that I didn’t, and fulfill it, and the community responded by showing up in chat and on the podcast. Before I saw no need for IRC; today I couldn’t imagine working without it.

Now, Randy isn’t a programmer but he knows how OSS works, so he knew enough to be assertive and volunteer his expertise in specific ways, much like Greg did when he got us started with git. Many of your newcomers AREN’T going to have that experience to know how to help, so it’s up to the people already embedded in the project to show them that.

When users show up at your project’s front door and offer their help because they love your software, it’s up to you to put on your Dale Carnegie hat and break out your copy of How to Win Friends and Influence People. Instead of thinking from the perspective of “what does the project need?” think about what this person wants. What makes them tick, what aspect of the software excites them, what’s their skill set, and how can you convert that energy into a productive contribution.

I spent many years writing about personal productivity, and the biggest takeaway for me from that work is that the hardest thing about getting things done isn’t DOING work, it’s DEFINING what the work you need to be doing is.

Now, your issue tracker does a good job of defining all the ways coders can contribute to the project. The workflow for coders is very clear: fork the repository, pick an issue, write the code to address it, and send a pull request. Done.

But you want non-coders like Randy to contribute their skill set to your project, so you’ve got to think beyond the issue tracker and define ways that non-coders can also help. People WANT to belong to your community and they want to influence the direction of the software, so you want to create pathways for them to do that.

Early in ThinkUp’s development, an interested user sent an email to the ThinkUp mailing list with the subject line, “The frustration of a non-developer.”

In it, he asks:

How can non-developers play a bigger role in technical open source projects that in the end are meant to work for everyone? I’m interested in technology, i know what i want, but i’m not a programmer. I love the concept of open source, but if you’re not a coder, it’s really difficult to play a role … i would love it if endusers or designers could play a bigger part in technical projects like this from the beginning.

How can a non-developer contribute to your project? This is a question every OSS project should have a ready, public answer to. At ThinkUp we drafted a list that ranged from “Tweet about the project” to “update the wiki” to “share a wireframe of what you want to build.” The goal is to give everyone a next step into your community.

Even complainers have the potential to become contributors—sometimes even more so than straight-up fans. If someone takes the time come to the project to complain, there’s a good chance he or she will be willing to put money where their mouth is and help fix the thing that doesn’t work, if there’s a ready way to do that.

I’ve got this guy Seth who follows my projects. He uses both my to-do manager and ThinkUp, and he’s very vocal about it. He’s not a coder, but he’s always got something to say about the software and it’s usually a complaint. Not mean-spirited complaints, but pointed complaints, and they’re hard to hear. This is a typical message I would get from Seth:

It gets cut off, but here he’s saying that the to-do app is too hard to use, and it should be easier. Now, I’ll be honest. When I see complaints like this, I morph into a total jerk. What I WANT to say is:

YOU’RE WELCOME for the free software.

But if you strip away the ego and defensiveness and take a close look at complaints, there’s often something of value there. To be honest, that part of the app Seth called out could be easier to use. Now it’s up to us to empower Seth to help change it. In this case it’s just a matter of saying: Hey, Seth, how do you think it can be easier? (It’s worth noting that after several back-and-forths like that with Seth, he sent an email to the ThinkUp mailing list volunteering his professional services to the project.)

Complainers are a unique opportunity. As coders, we all know that we usually fix the things that annoy the crap out of us the most. Same principle applies to non-coders, and that’s why complainers can have even more potential to become contributors than straight-up fans.

And you want non-coders like Seth and Randy to contribute to your project. To attract non-coders, you’ve got to:

3. Cast a wide net.

I mentioned earlier that one of my mistakes when I started ThinkUp was that I was too focused on just finding other coders to join the community and build new features and fix bugs. But you want designers, UI experts, users, documentation writers, interns, business folks, marketing experts and front end specialists all working on your project.

Not only do you want people with a wide range of skillsets, you want people who have a wide range of life experiences, too. Homogenous teams turn out homogenous products. You want women, non-native speakers, religious folks, atheists, gay people, married people, people with kids, people over 40, transgendered people, color blind people, people who do not own an iPhone, and people who do not live in San Francisco in your community.

Diversity matters. Inclusiveness matters. If your team has a limited worldview then your software will as well.

Here are two examples of design failure due to limited worldview.

First, my guy friend, who happens to be married to a man, signed onto his company’s payroll system to fill out his information so he could get paid. Here’s one of the error messages he got:

If you look closely, you can see that not only is this dialogue asking my friend to change the gender of his spouse, but it’s got a typo in it, too. Not a whole lot of code review going on there.

Second, my co-worker Andy Baio is a huge data nerd, and he’s also red-green color-blind, as are 1 out of 14 American males. So when Netflix published some research using a line chart, Andy wasn’t able to make any sense of it, because he couldn’t see the colors they used to draw many of the lines.

Diversity matters, but it’s hard. Getting the usual suspects is relatively easy. Someone who’s used IRC, a mailing list, a wiki, etc—those folks will know how to help themselves. To get the “non-usual suspects,” you have to work harder.

One way to do that is to reach out across multiple channels. A mailing list archive is a lot less inviting than a nicely-formatted blog post. A Twitter stream, a Facebook page, Stack Overflow, Get Satisfaction—these are all different channels that your project can use to cast wider net and reach out to people who haven’t contributed to OSS projects before, but have the skills and desire, given the right opportunity and tools.

One of my main metrics for ThinkUp’s success: how many brand new contributors added something to this release? How many of them never contributed to OSS before? That’s something you should call out, on every release. We like to give out the Nerd Merit badge.

Finally, I’m going to get a little woo-woo on you. The best thing you can do for a community is give it a higher purpose, to give its members a reason to be proud to be a part of it. You have a vision for your software, and your software does something meaningful in the world, and your community will gather behind that. People want to feel part of something only bigger than themselves, and they want to understand how that fits into the world.

4. Clarify your vision to help your community fulfill its destiny.

There are three parts to this.
* Defining the project
* Defining the project’s values
* In-group behaviors that communicate those values

First, defining the project. What are we? Why are we doing this? What is the problem we’re out to solve? What are our ideal use cases? You want to tell the story that embodies the spirit of your software, and when you do you’ll attract the right people to work on it.

For example, on one hand, you could look at ThinkUp and say: that’s a Twitter analytics tool that social media douchebags use to chart their follower count. Or, you could say: ThinkUp’s a democracy platform, which helps policymakers make better decisions by tapping into the wisdom of our country’s citizens using social media. You can imagine which story we tell. As a result, we attract more folks interested in Gov 2.0 efforts than social media analytics. (This is also why you want a good marketer on your team.)

Once you’ve got your story, your roadmap should back it up. Where are we going? How are we going to get there? Are we there yet? WHEN are we going to get there? At ThinkUp we use the wiki to define high level goals and the issue tracker to list out specific next actions, and we make heavy use of tags to separate those out by milestone or release.

Next, your project’s values. Every community has a culture and a set of values. Most open source communities are similar in that they value certain common things like publicness, code-sharing, collaboration. What are the values that differentiate your project from other projects? At ThinkUp, some of the values that define us are friendliness, inclusiveness, and openness to newcomers.

In-group behaviors demonstrate those values, and when they don’t, the behavior should be called out. We all know that in open source, you are what you write, and the things you say and do reinforce community values.

Good community managers know that group behavior self-perpetuates, so the key is to feature good behavior and discourage bad behavior.

This is a blog post featuring one of our contributors, who built our maps visualization.

This is a tweet I got from an experienced coder, whose work I didn’t merge because it didn’t include tests.

This is a tweet I got from a coder after he had his first commit accepted.

You want your project to be the one that people say things like this about.

To recap: Activate newcomers with a warm welcome and a pathway to in-group status and new achievements. Give everyone the tools they need to help themselves. Make specific asks for help on important tasks, and people will volunteer. Unless there’s a really good reason, have all conversations in public.

If you give people a way to be part of something meaningful, amazing things happen—like this.

Meet Gnome contributor Adrian Hands. Adrian had Lou Gehrig’s disease, and he coded by tapping a morse code keyboard simulator. When he lost strength in his hands, his son Ian rigged up a PVC pipe contraption so Adrian could type by tapping the simulator with his leg, which you can kind of see here. Using this setup, Adrian wrote a patch that addressed Gnome issue 78514.

On January 30th, Adrian received notification that the patch was accepted. He forwarded that notification to his son Ian, saying: “Accepted. Committed. Resolved. Boo-yah!” To which Ian responded, “I have the coolest Dad in the world.”

Four days later, Adrian passed away. Ian searched through his email to see what the last thing he had sent his Dad was. This message was it.

Ian went to Bugzilla and posted a comment on the issue thread.

I am so glad that my last comment to my Dad was something like this.Thanks so much for the great software, and a new great memory.

I wish you all more moments like this in your open source community. Thanks for having me here today.

All the CodeConf talks were fantastic; find more slides and summaries at The Changelog (Saturday, Sunday).