 Who maintains an open source project that you didn't start in this audience? There's a lot of hands, I guess my job is done, I don't need to be here. So I have to mention, I did not draw my own slides, I apologize, I worked for an art company, I should be able to freehand it easily, but I spend more time writing software than drawing, however we do draw on a regular basis. I also have other disclaimers in the stock, I tend to exaggerate things and then I'll give examples of people that don't really exist or exist in other worlds. It's really just to make it a little bit funnier. So a few years ago, about 10 years ago, I was looking for some silly piece of technology to do some installation sequencing and I found an awesome bootstrapper project that just chained installers together and it was run by, it was an open source project, it wasn't GitHub yet, but there was a rather competent developer that seemed to be working on it and he was Italian, I figured it out just by looking at a little bit of his history and he did a great job, he wrote the whole thing, he was maintaining it, I sent some bug fixes, some really simple stuff and he was very helpful, he was there, it was great and my company adopted it for all its software across the board, it was a big deal, we had a team of about 50 engineers and we started using it very, very heavily. And then one day he was gone and this was in the middle of a release and I kind of panicked a little bit because I now had a problem in my hand, I had a few fixes for the code and I needed some help from him to figure out whether these fixes even make sense and what the side effects are going to be of those fixes, I really had no idea and he just disappeared and so I thought I'll copy the code, I'll make some local patches, we'll ship a release and in the meantime I have 50 engineers, they have all kinds of issues, they need help with each individual installer, they have also personal problems and it's just all kinds of things to do and I'm looking at this and saying why did this just happen? What is this guy? Isn't he supposed to leave the project in good hands once he doesn't want to work on it? I started googling him, I started trying to find him, I tried to find a phone number, an email, no reply, nothing and this is a famous quote, I was really upset, he abandoned me in my needs and just vanished. Well, you know, sometimes stuff happens in life and you might not be in control of your own things, it turns out that he had some other issues outside of software and disappeared in the newspaper, so I understand, things happen in life and you might not be able to maintain your open source projects and in the meantime you got this crowd who's using it and the GitHub issues just pile up what's going on, should we take over, there hasn't been a fix in a long time and it's particularly striking when you use something, you realize something is broken, you make a code fix to the thing that's broken, you make a pull request and then you look at the list of pull requests, it's like fix the same thing, fix the same thing, fix the same thing and each one of them gets closed, oh, I realize somebody else has already fixed it, it just hasn't been merged in a long time, so that was me in that situation. I really need this thing, you know, and in fact it's not just me, it's my entire company really needs this, I mean we've got shipping software writing on this, we've got millions of dollars, many millions of dollars, I was working on some security software for the government, it's your tax payer money at work, and we really need this thing and now it doesn't have its heart, the person who wrote it, the very important person, and you know what I don't have, I don't have time, I really don't have time to deal with this, the whole point of using somebody else's project was to not do the work, I mean somebody else wrote it, I'm happy to contribute some bug fixes, but I don't want to deal with this thing, it's hairy, it's big, it's C++, it's complicated, I don't want to do it, I don't have time to do this, I'm a manager, I have a job where I have to counsel people and I have to tell them what to do and all those important things. So, you know, at the same time, while there are many contributors and many people who are using it, just like me, being very upset at the guy who unfortunately can't maintain the project anymore, really none of us in this group of people want to take charge, nobody really wants this thing, and it's big enough and complicated enough that nobody actually wants to step up at all, so we're all looking at each other and we're commenting on the same pull request, talking to GitHub, and you know GitHub has a lot of repos and so they don't really care, and they're not really trying to help you at all, they keep commenting. So, somebody needs to step up and somebody needs to take over this project and that somebody I decided was going to be me, and I felt really small in this compared to the size of the problem and how many people were using it, however, I thought it was necessary and I'm not sure what pushed me to do that, but I want to tell some of the stories of how that happens. So, the first thing that I try and I did this a few times after that episode, the first thing that anybody would try is to contact the maintainer of the project, and the true story is that the guy, this was some mafia boss, I thought it was a more striking example, however, the true story of the guy who abandoned his project was that he opened the vineyard and disconnected from the Internet. And, you know, I sent him emails and I said, listen, I've been using this project, and I also, I run a team, I've contributed some fixes, I put some credentials up front saying, you know, this is me and I'm a responsible person, I really want to help. I also have been involved in some other things before, and so I showed, I wrote the list, I said, here are things that I worked on, and it's not just some random guy on the Internet, some random developer somewhere on the other side of the Atlantic trying to take over your precious project, it's, we're going to actually make it happen. And I also put my team behind this. I said, I have a number of engineers, and here are some of them, some of their profiles and some of their names, and we're actually going to maintain this, and we're going to create a group around this, and we're going to do it. So I put a lot of credentials forward. I wanted to, the person on the other side to feel really good about moving, about giving away the project to a competent set of people. And so, however, people are actually human, and there is a ton of reasons why somebody would not want to even reply to you. And just recently I've tried to take over somebody's open source project that's quite good. I tweeted, I emailed, and I didn't call, I didn't stalk, I didn't go to the address of the person. However, I can see they're there, they're alive, they're tweeting cat pictures every couple of hours, and they've got, you know, a life and a Facebook profile and kids and whatnot. And they just do not reply. And I think it's really weird, however, we have to understand that humans sometimes just don't feel confident enough to do it. They're afraid that this, maybe there's a little baby of theirs, their project, the thing that they worked on, may not even be good enough for public consumption. And it's only an accident that somebody uses it. They may have moved on and they might not care anymore. And they're just, they're not ready to re-engage. And that's just the reality of things. So really, if that happens, if the person on the other side is really not willing to give away the project to a group of people, then all you have left is to fork it. And that, that's totally okay. However, before we do that, we're going to try and get to a better place. And so ideally, what you want, and especially for Ruby projects, is that the owner gives it away to you. And that is just two things. GitHub read-write access and the ability to add maintainers, you have to ask to become an owner of the project, not just the committer. And then RubyGems access. I don't know how many times I've taken over a project where I realized three weeks later trying to make a release, oh, I forgot to ask for RubyGems access. Now I can't push the gem. That's a real bummer. And I already asked for a favor. I already got pretty far. And now I have to go and ask again. So now I just ask for these two very specific things. And, you know, eventually, hopefully the maintainers like, okay, please help, please contribute. Here's all the access. That's great. If you, if they're responsive, the one thing that might be really useful is to ask them to donate the project to a larger community. This happened to a very famous, very large Java project. And the owner who works for a very big company as the last grand gesture agreed to rename the namespace from, you know, the megacorp.com to the projectname.io, something like that. And it's like a big deal in the Java world. And he also wrote an email to the group of people saying, you know, I'm going to step down. And here's a group of people that is going to replace me, that at least claims that they want to do this. So that transition is really important. If you can get the owner on the other side to do it for you, that's great. Now that you own the project, you can rule it. And you've got the power. You're in full control. You can make all kinds of decisions that are, they don't even have to be controversial, you know, like 90% of the people who are using this project are going to agree with you. And, you know, you can profit from this. You can put it on your resume. You can be like, I'm the maintainer of this awesome popular project. Maybe there'll be money at the end of this. Well, actually not at all. Now you have to do, now you have to do the real work. So you've inherited this thing. It's usually in a pretty bad state. There's tons of full requests. There's people. There's a lot of frustration. Now you're going to have to do work. And so this is something that can become clockwork if you do this. Often the first thing is you just need to organize the project. You just need to set up whatever basics in any project that you would like to participate in are. So anybody knows what this is? So, you know, we don't use those anymore. We use email for larger projects. You want the mailing list for smaller ones actually like the GitHub issues. You constantly have people saying, oh, where do I get help? And you know, you can just tell them, get help, ask a question on the mailing list or use a GitHub issue or something like that. You need a license for these things because you're going to be asked a thousand times why is what's the license for this project. Sometimes those things are missing from day one. I use the MIT license because it's short. I don't really read it. You want to get build automation running for it. So Travis is wonderful. You just hook it up. You get the builds running, some changes to a rake file, and off you go. You now have builds. You'll notice a pattern. You're trying to work yourself out of any mechanical job. You actually don't want to be maintaining the project per se. You want to create automation so that other people can contribute and grow. So there's actually a bunch of other things you can use today. There is code climate. There is dependency counts. There's all kinds of badges. I don't like to be badge heavy, but it's fine. If you have a set of things that you really love, just throw them in there. It will look good. It will be all green. The one thing that I encourage you to do right away is to list in the read me things of how to get help. So things like if it's a downloadable binary where to download it doesn't apply to Ruby too much. Where to get help. What to do. Like things that are work flow, basic work flow, essentials, whatever it is. And then they're getting started and how to use this and go and update these read me and make them cleaner. Make it look like the project is alive. One of my favorite things to do is to add a changelog. I'm very frustrated by Ruby projects that don't have a changelog. You have no idea what has happened before. So the way I run changelogs is it's very simple, mark down file. And I will start by saying next release your contribution here. That creates an environment where people are welcome to contribute to the project. And then I ask, I'm very specific about the format I like and this is completely personal. However, what I want is to be able to look up history online. So I want a link to the GitHub pull request for a fix or a feature, something like that. The explanation, this one comes from Hashi, which I took over a while ago. And then I always put people's names with a link at the end which gives them a real sense of ownership. And I don't know how many pull requests I've said, please add a line to the changelog. This happens all the time people contribute things and they don't call the work out. So I always do this. I really like having clean changelogs. The other thing is a contributing document. The way I develop contributing documents, I take them from the last project I wrote a contributing document to. It's kind of like your dev setup. You use the last person who did the dev setup to do the next dev setup. So I think these contributing things are very, very specific and they're really targeted to somebody who has never contributed to a project. And I've noticed that when you have a very clear contributing explanation, which is fork the repo, make the change, push the change, update the changelog, make a pull request. And then at the end, I always say that you should be patient. It's likely that your change will not be merged and that somebody very nitpicky is going to argue about periods at the end of changelog lines or something like that. But really, we as a community value your time and work and we really love you. And that has resonated with a lot of people. I've got emails about how nice it is to read this and I got a ton of read me updates. People who read the contributing guidelines and they notice a tiny little problem. They'll actually take the time to fix it and they'll actually do it, especially junior developers. And finally, you want a releasing document. That's actually surprisingly rare in Ruby projects. Sometimes releasing is as simple as typing rake release or something like that and maybe updating a version. But this is what you want to give to new maintainers of projects. You want to tell them, I'll talk about this a little bit later. Here, I want you to do a release. Please follow the guidelines and the releasing document. It might be obvious, but if you've never released the Ruby Jam, it's not that obvious. Finally, you want an upgrading document. This is something that is essential for projects that have some kind of API. You want people to use them. You want to give some history about how to upgrade. I love the colors of the new GitHub labels. So I always go in and I delete the current GitHub labels which are boring and bland. And I create these. I'm thinking about the workflow of how somebody has a question maybe or maybe reports a bug. Usually when they do that, they're not sure. They're not 100% sure that this is actually the case. So I start with creating a label called bug question mark. Whenever somebody puts in a bug in issues, I'll go and assign a bug question mark to it. And so this is a good way for me to acknowledge that I've actually seen that issue. I'll just quickly skim over it and then just put the label. There's chores, there's confirmed bugs. Confirmed bugs are great. When you reference an existing bug that you know is a bug, that somebody actually took the time to confirm that this is a problem, then you can give a link and then you can go and see, oh yeah, this is a real problem, I understand. Now I can actually fix it. Maybe I can write a test for it. You always want to leave room for discussion. The maintenance role is not necessarily to do long-term roadmaps or stuff like that, but you want to welcome some kind of feedback and it's a great place to redirect sometimes trolls. You just write an issue, put a label of discuss with it and people can argue about it. New feature request questions. And then you can help has been actually quite good. I've definitely seen pull requests for small things, either small things that somebody could code or really big things that are really complicated. And a couple of issues on these complicated libraries have been taken over by really competent people where the thread, the discussion is like, I give up, this is too complicated. I don't know how to fix this and then people would really try when they see this you can help thing. And by the way, the colors don't matter, you can use your own. Finally, it's when you see this merged pull request label, you know that the project is active. So now you've got the backlog. Think on Hashi, we had like four pages of GitHub pull requests up there. A year worth of work by probably 50 people. So you have to go through each one of them since you are taking over the project, figure out what to do with it, merge it. And it's a merged nightmare because you have 10 things that are colliding. And then decide what goes in, what doesn't go in, what gets thrown out, and discuss it with the people who are there. I love Rubocop. I always put it in right away. This cuts all, who doesn't know what Rubocop is? Oh wow, so many hands. Rubocop is an amazing project. It is a Ruby syntax linter. It basically takes, for example, 193 syntax doesn't require curly braces anymore for hashes. Rubocop can automatically clean up your code and can create a violation next time somebody puts it in. So you'd never have to argue about the layout of code ever again. And it's a two-liner to add to your e-file, jam Rubocop and you're done. Rubocop also has something that's awesome. It's a auto-gen config. So you run Rubocop the first time and it finds all kinds of violations. You run it with this auto-gen config. It creates a Rubocop YML configuration file that just says you have all these issues and I'm gonna ignore them. And here's the number of violations in them. So it takes five minutes. You create this config, you make no code changes other than the automatic cleanup that's done by Rubocop. And next time somebody makes a pull request they have to abide to the layout of the code. And it's somebody that just decided these are the best Ruby syntax practices. You don't write curly braces with four spaces after them or stuff like that. No more discussions about whether I like my left alignment, tabs, spaces, all that stuff is handled by software. This is wonderful, I always edit. You have in pull requests, dozens of people have made pull requests and it didn't get merged and they're hopeless. They abandoned, ship, they're gone, they don't care anymore, they might have moved on or they're still suffering. Kind of like me in the beginning of that project. You want to send them personal email and comment on their pull request and say, you know, from now on, hope is there. Giving people hope is something extremely powerful and they love it. And they're going to be with you and they will take a lot of problems and they will really wait and be patient and work with it. So recruiting the hopeless in creating this new team and kind of recreating the community around it is really important. Finally, you want to make a release. And this is where the job of a maintainer has its first validation and this is when you get the kind of the first satisfaction of have accomplished something. Now it's really yours. You've made the release of this Ruby gem that you took over. It's there and you can claim it. Now remember my slides of fame, profit and rule. That's why you put those. This is where you start making the money. So it's not that of a great job of a great job. You have to pick up a lot of trash and after people there is you have to make sure that you comment on every single poll request that you answer every single question on the main list. You have to be the last person to do it. I never do it right away. I let other people try to step in and kind of try to step back from now on and create space for other maintainers to be able to step in. However, things get unanswered and you really want to answer those. Even if it's I don't know, let's think about it. Anybody has ideas. You want it to make look alive. You have to create workflow and this workflow is personal to your project. I encourage people when they report a bug, I ask them to write a test that reproduces the bug. And then once they wrote the test, I tell them, well now you can fix it. So that's kind of a good workflow. And they change log and so on and so forth. So these things become automatic and I usually will spend half a day every week going through all the open source projects that I maintain and just pick up the trash, the stuff that was dropped down and then try to encourage people to do this stuff. You want a reputation of caring, this is awesome. Don't you love coming to a project where the maintainers really care about what you have to say about your problem, about your bug when they want to discuss it, they want to help you. And if you're trying to make a contribution, you really feel welcome. And this is something you just do every day and eventually it sinks in. The hardest thing to do in any open source project is create new owners. I have a very simple rule of thumb of finding new owners. First of all, I try to have them on day one. From day one, in those pull requests that have been abandoned, I'm gonna look for several things. Number one, I'm gonna look for amazing Ruby programmers. People who can do something really simple, really clean, who really get it in their first pull request. And they often are, some of them are junior, some of them are senior. It's really not a criteria of how long you've been doing it, but there's just some amazing programmers out there. I'm gonna always try to identify them and I'm going to make them owners. I'm going to bring them into this project by giving them read, write access as a matter of trust. I'm going to say, you now are part of the team or at least ask them, would you like to be part of the team first? And have them have a sense of, some sense of ownership. I also am going to try to work myself out of that job. One other thing that you can do if you work in teams, and especially if you are in some management role, you actually have people on your team who are dying to have open source work. They want that, they saw it with other people and they think it's awesome, but they just don't know where to start. Those people, you can actually assign them to be owners. Somebody I talked to gave me a story of where she took over an open source project and the first thing she did was to assign somebody on her team to basically do all the work that I've just described. And that person felt extremely fulfilled and was very thankful. It was a great entrance into open source world. Everybody knows the myth of the story of the chicken and the pig. They want to open a restaurant and they're gonna call it Ham and Eggs and the pig thinks about it and he's like, no, I don't want to open a restaurant called Ham and Eggs. You'll be involved and I'll be committed. There's a ton of people who want to be involved, but they're not committed. They have lots of opinions and sometimes they're called troll, sometimes they have something valuable to say, sometimes they want to talk about grant plans for the future, none of that matters. The only thing that matters is just making progress every day. It's digging, it's moving forward. So none of these projects have any discussions around the futures or some hypothetical next step. The way you want to contribute thought into the project is by writing code. And by making pull requests, they might not be complete, they might be experimental, but this is how you start. You always have to attach code to your ideas and you have to make progress every day. So I wanted to, the contents are not important, I wanted to show two projects that I maintained and took over and some of you may know them. How many here use Grape? Oh, there's at least two dozen hands, that's awesome. So I've been maintaining Grape for a number of years now and I didn't start the project, I started using it at Artsy and this is one release. Look at this list. There is about 12 to 15 contributors in that list. This is a super active project. It has right now 4,800 stars on GitHub and it's used all over the place. This is a project that could have been dead but a lot of people need it. And this is extremely gratifying. My name is not in that list, I have not written a line of code in that release. This is entirely done by the community of people and there is now something like five or six maintainers in it. Another very important project is Hashy. It's used by everyone and I feel like today the same thing is happening to Rack Contrib, for example, where the Rack Contrib does not have an owner and I probably won't be the one to step up, maybe some of you will. But this is the issue tracker in Hashy and you can see this is actually very active and Hashy had not seen a commit for a whole year and it's used all over the place. And so this is another very important project and very rewarding to see this thing. So I want to leave you with one thought. We have more code that we can handle on GitHub. There's so much source code out there and source code is a huge liability and this is not at all what we need. What we need is we need a community of people who contribute to these open source projects, who do the management work, the maintenance work, the dirty work, the hard work, the work that engages other people, the work that creates groups, the work that rises people to the occasion and helps them contribute in a meaningful way. That's really what we need. What we need is a community of people around these open source projects. It's not the most awesome code. So I encourage you to be part of creating a community around your small or big open source projects and really embrace that thought. Thank you.