I’ve written a few articles on how to be do something badly, or how not to do things, as I think they’re a great way of adding a little humour to the process of presenting something. Some examples include:
The last, in particular, was very popular, and ended up causing so much furore on a mailing list that the mailing list had to be deleted. Not my fault, arguably (I wasn’t the one who posted it to the list), but some measure of fame (infamy?) anyway. I considered writing this article in a similar vein, but decided that although humour can work as a great mechanism to get engaged, it can also sometimes confuse the message, or muddy the waters of what I’m trying to say. I don’t want that: this is too important.
I’m writing this in the midst of a continuing storm around the re-appointment to the board of the Free Software Foundation (FSF) of Richard Stallman. We’re also only a couple of years on from Linus Torvalds deciding to make some changes to his leadership style, and apologising for his past behaviour. Beyond noting those events, I’m not going to relate them to any specific points in this article, though I will note that they have both informed parts of it.
The first thing I should say about these tips is that they’re not specific to open source, but are maybe particularly important to it. Open source, though much more “professional” than it used to be, with more people paid to work on it, is still about voluntary involvement. If people don’t like how a project is being run, they can leave, fork it, or the organisation for which they work may decide to withdraw funding (and/or its employees’ time). This is different to most other modes of engagement in projects. Many open source projects also require maintenance, and lots of it: you don’t just finish it, and then hand it over. In order for it to continue to grow, or even to continue to be safe and relevant to use, it needs to keep running, preferably with a core group of long-term contributors and maintainers. This isn’t unique to open source, but it is key to the model.
What all of the above means is that for an open source project to thrive in the long-term, it needs a community. The broader open source world (community in the larger sense) is moving to models of engagement and representation which more closely model broader society, acknowledging the importance of women, neuro-diverse members, older, younger, disabled members and other under-represented groups (in particular some ethnic groups). It has become clear to most, I believe, that individual projects need to embrace this shift if they are to thrive. What, then, does it mean to be a leader in this environment?
1. Empathise
The world is not all about you. The project (however much it’s “your baby”) isn’t all about you. If you want your project to succeed, you need other people, and if you want them to contribute, and to continue to contribute to your project, you need to think about why they might want to do so, and what actions might cause them to stop. When you do something, say something or write something, think not just about how you feel about it, but about how other people may feel about it.
This is hard. Putting yourself in other people’s shoes can be really, really difficult, the more so when you don’t have much in common with them, or feel that your differences (ethnicity, gender, political outlook, sexuality, nationality, etc.) define your relationship more than your commonalities. Remember, however, that you do share something, in fact, the most important thing in this context, which is a desire to work on this project. Ask others for their viewpoints on tricky problems – no, strike that – just ask others for the viewpoints, as often as possible, particularly when you assume that there’s no need to do so. If you can see things at least slightly from other people’s point of view, you can empathise with them, and even the attempt to do so shows that you’re making an effort, and that helps other people make an effort to empathise, too, and you’re already partway to meeting in the middle.
2. Apologise
You will get things wrong. Others will get things wrong. Apologise. Even if you’re not quite sure what you’ve done wrong. Even if you think you’re in the right. If you’ve hurt someone, whether you meant to or not, apologise. This can be even harder than empathising, because once two (or more) parties have entrenched themselves in positions on a particular topic, if they’re upset or angry, then the impulse to empathise will be significantly reduced. If you can empathise, it will become easier to apologise, because you will be able to see others’ points of view. But even if you can’t see their point of view, at least realise that they have another point of view, even if you don’t agree with it, or think it’s rational. Apologising for upsetting someone is only a start, but it’s an important one.
3. Don’t rely on technical brilliance and vision
You may be the acknowledged expert in the field. You may have written the core of the project. It may be that no-one will ever understand what you have done, and its brilliance, quite like you. Your vision may be a guiding star, bringing onlookers from near and far to gaze on your project.
Tough.
That’s not enough. People may come to your project to bask in the glory of your technical brilliance, or to wrap themselves in the vision you have outlined. Some may even stay. But if you can’t empathise, if you can’t apologise when you upset them, those people will represent only a fraction of the possible community that you could have had. The people who stay may be brilliant and visionary, too, but your project is the weaker for not encouraging (not to mention possibly actually discouraging) broader, more inclusive involvement of those who are not like you, in that they don’t value brilliance and genius sufficiently to overlook the deficits in your leadership. It’s not just that you won’t get people who aren’t like you: you will even lose people who are like you, but are unwilling to accept a leadership style which excludes and alienates.
Conclusion
It’s important, I think, to note that the two first points above require active work. Fostering a friendly environment, encouraging involvement, removing barriers: these are all important. They’re also (at least in theory) fairly simple, and don’t require hard choices and emotional investment. Arguably, the third point also requires work, in that, for many, there is an assumption that if your project is technically exciting enough (and, by extension, so is your leadership), then that’s enough: casting away this fallacy can be difficult to do.
Also, I’m aware that there’s something of an irony that I, a white, fairly neuro-typical, educated, middle-aged, Anglo adult male in a long-term heterosexual relationship, is writing about this, because many – too many! – of the leaders in this (as with many other spaces) are very much like me in many of their attributes. And I need to do a better job of following my own advice above. But I can try to model it, and I can shout about how important it is, and I can be an ally to those who want to change, and to those worst affected when that change does not come. I cannot pretend that inertia, a lack of change and a resistance to it, affects me as much as it does others, due to my position of privilege within society (and the communities about which I’ve been writing), but I can (and must) stand up when I can.
There are also times to be quiet and leave space for other voices (despite the fact that even the ability to grant that space is another example of privilege). I invite others to point me at other voices, and if I get enough feedback to do so, I’ll compile an article in the next few weeks designed to point at them from this blog.
In the meantime, one final piece of advice for leaders: be kind.
Alice, Eve and Bob - a security blog 