Letters to an open source contributor: Collaboration

You don’t have to want to collaborate to use WordPress to do great things. You DO need to collaborate if you want to do great things in the WordPress open source project, though.

Collaboration isn’t always the fastest way to accomplish something, but I think it is the best way to accomplish things that have a huge impact. Most people are called to open source contribution because they are impact-driven and know that by working with lots of other people, they can grow their own skills and make better decisions/products/programs. Also, it’s fun!

So here’s some advice I find myself sharing semi-frequently, on collaboration in open source

Love your critics

Now don’t get me wrong — I don’t like being criticized; I hate being wrong, and I hate thinking that someone things I’m wrong even more. AND….

Don’t make the mistake of throwing away valuable feedback just because someone is angry or shares opinions you don’t agree with. You probably don’t know everything (and if you do, I wish you’d write it all down so I could, too!), so even mean feedback is data.

If you accept the notion that good ideas can come from anywhere — a foundational idea in open source, fwiw — then it’s criminally stupid to decide to stop listening to someone, just because you don’t like what they’re saying.

Beyond avoiding dumb moves, sometimes critical feedback is immensely useful. You can use it to check in with fellow contributors to see who shares the same ideas but just hasn’t been brave enough to say anything. You can use it to learn how you might be mis-communicating or misleading people in your communication. You can use it to fill in your own blind spots.

All that to say, don’t write people off as trolls unless they’re abusive, making personal attacks, or inciting violence. In open source, as in many other places, resilience in the face of criticism will make you much more effective, longer.

Assume smart predecessors

This is a twist on “assume good intent,” which I probably should have included in my Communication article.

I often talk to open source contributors who have found an organizational dysfunction and are passionate about fixing it. They come at the problem from multiple angles, talk to all sorts of people about their ideas for making things better, and keep running into roadblocks. It might be that others see the problem and have learned to work around it, or that fixing the problem isn’t a high priority right now. It might be that people disagree there is a real problem. Regardless, it’s frustrating for all involved.

My advice: when you notice an inefficient or “broken” thing in an organization — whether you’re just getting started or moving deeper into the group — get curious and ask yourself a few things before acting:

1. Am I the only person who notices this, and if so, why?
2. Who else experiences this problem?
3. Has anyone tried to address it in the past; if so, what did they try and why did it fail?
4. Do I have the agency/authority/expertise to fix this? Who does?
5. What does this “broken” thing fix, in the organization?

That last question is the most important one. Here is a truth: no organization tolerates broken processes unless those “broken” things are actually functional for some person or group. That doesn’t mean that anyone intentionally set it up that way — almost always not! — but if it’s persisted for a while, then this broken thing is fixing something, somewhere. And until you know who benefits from the inefficient process, you have at best a 10% chance of success, in changing it.

In your zeal to contribute, don’t assume you are the first smart or perceptive person to join an open source project. This doesn’t mean you don’t have the “right” answer! but do yourself the favor of learning from tenured contributors, and spending your energy wisely.

Start small and iterate

Open source is very friendly to new ideas and experiments. But when you work on a large scale, or in a large project, it can be hard to discern how and when to experiment. If you are still working on building trust with other contributors, the best way to try out a new idea is on a small scale at first, but in a way that can scale if your experiment is successful.

The best open source experiments start out by answering these questions:

1. What problem are we trying to solve?
2. What theory will we test in this experiment?
3. How long will we test this theory?
4. Who will participate in the experiment?
5. Who needs to know about this experiment? Who needs to agree to it?
6. How will we measure the outcome of our experiment, in a way that tells us whether we’ve solved the problem?
7. If this causes an unforeseen problem, how will we gracefully end the experiment?
8. Where will we communicate about this experiment?

You can limit the impact of an experiment’s failure (to the organization and other contributors) by offsetting risk and scope. If the impact of an experiment’s failure is likely to be low, then the scope of the experiment can be more broad. If the impact might be high, then the scope of the experiment should be more narrow. 

What did I miss?

Does this all make sense? Is there another tip for effective collaboration that you wish more people knew? Add your advice or questions in a comment on this post!