Flourishing FLOSS: Making Your Project Successful by Anna Ossowski

Alright everyone, it's 3. 10, so I'm going to get started. Um I hope you've been enjoying DjangoCon so far. This is my third time. that I get to speak at Jingacon and I'm super honored. Um I don't know if you had a chance to see Alicia's keynote this morning. I love the keynote. I got very teary-eyed and it reminded me of why I love this community so much. So thank you for being here and listening to me today. I'm here today to talk to you all about making your open source project successful. First I would like to introduce myself. A lot of you might know me but some might not. My name's Anna. I'm from Germany. I have a degree in English and Catholic theology.

That's why you saw Pope Francis and William Shakespeare right here. But about three years ago I got involved in Python and Django and started teaching myself coding and I noticed that I like code but I also really like people. So I kinda like working at the intersection of both and I currently work at Elastic and Developer Relations and I just started there last month so that's That's pretty cool. In my free time, I'm also involved in a few other tech-related things. I'm PyCon US Open Space as Chair, I'm DjangoCon Diversity Chair, and I'm one of the leaders of the Pi Ladies Remote Group. And to start with my talk, first of all, I have to give a big shout out to Tom Christie. Uh Tom Christie is the creator of Django

Rush Framework. Some of you may know him, some of you may know him may use Jjango Rest Framework. I had the chance to work with him as the community and operations manager of Jjango Rest Framework, and most of what I know about open source comes from my time. on working with Tom. Um and Tom is one of the most humble, brilliant, and kind people I know. And I'm sad that he can't be here today. But I just wanted to give him a big shout out. Before I start, I would like to do a small informal survey. Who of you contribute to open source? Awesome. Who of you are open source project maintainers? Okay, couple. And who of you have not contributed yet but are thinking about contributing to open source?

source. Okay, you should definitely come to the sprints if you're interested in contributing. Okay, awesome, cool. Before I start, I would like to first take a little bit of time to explain what open source is. I don't know about you but when I when people ask me what do you do, I never know how to explain it. Like I said, I just started a new job and my sister, who's usually not very interested in what I do, just asked me what what do you actually do for work? And I just sent her my job description because I had no idea how to explain it to her. She's an English teacher, so she's not a techie person. So I found this definition which is a little bit on the longer side, please bear with me. But it's really good, so I would like to read it to you. Source code refers to the code written to operate nearly anything

Your computer, software, your telephone, an ATM machine, even many of your household appliances have software written for them that allows them to operate and software that allows you to interact with those devices. When code is open source, it means that anyone is able to read those lines of code, reuse that code, and in some cases modify the code to improve upon it. What you're permitted to do with a code depends on the software license under which it was released. For the vast majority of the history of software, this code was Never seen by anyone except those who wrote it, it was generally considered proprietary and part of a company's or organization's intellectual property. This was a very long definition, so to sum this up, open source means that code is publicly accessible, it is reusable depending on the license, and it is modifiable depending on the license.

And now we know what open source means, but what exactly are open source software communities? I found another definition which is again a little bit on the longer side, but I promise this is the last definition. And then we'll move on to different things. Because the code is freely viewable and available to modify in most cases, it provides an excellent base on which people can write new or add on to existing projects. But like most things in life, when it comes to getting things done, it is far more effective to work in groups. The power of many is far greater than the power of one. An open source software community is made up of anywhere from a handful of people to hundreds or even thousands of people who are working collectively to improve the functionality of a piece of software.

The contributors and users in this community do anything from answering questions to writing code to working on documentation, finding and fixing bugs, and soliciting or providing feedback about how the software works. Um do any of you have any guesses on where these definitions are from? Any guesses? It's a little bit of a trick question. They're actually from Elastic's company internal documentation. We do a lot of open source at Elastic. And Elastic kindly offered to pay for my trip here, so I have to mention That was kind of the deal. But um I actually think those definitions are really good. Um if you have any other shorter definitions that you really like that explain to someone not technical what open source

