up.front Berlin • April 2014 Confessions of an Alien on 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. 

@ffffux I’m a writer and photographer specializing in marketing, communications and project management in tech. I’m currently working on Open Source projects in full time, mainly on Hoodie and CouchDB. And: 

I am Alien I am an alien in Open Source (or at least, I've often felt like one). Because I don't write code. 

Look at my code, my code is amazing Code is 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: 

Where do you go to, my lovely? What do you 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: 

Coding Oh yes, we've talked about this. Code is important. But there's sooooo much more to do … like: 

Coding is not everything • writing about your project • 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: 

Who can do it? Who can do it? – Thing 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. 

Developers developing developments Developers are experts in their fields, like 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., –> 

Why acquire experts? specializing in writing - and still not able to write even one single line of source code? Why should you aim to work with them? 

1. focus 1. Experts enable developers to focus on coding while shipping other, highly relevant things. 

1. focus 2. perspective 2. They bring a different perspective. 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). 

1. focus 2. perspective 3. help 3. They help with things you need but may not even have realized or thought about before. 

1. focus 2. perspective 3. help 4. improve 4. They help you improve. – By providing better content, reaching more people, getting more feedback in. 

1. focus 2. perspective 3. help 4. improve 5. because 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. 

WINS The Open Source Community that embraces designers, writers and other experts most, The open source community that embraces designers, writers, other people most, wins. A theory. /// There are -> 

How to non-coding experts? … two parts of to dos related with the question how to acquire “non-coding” experts for Open Source projects. The first track is about the -> 

Cultural Se!ings # is about the cultural settings which are required to attract them, … and the first topic there is … -> 

Think! Awareness. 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, 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. 

!important Consider opening your project to “non-coding” experts important. The 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. 

Is it necessary to work on more than code? The 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 

Acceptance & diversity acceptance and diversity. As we all know, 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 -> 

The appreciation of diversity and variety … acceptance and appreciation of diversity and variety in general. It is about the question 

What and who is being valued in your project? … question what AND WHO is being valued in your project. -> 

What and who is being valued in your project? Open 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 

Support the support your new experts will need. In most 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. // -> 

Don’t care for contributors. Furthering Open Source projects 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? 

Don’t care for contributors. Care for people. This, which may 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. 

Every person who supports our project, no matter if just as a supporter or contributor, is a gift. We should them accordingly. —- What does this practically mean? Well, it’s pretty simple: it means -> 

Get in touch and stay in touch % getting in touch and staying in touch. Don’t value contributions. Value people. ——- The steps pointed out until here seem to be pretty obvious. 

The Elephant in the Room Thus, all of them are 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, 

Practically let’s get to the second part: the practical steps. 

I don’t have a plan. I live from snack to 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 

Know that feel Understand what it’s like to not be 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. 

Call me by my name So, if you want those 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 

Recruitment Marketing Recruitment Marketing -> 

Recruitment Marketing \o/ Yeeeeeeeah! Everybody loves that term! … Not. 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: 

1. what you need what you need 

1. what you need 2. who you address who you address 

1. what you need 2. who you address 3. what they need what they need 

1. what you need 2. who you address 3. what they need 4. what ma!ers to them what matters to them 

1. what you need 2. who you address 3. what 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: 

Core Values 1. Open Source 2. Open Source people 3. 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, 

Search + Find figure out where to find the experts you need. Your two main premises here should be: 

1. Good targeting ◎ 1. good targeting - always keep in mind who you’re searching for 

2. low entry barriers ) 2. keeping entry barriers low. 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: 

1. write 1. Write about it. Describe your project. Keep 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. 

1. write 2. make a website 2. 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 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. 

1. write 2. make a website 3. use networks 3. 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. :) 

1. write 2. make a website 3. use networks 4. 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, -> 

1. write 2. make a website 3. use networks 4. 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. 

Onboarding It is said that it takes 90 days until 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 

+ Prepare really well for Onboarding really well for creating a good onboarding-experience for them, and -> here’s why: 

The What? The How? The Huh? 1. being a newbie 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 … -> 

an alien (as I did). ALWAYS keep this in mind. 

Meow? In addition, there’s one more thing which is special 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 

1. Code of Conduct 1. a code of conduct, that 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. 

2. Safe Space 2. create a safe space. It depends 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. 

" 3. Surroundings 3. introduce them to the surroundings. Explain 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. 

✋ 4. People 4. introduce them to the people. Send 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) 

. 5. Who cares? 5. name people who directly support 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: -> 

/ 6. The Job 6. give your expert things to 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. 

0 7. Let them go for it 7. Let them do their job. And whilst doing so, -> 

1 8. Trust 8. Trust them. They’re experts (that’s why 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: 

2 9. Implement it! 9. Implement it! This is the 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. 

Cookies ma!er Give them your personal feedback and praise, and 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 

Create visibility 3 -> visible to others. Encourage them to 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 -> 

Core Commi!ers in Open Source Projects Core Committers in your Open Source project. 

Thank you 

@ffffux Any questions?