Helping Yourself with Open Source Software

08 June 2017

Learn what open source software is, why you should contribute and what effectively run open source projects look like.

Presented at RubyConf Kenya in 2017.

Show transcript

0:00 Thank you.
0:30 Can everyone see the screen okay?
0:34 Is that working?
0:35 Great.
0:36 Well thanks very much everyone for having me today.
0:41 I'm coming here today with like two different hats that I wear in terms of my use of Ruby
0:47 and in terms of like what I do as a software engineer.
0:51 So the first one is I use Homebrew and I'm one of the maintainers of Homebrew.
0:56 I've been a pre-maintainer for the last few years.
0:59 Homebrew is a package manager for Macs.
1:01 If anyone likes it and uses it then I've got some stickers that I'll stick outside at the
1:06 front.
1:07 You can check out.
1:08 So I've been working on that since 2009.
1:10 That's basically like a way of installing software for it.
1:14 Does anyone here use Homebrew?
1:15 Yeah?
1:16 If you want.
1:17 Cool.
1:18 And then my second role or the one that actually gives me money is working with GitHub.
1:25 So people who use GitHub, raise your hands.
1:27 Cool.
1:28 Yeah.
1:29 I've been working there for about three and a half years.
1:36 I work as an engineer there.
1:37 And at the moment my main focus is like working on open source stuff.
1:40 Trying to make GitHub better for open source software and people who are building open source
1:45 software.
1:46 So feel free anytime you receive during the conference if you want to talk about Homebrew,
1:53 if you want to talk about open source or GitHub then just get in touch and we'll have a chat.
1:56 So start off with the basics.
1:58 So what is open source?
1:59 So who here thinks they know already what open source software is?
2:04 Let's put your hand in the air.
2:05 There's going to be a lot of putting your hands in the air by the way.
2:08 So you can swap between hands if one gets tired or if you feel like you really know something,
2:13 two hands.
2:14 And I'm also watching after people who don't know how to put their hands in the air because
2:18 you might be asked to come and dance or something like that.
2:21 Right.
2:22 So a fair few people know it but not everyone.
2:25 So open source software, this is the definition I took from open source dot com which is more
2:30 or less like the kind of place where people are writing about kind of official definitions
2:36 of what it is.
2:37 So effectively it's software where the code is available to you so that you can choose to change
2:45 the code and change the software.
2:47 So it's basically you have a bit more control over the software.
2:51 It's maybe to everyday kind of people who work on, you know, writing about computer science
2:56 or engineering, then it's kind of the same to them perhaps.
2:59 Generally it's maybe available for free of charge.
3:02 But as an engineer, then the cool thing about open source software is if I see something in it
3:06 that I think should be made differently or I want to work differently, then I can change that.
3:11 At least in theory.
3:12 So why should you use open source software?
3:17 So again, stick your hand up in the air if you use any sort of piece of open source software.
3:22 So anyone who hasn't raised their hands is probably wrong because almost everyone nowadays is using open source in some way.
3:29 If you visit almost any website now, almost any website you will interact at least in some way with some sort of open source.
3:36 You know, Linux is used on most servers now and then increasingly Microsoft, who used to be the biggest proponent of open source software,
3:44 they're using more and more open source now as well.
3:46 So practically every website you will ever touch will have lots of open source software that will be involved with the different kind of websites you can use.
3:55 So I guess the main reason that people are interested in open source, particularly nowadays,
4:00 and a reason why it might be relevant to you is that generally it's always free to use.
4:05 So things like Google Chrome, things like OpenOffice, things like Firefox, the browser we used to use.
4:12 These are all things which are available freely and the reason why they're available freely is because they're open source software.
4:19 They may have companies behind them or they may not.
4:22 In my case, working on Homeproof, Homeproof doesn't have any company behind it.
4:25 No one aids anyone working on Homeproof to actually work on Homeproof.
4:29 So we're all just volunteers during our spare time.
4:32 But there are companies like Google who have released a bunch of open source projects where they're being funded by people working full time at Homeproof.
4:39 So it's also really widely used now.
4:43 You know, maybe 25 years ago or something, there was bits and pieces of open source around but they weren't ever kind of the majority in any sort of area of software.
4:52 Whereas nowadays, I think in most areas of software, certainly on the back end, stuff which doesn't have a website, like increasingly all of that software is becoming open source.
5:05 And open source technologies are just winning because they are more widely used.
5:11 So, I think that's a good argument for using it yourself as well.
5:16 Because open source is, if you specialize in open source tools, then you're not going to specialize in something which is controlled by a single company.
5:23 And you're also using something which is going to be .
5:29 So, it's often in my experience, most open source software, not all of it is kind of well documented, not all of it is documented at all.
5:37 But most of it is generally reasonably well documented.
5:40 And I think the thing that's good about open source is, although when the documentation isn't there, because it's so widely used, you can see so many people on sites like Stack Overflow and around GitHub who may have the same problem as you have.
5:54 So, as a result of it being widely used, you can kind of speak with those people and figure out together how to solve some of these problems that you might have.
6:01 And for me, again, that's, I remember back in, you know, maybe like eight years ago now, when it was kind of coming to the end of people starting to use, you know, if you wanted some library for your application, you might, you know, actually pay and buy a library off another company.
6:16 But the problem with that approach was when there was problems with that library, because the company only had, you know, maybe hundreds, thousands or even 10,000 customers, there's just far fewer people on the internet using and talking about this stuff.
6:29 So if something doesn't work the way it's meant to work, you can't get that immediate help.
6:33 You can contact the company for support and help.
6:35 But again, you're still reliant in that case on like having a conversation rather than having that information and that conversation having already played out.
6:44 And to sort of very tangentially like ram this into the flow of the conference, I think open source is best for like agile and for entrepreneurs because of the reasons I've stated already.
6:58 Because it's freely available for people to use because it's widely used and not tied to a particular company.
7:03 I think it allows, you're starting a company, it allows you to get started much more easily because you're not paying for a bunch of software to experiment with and learn new things with new technologies.
7:14 But you can just go out there, take stuff off the shelf that other companies are using already.
7:19 So for example, a database like MySQL, you can just download that and use that freely on Windows, Mac or Linux today.
7:26 But that's also being used by companies like Facebook to power like, I guess what's probably the biggest data storage in the world.
7:35 So the fact that increasingly these tools which some of the world's biggest companies are using are available to you to freely use on your laptop or your server or whatever, I think it makes a really strong argument for why I think that's important.
7:49 So let's have a little segue on to what is GitHub.
7:54 So I already asked you to raise your hands about what GitHub is, so I won't ask you to do that again.
7:59 One sec.
8:03 So some little vital statistics for GitHub and how it relates to open source software.
8:08 So GitHub is roughly today like 21 million developers we've got working on GitHub.
8:15 Not in the company obviously, that would be impressive.
8:18 But 21 million people use our site in some form.
8:22 And about 58 million repositories.
8:25 If you haven't used GitHub, a repository is basically what we call like a project.
8:29 So they're separated, everything on the site, all the projects basically are separated under the username or an organization name if it's kind of being shared between multiple users perhaps.
8:41 And then the repository name.
8:43 So of these repositories, as I said, 58 million.
8:47 We've got about 28 million of them are public.
8:49 On GitHub you can choose with any of your repositories whether it's public or private.
8:53 Public ones are available for free and private ones you need to pay money to use.
8:58 So obviously if you're a company trying to keep all your stuff secret, then generally you would have a private repository.
9:03 And if you're doing work in the open, then you're going to have a public repository.
9:07 So of these 28 million public repositories, we consider about 20% of them to be open source software.
9:13 So that's ones that have a license, ones that have various other characteristics we've determined to make them open source software
9:20 and not say someone following a tutorial or whatever and it's not been licensed in that way.
9:27 So these kind of projects, they vary a lot in terms of the different technologies they use, in terms of the size they are and stuff like that.
9:33 So some four examples of like big projects you may have kind of seen or heard of, depending on the language you use, I guess one would probably be more well known to everyone in here.
9:44 So you've got Node.js, Django, which is kind of like Rails for Python-ish, and then Rust, which is like a new programming language, and Rails itself.
9:56 So as you can see, these are all projects that have like lots of people have contributed to them.
10:01 In Rails' case, you've got like over 3,000 people have contributed in some form.
10:05 So by contributed, I mean that's someone who has in the repository, they've submitted some sort of change that has ended up making it there in the repository.
10:15 So there's someone who at some point has helped to kind of make the project what it is and helped build it.
10:21 So I think that's, again, one of the really cool things about open source software.
10:24 As I mentioned earlier, everyone can kind of modify it, but then you can modify it and you can submit your changes, so other people can make use of your changes.
10:32 And other people can build upon your work, and you can have this community that are working together.
10:36 The other cool thing about all these four projects is none of them are controlled by like a single commercial company.
10:42 There's companies that have more influence in each of these projects, but there's no single company that gets to decide this is what happens entirely with any of these projects.
10:51 So they're basically run by a community of people, a significant number of which are doing it for fun in their free time.
11:00 So how can you get started in open source software?
11:03 Well, I guess there's lots of different ways.
11:06 I guess one way would be to start using it, to download something like MySQL or any other piece of open source software, Ruby itself, Rails, and just start using it.
11:15 But then what I like to think about a little bit more today is how you can start getting involved with open source as a contributor in the community.
11:22 So one of the best places I think for that will go into a lot more detail than the stuff I've talked about in this talk is the open source guides.
11:31 This is something GitHub worked on recently.
11:33 You can see it at HTTPS opensource.guide.
11:36 That basically has a bunch of guides on how to get first started with open source software, but then also how to kind of maintain projects, how to run projects, and various issues that you come across when doing that.
11:49 So I've got a bunch of little almost open source guides business cards as well.
11:54 I'll stick them with the stickers at the front.
11:56 You can feel free to take some of them away.
11:57 But yeah, I would recommend going on there and checking that out.
12:00 The other cool thing about that is the site itself is actually an open source project.
12:03 So you can go, and if you see a mistake there, you can kind of contribute to there and to that project, and we're kind of building that in the open as well.
12:12 But the main thing, I don't know if anyone else, has anyone heard this expression before in terms of talking about software scratching an itch?
12:20 So this is one of the best ways I think to get involved with open source software.
12:25 So the expression is generally scratching your own itch.
12:28 And what it means, I saw someone literally as I said that scratching their own itch.
12:32 So hopefully I'm not making people itch by saying that.
12:34 But by scratching your own itch, what I mean is, in software, the cool thing about open source software, as I said, is that you can modify it yourself.
12:42 So scratching your own itch is finding some piece of open source software you use, and then getting started by finding a small change that you think would be other people would widely appreciate that change or whatever.
12:55 And trying to make that change for yourself, and then submitting it back to the open source project.
13:01 So for me, that's how I got involved with Homebrew and various other projects, is that I saw this project out there.
13:07 It was doing like 90% of what I wanted it to do, but it wasn't quite as useful to me as it could be.
13:14 So I wanted to go and get involved with that project, so I could kind of scratch my own itch, so I could make it better for me, but then while I made it better for me, I also ended up making it better for everyone else who uses it as well.
13:26 So let's have a little think now about what the different groups of people are who work on open source.
13:32 So I mentioned before that you can kind of get stuck with open source just by using it, and there's these people called contributors, and I'll talk a little bit more about people with goal maintainers as well.
13:42 So the users of open source software are everyone.
13:46 As I mentioned, whether people know it or not, almost everyone is using open source on an almost daily basis now.
13:51 But we're going to think a little bit more now about the type of users who maybe are at least aware they're using the open source project.
13:58 They maybe know that the open source project has a repository on GitHub.
14:02 They maybe have submitted issues or bug reports to an open source project, but they haven't themselves kind of contributed to that project yet.
14:10 The next group of people are the contributors.
14:14 So these are people who have written some sort of code that have made it into the project, or it could be documentation or whatever.
14:19 Basically anything that makes it into the project repository on GitHub.
14:22 We're going to think about them as contributors because of people who contributed something to the project.
14:28 So, but these are people who, at least in my definition I'm going to use today, people who don't themselves have the rights to just make changes without permission.
14:38 So obviously with Rails having 3,000 people who have worked on it, not all those 3,000 people are maybe trusted to make every change every time.
14:48 So what you have is the next group of people called the maintainers, who are the people who have commit access to the project.
14:55 So generally the way things work on GitHub is you have a contributor will submit what we call a pull request, which is then viewed by the maintainers.
15:05 And it can be viewed by anyone in fact.
15:07 But a pull request is basically saying, hey, I've made this change on my version of the project.
15:12 And I would like you to pull this change into the main project itself.
15:16 So, and then there's generally some sort of code review happens, testing, automated or manual.
15:22 And then basically if that looks good enough, then that pull request will then be merged by one of the maintainers.
15:27 So the maintainers are the people who are going to have the rights.
15:30 And they're going to be the people who will decide whether or not that change is good enough yet.
15:35 It might mean that it needs to go back and forward a few times, maybe some code reviews spot some problems that need to be changed,
15:42 or the automated tests fail or whatever.
15:45 So the maintainers are the people who are kind of guiding people through that process.
15:49 So I think it's worth noting that with contributing to open source software, as I mentioned before with scratching an itch,
15:56 no one ever really became a contributor, particularly, I mean, it does happen sometimes, but most of the time,
16:03 let's say no one ever becomes a contributor without being a user first.
16:06 So that you should probably be spending the time, if you want to contribute to open source software,
16:10 trying to or managing to contribute to the projects you already use.
16:13 Because that's how you're going to end up being most successful, I think.
16:16 And if you want to be a maintainer one day, well, the way of doing that is by contributing to a project first.
16:22 Unless you start your own project and it becomes very successful, which is not unlikely, but just it's hard,
16:29 and there's a lot of other projects that kind of need help today that might be better uses than starting your own thing.
16:35 The best way of getting down that path and becoming a maintainer is just contributing.
16:40 Because ultimately, almost no one ends up starting out wanting to be a maintainer.
16:45 People end up on this path, they contribute a few times, their contributions get better and better,
16:50 and then eventually they get asked to be one.
16:53 And finally, if you ever do find yourself being a maintainer of open source software,
16:57 I don't think anyone can stay being a good maintainer of that software if they don't use the software anymore.
17:02 So, to be a good maintainer, to be someone who is able to make good decisions on what should and shouldn't be in the project,
17:08 you should really be using that project.
17:11 So, the way we think about it, at least on Homebrew, is this idea of almost like a funnel.
17:16 So, let's have a look at some kind of some numbers for Homebrew.
17:20 So, based on Google Analytics, Google Analytics says Homebrew has about 4 million users.
17:25 I reckon it's more like, you know, 1.2 million.
17:29 So, of them, we've had about 6,000 contributors.
17:33 So, that's 0.05% of our users, roughly.
17:37 And then we have 17 current maintainers, and about 25 maintainers in total,
17:42 because some have kind of left the project over the years.
17:44 So, that's 0.0015%.
17:47 So, as you can see, like the numbers on an open source project of people who are going to contribute,
17:52 they vary from project to project, and maintainers vary from project to project.
17:56 But, you can expect that you're always going to have way, way, way more users than you're going to have contributors,
18:02 and probably a lot more contributors than you're going to have maintainers.
18:06 So, how can we kind of...
18:08 So, I'm going to think, at the moment, with my Homebrew hat on.
18:11 So, if I'm a Homebrew maintainer, how can I get more contributors from my project, if I have all these users?
18:17 Well, as a starting point, I think most people who contribute to a project were kind of talked into it in the first place.
18:24 Although it's great, and hopefully I can kind of motivate everyone here to go off and try and contribute to an open source project after today.
18:31 Not everyone is always kind of motivated to do that.
18:34 So, one of the ways of convincing people to do that sometimes is if they are having a problem, then you can kind of, as I'll show you in a little bit,
18:41 you can sometimes kind of convince people, okay, well, I'm going to help you solve your own problem, rather than just solving it for them.
18:48 And with maintainers as well, similarly, a lot of people don't necessarily want to be maintainers.
18:55 They don't kind of think of themselves as contributing to a project so they can become a maintainer.
19:00 But instead, they get talked into it because they make enough kind of good contributions that they get asked to be one.
19:06 And ultimately, I think, in my experience with asking other people to be maintainers, like, almost always, people think they're not qualified for the job,
19:14 and that they're being asked wrongly or whatever, and they need some kind of convincing that they're going to do a good job.
19:21 So, let's have a look at some homebrew examples of this.
19:23 So, I don't know how easily you can see on the screen, but this was an example of a tweet homebrew got,
19:29 where someone was complaining, "Brew update," which is our kind of update tool, "fails with the permission denied.
19:36 Could this be related to the version of Mac OS they're using? Please advise them where to get help."
19:41 So, with this person, what we're trying to do, and we then link them to our issue tracker,
19:46 and how to, like, a link that doesn't show the full link, but how to kind of file a good issue, basically.
19:51 So, what we're trying to do here is we're trying to, like, again, like, almost, like, upsell or kind of convince this person,
19:57 okay, rather than just asking for help on Twitter, we're going to try and help you learn how to file a good issue on an open source project.
20:03 Because if you want to file a good issue, the best way of doing that is by making sure that, basically, other people can see how you've done that,
20:12 and what you need from the project, and what the project needs from you.
20:16 So, you need to make sure that you provide all of the information that the project needs to know,
20:21 like things like the project version you're running, things like what the things you were doing that produced the problem were, and stuff like that.
20:28 And then they're going to ask more information from you, and you need to have that back and forward to figure out what the problem is,
20:34 and then to hopefully provide some sort of fix for that problem.
20:37 So, something like this, when you just ask on Twitter, like, what the problem is, that doesn't give us enough information to figure that out.
20:44 So, we're trying to help him figure out, okay, not only how to give homebrew more information, but also how to file better issue reports in future.
20:52 So, something we might put on an issue to try and help people in the right direction, and I've occasionally used this with coworkers
20:59 who want me to help them with a problem, but aren't explaining it very well.
21:02 It's saying, okay, so, for us to debug this issue, ask, what were you trying to do, and why?
21:08 So, generally, that's stuff like, what command were you running?
21:12 What were you trying to accomplish with homebrew?
21:14 It's generally something like, I was trying to install some package, and it didn't work, and this is what happened.
21:20 Then the next step, as I said, is what happened?
21:23 So, was there an error message? Did it just never complete?
21:26 Did it take a long time? Did it take longer than you expected?
21:28 Basically, like, what was the difference between that and the next one, which is what you expected to happen?
21:35 Because I'm trying to figure out what the difference is between those two things.
21:38 Because it could be that what you expected to happen is what's incorrect, and what happened is what's correct.
21:44 In which case, we can help you understand that.
21:47 And then, finally, kind of step-by-step instructions to reproduce the problem.
21:52 So, again, in any software project, I think this is a big thing that hopefully you can take away today.
21:57 Like, the best way of ever finding out and helping other people to help you fix bugs is to make sure you have step-by-step reproduction.
22:05 And by that, what I mean is a series of commands or actions you can perform that will produce the same bug every single time you run them.
22:14 Obviously, with not every bug, not every time is that going to be possible.
22:18 But I think if you can manage to get that, then it makes it much, much easier for people to fix that, because then they can go and then follow the same steps, and then they can start to kind of debug it and then figure out what the problem is.
22:31 So, the next thing we might do is if someone has got in the habit of filing good issues that have this information, then if they ask for help on an issue that seems like it would be relatively easy to fix, but they haven't yet submitted a fix for it themselves, then I might say something like this.
22:50 So, I say, again, I'm not sure if you can all read the text.
22:53 Could you try and open a pull request?
22:55 This document, which links them to a document on how to do that, should help, and I'm happy to walk you through anything else.
23:01 So, what we're trying to do here is trying to convince people who are submitting issues to consider, okay, well, maybe you can fix this issue yourself.
23:11 Maybe you have what's, maybe you have it in you to kind of figure out and solve this problem with help from us, and then you'll have the satisfaction of solving that yourself.
23:21 I think with Homebrew, it's maybe easier for us than it is for some projects, because most of our users are software developers, so the majority of people probably do have it in them to kind of make some sort of change.
23:34 But I think it's a good thing to kind of encourage in open source anyway, is this idea that we are all in control, and we can all, given enough time and help and learning, we can all kind of solve our own problems.
23:46 So, this is our little snapshot of that document we have before.
23:50 You can, again, it's, the colors are such, you can't really see it.
23:54 If you go to docs.brew.sh, that's Homebrew's documentation site, and then it's kind of relatively prominently on there.
24:01 And we try and walk people through the step-by-step guide on what it needs to take to open a pull request, and more importantly, to get it merged, i.e., for us to accept it.
24:11 So, trying to get people guidance on what type of things are required for us to know that your work is good enough for us to include in the project.
24:20 So, similarly with maintainers, we have a document for this as well, which kind of walks through some of the expectations, in case you're interested, of what we expect from a new maintainer.
24:33 So, what type of things do they need to do, what type of things do they need to demonstrate, and how do we kind of communicate with that person that they should be a new maintainer.
24:43 So, the last section of the talk I'm going to get onto is, how can you go about keeping each of these groups of people happy?
24:51 So, you've got the people who use the software, the people who contribute to the software, and the people who maintain the software.
24:57 All of these groups are important. Obviously, without any users, there's not really any point in the software.
25:02 Without any contributors, you don't have that kind of large number of people who are going to be helping make the software.
25:09 And you also don't have people who are going to come in and replace other maintainers when they leave.
25:15 And without the maintainers, you don't have anyone who can kind of control access to the software, maybe make new releases and stuff like that.
25:22 So, for users, I think the thing most people care about is high quality.
25:29 Who in here likes it when they come across bugs in software they use? No one. Okay.
25:35 So, the most important thing to do, I think, with any piece of software is to focus on it being high quality.
25:41 That doesn't mean necessarily the code always needs to be high quality, but that means that using the software should be a pleasant experience.
25:48 It should not be very buggy. It should not be filled with lots of problems.
25:52 So, as a result of doing this, I think you need to be careful, if you're running an open source project or any software project,
25:59 that you maintain the quality of the project whilst making it better, whilst adding new features, whilst adding new changes and stuff like that.
26:07 Because, ultimately, if your quality keeps getting worse, then people are going to stop using your project.
26:12 Or, if it's a paid project, stop paying you money and go to one of your competitors who has managed to maintain that high quality.
26:19 So, the second one, and this relates to maintainers mostly, is relates to the first, which is don't merge things out of guilt.
26:28 So, in some open source projects, if someone's worked really hard on trying to solve a problem, but their code is maybe really still buggy or it's going to cause problems down the line,
26:38 Sometimes, and I've done this myself, it can be tempting to maybe just include their work because you feel really bad about them spending all this time and it's maybe not good enough yet,
26:47 and you don't think it maybe is ever going to get good enough, just because it's maybe a problem that can't be solved in a clean, nice way.
26:57 So, in that case, it's worth politely just declining the pull request if it's on GitHub, rather than merge something that you think is going to make the project maybe a little bit worse,
27:09 but maybe make you feel a little bit better.
27:11 Because, eventually, that's going to come around and it's going to cause more problems for you than it solves.
27:16 And the last one I would say, again, this applies to most software projects and is maybe controversial.
27:21 By no V2.0, what I more mean is what's kind of common more in open source projects than in closed source software, but happens in all software,
27:32 is that sometimes the temptation, if your code maybe isn't that great, if your project's not working as well as you want it to,
27:39 to just say, okay, I'm going to throw away everything I've done so far and I'm just going to start again from scratch and make a complete replacement for the existing tool.
27:47 Now, this is almost always a very, very, very, very, very, very, very, very, very bad idea.
27:57 And the reason is because while you may be able to introduce new features, while you may have new code and everything will be nice and clean after you do that,
28:06 you're also going to have all of the bugs that you fixed in the old version.
28:10 Maybe you might not have all of those bugs will come back, but you're going to have a bunch of new bugs that are going to come back from new code that hasn't been tested as much as the old code has.
28:19 And also in general, if you have a tool, again, either a tool that people pay for or an open source tool, I think this applies to both.
28:27 If you completely change the way it looks, completely change the way it behaves, then it's sometimes as easy for your users to use your new version as it is for them to just move to a competitor or move to another project.
28:40 And with open source, you see this happen relatively often that people release some new version of, say, a library, and they make it so that everyone who uses the library needs to completely rewrite all their code so they can use the new version of this library.
28:52 And what that ends up meaning is that actually I'm going to go and use another library instead because I trust that library now to not make me have to rewrite all my code every few years.
29:02 So for me with homebrewed, this has been an example where we have, you know, the way our packages are built, we call them formula.
29:10 So if we made a new version, the temptation would be to make a new formula thing which solves all the problems with the existing one.
29:17 But then all the thousands of formula out there and the thousands of contributors and the probably, you know, as I said, millions of users are not going to have the same functionality that they were used to before.
29:28 We almost have to start from scratch and build all this stuff again.
29:32 So although that would be tempting, that throws away a lot of the progress we've made over the last eight years.
29:38 So I think it's not advisable.
29:40 So thinking about contributors, how can you make a project that is good for contributors?
29:46 And how can you have, as a contributor, a good influence on a project?
29:51 So the first one is, has anyone heard of bike shedding, talking about that with software?
29:57 Okay, so bike shedding is this idea with software that again applies with both open source and closed source software.
30:04 That if you ask people, say you have some really complex part of the code, and you ask people for feedback on, you know,
30:11 how should we change this code so it can be kind of, you know, easier to work with and stuff like that.
30:16 Like, you might get a few opinions from a few people.
30:18 But if you say, okay, our office has a bike shed, I think the bike shed should be painted red.
30:24 Then everyone in your company and everyone in your project will be like, no, I think it should be blue or green or yellow.
30:30 And it's basically because there's certain decisions in any project that are, or any company,
30:36 which are very, very easy for everyone to get involved and everyone to have an opinion.
30:41 And it's very easy to have these discussions, particularly in open source projects where everyone can kind of think, no, I like A or I like B or I like orange or bananas or apples or whatever.
30:51 Like, and these conversations often end up spiraling out of control and you just end up with hundreds, sometimes even thousands of people arguing about something while none of them are actually volunteering to do the work.
31:05 And it's not really a conversation that can reach a helpful conclusion.
31:09 So both if you're contributing to an open source project and if you're trying to help contributors be more effective on an open source project,
31:17 trying to stop those conversations getting out of control so that they don't become bike shedding and instead keeping people focused on specific questions that can have some sort of actionable, like technical outcome.
31:30 So the next one is like open discussions.
31:35 So we, you probably do want somewhere that people can kind of maybe talk about what color the bike shed should be, but that should not be on the main, say issue tracker for the project.
31:46 That's a good place for that is not when people are trying to talk about bugs, when people are trying to talk about the code, but that can be going to happen somewhere else.
31:54 So for example, this homebrew uses a tool called discourse, which provides like a forum for us.
31:59 I think that's freely available if anyone else wants to use it as well for open source projects at least.
32:04 And that allows us to go and say, okay, if you want to just kind of talk about homebrew, then you can go and do that over here instead.
32:10 And if you want to kind of focus on homebrew's code and like working out how that should be done, then we do that on the GitHub issue tracker instead.
32:18 And finally, in homebrew's case, we try and not get people to create lots and lots of issues on our issue tracker about features.
32:30 And in general, when you're contributing to an open source project, you should be very careful about submitting feature requests.
32:36 And the reason why is as I said before, you are often capable of making things yourself.
32:41 Like if there's new features, you may be able to build that yourself.
32:45 And the problem is, is that because there's generally so many more users in open source than there are contributors or maintainers,
32:52 there's a lot more time spent on suggesting features than there is on building them.
32:57 So in homebrew, we generally don't allow any new feature requests that we don't have one of our maintainers say, okay, this is something that we definitely want to build in the near future.
33:07 And that basically just stops it getting out of control and having hundreds or thousands or more of issues, which we've sort of said, okay, maybe we'll do this at some point.
33:17 And then we never do. And that's unfair to the person who submitted the issue because we've kind of promised them something we can't deliver.
33:24 And that's unfair to us because it makes our issue tracker hard to use.
33:28 I would say this is the case, not no feature issues, but even when you're working on, again, closed source software as well,
33:35 it's always worth thinking about the things that you say in your project.
33:39 Yeah, this is nice to have. We would like to do this one day.
33:42 Like in my experience, anything that is not, you don't have a plan for when it's going to get built.
33:48 Say if it's not getting built in the next two weeks or a month or a couple of months or six months,
33:53 if it's something that, oh, we might do that in a year, we might do that in a few years, chances are you're never going to do that.
33:58 So it's not worth spending too much time and energy thinking about a problem which is not going to be solved for a few years,
34:06 maybe not even be solved ever.
34:09 So, and finally, for maintainers, the things that we generally try and do for other maintainers
34:15 and to try and help our projects be more effective, the first one that are kind of being used more and more on GitHub
34:21 and at conferences like this and generally in a lot of things around technology is this idea of a code of conduct.
34:29 So that's basically just like a written document that describes what expectations you have of people participating in an event or an open source project or whatever.
34:39 Basically just like making clear that it's not acceptable to be racist or sexist or anything like that, for example.
34:46 And just writing that down makes it easier for people because they know that, okay, you as a community have said that these things are not acceptable.
34:53 And it also makes it easier when you're running a community because if someone behaves in a way that's inappropriate,
34:58 you can point them to this document and you can say, okay, you're not behaving appropriately,
35:03 but also we're not picking on you, we've written this document and it's about your behavior that we've written down before you behave in this way in this document.
35:12 So can you please change your behavior if you want to remain part of our community?
35:17 And next thing I think is important in open source is that maintainers have a private space they can talk about things sometimes.
35:24 In homebrew there's one of the maintainers who I disagree with quite a lot, but I like him and I respect him.
35:29 And it's helpful for us sometimes to have our kind of sometimes heated arguments in a private space where other people don't have to see us maybe kind of arguing with each other or whatever.
35:40 And then we can come at the end and try and reach some sort of kind of helpful conclusion that we can present to other people,
35:47 rather than having to have like a loud discussion in public.
35:51 And the last thing I think that is most important to open source, to maintainers, and to everything is to be always growing.
36:00 So maintainers should always be looking out for more maintainers, contributors should always be looking out for more contributors that they can help,
36:07 and people should be looking out to get more users for an open source project.
36:11 Because this is how, as I said at the beginning, open source is a community that we all kind of share and that we're all part of and we're all using.
36:19 And the only way this community can be sustained is by ensuring that more and more people,
36:24 as they come into that community as users, more and more people come into that community as contributors,
36:28 and more and more people come into that community as maintainers as well.
36:32 So with that, I think that's me, and if anyone has any questions, I'll be happy to answer them.
36:38 Are we doing questions, Michael?
36:40 Yeah?
36:41 Anyone?
36:42 If you have any other questions?
36:43 Oh, there we go.
36:44 Male Speaker 2: So I have a maintainer.
36:45 Male Speaker 2: So I generally thought I felt you're trying to do that.
36:46 If you have any other questions?
36:47 If you have any other questions?
36:48 If you have any other questions?
36:49 Male Speaker 2: So I have a maintainer on the open source project.
36:50 Male Speaker 2: So I generally thought I felt that's happening.
36:51 Male Speaker 2: Yeah, so if you have any other questions?
36:52 If you have any other questions?
36:53 Oh, there we go.
36:54 Male Speaker 2: So I have a maintainer on the open source project.
36:57 So for example, full request and what is a polite way to decline the full request or maybe
37:11 ask for changes?
37:12 Male Speaker 2: So what I have felt is a way to do is maybe write some sort of suitable
37:23 code for them.
37:24 So the way to do it is maybe write some sort of suitable code for them or it may not work.
37:31 But was it right?
37:32 But they are not just complicated.
37:34 But they don't have an idea how to go about it.
37:39 So I feel like it's kind of so that something is on the table.
37:45 So that's how I feel.
37:50 Thanks.
37:58 That was a really good question.
37:59 Did everyone hear the question okay or did you need me to repeat?
38:02 No?
38:03 Cool.
38:04 So I think the best ways -- and I think this applies to progress in people you work with as well.
38:11 So the first best way, I think, is making sure that -- and you can't always go back and do this retroactively.
38:19 But trying to have as many of your checks be automated as possible.
38:23 So for me with Homebrew, my guide is if I give the same piece of review feedback three times, I want to try and write an automated check for that.
38:31 And there's a few reasons for that.
38:33 One is because then people can get feedback on their computer before they even submit the pull request if they can run that automated check locally.
38:42 Another one is that then they can get that immediately after they submit the pull request rather than having to wait for me.
38:47 And then a third one, which is -- I don't know whether this is true or not, but in my experience, people respond better to negativity from robots and positivity from humans.
38:59 So if my robot says, okay -- and by robot I mean like, you know, automated tests or some bot user on GitHub or whatever.
39:09 If the bot says, okay, you need to make this change and this change and this change, it doesn't feel like it's a human who has a problem with me.
39:16 It's just like, you know, that's the system and it's obviously a system that predates me and it's not personal and no one's picking on me or whatever.
39:24 So I feel like that tends to produce more positive interactions.
39:28 And also it makes it kind of clear if you use GitHub, for example, if you set this up as continuous integration with something like Travis CI,
39:35 which provides free services for open source projects to do this, then people see like a big red cross at the bottom of the pull request or a green tick depending on whether it's passed or failed.
39:45 So I think robots are a really good way of solving that.
39:50 And then I agree with you.
39:51 I think that's a good point about trying to provide people like with a sample of the code of how you think it should look.
39:58 And you can with some stuff on GitHub now just do it for them, but I think it's sometimes more useful.
40:04 Even if people like literally are copying and pasting what you write into a new commit and then pushing that.
40:10 I feel like that produces more of a kind of helpful, responsive sort of feedback loop.
40:16 And then I think mainly the main thing is just being like nice, being friendly about it.
40:22 And yeah, some people are always going to get pissed off anyway because there are some bad humans and some good humans.
40:28 But I think if you kind of say thank you for your pull request, we really appreciate it.
40:33 Like this is looking really good, but I just have like a few, a couple of like small things that I'd like you to change before we can include it.
40:40 Stuff like that generally puts people on ease more than if they submit a change and then you immediately just make, you know, 40 suggestions of things that need to be changed.
40:50 And particularly, obviously something to avoid is ever being insulting about the code.
40:56 Even if it's the worst code you've ever seen in your life, you know, saying that that code is crappy doesn't help anyone.
41:02 That just makes it less likely that that person is going to want to contribute again.
41:06 Because fundamentally you're wanting with, as a maintainer, you're wanting people to walk away from the experience of contributing, feeling good about themselves and feeling like they can do more than they felt they could.
41:19 And if they don't feel that way, then maybe the pull request gets merged, but they won't probably want to do it again.
41:25 Because with open source, as I mentioned, the big thing is because a lot of people are doing it as volunteers in either their spare time or not being paid directly to do that.
41:35 If you make someone feel like crap, then they're not going to want to do that again.
41:40 So, but yeah, thank you.
41:41 Great question.
41:42 Any other questions?
41:45 Well, if anyone wants to ask me anyone personally, then just grab me anytime during the conference.
41:54 And thank you very much again for having me.
41:56 Thank you so much.

Mike McQuaid

Helping Yourself with Open Source Software