An English idiom says, "There is a method to my madness."[1] Most of the time, the things we do make absolutely no sense to outside observers. Out of context, they look like sheer madness. But for those inside that messiness—inside that whirlwind of activity—there’s a certain regularity, a certain predictability, and a certain motive. A method.
A method is a way of doing something, a particular manner or style of practice. The practice of open source community management can seem like its own form of incomprehensible madness, especially to someone who is unfamiliar with how open source software gets made, or those who find themselves staring down the prospect of having to coordinate others to join in making it. What this guide hopes to provide is some insight into an ever-evolving methodology, a form of practice. At its core is a simple question: What are your preferences for practicing the open source way?
But beyond that, this work is really digging into the question of why someone might do the work this way. Why use this or that method to organize the madness?
So from this introduction you should take two important points:
-
There is a what, a how, and a why to the practice of successfully and sustainably creating and maintaining open source software.
-
This guide distills opinions from a sizeable group of open source practitioners, the kind of people always having to answer the question of, "Why do we do this open source thing the way we do it?"
In particular, this guide is a living document that endeavors to gather and spread a diverse group of voices who are similarly (and somewhat-opinionatedly) collecting the best ways to create and manage an open source software community.
These voices are all part of this community of practice around open source software community management.
When you look at this guide’s table of contents, notice the organizational flow: from user to participant to contributor. This arrangement specifically tracks our view of how a community comes about and grows. And it all starts with a need. If you’ve worked in open source projects and communities, you’ve likely seen the cycle many times. It goes something like this:
-
A person or group addressing a problem creates the first iteration of software that offers one solution to that problem.
-
Other people with similar needs start using it, forming the core of a userbase.
-
From the userbase arise enthusiasts, people who promote the software and the community emerging around it (that is, the values and principles that project seems to espouse).
-
Eventually arising from the users and the enthusiasts come people who are interested in (and have grown capable of) contributing to the software in some way; they ensure the project remains active and responds to the changing nature of the problem for which it was originally developed.
Thus, the primary and continual focus for a project is to take good care of your users, for some of them will become your contributors, and you want them to do it out of love more than resentment.
A key element of all this is recognizing the value in contributions of all types, at all levels. Rather than valorizing only a single type of contribution, the best practice is to treat all manner of gifts to the project as equal. These contributions comprise content and code, hours and effort, and all types of broad contributions for the project via events, discussion forums, infrastructure maintenance, and so on.
When you lower barriers to participation, you make your project welcoming at all levels. This doesn’t mean you remove all barriers—just lower most of them appropriately. Appropriate barriers are necessary for someone receiving keys to systems, for example, and these barriers are different from those allowing only certain participants to contribute a help article or a patch to the configuration management system.
There is an opinion at the core of this work, that explains how the content is laid out, how the steps on the path are revealed so that you can find yourself wherever you are in your journey of open source practice.
Focus on your end users and lower the barriers to participation all around.
Contributors arise from participants, who all started as users.
Make your software wildly successful by having a user-centric initiative, while making the community open and welcoming those users curious enough to investigate how the software gets created.
The pathway of this guidebook therefore is:
-
Attract users to your software because it solves the problems they have; then
-
Guide participants who care about open source and sharing good solutions so they can be effective enthusiasts for your software; and
-
Grow contributors from this rich, fertile user and enthusiast base, by making sure when any of those folks look into how the software is made, they see themselves represented and can imagine how they could fit in, too. Make sure when they get to the contributor party, the barriers are clearly lowered and welcoming.
Think of it this way: It’s one thing to let people know about your great dance party. It’s another thing to empower those dancers to advocate for your way of throwing a dance party. It’s a very great thing to make the dance party able to evolve to welcome all manner of music and dance from the world around us.
To get the dancers who see your poster and show up is the first step to stick around, and it helps if they can see right away that this is a place for them and theirs, too.
You can see this pathway to project success doesn’t necessarily emphasize expertise (or even existing skills relevant to the project) more than curiosity and willingness to try the software, to care about the software, and to help create the software. This does not mean that people don’t bring skills to the project; they do, many of them right from first point of contact with the project. But it is easier to teach skills than to teach someone to truly care about your project.
In this journey, there are many best practices we recommend, including how to put together a plan for measuring your community’s progress. We also list some specific areas to be careful of and watch out for, including a robust discussion on self-care and mental health considerations for community managers themselves.
Our best way of more-deeply conveying all this information is with stories. Aside from stories that naturally arise in the body of the chapter, there are other areas in the guidebook and in The Open Source Way community to gather all these stories of why.
Each section of this guide consists of one or more chapters.
A chapter represents discussion of a discrete topic or closely-related set of topics.
The idea is that you can open and read a chapter as a stand-alone experience without needing to read the rest of the guide to understand and act from the material in that chapter.
The vision for the 2.x series of this guidebook is for each chapter to consist of several aspects. The version number in brackets indicates when that aspect is planned to appear:
-
An introduction. [2.0]
-
Primary material, written in third-person point-of-view, focusing on a balance of what, how, and why content. The examples (stories) told here are brief and in the third person. [2.0]
-
Each chapter contains a lexicon at the end that defines the special usage for terms within that chapter. [2.1]
-
Expanded stories come at the end of the chapter, and are one or more stories from the chapter author(s). These may be written in the first person—that may be the most effective way to make the point in many cases. These stories are modular, in that another story that makes a similar point but from a different situation can be used instead. [2.2]
-
The idea is to start with a base story or set of stories in a chapter, and supplement or substitute other stories that are contributed to the project, such as through the interview effort. [2.1, 2.2]
-
Finally, we’re collecting stories from practitioners of the open source way, stories we know tend to illustrate more than one principle in action. The idea is to start with a base story or set of stories in a chapter, and supplement or substitute other stories that are contributed to the project, such as through the interview effort. Stories not interspersed into chapters will be collected at the end of the guide (for your endless uses).
What you are reading here is just one facet of the growing body of principles, implementations, and examples that this community is gathering, cultivating, and maintaining.
In the end, it’s just one way to pull this material together (one method, you might say, of organizing the madness). We’ll be updating this guide. We’ll be issuing similar, new guides. And we’ll experiment with other ways to understand and present this material.
But at the core—in addition to the what and the how that benefit your open source community—you will also learn to understand the why, and be able to spread those stories wherever you go.