Flourishing FLOSS: Making Your Project Successful
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 4 | |
| Number of Parts | 48 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/33187 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DjangoCon US 20174 / 48
2
5
6
14
16
23
26
30
31
32
34
39
43
48
00:00
Elasticity (physics)Open sourceSource codeCodeSoftwareVirtual machineAsynchronous Transfer ModeComputerLine (geometry)Personal digital assistantDialectGroup actionFunction (mathematics)FeedbackOpen setSoftware frameworkCodeProjective planeSource codeOpen setBlogSoftwareBitEmailTheory of everythingBlock (periodic table)Endliche ModelltheorieProcess (computing)Existential quantificationSoftware developerMultiplication signSoftware maintenanceOpen sourceDisk read-and-write headPoint (geometry)Product (business)Coefficient of determinationNetwork topologySlide ruleMereologyFeedbackSoftware bugPower (physics)Functional (mathematics)Video gameGroup actionCASE <Informatik>Right angleFreewareDigital mediaContent (media)Elasticity (physics)Software frameworkConnectivity (graph theory)Set (mathematics)Archaeological field surveyData managementRemote procedure callSpacetimeTheory of relativityDegree (graph theory)Basis <Mathematik>SummierbarkeitCategory of beingSelf-organizationLine (geometry)Descriptive statisticsVirtual machineOperator (mathematics)MultilaterationInheritance (object-oriented programming)Computer animation
09:48
TelecommunicationSoftware bugOpen sourceData managementProjective planeCodePlastikkartePoint (geometry)Core dumpProcess (computing)Slide ruleTraffic reportingArithmetic progressionPhysical systemTelecommunicationoutputSoftware bugTime zoneEmailElectronic mailing listSoftware testingPatch (Unix)Video game consoleWordMultiplication signTwitterGoodness of fitFeedbackReal numberLink (knot theory)Data conversionLimit (category theory)Repository (publishing)Different (Kate Ryan album)Software maintenanceOrder (biology)Group actionData managementOpen sourceSelf-organizationDigital mediaRight angleWebsiteConnectivity (graph theory)Reading (process)Closed setDeterminantBuildingComputer animation
19:37
Formal languageOpen sourceLevel (video gaming)VideoconferencingCodeDifferent (Kate Ryan album)Set (mathematics)Type theoryProcedural programmingState of matterCanonical ensembleGenderLevel (video gaming)Point (geometry)Electric generatorProjective planeWebsiteProblemorientierte ProgrammierspracheOrientation (vector space)Multiplication signTwitterRemote procedure callThermal conductivityMedical imagingSystem callGoodness of fitVector potentialGraph coloringSelf-organizationShift operatorCollaborationismSocial classOnline helpComa BerenicesOpen sourceComputer programmingAttribute grammarGroup actionFormal languageInformationSoftware maintenance1 (number)CodeOrder (biology)Patch (Unix)VideoconferencingWordLine (geometry)Web pageMetropolitan area networkProgrammer (hardware)Revision controlDigital mediaEvent horizonTelecommunication2 (number)Control flowWater vaporHTTP cookiePhysical systemoutputInheritance (object-oriented programming)Open setWritingComputer animation
29:25
XML
Transcript: English(auto-generated)
00:16
It's 3.10, so I'm going to get started.
00:23
I hope you've been enjoying JengaCon so far. This is my third time that I get to speak at JengaCon, and I'm super honored. 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.
00:40
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.
01:01
That's why you saw Pope Francis and William Shakespeare right here. About three years ago, I got involved in Python and Django and started to teach myself coding. I noticed that I like code, but I also really like people. I kind of like working at the intersection of both. I currently work at Elastic and Developer Relations.
01:21
I just started there last month, so that's pretty cool. In my free time, I'm also involved in a few other tech-related things. I'm PyCon US Open Spaces Chair. I'm DjangoCon Diversity Chair. I'm one of the leaders of the PyLadies Remote Group. To start off my talk, first of all, I have to give a big shout-out to Tom Christie.
01:44
Tom Christie is the creator of Django REST Framework. Some of you may know him. Some of you may use Django REST Framework. I had the chance to work with him as the Community and Operations Manager of Django REST Framework. Most of what I know about open source comes from my time on working with Tom.
02:02
Tom is one of the most humble, brilliant, and kind people I know. 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.
02:21
Who of you are open source project maintainers? Okay, a couple. Who of you have not contributed yet but are thinking about contributing to open 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.
02:44
I don't know about you, but 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 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.
03:03
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, and ATM machine,
03:22
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.
03:42
What you're permitted to do with the 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 organization's intellectual property.
04:02
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. Now we know what open source means, but what exactly are open source software communities?
04:21
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.
04:47
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.
05:01
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. Do any of you have any guesses on where these definitions are from? Any guesses?
05:22
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 them. That was kind of the deal. But I actually think those definitions are really good.
05:42
If you have any other shorter definitions that you really like, that explain to someone not technical what open source is, please send them my way. I would love to read them. When we think open source, most of us think code. And code definitely is an important part of open source projects. But it's not the only part.
06:01
You can have the most amazing code of the world, but if you neglect all these other parts that you 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 nurtured. Your project needs marketing. Your project needs good documentation.
06:20
Your project needs people to work on ticket triage. All of these things have nothing to do with writing code, but they are as important as working on code. And you're going to 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 docs, or we don't praise the people who work on social media,
06:41
but 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 Django REST framework. Python is also open source, and Elasticsearch is actually open source as well.
07:01
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. And some companies out there pretty much use, like we said, open source code is free code that is out there to reuse, depending on the license.
07:21
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,
07:40
to give back to open source. 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. Tom Christie does a lot of awesome things with Django REST framework, and Tom Christie is actually able to work on Django REST framework full time as his job,
08:01
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 into DjangoCon,
08:20
and she said that it takes about 70 emails to get one or two sponsors. So you can see that fundraising is a lot of work. 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.
08:41
This ranges from $15 to $400 a month. If the company 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.
09:01
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,
09:22
there weren't any new features. It's likely that this would cause a huge issue for your project or product at one point. So next time that you 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.
09:43
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.
10:02
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.
10:22
Listen to them and their needs, and act upon it. 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,
10:42
then you may as well not ask. I was involved with an open source project, 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.
11:02
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, Disqus, GitHub, Twitter, anywhere. Don't ignore what they have to say. Good communication systems are especially important
11:23
if you want to cultivate new contributors, and 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
11:40
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. Tom Christie publishes monthly progress reports, in which he explains what he's working on, what he's planning on working on, and he also does a really good job in breaking down finances
12:03
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,
12:22
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 thank people who do marketing or take a triage or documentation. So maybe next time you have a big release,
12:40
thank those people in your release notes as well. It's such a small thing to do, but it has such a 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,
13:00
small bug fixes are important, ticket triage is important, 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,
13:21
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
13:41
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?
14:01
Sometimes a picture is worth so much more than a thousand words, so consider putting pictures and screenshots into your documentation. And greet me, maybe even a gif, and I don't mean like those funny gifs, but gifs 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.
14:23
If a project isn't well documented, then it 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.
14:41
Or you can 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.
15:00
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.
15:22
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
15:41
into a 140-character limit that's informative but also funny. You need to use the right hashtags. You need to tweet at the right time or 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.
16:02
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 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 Bewear Project
16:21
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 Bewear. 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.
16:40
I can highly encourage you to contribute to Bewear or talk to Russell or Philip, who's sitting right there, who contributes to Bewear, or Katie McLovlin, and find out more about Bewear. 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 significantly longer.
17:01
Tickets need to be assessed according to urgency and difficulty. They need to be assigned labels. Oftentimes, you also need to communicate with the people who create the tickets and clarify what exactly they meant, what other problems. Bugs need to be reproduced, and so on.
17:21
Also, as an open-source project maintainer, when it comes to ticket triage, you need to say no a lot. Actually, you need to say no more than you need to say yes. 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.
17:42
I appreciate it. It's an interesting issue, but it's not a priority for me right now. 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. So sometimes it's better to put up front why you want to close this issue
18:00
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 appreciate a patch, then ask the person to make a pull request.
18:21
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 12 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.
18:41
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 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. As you've heard me talking about open source projects, you may have noticed that I never talked about
19:01
people doing this alone. I always talked about groups of people or whole communities of people. Nobody succeeds alone. If you think about your own 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.
19:20
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, a lot of people about Django love the community. I'm here for the community.
19:41
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
20:01
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 Brett Cannon's famous quote, I came for the language. I stayed for the community. He said this about the Python community.
20:22
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.
20:42
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,
21:01
people of different educational backgrounds and people of different skill levels and expertise. Open source projects need contributions from people of all skill levels and expertise. You don't only need the experienced coders. If we keep only nurturing those people who already are superstar coders,
21:20
then at one point, those people will go away but we don't have a second generation who can 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 maintain your open source project. I'll give you another example. The people who write the docs,
21:40
usually other 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 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.
22:01
But 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,
22:22
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
22:42
so I helped as the diversity chair. I'll give you two other examples. Ashley McNamara is big in the Go community, but she's also a very talented artist, and she created a website called Go4RiseMe where you can create a Go4 version of yourself. I would recommend that you try it out.
23:01
It's 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 Adrienne Lowe, she's not here right now, but she's flying in tomorrow.
23:21
Adrienne Lowe used to be a chef before she became a programmer, and she tends to bring cookies to conferences because everyone loves cookies, and Adrienne 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 going to take a little water break for 30 seconds,
23:42
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, a patch of 50 to 100 lines of code for it to matter,
24:01
and that's not wrong. My first open source contribution was going through the Django Girls tutorial and correcting grammatical mistakes and other little language mistakes. 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
24:20
in order to make a difference in order to be able to contribute to open source. As an open source project maintainer, you need to be aware of this. Put in your readme that you're open to new contributors, that you're open to first-time contributors. Create first-timers-only labels. Label your issues according to difficulties so people can pick the last difficult ones
24:43
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 speaker mentor program, and you may have noticed that we almost have 50% women speakers,
25:01
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 be diverse because some women only want to be mentored by other women, so you need to have a set of mentors
25:22
that also matches your set of contributors. Pay it forward. Give more than you received. 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.
25:43
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 who use your project want to give back
26:03
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,
26:21
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. 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 conduct.
26:42
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 does not have a code of conduct because some people won't contribute if there's no COC. But a code of conduct only matters,
27:01
only 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,
27:21
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 in 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.
27:41
You don't need to write your own. Coraline Ada Amke 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.
28:00
I would love to hear about it. One more thing. Like I said, I'm a co-organizer for PyLadies Remote. We're always 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
28:21
because you can wear your pajama 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 remotetpyladies.com We also have a website with all of our previous classes. The website is currently down.
28:40
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 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 on GitHub. Katie is also giving a talk
29:00
about the same topic today at 5 p.m. You all should come if you can. I also brought some stickers of this logo and some rainbow PyLadies stickers from PyCon with me. If you'd like a sticker, please come find me after my talk. I'd love to gift one to you. That's all I have for you today. I'm also out of time. Thank you so much for being here and listening.
29:21
I appreciate it.