source is, please send them my way. I would love to read them. And when we think open source, most of us think code. And code definitely is an important part of open source source projects, but it's not the only part. You can have the most amazing part code of the world, but if you neglect all these other parts that you can can see on my slide, then your project is likely to fail. Your project may need funding. Your project has a community that needs to be be nurtured, your project needs marketing, your project needs good documentation , your project needs people to work on ticket triage. All of these things have nothing to do with writing code, but they're as important as working on code. And you're gonna hear me say that a lot because it's really important to me. We tend to praise the people who write code, but we don't praise the people who write the dogs or we don't

praise the people who work on social media, but those all those components interact with each other and are equally important. More about that later. Here are a couple examples of open source projects that I like, just to clarify this a little bit. Django is open source, so is DjangArest Framework, Python is also open source, and Elasticsearch is actually open source as well. You will see that a lot of tech companies out there either maintain their own open source projects or use other open source projects for their work. Um and some companies out there pretty much use op like we said, open source code is free code that is out there to reuse depending on the license. So you could say that some companies make money off of using free projects

because other people spend free time on maintaining And developing these projects. So let's get down to the nitty-gritty right away. It's important for open source users, especially for companies using open source projects, to give back to open source users. And this can be done by having the developers work on code and documentation during their work hours, but oftentimes that's not enough. Most open source projects need money. Neat and Tom Christie um does a lot of awesome things with Django Rest framework and Tom Christie is actually able to work on Django Rest Framework fold time as his job because he has established a very successful fundraising model. Most of my time at Django Rest Framework when I worked there was actually spent on fundraising. Heather Luna, our sponsorship chair here at DjangoCon, wrote a really awesome blog post on her personal blog, kind of explaining her journey about into DjangoCon.

And she said that it takes about 70 emails to get one or two sponsors. So you can say that, see that fundraising is a lot of work. Um but if you think about it, it's a win-win situation. Tom gets to do what he loves, he gets to work on Django Rest framework full-time, and the people using Django Rest framework donate a little bit of money back. This ranges from $15 to $400 a month. If the company you use for you work for uses an open source project, I can only encourage you to talk to them to give back to open source. Don't only think about it as giving back though, also think about it as giving forward. By supporting open source projects financially, you make sure that their future development and maintenance is

sustained. Imagine that you use an open source project for your product or your company and you heavily rely on it. Imagine what would happen if that project wasn't maintained anymore. No bug fixes, no one would care about your issues, there weren't any new features. There it's likely that this would cause a huge issue for your product for your project or product at one point So next time that you hesitate about think hesitate giving back to open source, create that scenario in your head. And if it makes you nervous, then maybe you should give a little bit of money. But also as an open source project maintainer, don't just take someone's money. You need to offer them something valuable in return. Build real relationships with sponsors

and determine ways how both of you can benefit from this relationship. Like I said, fundraising is hard work. If you have questions about fundraising, if you would like to hear more about it, I don't have time to go into detail here, then please find me after my talk or reach out to Tom Christie. We're both super happy to talk to you more about that. One way you can offer sponsors something valuable in return is simply to listen to them. Listen to them and their needs and act upon them. But also listen to your users and contributors. Listen to their feedback and input and also make them feel heard. Listening can sometimes be uncomfortable because you may hear things you don't want to hear. But if you ask people for feedback and then you don't do anything about it, then you may as well not ask

I was involved with an open source project where we'd you where we'd ask people for feedback, but in the end we would only do what the core contributors wanted to do and that led to people getting frustrated and not contributing anymore and the project failed in the end. It still exists, but it's not very successful anymore. So if you don't listen to your contributors, it's likely that your project will fail. Also, establish good communication systems. Answer people's questions in Slack or IRC, discuss GitHub, Twitter, anywhere. Don't ignore what they have to say. Good communication s systems are especially important if you want to cultivate new contributors. And you will need they will need a way to reach out. It's likely that they'll have questions.

So give them a way that they can reach you. If I want to contribute to a project and I get stuck And there's no one that I can contact, it's likely that I will move on to a different project which has a better support system. Also be transparent with your contributors. Let them know what you're working on currently, what you'll be working on in the future. People like to know what's going on. Uh Tom Christie publishes monthly progress reports in which he explains what he's working on, what he He's planning on working on and he also does a really good job in breaking down finances and letting people know how he's spending his money. Transparency is key. Also, don't forget to say thank you. Don't only thank your core contributors, thank everyone who contributes.

