In her Texas Linux Fest keynote, Joan Touzet talked to us about how to improve our open source communities. Joan's talk was a series of stories about communities who have faced a crisis and then rose above it.
The most important takeaway from her talk is that community building is not just hard, but painstaking. And this doesn't just apply to open source communities, but all communities you try to build. All of us who have participated in an open source community have experienced stonewalling, unfair decision making, and other negative communities experiences. So how do we evolve?
Joan broke her talk down in to three acts.
Act 1: Don't go breaking my heart
There will inevitably be a time in your community experience where things will get personal. When it gets personal, you have to get personal back. When this happened to the CouchDB community that Joan belongs to, the community decided together to kick out that community member. Joan shared a great quote from Ted Husted with us:
We strongly believe that a codebase belongs to the individuals who create and maintain it, and a codebase should be a collaboration between individuals.
In short, those who have proven that they can do, get to do. Individuals, not corporations, earn merit. People who work for an organization don't earn special treatment because they are part of that company—they are equal to all others in the community. Merit also doesn't buy you authority and the community always has to agree on decisions that are being made. In short, we're all individuals making individual contributions and those contributions earn us a right to vote in the community.
Joan redefined meritocracy as an organization that is run by the people who do the actual work. She says, "If you do the work you get to be part of the organization." It's that simple.
Act 2: The creative process
The creative process is different for everybody, but what it takes to foster this process is the same for everyone. The main question is, "How can we lower the barriers for entry in to our communities?"
One of the barriers CouchDB has faced is that the complexity of bug fixes hasn't been clear to new members. The simple fix for this was to create a field in their bug tracker to define the complexity of bugs. This way, newbies could easily find items that were within their skill set to fix. They also used IRC chats once a week to talk about bugs with developers of varying skill levels.
Another important thing to remember when figuring out ways to get people involved is that not everyone likes to do the same thing. Leaders need to find new ways to let people contribute to their project. They need to create new roles and responsibilities so they can encourage support from all types of creative folks. It's also important to acknowledge their contributions. In the CouchDB community they created new roles for UI designers, documenters, translators, marketers, project managers, and community advocates. Merit doesn't just come from checking in code—these roles are also essential to a project's success. Project learners need to make sure they thank them all in a readme or thanks file.
The key here is openness. Be sure that all of the contributors get a say in the decision making process. To be sure that everyone is included, the final decisions should be made in the open. The best way to do this is to have all decisions made on the mailing list. IRC and in-person meetings have limitations such as location and/or timezones. The mailing list might be slower, but at least everyone has access and can contribute in their own time.
A rule that decisions must be made on the mailing list is in the bylaws for the CouchDB community that Joan belongs to.
Act 3: P.L.U.R. (Peace, Love, Unity, and Respect)
In the CouchDB community, there was a general feeling of hostility. When Touzet and others asked people why they felt this, they got several answers: "My contributions go unnoticed," "I couldn't get the mentoring I need," and "This one person keeps vetoing everything I propose. Is it me?"
Problem 1: Cookie licking
This is when someone keeps saying: "I've already started the change, leave it to me," and then gets distracted. This leads to features that take years to get merged in to the project. The problem we face is that the people working on the project are volunteers. It's hard to criticize people who are working for free, but we need our projects to grow at a faster rate if they're going to stay viable. You need a way to move projects between multiple people within the project.
Problem 2: Bad actors
Every project has people that are difficult, if not impossible, to work with. Joan had a great quote for this too: "Rejection appears to lead very rapidly to self-defeating and antisocial behavior." The longer you ignore people like this, the worse it's going to get. These people need to be reigned in or removed from the community to prevent the spread of bad behavior.
A code of conduct can assist in identifying and removing these people from your community. In the CouchDB community, they listed empathy as a top-level concept and defined it as "awareness and understanding of the emotional state of others." Keep in mind that a code of conduct is useless unless you enforce it.
Community before code
This all boils down to choosing community before code. Without the community, there's no reason for your code to exist in the first place. The attitude that the code is the only thing that matters won't get things done. The lifeblood of your project is the community. Community isn't just important, it's vital!
Conclusion
Openness ensures that our projects remain neutral!
When thinking of your community, you need to keep burnout in mind. Joan didn't have enough time to talk about all the things she wanted to in relation to this, but she did have some great citations I hope you all check when you view her slides online.
Joan ended with a quote from her gaming group:
Where the Internet is in many places a cesspool of trolling, hatred, and discrimination, we've created a place that strives to promote respect, teamwork, and equality ... What keeps me going and keeps our community going is that there are people here that will not only keeps us get through the rough patches, but to help fix the problems in the system as well ... That is what makes the difference—people that want to see each other succeed.
recap
This article is part of the Texas Linux Fest series. Texas Linux Fest is the first state-wide, annual, community-run conference for Linux and open source software users and enthusiasts from around the Lone Star State.
3 Comments