To grow an open source project, give up control

One question that I get from companies and company-led open source projects is “how do we build our community?” Bad news: there is no easy or simple answer. It requires a lot of work, patience, and luck. Jono Bacon’s The Art of Community and People Powered are good reads for long answers. But there is one thing that I see as foundational to building a contributor community: the company can’t be special.

Influence instead of control

What does that mean? Fundamentally, it means giving up control. This can be hard for a business to accept, especially when the open source project is important to the business. But open source projects are meant to be collaborative, not extractive. If you want contributors, they can’t feel like they’re doing free labor for you; they have to feel a sense of ownership.

This doesn’t have to mean giving up all influence, though. What it means is that the company has to participate as a member of the community. More specifically, the company’s employees have to participate as individual members of the community. The company itself doesn’t get to be a monolithic entity. It can tell the employees what to do, but it can’t make demands of the community.

Part of this is structuring governing bodies such that people outside the company have a real opportunity to be members. The company can fund people in specific roles (for example, the Fedora Project Leader and Fedora Community Architect, who are members of the Fedora Council). Or the project can have an entirely-elected body, like the Fedora Engineering Steering Committee. In either case, the individuals have to be trusted to act in the best interests of the project, which will benefit the company in turn.

If the project structure shares leadership outside the company, it becomes more appealing to people outside the company.

Communicate openly

The “how do we build community?” question often comes up in the context of small projects. They have a handful of developers who all work for the sponsoring company. In cases like this, it’s easy to fall back on the internal tooling for communication. Sure, the code and issues might be in a public repository, but the collaboration goes on “behind the firewall”. The project becomes open source in the “uses an OSI-approved license” sense, but that’s not what people mean when they use the term. The collaborative community is an implicit part of an open source project.

Even if the developers work for the same company — even if they sit in the same office — they should hold discussions and make decisions in a public forum. It’s easy to lapse, so you have to actively encourage the habit. People can’t develop a sense of ownership if they can’t participate in the discussions.

Of course, this is more than a performative act. You can’t just pretend to have open discussion, you have to let people actually engage. And like I said in the opening paragraph, this isn’t enough on it’s own. But it’s necessary.

This post’s featured photo by Nadine Shaabana on Unsplash.