Healthy productive FOSS projects don’t just happen, but are built, and the secret ingredient is Community over code. Purpose and details are everything: If you build it will they come, and then how do you keep it going and growing? How do you set direction, attract and retain contributors, what do you do when there are conflicts, and especially conflicts with valuable contributors? Joe Brockmeier (Red Hat) shares a wealth of practical wisdom at LinuxCon North America.
We hear the word “community” bandied about all the time, and have this fuzzy notion that it’s a good thing, but what does it really mean? Brockmeier says, “I’ve worked with a number of different companies and projects…and they say, ‘Well, we want community.’ Great, what kind of community do you want? Who is important to you? What users matter to you? What developers matter to you? You need to know what success looks like. You need to know what your project goals are. These look different for different projects.”
What do you expect your community to do? “Some companies, for example, really don’t care that much about having a core contributor community outside their company, but they care deeply about having a lot of users. If you’re building a community to attract users, that’s not the same thing as building one to attract core contributors,” says Brockmeier.
Inclusion Is Key
Any software project, even a small one, requires dedicated contributors filling many roles beyond coding. You need code reviewers, documentation writers, bug finders, bug fixers, people who hang out on IRC and forums helping users, packagers, sysadmins, marketers, and perhaps artists and musicians. Attracting and retaining contributors really isn’t mysterious, just work. For example, having mentors to smooth the way for new contributors, recognizing all contributions from all contributors, and ensuring that all communications and decisions are open to all, and not just a small in-group. Brockmeier stresses inclusion: “My favorite with the Apache Software Foundation is if it didn’t happen on the mailing list, it didn’t happen. You don’t get to make decisions that affect the entire project in private and then just implement them.”
Recognition is essential: “You need to go out of your way to recognize contributions from people. It doesn’t matter whether it’s marketing, whether it somebody who’s on IRC every day answering user questions which is really important and usually not something the developers want to do. You need to make sure that you are recognizing all those people.”
Watch the complete talk (below) to learn about more key concepts including lazy consensus, code of conduct, setting measurable goals, governance, inclusion and diversity, and what to do about valuable but troublesome contributors. (Hint: no one is indispensible.)