There are so many ways you can do that. You can send people cards, you can do happiness packages, you can do shout-outs on Twitter, you can send them special stickers. All of us love stickers. Or you can thank people in the release notes. And we often tend to thank code contributors in our release notes, but we don't think people who do marketing or ticket triage or documentation So we mean next time you have a big release, thank those people in your release notes as well. It's such a small thing to do, but it has such a big great impact on those people. Their work and efforts matter as much as those people who contribute code. Which leads me to the next point. Documentation is important, marketing is important, small bug fixes are important, ticker

triage is important, operate operational work is important. Like I said, there are so many components of an open source project that we take for granted that really matter. Let's walk through all of them real quick. Without documentation, no one would know how to use your project. And you may think that I'm exaggerating, but think about it. If there's no installation documentation or really any kind of documentation , then the only person who knows how to use your project is you or maybe a couple of other contributors who have contributed a lot of code. And I don't know about you, but if I stumble across a project that I want to try out, but the documentation sucks, then I will move on to a different project. After 30 minutes because I will get frustrated and I just don't want to put the time into it.

If people don't put the time into documentation, then why would I put my time into contributing to their project or even using their project? Um sometimes a picture is worth so much more than a thousand words, so consider putting pictures and screenshots into your documentation, maybe and greet me maybe even a gif, and I don't mean like those funny gifts, but gifts of you writing code in your console can be really helpful, especially for people just getting started. I'm a very visual learner, so I always appreciate any pictures. If a project isn't well documented, then it way may as well not exist. And as an open source project maintainer, you can really steer your contributors towards documentation. You can say, hey, if you want to

submit a patch, I need documentation to come with it. If it doesn't, then I won't accept your patch. Or you could encourage your contributors to write the documentation. first and really think about the features and how to implement them and then write the code in the next step, like a documentation-driven approach to coding. Next up is marketing. Without marketing, no one would know about your project. How did all of you find out about DjangoCon? Was it Twitter, mailing list, you just knew about it? So likely you found out about it because there's marketing. Because Rebecca, our communications chair, put a lot of work into our Twitter. And the same needs to happen for an open source project.

Your open source project needs a website that's well designed and easy to navigate but not cluttered. Your project needs an active Twitter account. Your project needs a mailing list. Your project needs a blog. And I don't know if you've ever run a social media account, but it's a lot of work. You need to figure out what you put into a hundred forty character limit that's informative but also funny. You need to um use the right hashtags, you need to tweet at the right right time to reach all the different time zones. So it's really not an easy job. Sometimes people think that people who work on social media they just play all day. But it's really hard work. Your project needs people to evangelize. If you've ever prepared a conference talk, you know that it's a lot of work. And it's likely that you won't be able to attend all the conferences

friends as you would like to. So you need other people to help with that. You need people to help you with sprint organization and promotion. Sprints are so important for open source projects. I don't know if you've heard of the Beeware project by Russell Keith McGee. They do a really awesome job at Sprints. Russell gives away those challenge coins which everyone gets that makes their first contribution. To beware. I'm sure they'll be doing that again today, on Thursday and Friday. So you will see people walking around with challenge coins or you'll see them tweet about them. I can highly encourage you to contribute. to BeWare or talk to Russell or Philip who's sitting right there who contributes to BeWare or Katie McLovelin and find out more about BeWare Next we have ticket triage. If there weren't people who worked on

ticket triage, then bugs wouldn't get fixed. Or it would take significant Tickets need to be assessed in or in according to urgency and difficulty. They need to be assigned labels. And oftentimes you also need to communicate with the people who create the tickets and clarify what exactly Bugs need to be reprodu reproduced and so on. Also, as an open source project maintainer, when it comes to ticket triage, you need to to say no a lot. Actually you need to say no more than you need to say yes. When you need to s when you see a new issue and you already know that you won't be working on it in the next six to 12 months, then it's sometimes better to say, hey, thank you for this ticket.

