 Good afternoon. Thank you for having me here today. I'm very excited to be up here on the stage talking about a subject that's very very dear to me close to my heart And it's not going to be why isn't the rest API merged into Korea that it's been covered at depth today I think now today's talk is about the emotional roller coaster that you experience in maintaining an open-source project Specifically the emotional highs and lows of publishing code on github So I want to start by first taking a look at the bigger picture the famous guy Invented a browser Once said software is eating the world I'd actually like to posit that it's open-source software that's eating the world and I have a couple pieces of data to back it up First a conclusion from the 2015 future of open-source survey 78% of respondents said that their companies run all or part of its operations on open-source software and 66% said that their company creates software for customers built on open-source Notably this statistic has nearly doubled since 2010. So there's a big thing happening and it's happening really quick Similarly Nadia egg ball who is doing was some really great research right now into the economics of open-source Calculated that open source was worth at least one Sorry a hundred and forty three million of Instagram's one billion dollar acquisition One tenth over one tenth of Instagram's one billion dollar acquisition was because of open source now There's a couple reasons why I think a Couple reasons I think are driving the Cambrian explosion of open-source usage first open source is free to use Which means that businesses get to spend money on people instead of software licenses There's now a critical mass of reliable open-source components to accelerate your product's time to market open-source produces quantitatively better software. This is proven in studies and Dear to my heart open source permits companies to collaborate on common problems without complicated business agreements So it's win win win win win all across the board. So an open source is pretty huge But what is open source exactly? Well, we all know open source to be its license It's permissive license that grants certain freedoms to the end user In fact it grants so many freedoms to the end user that end user is not obligated to give back to your software They can just use your software as much as they want and never Contribute a bug report nickel or dime towards it. However, when people use open source the term open source today They're probably referring to building and collaborating in public In fact, they may not care about the license at all on GitHub over 80% of the projects don't have an explicit license So why are so many people involved in open source? Well, there's the economic driver all the business reasons that I just covered It's also very joyful to get to work with the people of variety of cultures and backgrounds and that's exposure You might not have during your normal day-to-day job Personally open source has given me a sense of permanence to career to my career where my job has not You know, I've been jumping from job to job year to year, but the open source communities that I've been involved with I've been involved with five plus years So there's a couple different ways to participate in open source There's contributing and maintaining contributing is a short form of short-term participation where you come and contribute one Maybe two and in one or two ways, and then you go on your merry way Maintaining on the other hand is taking a long-term term Ownership of some particular aspect of the project. So in this little chart I produced here maintaining is greater than contributing It's greater than contributing for its level of reward But it's also greater than contributing for its level of effort commitment and emotional involvement So if you're thinking about becoming a maintainer of an open source project moving beyond the contributor stage Let's go through the emotional journey of what that experience might be Starting off when you're just thinking about posting your code online. You might be embarrassed by it So embarrassed that you think I'm not actually gonna post it online. Well, here's a little secret Everyone's embarrassed by their code. I started off not as a programmer. I posted code online I'm a mediocre programmer now Being by embarrassed by your code is not an excuse not to publish Your project and become a maintainer in fact Publishing your project online is that a great a great excuse to learn Posting your code online leads to conversations about it that you wouldn't have otherwise when people come to use your project They'll give you problems to solve it will help you grow as a developer and it's important to note It's a long hard road to mastery and that road never ends learning never ends As a newly minted maintainer of an open source project you may feel discouraged that you can't ever finish your releases In fact, I used to feel all this this way all the time too I used to plan a release by assigning a bunch of issues to a milestone and working against those issues until the milestone was complete Unfortunately, there'd be a few to several to a dozen issues that wouldn't couldn't be completed for some reason another and my delivery date of October would slip to November to December and into January Nowadays as I maintain WPC li I release on a time-based schedule In fact philosophically, I feel that users shouldn't care about which version of your software They're running they should only care that they're running the latest and greatest I Actually also avoid assigning issues to milestones until they're nearly complete or they're a bug that's critical and absolutely needs to be fixed This helps me Keep my releases on schedule and regular regular Similarly to streamline the release process I've adopted a consistent release note format which solves my indecision on how I should actually write my release notes And I checklist the release process and script as much of it as possible So that when it comes to actually performing the release It's just a matter of following procedure and not having to actively think about the steps that you're you're taking And it's important to know that wrapping up a release still takes several hours that you need to find in your schedule And so as you're making the decision become in the maintainer of a project and making a commitment to your community Realize it does take time As the maintainer of an open-source project you may feel overwhelmed by your issue backlog as your project becomes Popular users open issues and this will happen at a greater rate than you have the ability to close those issues at some point You'll hit the 400 issue mark feel completely overwhelmed and give up all hope With WPC li address this by triaging the issue backlog on a regular basis in prioritizing I Also make decisions on issues that have been on issues that have been open for years if an issue has been open for a couple years And hasn't seen any movement. It's probably not important enough to do and it can be safely closed I Prioritized by only assigning myself on a few issues at a time These are issues I deem most important for me to work on personally for the project and it keeps my focus on those issues And not distracted by everything that I could be doing and it's important to note that you'll never get to zero in your issue Backlog, so you need to come to grips with what's a healthy number of open issues in your project? As the maintainer of an open-source project you might get frustrated when issues turn into flame wars Text as a conversation medium has a very low emotional density When you and I are sitting across from another one another at a table when we talk We actually have facial expressions body posture and the intonation of our voice to Communicate the message that we're trying to communicate text-based Conversation with its low emotional density can easily lead to misunderstandings With WPC li I do my best to be empathetic respectful and firm first when a user comes to Comes to the project and opens the issue. I realize that there might be more than what they're able to say in text To their issue and so I try to do my best to put myself in their shoes Understand where they're coming from and understand what might not have been said Second I do my best to be respectful in my replies in my conversation If they're reporting a bug it's potentially a bug that sunk a day or two days of their time And so I want to acknowledge the fact that they've actually done me a huge favor by coming to my project and reporting The bug so I can fix it for the next person Lastly being a firm being firm asserts myself as an authority on the subject which sets the tone for the conversation and reduces Ambiguity I think that a lot of people working with open source Projects want some level of authority in the conversation so that they know whether or not You know what they're reporting is is going to be addressed or not And it's important to note that you still need to develop a stick of thick skin Sorry just one moment as the maintainer of an open source project you may feel over committed on your open source involvement People ask you to do things and you say yes if you say yes too many times suddenly You've got a hundred different things to do and you're paralyzed with where to begin In maintaining WPC li found it's important to make myself Happy first and set clear boundaries for my involvement with open source The best balance I found is about two to five hours a week maintaining WPC li as a part of part of my normal 40-hour work week At this level of commitment my involvement is still very much a passion And it doesn't feel too much like work and because I prioritize the issues I'm working on I make regular progress on what I think is most important It's important to note that your commitments are gonna be a balancing act that you continually continually need to readdress on a weekly basis As the maintainer of WPC li also feel very alone I feel like I'm the only one ever working on the project and a lot of people are benefiting from it Which is great, but I'm doing all the work. So this is a very you know current struggle for me I'm trying to figure out a long-term future for WPC li. That's not wholly dependent on me While being a benevolent dictator is fun. The project isn't healthy if it has a bus factor of one So what I'm trying to do is focusing on now on leadership guiding others contributions and identifying opportunities for others to be decision-makers With the project there's a few different ways I'm trying to do this first some of you may have noticed blog posts I wrote on Thursday that identified a few different non code roles where I want people to participate These are areas where I feel like I am weakest and where there's a opportunity for greatest contribution I'm also writing more documentation for the project than I think I need the documentation isn't for me The documentation is for the people that are new to the project and want to learn how it works And so you have to actively force yourself as a maintainer to document the stuff that's in your head that needs to be written down For the people that want to get involved with the code I do my best to identify good first bugs is entry points to the code and I actually want to Discourage regular contributors from taking those good first bugs because I want to make sure that there is always a pool of good first bugs for new contributors And lastly I highlight contributors and release notes and tweets as a way of recognizing people's contributions to the project Now it's important to note that you'll never find all the contributors you want So you'll need to accept and make use of what you have which can be difficult So where is this all leading? Well, WPC li is eating WordPress WPC li is becoming more and more embedded in the WordPress developer experience And it seems like there's a WPC li session at every word camp these days This is because with the command line WPC li enables doing more with less effort So you can help WPC li eat WordPress by writing and maintaining custom commands Just like WordPress has plugins the future of WPC li is packages of commands for this future I'm trying to proactively solve the problems that WordPress has plug with plugins where WordPress plugins are considered second class to with a code That's included in core I'd like WPC li packages to be considered first-class citizens amongst the commands in WPC li and all too often WordPress plugins Have just one author. I'd like to eat for each WPC li package to have two or three active maintainers We're all aware that open source is an increasingly valuable part of the global economy in this talk I hope I've conveyed that emotional roller coaster aside maintaining an open source project can be a hugely rewarding part of your career And when you decide to take the leap I look forward to saying to you my condolences You're now the maintainer of a popular open source project. Thank you