Confessions of an Alien or: The Ultimate Guide to Attracting Non-Coding Contributors to your Open Source Project (2)
This is part two of our tiny “Confessions of a ‘non-coder’“-series. Part 1 mainly showed why “non-coders” is not appropriate term for addressing us, and why we, those people who don’t code, may be relevant for your Open Source or Free Software project (I’ll use “Open Source” to mean both from now on).
One note in advance: no matter what I’m pointing out here, I’m fully aware that we of Team Hoodie still have a lot to do until we’re good at all these topics ourselves (honestly, at the moment we’re even pretty bad at some). We’re aware of them and are working on major improvements (more on this soon). I know how hard many people in Open Source are working and that it’s not always a piece of cake. We’re not perfect and I wouldn’t expect anyone to even aim to be. We and our projects are all work in progress. But there is progress, so it could be worse :)
This time, I want to show you
15 steps to attracting people who don’t code to your Open Source project
Awareness is often already half the battle, and so it is in this case. Once you decided that you want your project to be more than code, you can start planning your next steps. This is also the time to realize that you may have a long way to go. It takes a lot of time (in which you won’t be able to write code), you’ll have to answer our “stupid” questions, deal with the results of our work (more attention to your project, for example) and much more. We are an investment you make. But I can assure you: we are definitely worth it.
2. Consider opening your project to us important
The question of who you’re allowing to contribute to your project and the reasons why can’t be answered by yourself on your own. If you’re the one who started this project (congrats, by the way!) but you’re not alone on it anymore, you’ll have to get your community, other committers, your team into this. The question whether it’s necessary to work on more than code is a very crucial one.
And mainly, it is a question of culture. As pointed out, you will have to make an effort to get people who don’t code involved. It is very important that everyone that you’re working with on this project does not only know about this, but fully support it. And there may be doubt: doubt about the necessity of all this. Questions about a (probable) lack of focus. People who wonder what the heck you’re planning there (and why). All of this happens, and it’s understandable. But it makes it even more important to establish a team-wide culture where not only code contributions and work on “real features” and other “important things” are accepted and appreciated. In my opinion, this is one of the overall core topics.
Here I am giving your a short handout (also a probable basis for argumentation) about
Why we, the non-coders, can be important for your Open Source project
- We don’t code. – But there’s various things that we’re experts in.
- We enable you to focus on coding while shipping other, highly relevant things.
- We bring a different perspective. May it even be your (future) target group’s or just our own: we see things differently (first, because we don’t code, secondly, because we haven’t dived deeply into your project and never will do as much as you can).
- We help you spread the word about your lovely project.
- We help you improve. – By providing better content, reaching more people etc. pp.
- We help you win. – The open source community that embraces designers, writers, other people most, wins. A theory.
3. This is about acceptance and diversity
It is also associated with the huge sub-topic that is diversity. As we all know, there’s still a real lack of diversity (which leads to a lack of e.g. women and people of colour) in Open Source. Although there may be various reasons for this, I think one of the main issues applies to both diversity and having “non-coders” in your project. And I think the thing they both have in common is that it’s all about the acceptance and appreciation of diversity and variety.
Open Source is still mainly characterized by “white, male, coder”, and I’ve experienced some projects in which these attributes are still being wanted amongst new contributors. I highly appreciate the huge efforts that many people are making in the Open Source community to make a change, to empower “non-white, non-male, non-coding” people and make them part of projects. But still, I’m mentioning this out because I think there’s still a lot of work to do.
And although I don’t expect you to do so, but: should you work in an Open Source project in which nothing but code is being valued, I warn you: you’re going to have a hard time trying to attract other contributors. Aiming for diversity, by the way, should not just be a “tool” you use to make your project more attractive but a core value of all things you’re working on. So, as long as diversity is not deeply embedded in your project’s culture, I don’t see why anyone besides “white, male, coder” should want to support you. (Oh, and by the way: I also heard of not just a few white-male-coding people who wouldn’t do so either.)
There is one more implication here and it is about
4. The support that we will need
No, we won’t need your help while we’re writing, designing new interfaces, thinking about typography or writing communication strategies. But in most cases, our work has impact on yours. For us to contribute to your project, there will have to be developers who implement our work. We can of course redesign everything, write new content etc., but there’ll have to be someone who puts the content on and launches it.
This means, there will come a day when we’ll ask you to interrupt your “very important work on
pet projects real features” and implement our work’s results or work on a design instead. For real. That day will come. And it will be the day of reckoning. (Yes, I know, maybe you just don’t have time the exact moment we’re asking you. But you know what I mean, don’t you?)
5. Don’t care for contributors. Care for people.
Bringing Open Source projects further along is very often a whole lot of hard work. Usually, everyone who helps is welcomed, many times they’re urgently needed, and their contributions are highly appreciated. But the question should be: is it really their contributions that we cherish? Or is it the people that spend hours of work to make those contributions?
This, which may seem to be no big deal at first glance, is an essential query.
People are people, no matter if they work on Open Source projects or don’t. And people tend to be fine, not fine at all, have trouble at home or good times, feel good or bad, have to care for their partners and / or kids (and themselves), have enough money or be starved of funds, have enough food or not, be in good health or suffer from illnesses or mental diseases, feel strong about all the things or have a burnout or depressions. All in all: just as all humans do.
I don’t suggest that we should all try being our co-contributors’ therapists, doctors or best friends. BUT. In my opinion, this is about attitude: about whether you look at others just as contributors (because contributing is what they do) or as people (because you’re oblivious to the fact that they are); as human beings, with their own personalities, strengths, weaknesses and personal issues they may carry around with themselves.
I’m writing such a long piece about this specific topic because I think it will gain more and more importance in the next years. In the past, the Open Source community experienced pretty much similar things to what companies do: people just stopping their work on a project without notice, people stopping their work with notice, people suffering from burnouts and / or depressions and much more. These are serious issues which can’t be negated. We have, of course, still a long way down the road to figuring out what we can do to help these people – NOT because we want to keep them working on our projects. But because we want to (try to) help and support them, as long as it’s in our power, and ideally before things are really bad for them. And implementing a culture in which people at least know that they can talk about those topics when they want to, a culture in which they’re heard because they know that there are people who care, may be a good start.
This, of course, will only work consensually. You clearly won’t be able to force someone to do a skype call with you or talk about their personal issues. And you won’t be able to do this with every new person joining your project when there’s hundreds of them, and it will take time until people open up to you. But that’s not the point I want to make here anyway, because: if your cultural setup is just like this, other people in your project will care as well (so you won’t have to do it on your own). And the main thing is: if people know for sure that there is someone who is interested in them as a person and that there’s a culture where they as people and their personal topics are respected and valued, it may make it easier for them to do so whenever necessary.
Often, when people talk about their reasons for being part of Open Source projects, they usually name “the community”. Thus, I want to spend some words on it. Ethymologically, its origin is Latin communitas, meaning “the very spirit of community; an intense community spirit, the feeling of great social equality, solidarity, and togetherness” (source 1, 2). This is why it’s often compared with a tiny village or your neighbourhood. In Open Source projects, the community is something you can of course feel: at conferences, meetups, basically everywhere you meet real people. But, honestly, it’s quite difficult to feel “an intense community spirit” when you’re sitting at your desk alone working, eating cookies and starring at your laptop and discussing issues on IRC.
As this is still the mode in which many of us are building our Open Source contributions, it becomes even more important to keep people (and not just the catchy, but very unconcrete “community”) in mind. And as attending conferences and meeting all those lovely people often requires a bunch of money and time, not everyone can make it there. This makes everything that happens virtually even more relevant. And, no worries, I don’t want to get too romantic here. I just wanted to include a little reminder what this “community” that we’re in and working on and aiming to extend, actually means. And that everything we talk about finally results in people.
What does this practically mean? Sincerely, it’s pretty simple: get in touch and stay in touch. Let me give you an example: Gregor, who’s also working on Hoodie, handles this topic this way: whenever a new contributor joins a project he’s working on, he just directly asks them (on IRC or twitter, for example) to do a 10-minutes-Skype call or Google hangout. This is a pretty easy thing which doesn’t take much time, but helps both him and the other person involved get to know each other better and get at least a tiny impression of who you’re working with.
Basically, this is just the classic having someone new in the team, giving them a tour around, showing them how things work, and telling them you’re happy to have them and that they shall never hesitate to come up with questions or feedback they have. That’s all. Just the friendly “hey, good to have you, here’s how it works, I’ll be there for any questions”.
No matter if you decide to call people, meet them for a cup of tea, stay in contact via Twitter or IRC, arrange a weekly call / chat with all members of your project, or whatever it is you may choose: do it. It brings
contributors people closer and, most importantly, it helps create a culture in which people do not only talk about code, but also about things that are going on in their lives.
(No bro culture support here, by the way.)
As you see, the steps I depicted (especially #2-5) up to here aren’t really about attracting “non-coders” specifically. They are what I would call obvious. Thus, all of them are still topics which I, after all I read, heard and talked about with other people in Open Source, consider real issues in some projects. And, again: I know that many people in the Open Source-community are working hard on these, which I wholeheartedly appreciate and support (although I consider them as topics which, in an ideal world, should not be topics at all. But as we’re far from an ideal world, there we go). I don’t want to negate the effort you are making for a better Open Source-community. Nevertheless, I think it’s important to bring these topics up again and again. In this context, I’m doing so mainly because of one reason: I could’ve written all of this in the classic business “how to”-recruitment-style: where to get it, what price to pay and how to make most profit. But this is not about business, this is about people. And I think all steps following are useless (if not even self-defeating), as long as the project’s and community’s culture are not ready, as long as there’s no proper base to start them from.
6. You can call me Al
As stated last time: I like you, the people who write code. And I try my best to acknowledge your expertise. I try to avoid disrespectfulness and at least understand some parts of what you actually do (and not just peg you as “the coder”). This may implicate me asking you “stupid” questions about what you’re exactly working on, what the latest repo in our project is for or if you could help me learn how GitHub works. But it’s my way of trying to show you as a person my respect.
So, if you want me to work with you, you should begin by thinking about who you need. Because, honestly: if you just search “non-coders”, I personally won’t feel addressed at all. Figure out what you need help with: do you need a designer, someone who helps with communications and marketing, a copywriter, a law expert? Define what you really want. And then search for us specifically.
7. Understand what it’s like to not be in Open Source
There is already a remarkable amount of non-coding people in the Open Source scene who are doing a lot of great work. For attracting those who aren’t yet, you’ll need a special strategy, detailed in the following steps. Maybe you’ve been participating in Open Source projects for quite some time now, so this one may be a little difficult for you.
I’d like to ask you to imagine what it’s like to not be and never have been part of an Open Source project and to not know how to code and probably be neither white nor male. …
Which means: we will have questions. Literally, I started my work in Open Source by googling what “Open Source” exactly means, the philosophy behind, the big picture, what is done in Open Source, why the heck people contribute (!), and much more.
All of this leads to a chain of causation:
- If people don’t know about Open Source,
- If they don’t understand what your project is about,
- If they can’t see the value that it creates for other people,
- And if they don’t feel which value a contribution can create for them,
for all the world: why should they want to join you?
This means, in the first place, you’ll have to sell your project. Seriously. So let’s call it what it is: marketing (with an extra challenge as, in this case, you may have to sell your project to someone who may not be your final target group). Literally: it’s recruiting and recruitment marketing.
Yeeeeeeeeah! Everybody loves marketing!
I’m using this “recruiting / recruitment marketing”-term for two reasons: first, it makes more explicit what we’re actually talking about. Secondly, it emphasises both its seriousness and scope. But still, don’t let yourself be deterred by this now and let me tell you one thing that may make it a little easier: maybe you’ll only have to do this once to convince your first non-coding contributor to join – and next time they can be the ones to do this ;) … Okay, that’s not entirely true. The effort in the background (especially the culture-related topics above) are a project- and community-wide topic which can’t be done by one person in one day, they require full support of all people involved in your project. They’re issues that never reach the status “closed”. But at least the following items may get easier as soon as you found your first “non-coder”.
This topic is essentially about the selling of your project on a prospective new contributor. As said about my experience when joining Hoodie: yes, I had a very rough idea that this project seemed to have some relevance to other people™ (because my team members told me this were the case). (By the way: hi Team, if you’re reading this: you gotta be strong now.) However, in fact, I mostly joined Hoodie in the first place because I didn’t have another thing to do and I considered the people involved pretty nice. That was about it. (Guess I don’t need to tell you that things have slightly changed since then. But take that just as a side note to my team members :) )
Starting “recruitment marketing” for your project means to consider
- who you address
- what they need
- what matters to them (values, money, fame, getting to know new people, …)
- how they can be motivated
- what you’d like them to do
So, now, two lists to start off your imagination:
Things that can be relevant to us, the non-coding people, when you want us to join your project
- On Open Source in general
- What is Open Source?
- Which Open Source projects may I already know?
- What’s the philosophy behind it?
- What kind of people work on it in general? (in other words: who will we have to deal with?)
- Tell us about the community!
- On your project
- What is it about?
- What does it aim for?
- Who does it (mainly) address?
- What’s the added value for people who use it? What does it give to them?
- What kind of people work on it in general? (in other words: who will we have to deal with?)
- How do you collaborate? (Do you have regular meetings, chats, …?)
- On you, personally
- Why are you working on this project? What is your motivation, goal, …?
- What are you working on?
All of these are core values, of both Open Source in general and your project. Those core values don’t all need to be run through from A to Z, but it’s really useful if you got at least a vague idea of them which you can then communicate.
By the way: sending out links to Wikipedia articles is not a solution here. As warned above, it is a bit of an effort, and this may include talking to your prospective co-worker in person (or at least via email or Skype). If this seems too much effort for you … see above. (And, yes, I’m pretty strict in this point. You, as a developer who may have been part of the Open Source scene for maybe years, of course know why Open Source is a damn good thing. But, ha, you’re not the target group in this case.)
Reasons for us to join Open Source projects:
- personal relationships – It helps a lot to get us involved if you’re someone we know, or, even better, like :)
- interest – Sounds mundane but isn’t. If the things you’d like us to do sound interesting, this already might be enough of a reason to join you.
- Doing good™ – Can be a reason for the idealists amongst us.
- Working on something that matters – Yes, Open Source projects are important and many do have a big, direct or indirect impact on many people’s lives.
- Working on something meaningful
- Adventure Time – Aside from knowing the person who asked me to join Hoodie, it soon turned out that my main interest was about the adventure. Going where no one has gone before and doing what no one has tried before is pretty stunning. (Sorry for that, had to get a little exaggerate here.) But this “from zero to hero”-feeling (sorry for still exaggerating) is really pretty helpful as it makes things more interesting. There are no “standards” as there are for you, usually no big rules, we can do and try what is on our creative minds.
- A million opportunities – Marketing speech for “a LOT of work to do”.
- Bringing forth the project
- Having an impact – Knowing that you can achieve something with your work is always a good thing.
- Challenge – some people like challenges, and e.g. doing marketing for an Open Source project or attracting more committers can be a real challenge.
- Meeting other experts
- Get to know great people – a.k.a. “Meet the community”
8. Figure out where to find us
Let me say: sorry, this one won’t be easy (but the others haven’t been either, so I guess you’re already used to this ;) ). Because, more or less, we’re everywhere and nowhere.
I’ve started using Twitter in early 2008 and had quite some fun there, reading mainly jokes and wordplays. Ten months ago, at the beginning of my work on Hoodie, I opened another Twitter-account. I started following completely different people, mainly from the Open Source community. Soon, I realized how different “my Twitter” was from that day on: it had around zero overlaps with my Twitter-experience in the first place.
This one is about the good ol’ filter bubble. Chances are that even people who are high-frequency-tweeters have never ever heard of any Open Source project before, although they’d be of interest for them, if only they knew (same applies to any other social network you may use and also about people you know or are friends with). But, still, there are some ways to finding us:
- First, make a list of things you need. Describe the tasks and / or long-term work to do.
- Write about it. Describe your project (btw., based on who you’re searching, it may help to mainly describe about what it does and not how it works). Tell about the people who are working in it (e.g.: how many? Who are they?). Write about what you need help with and why. And, of course, who you’re searching. Sounds like a job-ad to you? Well … it is, pretty much.
- Send out Tweets with your search for help and ask people to re-tweet them.
- Use networks: got friends who don’t code? Perhaps they could help you. Or they know someone who knows …
- Search the internets™. There are websites where e.g. designers are presenting their work, networks of writers etc. pp. Keep in mind that if you contact them saying “hi, I need your help for
freethe glamour and the fame”, not all people may necessarily answer “wow, this is the opportunity I’ve been waiting for all my lifetime”.
- Facebook is crap. But if you don’t boycott it: there are hundreds of Facebook groups for everything. And yes, there are also some for people who share similar fields of work (like designers, writers etc.).
- Make a website. Although your project may run on GitHub and this is how you roll, this may not be the very best place to show you’re looking for e.g. a a tax advisor. You should do it anyway, although your target group will rather not hang around on GitHub (but perhaps they will, one day, so be prepared). But why not just make a website in addition?
- Finally: be addressable. Somewhere around your nice content, there should be an email address, a Twitter user name, someone that people can contact and say hi to. Helps a lot.
No matter what you decide for: always keep in mind who you target, so keep entry barriers low.
There are some projects who are doing a pretty decent job here, all addressing both coding and non-coding people. Why not take a look at what they did? Just to name a few:
- KDE TechBase
- GNOME for Designers
- One Web For All (thanks to @kriesse!)
- … and many more. Tell us if you know more!
10. Let us do our job
Once you got us on board, help us stay: help us when we need your feedback, your approval, an implementation or just an answer from you. Stay in contact with us. Trust us and our judgement, and stick to your commitments. We trust you to do your job as best as you can and you need to trust us to do the same. If we do designs, you say yes to it, then implement it the way you agreed to. If collaboration is required, don’t drag things out artificially, just because it’s “not code”.
11. Support us
Remarkable parts of the Open Source scene still consist of people who write code, and it takes some time until the feel of being an alien decreases. Fairly, it still isn’t always easy.
Open Source is still mainly a developers’ party. And as a “non-coder”, you’re not necessarily one of the cool kids there, or at least maybe you just don’t feel like you ever could be cool, sassy, intelligent or experienced enough to have something to throw in there.
I also had my issues™. And I’ve had plenty of them in the last year. My main thought and feeling was that I couldn’t contribute anything valuable to this project. I often came up with thoughts about “real features” and that I wasn’t able to contribute to them. In addition, I’ve had some struggles with my own self esteem, my abilities and limits, imposter syndrome and frustration.
Luckily, I soon knew I could really talk to my team. And this certainty helped a lot. I often first talked to one team member (mainly Jan, in this case. Btw.: thanks for encouraging me!), sometimes I brought topics up in team meetings. I was sincere and spoke about my weaknesses and the team’s reaction was so wonderful in all cases. They had promised to support me, and so they did.
12. Give cookies
Everybody loves cookies, and so do we. So if you like our work or what we do for the team, let us know. This is very important, even more in the first months of our collaboration (but not to be forgotten afterwards).
Listen to what we have to say. Value our feedback (see #5).
14. Keep on keeping on
You’ve come so far, you’ve reached a lot. No matter how many people you attracted and if you reached all your goals: my congratulations. Because there’s one thing which you quite likely achieved: your own point of view or your ideas who can be part of Open Source changed, or maybe a change in your community got started. Keep on doing your good work.
15. Go the Elvis Presley-Path
Keep us on your mind. Always remember that all of us got the same goal: to bring the project further along. Which is not only yours anymore, but has become our project, too.
Thank you for reading and sharing your thoughts (if you want to). <3