I appreciate it. It's an interesting issue, but it's not a priority for me right now. And you may think this is rude, but if you have issues sitting in your GitHub repository that are years old, then people will think that you just don't care. Sometimes it's better to put up front why you won't ex why you want to close this issue and just communicate well with people. Also, you don't want to clutter up your GitHub repository with a bunch of issues which you think are not necessary. So either close them or if it's something that you don't have time to work on personally but you would uh appreciate a patch, then ask the person to to make a pull request. Bugs are a little bit different, but again, if you know that you won't be working on fixing a bug in the next

six to twelve months, then maybe close the issue and document it as a known limitation rather than keeping it open for forever. And in general you should treat issues and pull requests like a conversation with a maintainer. Tom Christie wrote a really good article on sustainable open source management. It's a really quick five-minute read. I can highly recommend that you can you go and read it. Don't worry about writing down the link right now. I'm going to be tweeting out the link to my slides after my talk Um as you've heard me talking about open source projects, you may have noticed that I never talked about people doing this alone. I always talked about groups of people or commute whole communities of people. Nobody succeeds alone. If you think about your own um coding journey, you

probably had mentors, you probably had people who helped you, co-workers, friends. You didn't do this all alone, most likely. And open source projects are also team and community efforts. You certainly can do this all by yourself, but I wouldn't recommend it because it's not very sustainable and it's likely that you will burn. out at some point. Community is key. Like I said, I a lot of people about Django love the community. I'm here for the community. I haven't touched Django Code in probably a whole year or longer. And community is work. You need people to cultivate new contributors. You need to establish and maintain communication channels. Without a good community, your project won't be successful.

So you really need to figure out how to nurture your community. because most likely your contributions will come out of the community and people will only contribute if they feel accepted and appreciated and like they're getting something out of this. You may have heard Brad Cannon's famous quote, I came for the language, I stayed for the community. He said this about the Python community. Like I said, I feel that way about the Django community. I know that a lot of you do as well. What it comes down to is always the community. And when we talk community, we also need to talk about diversity because diversity matters. DjangoCon and other conferences put a lot of work into diversity. We have a dedicated diversity chair, which is me. PyCon has a diversity chair.

Other conferences do as well. Your project will never reach its full potential if you don't have a diverse set of contributors. And with diversity, I mean more than just women. I mean people of different ethnicities, people of different age groups, people of different sexual orientations, people of different educational backgrounds, and people of different skill levels and expertise. Open source projects need contributions of all from people of all skill levels and expertise. You don't only need the experienced coder. If we keep only nurturing those people who already are superstar coders, then at one point those people will go away, but we don't have a second generation who can uh come after them. So if you think it's a waste of time to mentor people, it's really not

because you're nurturing the next generation who at one point will open will maintain your open source project. I'll give you another example. The pr people who write the docs usually are the people who use the code the most and are most familiar with it This oftentimes leads to docs being written on a very high level, which means that a beginner coder or an intermediate coder might not be able to understand it or someone can Coming from a different language might not be able to understand it. And if people at this level don't understand your documentation, then you need to go and fix it. But um if you wrote the documentation yourself, then it's likely that you're blind to these other people who are having issues with it. So you need people of different skill levels and expertise to go and read your documentation and tell you how you can improve upon it

Even if you don't write code or aren't technical, you can still contribute. I spend a lot of time talking about how open source projects consist of so much more than code. All of us have different talents. Some of us are really good event organizers, some of us love social media. Like I said, I haven't touched Django code in a long time. but I'm really passionate about diversity work, so I helped as the diversity chair. I'll give you two other examples. Ashley McNamara is big in the Go community and she she's but she's also a very talented artist. And she created a website called Gopher Sme where you can create a Gopher version of yourself. I would highly I would recommend that you try it out. It's really cool. Really cute. And she also creates these stickers.

All of us love stickers, but not a lot of us have a talent to design stickers. So this is the talent she had, which she brought into the community, which has nothing to do with code per se, but which was still important. If you know Adrian Lowe, she's not here right now, but she's flying in tomorrow. Um Adrian Lowe used to be a chef before she uh became a programmer and she tends to bring cookies to conferences because everyone loves cookies and Adrian likes to bake vegan cookies. So she brings those cookies. And they have nothing to do with programming, but the community loves them. So I'm gonna take a little water break for 30 seconds, and I would like all of you to write down one talent that you have that has nothing to do with coding, which you could

