 Okay. So I'm in Phoenix. Thanks for getting up early this morning, everyone. I'm going to have a feedback on this. Okay. So I've been working on Rubinius for years and years now, and I'm lucky enough to be someone who gets to work on an open source project as my main job. Every day, all I do is work on an open source project, which is an amazing way to spend your day. And throughout the years, I've sort of slowly learned and picked up things that have helped me figure out how to navigate running an open source project because it's not a simple thing. So I decided that what I would do is really try and distill it down into four laws or guidelines for how you can approach different problems and different things in your open source project. And we'll get on to this. This is not just for I'm running a project. This is also for I'm contributing to one, because as you see these laws, you should think about the fact that the people you're contributing with would be adhering to these two. So we'll get on with the laws here. So the first one is that contributors are a privilege. And this is something really that is important to remember because a lot of times they feel like a complete pain in the ass. There are certainly times where you get contributors coming in who are doing all kinds of weird things and they just seem like a burden rather than that they're helping you out. But it's important to remember that even in those cases that they're providing you with a service that you couldn't get on your own. Having them around is a privilege to you. So number two, no is a perfectly acceptable answer when talking about things inside an open source project. And we'll get to how that works out. Three, responsibility inside the project. And this is one thing that I found really amazingly over the years working on Urbanius is that responsibility, someone having responsibility, it gives them this amazing sense of how to guide the project. And we'll kind of look at that. And then four, you have to communicate and you have to do it a lot. Open source projects live and die by how well they can communicate with the people inside the project as well as outside the project. And I have lived and died by this, sometimes not communicating very well, sometimes communicating hopefully not too much. So this is an incredibly important point. So when you have a project and you're looking to apply all these things, remember that you need to be nice. So by that I mean that it's so easy to fall into a trap with contributors where it feels like they're really pushing on your, almost like they're pushing your buttons and it's easy to lose your patience with contributors. So it's really important to be nice and remain keeping the community as nice as you can. And remember that these contributors are really doing you a favor by being there. Apply that first law. It's a privilege that they want to be around you with your project. So it's important in those cases to keep your cool. So let's look at sort of one first sort of case study of where this would come in. And we've all experienced this either writing one of these and getting the rejection or working on a project and having these come in. Where someone writes a rather unwanted feature. So this is our case study. You get a patch that says, hey, I made it so that you don't need to flush a toilet anymore. It seemed like a really great thing because I was wasting all this time every day flushing a toilet. And this is probably what you're thinking. Even in this case, it's important to take a step back and really remember that they're trying to help out. They feel like this is a great thing. They want to help with your project. And this is a huge invitation to you for what to do. So while you may think this is the stupidest thing I've ever seen, it's important to think, okay, that's a really interesting feature. That's great. I don't think we're ready for that just quite yet. And this is where you start the dialogue with them. You need to have a conversation about, well, why do they think it's important not to flush a toilet after every time you use it? And why don't you necessarily want that feature in your product right now? Having that conversation enables you to figure out maybe there's a very valid case that they've got and maybe you want to, you're not ready for it now, but maybe they've enlightened you to a whole aspect that you weren't open to before inside your project. So in this case, there are plenty of times where someone has decided they want to work on something else. And it becomes a question of, if you aren't ready for them, what should they do? Well, we've all started, we're all for the most part on the sort of get hub forking aspect. So it's important to look at when should you, as a contributor and also as a committer, push for different kinds of forks of the project if someone wants to work on something interesting. But it's important to remember that you need to fork for the right reasons. You really need to be forking for love of a project and not for hate. And a bad reason for forking would be all these guys are assholes. This is the typical sort of the pre-distributed software configuration, software management tool version of forking where like Linux gets forked because someone thinks Linus is an asshole. These forks were the peril of open source development for a really long time. The big thing that we've sort of realized in the last few years is that forking can be perfectly great. In fact, the reason for forking hopefully is this, that I really want to do something new that the other developers aren't doing and I want to figure out how we can work together in this. So it's important that as those forks come into play and as you're sort of building out your community that you're really forking in public. Because there is an incredible, well it may seem like okay well I'm going to fork it and I'm going to just do it locally and I'm going to do all these changes and really build out this big thing which I have done before on a particular project that generated like a 20,000 line patch. The idea that those things would ever work together after that point was sort of naive on my part. But if you decide as a contributor that well they're not ready for my patch yet but if I fork this thing and I do the development in the open if they can see what I'm doing and I can have a conversation with them an ongoing conversation about okay hey guys I added this new feature I know you're not ready for it but you know could you take a look at it, what do you think? That builds up this, that is rather than sort of eating off developers into this fork that's really building up pillars of support underneath your project because now you start to have this very rich ecosystem of innovation and of experimentation and of enthusiasm because enthusiasm is really what open source development is all about. So when you have as a contributor and as a project manager when you see a fork up here it's in your best interest to be a friend of that fork. Don't say oh these guys are doing something stupid, ignore their fork please don't pay attention to them, they're off being crazy. The best way that you can handle this is to go out and to talk to the people who work on this fork and say okay well how can we work together? I see that you've got a lot of enthusiasm for the project maybe is there a way that we can incorporate these things together? How can we move together forward? And there are certainly times where you can move together forward but it's best that you decide that by having that conversation rather than just sort of deciding it by fiat because you're not talking. So one thing that has sort of come with open source and with forks and contributors and everything there's always the need for, I get questions a lot of time about okay well if I want to build up my open source project I think that I need these 25 steps of things so we need to talk about process a little bit about how the process for managing your open source project because really too much process can be the death of your project because all it is process, all process in general is contributor pain and it's all about how much contributor pain you want to push to them but on the other hand you can't have no process because too little process means you're spreading the pain out of working within a group to the entire project to everyone and at that point your project becomes just this complete chaos but there's a subtle balance in there so we want to talk about what that balance of process and project is. So first off I see a lot of projects adopting like a Git workflow and I want to say having been one I believe one of the first projects in the Ruby community to be using Git avoid complicated sub and workflow as much as you can it may seem like oh well I'm doing the computer a favor this will help us out in the end and I think that there's all of these 37 problems that might occur that I'm avoiding with this workflow and I want to start this new meme here today premature process is the root of all frustration if you decide okay well these people are going to do something crazy I just know it I know they're going to do something crazy they haven't done it yet so I need to build up a whole bunch of process to deal with this crazy event that has not yet occurred all you're doing is you're making more work for yourself and you're pushing more work onto your contributors so use as little process as you can in what you do and really treat process like you would doing agile development you have an issue, you adjust, you add process as you need to so let's look at another case study on this controlling chaos so this is one of the when you get this email from someone you've never heard of before hey by the way here's 10 new patches it's an amazing feeling this is just you you're like great there's a person out there with enthusiasm and they're learning our code base and they want to how about you're excited you're just you're gleeful and then you start to look at the patches well okay so these okay so this this person's been working on these patches for a while and I see that we've already added you know four or five things that are in here that's too bad oh geez they introduced five new dependencies and they decided that okay so okay for some reason this needs to pull in some huge gem or something that we never used before and they're in a completely different coding style so yeah we'll get to that so this is probably what you're feeling like you were just high on 10 patches and now you're now you fit the low of dammit right so remember the laws this is completely a teachable moment because what you have here is someone who has an abundance of enthusiasm but you don't they haven't followed your process or you don't have process for them which is totally fine this is how you decide what process your project needs and also how to push these people forward so really what you want to say is this is great I love what you've done here but let's have a conversation now about these things and go over them one at a time so in this particular case you start to discuss okay this is great I see that your patches are you've sat on them for like three weeks and we love to get you integrated more often so you have to figure out and you have to discuss okay how can you get those people to contribute more often so that their work isn't out of date very rapidly in the case of the dependencies educating your users and educating the people about what the architecture is and that's not always an easy thing to do architecture is an incredibly hard process but even if it's not a formal documentation even if it's just a discussion with a person oh yeah well you know you've overlapped dependencies because we're already using this thing and could you think about using this and even just having that conversation becomes a collective documentation about what goes on and then the style thing that's always something you have to discuss with people and say well you know I really need you to push and to sort of stay consistent with the whole project because that's important to the project project's longevity so like I said you want to revise this process so you may have this conversation with a person and really the worst case scenario is that you get this response from them I'm just not willing to change for anybody and this happens you may push and you may get someone who's like well you know that's just I think that my way is superior to the way that you want to do things and that's fine, that's a totally valid response if they feel like that's what they want to do and you can just say that's great have a nice life no hard feelings it's just not going to work out between us it doesn't have to be a big thing if you feel like well you know this is what we need and if you can't give us that right now that worst case scenario is really not what typically happens this best case scenario is really the common case in the course of working on a Rubinius for years we've got, we've had this exact problem you know hundreds and hundreds of times over and in every single case that I can think of we've come back with a person and we had this discussion and they've responded with no problem, thanks for getting me up to date I love that you took the time to discuss this issue with me I'll get right on doing these fixes and having that first conversation with that person means that they feel included in your community and now they're willing to go out there and do those things and help out and a lot of times what happens is after you've had this conversation the next time this occurs you get this feeling of delight when you see on the mailing list or in the IRC channel or wherever it may be that this person who you had this conversation with is now helping the next person do these exact same things how should, what should the process be and they're now educating other people and bringing that in because the key here is that enthusiasm for the process is transformative if someone is wants to be working on your project then that enthusiasm can ride them through getting integrated with the project and the sooner you do that the sooner that you just have this discussion with them the better off everybody is so we've talked about how to integrate changes and we've talked about you have somebody who's already given you stuff but the biggest problem for an open source project and a lot, a problem that you hit right away is you've decided okay I've been working on this thing on my own and I want to have people help me on it I'm going to go ahead and I'm going to push this out to the world and I'm going to tell the world I'm going to put it on the mailing list I'm going to send out flyers with the pizza guy I mean whatever you've decided to do to get the word out that it's out there but the minute you have people come to you and they say hey I want to help out with the project where can I help now it's on you now the onus is on you because this person they have enthusiasm for your project but you have to push them in a direction so the best way to get someone integrated on your project is with easy wins the best and this is exact the same as a test first strategy you want to have this this person try the simplest thing that could work and if they fail that's great because that can be a teachable moment so you want to have the easiest win possible you never want to have you very rare, never is a big word you very rarely want to have someone come up to you and say oh what should I work on and they say we need a brand new architecture get on that I mean it's clear that they're going to go like ok little goodbye but if instead if they're asking you how can I help then if you can give them these simple goals and these easy tasks to work on then it brings them it's a very easy simple door for bringing them into your project the simplest way is if you can tell them alright run this command whatever is broken and this is a strategy that we've used with Rubinius for years and it's been amazing there's just a very simple command that you can run that will run and it will print out a list of all of the specs all the ruby specs that don't pass so I'm ahead of myself here so it's a very simple command and it will print out all the things that don't pass and then the user can just say it doesn't work here ok well array is supposed to take on argument and it doesn't ok let me go look at the test ok alright we used to do this and now they've got a very simple they know exactly one thing that they want to get done and even if they only do that one thing in the project it's a very simple easy way to get them in that door and in fact 90 plus percent of all people who contributed to Rubinius have come in this door of the 200 people who have commits that are inside the repository 90 percent of them we said oh work on a spec first so I want to highlight one particular person because he's a wonderful example of this which is Durkian he works on data mapper and he got interested in the project many years ago and wanted to figure out ok how can I help you guys out so here is Durkian's first commit it's a very I didn't print out the entire diff here but it was basically just a ok well I just need to check the return value of some argument and raise an error if it's not a particular value it was a very simple commit right and this is back in January of 2008 so it's been almost three years since this commit happened and in those in that time just by opening up that little door by giving him a little breathing room a little space of the ability to peek through the bushes for how to work on the project I looked and he has 446 commits as of yesterday and those are not just in specs those are everywhere he's worked on the JIT now he's worked on the entire gamut of the thing and he just he has a normal job he works on other projects as well but by just having that easy way into the project it has enabled him to flourish inside the project which is really something I'm extremely proud about so my point here is that easy wins are the gateway drug the quicker that you can get someone to give you a patch and get it into the project the quicker that their enthusiasm for your project will build and they'll want to continue to work on your project so another part of this is they've given you that first they've given you that first patch and maybe they give you a few more patches and you have to decide how is this person going to continue in my community am I just going to take patches from this person and commit them or do I want to integrate them directly into the community and a lot of people call that the core and I want to push something on to people the idea that you should have no core team and this is a scary idea but a core team is a sort of a lofted place it's a place of privilege but from my perspective by not having a core team by pushing out this idea that anybody can be part of the project you give them trust and again just like enthusiasm that trust in that person can be transformative in them being a contributor because you are saying to this person your work is just as valuable as mine so let's look at again my number one example here Rubinius so back when I first started this project in 2007 whatever I had been reading a lot about other open source projects and one in particular was called Pugs which was a Pearl 6 implementation in Haskell and I wasn't doing Pearl 6 I wasn't doing Haskell but the idea that really stuck with me was that Audrey had a very who's the developer the main developer there had a very simple strategy which was that if you submit one patch you get commit rights so no matter what that patch is even if that's a documentation fix if you add a period to the README file you get commit rights after that and the same strategy that Rubinius has used and continues to use and it has been amazing and the reason is that in my opinion responsibility is greater than privilege the fact that we will give into telling someone that oh you know great you sent me a README fix why don't you go ahead and just continue to fix the README in fact why don't you just fix anything that you want in that time puts an amazing amount of responsibility on the person's shoulders and one of two things happens either they take that responsibility and they say wow this is great I'm one of I'm a core team member now and they flourish and they for the most part are just an integrated part of the community that is very respectful of what was going on or they see the responsibility and they decide well maybe this isn't for me but it is an amazing way to weed out what is essentially what people you want in the project and what people maybe aren't so interested in it so when I explain this idea to people I get a lot a lot of times I get there must be just complete chaos then because you accept a patch from someone and then they just go crazy they rewrite all of something or they do whatever but the reality is that while that may seem you may think that would happen in the years that I've been doing this I think we've only reverted 10 or less commits because the person did something crazy and we decided that we didn't want to do that and the reason that happens is again responsibility and the fact that you have to apply all of these three laws so you have you've trust them you've given them responsibility but you also have to communicate with these people a lot if they decided I want to do something I've got a great idea for a brand new feature it's important that they feel included that they feel that they are peer with the rest of the project so they can come to you and say hey I've got this idea for a feature what do you think and you may decide well I don't think we should do that right now and why don't you go do that somewhere else or do that in a fork or whatever it might be but they know that there is a sense of responsibility to ask you and to ask everyone else not just me or not just me specifically because I started the project but anyone hey what do you think about this thing inside Rabinius and that sense of responsibility drives them forward in an amazing way that I hoped but I didn't know if it would happen on the other hand like I alluded to before this does conflict with the idea that you want to say no so I kind of got ahead of myself it's important to communicate about the features that you want it's important to communicate what the goals are for your project and if someone decides hey I want to go off and do something really wild and I do this to myself I have a tendency to oh this would be an awesome feature but it's going to take me three weeks or it's going to do something crazy rather than push and force everyone to deal with that I go off and I do it in a fork or I do it in a branch and pushing that people to do the same for those wild and crazy things but having those people and those forks integrated with the project to say okay oh you finished with that let's go see it oh it works in a completely different way than I had thought we totally want that and now you can integrate that back in but you have to be communicating with the person they have to trust you and you have to trust them and there's all the sense of those things so on the flip side again as a contributor remember these laws it's important to remember that a project hopefully is adhering to these things that they've got all these things in mind that they want to trust you that they think you're important so from that it's easy to get your ego tied up in what you've done because you feel like a patch is yours you feel like it's a part of you and when someone comes and they say no we don't want that right now it's so easy to feel like you're being rejected on a personal level but in this case this project is just not ready for your awesome that's the way to think about it they want you to be in the community they want you to help but what you're doing right now is not where they want to be yet so you have to figure out okay well that's great guys I realize you don't want to right now I still want to be a part of your community I still want to be a part of this project I will do this in open source development is not a thing for software it is a thing for people it is completely a social contract you could have open source development for construction working it is not related to software and it is all about the idea of how people are going to integrate with the project it's important also to remember that contributors to your project want to succeed help with your project they want to see your project succeed but they also want respect they want to know that you're not going to just eschew them that they're not something to just be brushed aside as annoying so it's important to remember that if you give these people respect for what they're working on they will give you respect back if you say I realize what you want to do but we're not ready for that then they will return that saying okay great I will be respectful of that and I will go off and I'll do my work somewhere else or I'll figure out how to communicate with you to integrate this in and so it's really boils down to we all just want to be loved these people want to feel like they're a part of something they want to feel like they want to feel that sense of community for working on the project and they want the project to succeed for them to know that they you as one of the existing members of this community want to know that they respect your work that they think that your decisions are important and that you have the that all of you can work together towards pushing your project in a new and exciting direction and so with that go work on a project I think we do we have time for any questions or two Ryan do you want to say what you're saying about testing frameworks with the microphone okay questions thanks I really enjoyed that question can you talk a little bit about how important marketing is with open source projects that I get the sense that open source projects that really focus on marketing do really well sure I am no expert in this because I don't honestly I could market my projects much better than I do and I'm aware that other projects do a great job but that in my opinion is the same as you'd market anything else you want to get people excited and you want to use all these same techniques to get them in the door so if it's with say it's with a project like Rails which is a very good marketing and it very has a lot of enthusiasm for it they have sort of pushed and people will contribute back in because they've made it easier to do that I think so I can't speak as much to that because I don't think I do it very well so that's sort of my not answer if you will anyone else? Ryan wants to heckle some more so go ahead that was a great talk thank you about communicating and how important it is with contributors can you tell us a little bit about some of the tools that you found works best for communicating with your team and why you decided to go with those? sure and this is a great question I think IRC is terrible personally but it is better than everything else I have had it is incredibly difficult to have a high level technical discussion about something that people feel passionate about in IRC without both parties getting completely pissed off in my opinion because there is so much line noise there is so much delay having to parse what the person is saying not being able to IRC is good but it sucks I'm a big advocate and just basically saying person who I don't even know what you look like do you want to have a phone call I would love to talk about this and when you do that with someone who maybe they have just committed their second patch or their third thing this is a great idea can we talk about this more on the phone they feel so excited this person is taking their time out of the day they are making a really concerned effort to discuss this with me IRC, phone I do video chat I have debugged over face time the thing whatever tool that you can use that gets you the lowest latency between the communication and the emotional state of the other person and IRC does not communicate emotional state which means that everyone gets riled up essentially so yeah screen share is also really good for this we do screen sharing sessions with audio because then you can see what is going on and you can hear the other person you can hear that they are getting frustrated so you can know to back off any other questions I think we are going to wrap it up we will talk about it later thanks everybody