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.
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:
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:
What’s always against the grain? The following (non-exhaustive) list always cuts across the community. These things will reduce participation and create disharmony:
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.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?