use to bring into our community. Just one. Some people think that you have to submit a code, uh a patch of fifty to a hundred lines of code for it to matter. And that's not wrong. My first um open source contribution was going through the Django Girls tutorial and correcting grammatical mistakes and um other little language mistakes. And you may think that didn't matter, but it actually did because it made the tutorial easier to read for others. So you don't have to contribute whole patches of code in order to make a difference and in order to be able to and contribute to open source. As an open source project maintainer, you need to be aware of this. Put in your REATME that you're open to new contributors, that you're open to first-time contributors. Contributors, create first-hammers-only

labels, label your issues according to difficulty so people can pick less difficult ones if you if they're contributing for the first time. Also, put in your contact information so people can reach out to you. Offer a mentorship. For DjangoCon, we have a special mentorship speaker mentor program and you may have noticed that we have only that we already have that we almost have fifty percent women speakers which is really awesome and I attribute a lot of that success to our mentorship program. Mentorship really matters. As an open source maintainer, ask your contributors if they want to be mentors. Your mentors need to need to be diverse because some women only want to be mentored by other women. So you need to have

a set of mentors that also matches your set of contributors. Pay it forward, give more than you receive. It's most likely that all of you received some help or mentorship, so pay it forward and help other people. I gave a whole talk on mentorship and there's a video which you can find here and also a transcript which you can find. Um if you have any questions about mentorship or open source I'll be around and I would love to chat about it. As an open source project maintainer, if you're looking for new contributors, look among your users because it's likely that those people um who use your project are want to give back and learn more about it. But also if you're looking to make your first open source contribution, there were a couple of people here who haven't made an open source contribution yet.

Look at the projects that you already use. Don't look super far, just look at something that you use that you like and see how you can get involved. Like I said, my first contribution I made to the Django Girls tutorial because I was heavily involved as a Django Girls organizer, so it made sense. Last but not least, your project needs a code of conduct. Um, you may think your project doesn't need a code of conduct because all of your contributors are super nice, and they may be, but your project still needs a code of code of conduct. Be prepared. Make sure that your project is a safe place for everyone to contribute. And you may actually lose a couple of contributors or potential contributors if your project Project does not have a code of conduct because pep some people won't contribute if there's no COC.

But a code of conduct only matters only is Also needs to be enforced. If you have a COC but you don't do anything about it when people complain, then it's really kind of useless You need to be willing to call people out for bad behavior. Don't let the trolls win. Sasha Romain gave a really good talk about code of conduct just before lunch. If you didn't catch their talk, I can highly recommend that you go and watch it. I know they're also happy to chat with you about code of conduct. So am I, and so are other people of the Django COC community that are here. If your project does not have a code of conduct, please do me a favor and implement one today. You don't need to write your own. Coraline Ada Aimkey did so for you, and it's called the Contributor Covenant, and it's online and it's free and it's available for you to use.

It's been implemented into thousands of open source projects and it's been translated into many different languages. And if you do implement a code of conduct, please tweet me. I would love to hear about it. One more thing. Like I said, I'm a co-organizer for Pyladies Remote. We're always for looking for new teachers If you're interested in teaching a class for us, our classes are taught as remote online screencasts. They range from an hour to three hours, and it's pretty cool because you can wear your pajamas pants and no one can see. It doesn't have to do anything with Python, anything tech related. We're super open to any topic. Reach out to us at remote at pylades. com.

We also have a website, which all with all of our previous classes, the website is currently down. We're experiencing some issues with Heroku. If any of you would like to help me bring back the website, find me during the sprints. I'd love to I'd love some help with that. You can also follow us on Twitter. Our next class is August 26th. Katie will be talking about collaboration and code review and GitHub. Katie is also giving a talk about the same topic today at 5 p. m. You all should come if you can. And I also brought some stickers of this logo and some Rainbow Pie Lady stickers from PyCon with me. So if you'd like a sticker, please come find me after my talk and I'd love to gift one to you. Um that's all I have for you today. I'm also out of time. So thank you so much for being here and listening.

I appreciate it.