Tag Archives: open source advice

Letters to an open source contributor: Leadership

Much of my work in WordPress over the past decade has involved coaching and training leaders working in open source, and as I wind down this part of my career, I find I have a lot to say on the topic! I’m going to try to follow my own advice and be brief here, but I do not promise.

If you’re just getting started hearing me talk about leadership, I recommend a previous post of mine: What happens when you won’t admit (or don’t realize) you’re a leader. That piece resonated with a large number of people I’ve worked with in WP, so I’m recommending it as supplemental reading for this article.

Oh! And the other important thing to know, going into the leadership advice I will share below, is that I firmly believe in leadership at any level of an organization. Open source embraces this idea, in that our organizations are usually less hierarchical and, because the work is accomplished by the people who show up at the time, more fluid when it comes to who we look to, when we’re navigating a problem.

So! With those ideas in mind, let’s dig into more advice for leaders in open source.

Don’t make yourself indispensable

One of the most powerful things I’ve learned from Josepha is that

If you can’t be replaced, then you can’t be promoted.

– Josepha Haden Chomphosy, Executive Director of WordPress

I know, I just told you that open source isn’t very hierarchical, and I wasn’t lying. This concept applies to flat/open source organizations more like this:

If you can’t be replaced, then you can’t ever work on cool new stuff. Because if you do, all the cool old stuff you built… will end, or break.

Teaching people how to do the work that you do? It’s time-consuming, and can be a real challenge. But the people who do this — who document their code, who design in public, who create a succession plan and train their replacements — those people get the best that open source has to offer. They get to create amazing new features, programs, events, etc… and then they get to see those things keep growing, even when they move on to the next thing.

Recruiting, training, and cultivating your successor will make you much freer and more nimble, in an organization. It’s also the best way to ensure your work has a lasting effect.

Love your beginners

Photo by Ron Lach on Pexels.com

If you want your project/initiative/coalition to grow, you need to welcome new people into it. One of the things about new people = they don’t know everything yet. Don’t fall into the trap of thinking that ignorance is the same as stupidity — answer questions (even the ones you answer a lot!) with warmth and grace.

Also, be aware that beginners are a rare and valuable resource. They see things with fewer preconceived notions than the people who’ve been around for a long time. They question things that tenured contributors don’t even notice anymore, or have given up complaining about but still dislike.

Beginners are also an endangered resource! If you can get them to stick around a while, and train them for a while, then guess what? They’re not beginners anymore! So be sure to engage with your new people while they’re still new, and can help you fill in some blind spots or clarify where your outreach or messaging is still confusing.

Open source your decisions and thought process

Working in public is one of the hardest things we do, in open source, but profoundly worthwhile. Transparent processes and work patterns result in well-documented decisions, which lead to higher-quality contributions in the future.

I had this realization a few years back, when I was complaining (not for change, btw) about how many suggestions my team got, that didn’t demonstrate an understanding of what our work was about, or why things were set up a certain way.

“Why don’t they understand that [thing that was obvious to me at the time]?!?,” I fumed. And then it hit me: BECAUSE I HAD NEVER TOLD THEM.

Me, about me.

When you keep your concerns, doubts, convictions, and theories private, then the people who show up to collaborate with you… are slower to connect with both you and the problems you’re trying to solve together. Maybe so slow that you never connect in the first place.

But thought leadership can scale pretty elegantly, if you are willing to work in the open and diligently share your goals, observations, reasoning, and philosophies. It’s not easy, but it works.

Play the long game

Things tend to move slowly in large organizations, even if you have all the power in the world. Groups with broad impact are powerful but tend not to be nimble. So you will run into a roadblock or traffic jam in something you’re trying to accomplish.

When this happens, try not to force it. Do your best to take the long view, and bide your time. I have accomplished a lot of things in WordPress that I wasn’t sure were possible, sometimes simply because I stuck around longer than the people who were blocking my progress.

Be patient, pace yourself, and keep a few ideas on the back burner, for when conditions might be right for them. The story only ends when you stop writing it.

Looking for more advice?

