Working with wood, one of the most important lessons I’ve learned is to understand it and work with it, not against it. When I chop logs, I split them by cutting into the grain rather than hacking away at the bark. When I plane timber, I work along the grain of the wood rather than across it. I avoid working near knots, I watch out for irregular grain around damaged areas. Sometimes it’s unavoidable to cut into the grain, but it’s always time-consuming and needs patience. It’s also easy to get hurt or to cause damage.

Whether I am harvesting it, crafting it or consuming it, life is better if I fit my needs to the wood rather than trying to force-fit the wood to my needs. These are all obvious metaphors for interacting with an open source community as a representative of a company.

The flow of the grain

All open source community members care about the “four freedoms” – the permission given in advance to use, study, improve and share software in source and deployable forms. Some do so as an ethical imperative, while others do so as a matter of pragmatism related to their use of the code. But everyone in a community expects to be able to take the code and do what they want with it, without needing to get any further permission from anyone.

They expect to be able to contribute in good faith. There may be rules about who can contribute when and how, but they will be reasonable and apply equally to everyone. Contributing isn’t a matter of (just) philanthropy; one of the important benefits of community-maintained code is sharing the ongoing maintenance.

They also expect all the interactions of the community to be transparent. Where there are leadership roles, they expect them to be filled by the most appropriate willing person, probably chosen by voting where there’s a choice of candidates. In an open source community, participants expect reasoned fairness.

That’s the “grain” of an open source community:

• The Four Freedoms, guaranteed
• Open to all participants
• Run transparently and fairly

Along and across

What goes against the grain? Obviously withholding the freedoms that an OSI-approved open source license guarantees is wrong. But anything that applies preconditions to accessing the code or community is also a source of unwanted friction. Any time a community member has to ask permission before proceeding – that includes signing a form, asking a lawyer, checking with their manager, buying membership – is problematic.

Obviously, that can’t always be avoided. But choosing to go with the grain rather than against it will help immensely. Some examples of choices:

• When you need to secure the provenance of contributions, choosing to use a DCO process rather than a CLA approaches the problem transparently – anyone can check the DCO – and with minimal need to seek approval and advice.
• When you introduce new staff to work on a project you have initiated, ensure they gain status by the same process as people who don’t work for you. It may be OK to accelerate it, especially if they are known to the community, but don’t just assign privilege as a matter of course.
• When you want to set the architecture of your software, create a group within the community where your experts can propose direction and work in the open with peers from elsewhere in the community. Community members have their own motivations for being present that may not match yours, so a place where technical priorities can be harmonised is important. It should be possible for any community member to add to the roadmap. Privileging your internal architecture team to make all the decisions based on your priorities alone will result in, at best, conflict and, at worst, forks.

What’s always against the grain? The following (non-exhaustive) list always cuts across the community. These things will reduce participation and create disharmony:

• Selfish licensing always harms a community. That includes:
  • Dual licensing, in the sense of permitting your customers to use the software without complying with the same license as the community.
  • Copyright assignment agreements (usually to enable dual licensing, but also to create a copyright and patent asset owned by you alone)
  • Patent grants that build you more protection than others, like the one Facebook controversially used for React.js
  • Using trademarks in a way the community can’t. Owning the community’s trademark – especially if it’s your company name – is against the grain.
• Hidden decision making is also toxic. That includes:
  • NDAs
  • Bilateral agreements between community members
  • “Throwing code over the wall” that’s been modified internally. If the source trunk or issue tracker are behind a firewall, you’re doing this.
  • Internal-only architecture and road-maps

These things can never be mitigated because they lead to (at very least the perception of) inequality and exploitation. You may never get complaints, but that’s probably because you don’t have contributors you would otherwise have.

This is not intended as an exhaustive list, but rather as an overall approach. Go with the grain of your community, shape your requests and requirements so they flow with the expected freedoms rather than cut across them, and you’ll get better results in the long term even if it takes more thinking in the short term.