Confessions of an Alien: Attracting Non-Coding Experts to your Open Source Project
What and which kind of contributions is being valued in Open Source projects? Why can there (and probably should) be more than code? And how can you attract people who can help you further your Open Source project apart from the code parts?
Experts in Open Source Projects Hi, I am Lena and first, I want to say thank you to the wonderful up.front team and especially to Kriesse for inviting me. It's a pleasure to be here.
important. It is the core product and core value of most Free and Open Source projects. And – it is important that this product is great. Products have to compell people. This is why many or even most parts of the work on Open Source projects are usually done by developers. Still, the question is:
want to achieve with your project? Do you want to, for example, • provide good, useful software • enable people to realize their dreams • change the world of technology • be well-known in the Open Source scene (and beyond) • or anything else you may think of? No matter which of these you choose – this leads to a bunch of to dos. (yes, there’s a rhyme included. You’re welcome. :) ) So, the to dos for achieving your goals:
improving your documentation (or starting one from scratch) • finding bugs • providing translations • designing a UI, UX, a good website, logo and much more • getting funds • organizing events • attracting new users / contributors And the question is:
is: many of these things currently can often just not be done. There’s no time, no resources, no one who could (or would want to) do it, no experts, no money to pay people, no “need” to, etc. I know.
frontend or backend development or software architecture, they master one or various programming languages and so can contribute to the core "product" of these projects. And it's just the same with all other to dos mentioned: Copywriters can write content. Designers can design etc. But isn't it the case that developers can also write? I, as a professional writer, would say: yes, they can. So why should you care about acquiring experts, people who are, e.g., –>
They see things differently (first, because they don’t code, secondly, because they haven’t dived deeply into your project and never will do as much as developers can).
experts 5. There’s a reason why I’m not writing code for Hoodie or CouchDB and it is that I am not an expert in coding. I’m not good at it, I’m generally interested in it but there’s many other things I’m good at and love doing, and that’s why I’m not a developer. I’m specialized in other things and I think: whenever you got the chance to get experts on board, you should go for it. Because they’re experts.
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, always keeping in mind that it takes a lot of time. This is an investment you make. But I can assure you: it is definitely worth it.
question of who you’re allowing to contribute to your project and the reasons why will have to be answered by yourself, other committers and your community. It is very important that everyone that you’re working with on this project does not only know about this, but fully support it.
discussion whether it is necessary to work on more than code is the most crucial one in this entire topic. And it leads to the bigger picture - which is about
there’s still a real lack of diversity in Open Source (which leads to a lack of e.g. women, trans*people, people of colour and “non-coding” people). Although there may be various reasons for this, I think one of the main issues applies to both diversity and having “non-coding” experts in your project. And I think the thing they both have in common is that it’s all about the ->
Source is still mainly characterized by “white, male, coder (and bearded)”. And although many people are making huge efforts to empower “non- white, non-male, non-coding” people, I think there’s still a lot of work to do. 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. (And I also know of many white-male-coding people who wouldn’t do so either.) There is one more implication here and it is about -> ! img source: http://25.media.tumblr.com/7396684fc5a700975f26a0585fcaa4d3/tumblr_mkfgr5Y7HY1rk5xl7o1_1280.jpg
cases, their work will have impact on yours. For them to contribute to your project, there will have to be developers who implement their work results. This means, there will come a day when they’ll ask you to interrupt your “very important work on 'real features'” and implement their work’s results. And it will be the day of reckoning. // ->
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?
seem to be no big deal at first glance, is an essential distinction. It is a topic which is near and dear to me 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 being fine, not fine at all, having trouble at home or good times, people stopping their work on a project with or without notice, people suffering from burnouts, depressions or other mental illnesses 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 in those cases to help these people – NOT because we want to keep them working on our projects. But because we care. Because want to (try to) help and support them, as long as it’s in our power, and ideally be there for them before things get really bad. 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 and they know that there are people who care, may be a pretty good start.
still 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. Nevertheless, I think it’s important to bring them up again and again. Especially, because I think all steps pointed out in the next slides are useless (if not even self-defeating), as long as a project’s and community’s culture are not ready, as long as there’s no proper base to start them from. —- So, after fixing the cultural settings,
snack, from day to day. “I don’t have a plan. I live from snack to snack, from day to day.” (This is not only one of my favourite Alf quotes, but also kind of my life motto.) Your first to do for acquiring “non-coding” experts to your community is the opposite: Make a step-by-step plan. And stick to it. (And have snacks from time to time. Helps a lot.) ! img source: http://www.bolumrehberi.com/images/tv-show/ALF/alf_wallpaper_1024x768_3.jpg
in Open Source. People who haven’t worked on Open Source projects yet will have questions. So prepare answers. Literally, I started my own 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. Take that point of view and, in everything you do, remember this again and again.
experts to work with you, you should begin by thinking about who exactly you need. Because, honestly: if you just search for “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 so you can search for them specifically. —- This means, in the first place, you’ll have to SELL your project to them. Seriously. So let’s call it what it is: it’s
I’m using this “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. Starting “recruitment marketing” for your project means to consider:
they need 4. what ma!ers to them 5. what motivates them and what motivates them. Write all of this down. Next, it may help a lot if you put together -> core values:
your project 4. you of Open Source in general and why people work on it; of your project and you personally, and your reasons for working in Open Source. Give these people reasons to join your project! —- Depending on these lists you wrote,
Always and in everything you do. Aiming for diversity in your community also means to be embracing and aiming for inclusion. ! So, here’s what you can do for finding the experts you’re searching for:
in mind that, based on who you’re searching, it may help to mainly describe what it does and not how it technically 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 for. Sounds like a job-ad to you? Well … basically, it is one.
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 put your job ad on GitHub anyway, but we just talked about accessibility - so create a thing that is accessible for people who are not used to GitHub.
Use networks: got friends who don’t code? Perhaps they could help you. Or they know someone who knows … If you don’t have friends who don’t code, you should really try to find some. There are really awesome people amongst them, I heard. :)
leave your filter bubble 4. 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 people saying “hi, I want you to work for free, just for the glamour and the fame”, not all people may necessarily answer “wow, this is the opportunity I’ve been waiting for all my lifetime“. So be well-prepard to compell people. Also: make good use of social media: Facebook is crap and they’re doing a lot of things wrong. 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. Send out Tweets with your search for help and ask people to re-tweet them and thus try to leave your cozy filter bubble. Finally, ->
leave your filter bubble 5. be addressable be addressable. Somewhere around your nice content, there should be an email address, a Twitter user name, probably also with a nice picture, basically just someone that people can contact and say hi to. Helps a lot. —— Once you found someone interested in working with you, help them get on board.
someone new to a company finally really got onboarded. And it will take even more time with someone who is working on Open Source only in their spare time. Those first months are already an important time for any new committer. But there's a few reasons why they are even more important for non-coding committers in Open Source these days, so you should -> prepare
to something is never easy 2. being a newbie in a thing you haven’t ever done anything in (like an Open Source-community) is even more difficult 3. and being one of your first or even the first non-coding committer to an Open Source Community is the worst thing of all. Everyone in your project does different things than you do. Everyone else’s perspective differs from yours in almost all ways. 4. Chances are, that after a good onboarding experience, your new committer is more likely to stay AND also help you get new non-coding committers in. 5. There are meetups and conferences for almost everything and everyone. … At least, for everyone who is a developer or at least codes a bit. Which makes it harder for people who aren’t – even if your new non-coding expert wants to meet new people in your community and attends meetups and conferences, it may be a tough time for them. They’re usually not the core target group there, and yes, even small talk becomes difficult when you’re amongst people who have a good time talking about their projects and code and you just don’t understand a thing. And you feel like … ->
about onboarding committers who don’t code: for getting new developers in, you can use your code base and create starter issues they can work on, let them fork your project and play around with it or let them create issues and pull requests on their own. This will become quite difficult when you want someone to design a thing or write blog posts about your project. First, because many non-coders are often not used to GitHub and it may be more frightening than helpful in their first months. Secondly, because it is way harder to break those topics like communications down into GitHub issues. This is, besides the alien-situation, one of the core differences to the onboarding of a coding committer. —— So here’s what you can do to create a good onboarding experience: -> first, create
shows the values of your community. In everything we do, there are rules, and there should also be rules for your Open Source project. Knowing that there are rules AND PEOPLE who enforce them (and people they can also talk to if someone is not acting accordingly) helps a lot.
on the way work is being done in your project, but it helps a lot if there’s, for example: a mailing list with not too many members who all support your new team member and your goal of getting non-coding experts board. This could also be a special chat room with only a few people. It can of course also be your regular chat room. Just make sure this space is safe and people and their opinions are being appreciated there.
them in details how your community is structured, how it works, how work is done, how you all stay in contact. If there are political and diplomatic issues in your community which your new team member may be affected by, let them know. If you have a chat or mailing list, help them do the setup (yes, I had never used IRC before and had no clue how to do those things). When they agree, show them how GitHub or your specific code base service works and how they may be able to use it for their work.
e.g. an email to all your community members introducing your new member, explaining what they’ll work on and asking everyone to support them. Give everyone the chance to give them a warm welcome and show their presence is being appreciated. (19)
your new team member. There should be at least one person (better two or more) who are always (!) addressable and who will especially in their first months always take care of them. We are all humans, and as humans, we tend to feel insecure when we’re new to a group, and your new community member may also have the alien-feeling I described. Thus, this is a time in which they need special support, help and caring. Ensure that these people stay in close contact with them, are there for any questions and do their best to ensure they feel safe and never lonely or helpless. Part of this is: ->
do. Remember the main reason you got them on board? Introduce them to their new job. Show them what needs to be done and show them other projects that did similar things so they get some orientation.
you hired them), so trust them and their decisions. They know what they do. Encourage them, be there whenever they got any questions. Ask how they’re doing when you don’t hear from them. Always keep in mind that it’s not about the contributions but about the people. – And, finally, when they’re done:
crucial point we already talked about, the point where it is shown how much your community and you really support this entire endeavor (and an endeavor it is). Of course there’s room for constructive feedback and criticism, but once those items are fixed, don’t hesitate and implement your new team member’s work. Really. Don’t hesitate. And always remember to -> give cookies.
encourage your community to do the same. Point them out what a great job your new team member has done, let them or someone else write about what they worked on and -> make them and their work visible to others ! // img source: http://voices.suntimes.com/wp-content/uploads/2013/08/Cookiemonster2_FB.jpg
share their experience and attract other new committers to your community. Keep up your work and keep on searching more non-coding experts that support your community as well. So that hopefully, one day, we won’t feel like aliens anymore. And one day, we, those former “non-coding” experts become ->
lenar
yng87
furuton
koujikozaki
cyberagentdevelopers
kazushi_ohata
ufried
shuzon
ikumatadokoro
takesection
lauravandoore
garrettdimon
paulrobertlloyd
geeforr
bryan
hannesfritz
shpigford
holman
csswizardry
reverentgeek
sferik
jcasabona