If you’re joining this open source advice series in progress, you might enjoy the other articles, too!

  1. Intro: Letters to an open source contributor
  2. Communication
  3. Collaboration
  4. Criticizing for change

I think I have a few more of these articles in me, so stay tuned!

Letters to an open source contributor: Criticizing for change

This post is subtitled “criticizing for change” because not every criticism is fueled by a desire for change. Some arise because someone is having a rotten day, looking to connect over a shared experience, or even declaring what they value. Treating all criticism equally is as big a mistake as ignoring all criticism.

But this post is for critics, not those being criticized. More specifically, this article is for those of you who see things that you think are wrong in open source, and want tips for sharing your critical feedback in ways that that are more likely to result in a change.

The bigger the change, the longer the game

Photo by Krivec Ales on Pexels.com

Organizational change takes time. Big-impact changes take time. Big-impact changes in large organizations take a LOT of time. Change advocacy can be tiring, so I recommend taking the long view and setting yourself smaller, more attainable goals that will pave the way toward your ultimate goal. If you can, if you are privileged enough to have the time and stamina, pace yourself.

Avoid personal attacks

Some open source projects like WordPress have fostered a deeply connected, engaged community of contributors. Open source is also deeply vulnerable to the Five Geek Social Fallacies, which can lead the group to close ranks around a community member if that person is criticized or attacked, even if that person has done bad things.

This doesn’t mean that you can’t say, “this person’s behavior was terrible.” You can. But if you lead with “this PERSON is terrible” and point to their behavior, you will lose a lot of people before you even get to your examples.

For better or worse, repetitive critiques of a particular person or people result in diminishing returns. The reason I encourage people to love their critics is because most people start ignoring messages from “a complainer” or “someone with a grudge,” after a time. If you’re playing the long game and working toward change, then remember to criticize the behavior, not the person.

Build coalitions

In open source — and probably everywhere — it’s easier to get people to listen if you are speaking as part of a group, instead of a lone voice of dissent. This doesn’t mean lone voices of dissent are any less correct, or that a group is guaranteed to be right. I’ve seen large groups of people who were wrong, in open source, and been part of groups that were wrong, myself. That’s just part of being human. (Unfortunately. I sure do love being right.)

That said, building a coalition is the most effective tactic I know, to successfully accomplish change in an organization. Convincing other people of your idea’s merit on a small scale demonstrates a plausible promise. That plausible promise helps more people take your idea seriously. As you continue to test the idea with more people, presumably the idea gets refined and improved, helping it fit better into the fabric of the project. Eventually, the idea builds enough momentum that it takes on a life of its own. By the time that happens, you can usually just sit back and let the organization grow into the change.

Optimism FTW

Open source contributors are optimistic — you don’t put the time into contributing to a project that’s bigger than you, unless you have hope that your work will have an impact. Our work is fueled by hope, and our hope fuels our work. In contrast, advocating for change can be discouraging, which can lead to cynical or despairing attitudes.

I hope this goes without saying, but I’ll say it anyway: you’re going to have a really rough time getting inherently optimistic people to want to work on a change that comes with the message that “we’re all doomed.” And if you believe, down deep, that nothing’s going to help, then you’re probably not criticizing for change in the first place.

Either way, “this idea could make us great!” is a much more motivating message than “this idea could make us less terrible!” Tap into that open source optimism, and let it give your idea wings.

Pragmatism is powerful

It may be that the change you’re suggesting is morally right. I hope it is! But remember that what’s considered morally right… varies between different cultures. And most open source projects include contributors from many different cultures — WordPress certainly does. So I recommend against relying on the argument that “it’s the right thing to do.”

Instead, focus how the change you seek will help the organization move closer toward its goals. Warning: this does require you to understand what the goals of the organization are! But if you don’t know that already, then pause until you learn them. You never know… what you identify as a bug, might actually be considered a feature!

What did I miss?

Any other tips for our change-makers? Does something I’m saying sound wrong to you? Share your advice or ask questions in a comment on this post!

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.

Photo by Anete Lusina on Pexels.com

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

Mighty oaks from little acorns grow!

Photo by Eriks Abzinovs on Pexels.com

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!

Letters to an open source contributor: Communication

Josepha likes to say, “all problems are, at their heart, communication problems,” and I couldn’t agree more. The most powerful tool in your open source toolbox is not an understanding of code or usability, but rather the ability to express yourself and understand what other people are trying to say.

Here are some qualities I have observed among highly successful contributors in open source:

Brevity

Avoid “walls of text,” long paragraphs, and complex sentences.

Inexperienced or insecure contributors sometimes try to establish credibility or persuade their audience by writing a LOT of words. This is a mistake. Verbose communication requires people to work extra-hard to understand what you think or want. By the time they think they understand you, they are likely irritated that they’ve had to work so hard, or they have untested assumptions about why you’re burying them in words.

This is not easy advice for me to follow, because I love words and complex sentences! So when I’m writing to communicate in open source, I make a first draft and then cut words and sentences as far as I can. I sometimes joke that most of my writing time is actually spent deleting!

In open source, time is short and information overload is constant. You appear aggressive and disrespectful when you only communicate in long, complex messages. Be kind; be brief.

Humility

Don’t try to establish credibility by trying to appear smarter than other people; it just makes you look like a jerk. No one wants to work with someone who brags about their skills or calls attention to other people’s ignorance.

Photo by Magda Ehlers on Pexels.com

No one was born knowing any computer language, or any fact, about open source or WordPress. Even if people were snotty to you as you were learning — remember how bad that felt, and don’t perpetuate the pattern. Rise above, and be kind to those who know less than you.

Showing off rarely makes you popular in open source, but humility and helpfulness nearly always do.

Consideration

Open source projects are, if they’re lucky, global organizations full of very different people. Working in the open, with lots of people who are very different from you, is a great way to build something extraordinary.

Photo by Dio Hasbi Saniskoro on Pexels.com

To communicate effectively in those conditions, you must consider how your messages will be received by people from many different backgrounds and cultures. This isn’t just about refraining from slurs, swearing, broad generalizations, and gendered language — though, please avoid all that too! Really, I mean it!

But considerate communication is also:

  • thinking about how to include more people into the conversation, regardless of time zone,
  • allowing enough time for people with different availability to join a discussion or project,
  • assuming positive intent,
  • using group Slack pings sparingly, and
  • thinking about how people will feel, when they read your message(s).

We also communicate considerately by focusing our criticism on the problem, rather than the people. Personal attacks won’t get you anywhere that you really want to be.

Over and above

For even more open source/WordPress communication tips, check out these lessons from the WordPress contributor training course!

What did I miss?

Hey, other experienced open source contributors, what else do you think people need to know, about communicating successfully in open source? Add your advice in a comment on this post!

Letters to an open source contributor

As mentioned, in September I’m leaving Automattic and my full-time role supporting contributors and programs in the WordPress open source project.

(I’ve been overwhelmed by the number of people who’ve taken the time to tell me that I’ve had a positive impact on them or on their experience in WordPress. Thank you so much, friends! It means so much to know that I made a difference.)

Also as mentioned:

One of kinds of “invisible” work I do as a leader in an open source project is to coach or mentor contributors who are new to WordPress, or who are looking to grow in this community/ecosystem. If you’re thinking “I’ve worked with Andrea before, and she never told me what to do!” then it might be that I had feedback that I was waiting for the right moment to share. It’s also possible I was shadowing YOU and hoping to learn how you do cool stuff around WP. Anyway, I have a lot of stored up counsel, that I want to share with a bunch of people before I go on my possibly-forever hiatus.

And what do we do in WordPress when we have something to say? Well, we blog about it of course. 🙂

“Letters to a Young Poet, by Rainer Maria Rilke” by elycefeliz is licensed under CC BY-NC-ND 2.0

So please stay tuned for a series of articles, which will include possibly-sassy versions of the advice I generally tailor to individual needs and moments. I hope that sharing my observations about what works and doesn’t work, when trying to accomplish things in WordPress, will result in some assets that help open source contributors, even when I’m not around. As you can see from this title, I’m going to try to humbly channel Rilke.

Is that even possible?

Stay tuned to find out!