Almost every company today uses open source software to do business (whether they know it or not). Almost every company isn’t using open source software as effectively as they could. Learn from GitHub’s Mike McQuaid about how to use open source software in your organisation without succumbing to the most common of pitfalls.
← All talks 
Build Engineering Turing Fest 2018
How to Not Fail at Using Open-Source Software in Your Organisation
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Thanks, everyone. Thank you for having me today. It's really nice to be at Turing Fest. I wasn't able to be here yesterday, but I heard the talks were great, and I heard, particularly, I think the audience participation has been very strong, so people have set a high bar for you folks to continue with.
I'm gonna ask for some raised hands at various points during the talk. Firstly, can you raise a hand if you have any arms? Okay, I think some people anyway, I'm not going to question that, but you know who you are, okay? So thanks very much for having me today.
I thought I spoke a little bit about open source here last year, more from the perspective of contributing to open source and maybe maintaining open source projects. So I thought I'd spin it around a little bit differently this year and speak about how to use open source effectively in your organization.
I think nowadays, I'm sure most of you have some experience with using open source. In fact, how many people have used open source software knowingly in any form? Okay. Yeah. That looks like everyone. Great. So I mean, as we know, it's become part of the engineering landscape for everyone nowadays.
So it's quite important, I think, to know not just how to use open source software because we're all doing that already, but know how to use it effectively in a way that can make you better at your job basically. So I'm gonna talk to you today about how to do that, how to avoid failing and falling into some of the common pitfalls that you have often when using open source software, and how to hopefully do even better than that and be a shining example of how to do open source well.
So I come at this topic, I guess, Rachel mentioned already, with two different hats on. So my first is I'm a maintainer on Homebrew. I've been working on Homebrew for almost nine years now. Been the lead maintainer for the last two. And that is in fact, sorry.
How many people know what Homebrew is or use Homebrew? Okay. So some people know everyone. Homebrew is like a package manager for Macs. Is effectively like the little spin I call it is like the app store for your terminal in some ways, a good way of installing a bunch of open source applications and libraries and things like that in a really easy fashion.
So through that as well, I've come in contact with lots of other open source projects, and you get a good sense of both on the project that I'm helping to run and without encountering these other open source projects, what makes a project do well and what makes a project not do so well.
Also, if any of you are ever interested in contributing to then please get in touch. Out of interest, anyone here submitting a PR to Homebrew ever? No. Sometimes people have. Not today. Next year, I want to see all the hands up. Okay? Right.
So my other hat is I'm a senior engineer at GitHub. I was on their open source team this time last year, and I've kind of the whole time I've been there, my work in open source both as a user and as a passionate advocate of open source affects my day to day work at GitHub.
I wanna see GitHub be better at open source, and I wanna help empower the open source community to use GitHub better as well so that both sides can have a much better experience because I think they're so intrinsically entwined at the moment for good or for ill.
How many people in here have used GitHub? Yes. A few people again. So my other side thing, I guess, was mentioned before, I threatened to be doing this talk with a baby on me, but it's actually it's time for his nap right now.
I'm on my paternity live right now from GitHub, so I've been looking after my son for the last little while. He's actually sleeping out back, and you'll see him and me hopefully walking around the rest of the conference. If you are in any sort of management position in your organization, I strongly encourage you to try and advocate for fathers to get at least one month's paid paternity leave because it makes gender pay imbalance and things like that through various studies have shown, like, lesser in your organization and generally makes, I think,
the world a bit of a better place if mothers and fathers have more equal share in responsibilities. Anyway, that's my little political side topic. Let's go on to the real topic. Open source. Right. So I'm gonna talk about three points today. So why should you use open source software at all, and why are people using it, and perhaps why they are wrong to use it for the reasons that they are using it.
How to fail at open source software, because I can't just tell you the secret straight away or you won't step into the talk. And then how to win and do well with your open source contributions, with your open source usage, and generally with your be a good, upstanding member of the open source community.
So why open source software? So the first reason you may hear people say is this. Proprietary software, and by proprietary software, I mean software that is not open sourced. Basically, that is not sorry, this keeps jumping back and forth. Let's see. Can I convince it to go twice? Nope. Nope.
Now it's just going forward. Oh, wow. Oh, dear. Is it going to stay there now? Let's see. Nope. There we go. Okay. Yep. Okay. Sorry. The clicker is not my own, and it decides that it's not like me, obviously. Maybe I poured some water in it or something. Who knows?
Let's pour some more and see if that works. Right. Anyway, so proprietary software. I guess, as we all know, proprietary software generally costs money, and open source is generally free of charge. And as you've already had spoiled by jumping to my next slide already, we know that provides you software, as I said, it costs money to buy it, It costs money to pay for support.
It costs money to pay for training. And open source software, as you probably also had spoiled already, is free to buy. Isn't this fantastic? Open source software is free. I can download it. I can use it on as many computers I like, and I don't need to pay anyone a dime.
However, the support contract, if you want to have a similar experience with an open source project, I by that, I mean if you have problems, you effectively have someone who you have a relationship with who you can go and say, please fix this and have a reasonable expectation that they will fix this, that's gonna cost you money.
Similarly, in your organization, if you're using open source software widely, then you may need to pay a training provider or pay for training services. And that's not saying anything about open source software documentation because it's often, I think, as good, if not better than proprietary alternatives.
But in general, with open source software, you need to be willing to kind of spend that money and consider that your total cost of ownership with using proprietary software or open source software. So, again, another spoiled slide for you. This is something who's heard this expression before? Anyone?
Yeah. It it's a little bit cruel, and it's not. It's genuinely not intended as a dig on people who might use Linux on their desktop or their laptop or whatever. But I think it makes a reasonable argument that it's not without cost when you use open source software.
So what this argument is trying to make is the open source software may require, I guess as I pointed out before, support and training costs in a commercial organization. This is more referring to an individual level. You you can, I think, get the same experience on a Linux desktop as you can get on a Mac or a Windows machine or whatever, but it may require a little bit more investment of your time to get everything set up quite the way you want to get all your
hardware configured to make sure when you buy new hardware that it works with Linux and stuff like that? So as a result, that slight investment of your time, if you want it to be hyperbolic and funny, which I do because this is a talk and that generally does better on Twitter, is it's gonna be part of your part of your total ownership, part of the total time that you're investing with using that project.
So you need to factor that in when you're factoring whether or not that's a good decision for you or not. So this argument provides you software cost money open source is free. Yes. Okay. That's true. But I would kind of give that a thumbs down because it's not really a good reason, and if you're trying to use that to justify to other people why they should be using open source, it's generally not much of a winner to someone who kind of is gonna think through and ask you about maybe deeper
financial questions. So the next thing, I guess a common thing that people might raise is for proprietary software, you may need to pay for a service contract or whatever to get all the updates you want and things like that, And if you have problems, you need to go and speak to the the company, and if you're not paying them anymore, they're unlikely to fix things for you.
Whereas an open source, you can just file an issue, and then someone will just go over and fix it for you, which is great. And, yeah, obviously, problems get reported in open source projects, and problems get fixed in open source projects. But I don't think you can really rely on that, and let's see why.
So this is a screenshot of Ruby on Rails on GitHub from a few days ago. So they have three hundred ninety one open issues, seven hundred twenty three open pull requests, and one thousand sorry, eleven thousand three hundred closed issues. So clearly there's a lot going on here.
Clearly there's a lot of people who've reported a lot of issues. Clearly there's a bunch that have been closed, but you know, three hundred, and this is again no shade on the rails project, three hundreds are non trivial number of issues to be open.
And if you look through these as I did the other day, you know, you'll find some that are kind of years old and things like that. So obviously, some people have probably problems they've had with rails for multiple years, which they have reported and no one's fixed them for them.
Isn't this just terrible? Well, not so fast. So if we look at the rails contribution guides, obviously, you can't read that because it's teeny tiny, but the most important bit here, I read out in full because I think this is one of the best things I've read when I was researching this talk.
Okay. So then don't get your hopes up. Unless you have a code red, mission critical, the world is coming to an end kind of bug, you're creating this issue report in the hope that others with the same problem will be able to collaborate with you on solving it.
Do not expect the issue report will automatically see any activity or that others will jump to fix it. Creating an issue like this is mostly to help yourself on the path of fixing the problem and for others to confirm it with a I'm having this problem too comment.
So in short, you can't really expect other people to fix your problems for you. So this gets kind of a raised eyebrow. I wouldn't say it's a full thumbs down, but I would say that generally, this isn't kind of a good attitude to have towards open source.
It varies a lot from project to project, and generally, if you're a for profit company relying on volunteers to fix issues which are business critical to you, probably your customers are not gonna end up not being very happy with you. And I'd argue you're being a bit of a freeloader on the open source community unless you're contributing back in other ways.
So the third reason you might hear people say that, they use open source, is that everyone uses open source now. Well, I guess as we saw from our very scientific show of hands earlier, this is kind of true, really. So ten years ago, I feel like this would have been a bit more of a contentious claim.
You know, on the, say, the Microsoft ecosystem particularly on, you know, if you were a dot net developer on Windows, it may well be that literally nothing in your tech stack is actually open source. Whereas nowadays, almost everything on almost every tech stack is looking at more and more open source.
So how did this kind of come about? Who's using open source? Well, let's start from the earliest kind of folks to the later comers to the party. So I guess as I besmirched them earlier, let's be honest and say the links on the desktop people, and this isn't necessarily someone running up into their laptop now or whatever, but I'm talking about if you go back to the nineties, the people who went really, really all in on open source first were those type of folks.
The folks who were using the free software folks, the folks who were using Linux for pretty much everything, people who were using open source for pretty much everything. Like those were the kind of early adopters that kind of that we're sort of standing on the shoulders of today because without them, we wouldn't have all of the infrastructure and architecture that we have that backs up so many of the projects that we use.
Next, there's a kind of Linux on the server people I call them. So I guess this probably applies to a bunch of us in here. So people who are running Windows or Mac, laptops or desktops or whatever, but then they wouldn't think of doing anything other than running Linux on their server machines.
They accept that the use case for a server machine and a desktop machine are very different, and they accept that that applies kind of with software as well, really. So the next group of people, you start to see more and more companies like, who are kind of dabbling with open source.
They're using more open source to do more stuff that provides business value for them, and they're also starting to open source more of themselves themselves. Then, again, without naming any names, like you started to get more and more of the big companies getting on board, more and more enterprise companies who are realize that this is the way things are going, and they're gonna start selling this stuff to their customers.
They're gonna provide consultancy and training and everything around open source. And then, I guess, somewhat finally, you have Microsoft. As I mentioned before, ten years ago, Microsoft was very much on the other end of the spectrum in terms of, you know, their ecosystem not was almost like the anti open source.
And by that, I don't mean that they were rapidly opposed to it, although there was a time in the past where they were, but I mean that their ecosystem was the one that wasn't open source centric and generally didn't have that way of thinking and working.
But nowadays, even that has changed. So, yeah, pretty much everyone is using open source now, and I don't feel that's a particularly contentious claim anymore. So what open source are people using now? So again, starting from kind of beginning to more recent stuff, you had people started using it first for kind of servers and services.
We were seeing Linux being used for more and more servers. We're seeing things like Apache and I guess more recently NGINX being used on servers as well to kind of host proprietary applications. Then after that, we see server applications that are being used more, which are open source.
So we see more and more people hosting their blogs and websites on WordPress, for example. Then after that, although, you know, my chronology here is slightly off, so let's excuse it for the sake of bullet points that can't go side by side. We have more people using more development libraries.
So for example, SQLite, a nice little on disk memory sorry, on disk database that people can use. That is kind of has seen more and more usage in more and more pieces of software. We see the widespread use of kind of Ruby gems, NPM libraries, things like that.
Then our developer tools are increasingly becoming not just people some people using some open source development tools, but increasingly, I think we're at a point now where a lot of developers would in fact, out of interest, quick show of hands, who would use, say, a daily development tool which was not open source nowadays?
Just out of interest. Yep. So very few people now. So it would be interesting if I flip that question around how many hands I would get, but we'll we'll leave that for another time. But so developer tools like Git, I feel like one of the reasons why Git has done as well as it's done is because it's open source.
If it was a paid proprietary product that people were having to buy, it wouldn't have got the mindshare that it's got, and it wouldn't have kind of taken over to the same extent. And now, again, we're seeing even like companies like Microsoft who are open sourcing things like dot net, their new library visual studio code, which is really great.
I use it. And that's now open source as well, and Microsoft are going all in on things like Git as well. So I say all this just to kind of convey how much things have changed and how much everyone uses open source now.
Yeah. I think that's true. And I actually think with, hopefully, with the reasoning I've dispersed before, like, there's actually really good reasons for thinking that's a good reason of using open source software as well, because it has become a big part of the developer landscape for everyone to use.
So let's see now how to fail at using open source software. What are some of the common mistakes that organizations make? So who knows what I mean by forking a repository? Raise your hands if you know what I mean by forking. Cool. I'm gonna assume pretty much everyone.
So the very brief one for anyone who didn't raise their hand is forking. By that, I mean, kind of in the GitHub sense, let's assume for simplicity's sake, is when you make a copy of another open source repository, and then in the sake I'm gonna use it, we'll say you make some changes to it.
So quite often in your organization, I'm sure some of you have found in your day to day work, you maybe are using some library or some tool that's on GitHub, and you find that it doesn't quite work the way you want. And NPM or RubyGems or whatever allow you to kind of pretty easily use the fork in your own project.
So you think, okay. Well, I'll go and get this library or fork it or make the slight changes so it works the way I want, and I'll just do that for now. But pretty soon, I'll make sure that that's, you know you know, it's a it's a short term thing.
I'm not gonna rely on this. But in reality, this is what happens normally. You fork it, and then you never quite get around to doing it. And then before you know it, you're running all these random little forks of various projects. The problem with that is when there's, say, security updates or feature updates or whatever it may be to your little library, you need to then manually make sure that your changes play nicely with those new changes, and you need to apply your changes on top of that in your own fork.
You're effectively now maintaining your own little version of the library just for your organization. For some organizations, that may make sense. That may be some good reason why they need to do that. But often, what ends up happening is that just ends up being accumulating tech debt and building all these forks out and all these kind of slightly patched versions of libraries, which means that you can never update to the latest versions.
But that's okay because you don't need to worry about that because security updates might cause bugs anyway. Right? So if I just sit on the old version with outdated known vulnerabilities, then at least I know where I'm at. At least I'm not gonna cause any issues for my customers.
Well, maybe. But also, probably if you get hacked because you're running a known outdated version of software, and particularly for something like and this is just to name something that I happen to know is done this way. Again, no critique on the project itself.
If you're running a project like WordPress and you're sitting on an intentionally old version, then there are various bots that go around the Internet scanning for WordPress sites that are running slightly old versions to take them over and then use them for whatever people do when they hack things now, Bitcoin or send out spam emails or whatever it may be.
So probably your customers aren't gonna be super happy if you get hacked and that you have downtime, and they're probably also not gonna be super happy if you get hacked and people steal a bunch of their personal information as, again, happens more than often more than it should really, and you see a lot of these big public data breaches.
They have sometimes turned around and pointed the finger at open source projects where it turns out that the reason why there's the problem with the open source project is because they've been running an outdated version which published these announcements that it's outdated and there's security vulnerabilities, and the organization didn't update.
So a question for you in here, and again, everyone should probably close their eyes, even though you're actually not gonna close your eyes, so don't do it anyway. But everyone should probably close their eyes for this next one, because this is a little bit of a sensitive question.
How many of you can answer this question for your organization? How many libraries you use are on vulnerable or outdated versions right now? How many think that you could run a tool in your organization and get that result immediately? Not many people. You can now open your eyes again.
So I I would say that this is a pretty big wake up call. Like, GitHub is shipping features to kind of improve this stuff, but I don't think you can rely on GitHub alone to do this. There's a bunch of other tools. The one I like for the Ruby ecosystem that I think does some node stuff as well is Dependabot, which is I have no affiliation with them, I just happen to use them and think they're really great.
So they will go and, like, submit pull requests to automatically kinda bump versions of your gems and your NPM modules and stuff like that. You should really consider something like this for your organization because, again, outdated versions of things are bad, particularly when you're not keeping track of major security vulnerabilities.
If you have a decent sized security team, they may well be doing this for you, but if you don't, you should you have the right and reason to be slightly afraid, and hopefully that can motivate you to kind of check out some of these tools.
It's worth noting proprietary software still has these problems as well, but they're not publicly cataloged to the same extent, which if you believe in security through obscurity is a good thing, and if you don't, you would think it's a bad thing. So it's actually it's good news that you know this stuff with open source, that you can find out this information, you can hit this stuff with public APIs, query this information, and build a decent understanding in your of what is running outdated versions and what isn't.
Again, I'm not saying everything should be on the newest version at all times. Obviously, that way is a way towards madness and instability, but you should at least be aware of the risks you're taking if you're running intentionally old versions. So another way in open source of not doing very well is when you experience a problem with the open source tool that you use, you should make sure, because I'm sure you're very important, that you go onto the issue tracker and post a comment like this.
Make sure to tell them that you can't do any work right now, maybe even tell them that your company is very important and makes lots of money, and that this problem is stopping you making any money right now. So actually, that open source project really needs to pull its act together and sort things out so that you can go back to making some money again, which you're not gonna give to them.
So this is a little thing that I kind of have ranted at many times before. Obviously, this is a slightly silly example, but I'm sure, myself included, we've all been on the other side of this where you're really frustrated with a project because it's causing an issue for you right now, and you kind of want to rant or vent or or whatever.
And the issue tracker for projects is not the best place of doing that. So a few, like, summarized tweets that I think some are better than I probably would verbally. So I feel like that's kind of a fair point. I sort of slightly paraphrased from someone else, but unless you're giving lots of that nice money that you're running through the open source project back to the project, it's probably a little bit unreasonable to expect them to kind of dance to your tune.
Similarly, I think this is an interesting way of thinking about things as well. If you're a proprietary software user, and you're, say, paying a company like a million dollars a year to use their software, and you have a big problem, they're gonna be worried because, hey, you're paying them lots of money that's helping pay their bills, and they want you to be happy when you use it.
If you're making a bunch of money yourself and you're using an open source project and you have it running on a thousand of your servers, I as a maintainer feel really bad for you if my bug or whatever breaks your stuff. But, like, ultimately, that's your responsibility.
That's not my responsibility, and you need to help provide me the motivation to spend my evenings and weekends helping you with stuff that's gonna help you out at your job. So you can read a little bit more about this. I wrote a blog post about it with the slightly contentious title, Open Source Maintainers Owe You Nothing, which kind of goes through some of the kind of common open source licenses and explains that basically, like, when you're using open source software, you have, whether you're aware of it or not,
agreed to these terms where the open source software project will have disclaimed all warranties and basically said, hey. If it doesn't work, not my problem, dude. So, like, it's worth kind of reading and thinking about this stuff. And, I don't think this in any way speaks negatively of the source software because it's still great and you should still use it, but I think it makes it makes your contract with those projects a little bit more visible and something you can be aware of.
So this is again something you see in some organizations who are looking to open source software themselves. They think, oh, awesome. If we open source all our stuff, everyone's gonna get really excited, and they're gonna come along and work on our project for free, and then we can just fire the engineer and team that's working on it right now, because they will just do it in their free time instead.
Well, so obviously, when you open source a project as an organization, people aren't actually gonna be super interested in it, and they're not gonna be super interested in contributing to it unless they think it's good. So in reality, it's a little bit more like this.
So you need to already make your project good and have lots of users before people are gonna come along and contribute. I've kinda touched on this before. You can find more in like other talks I've done. There's a thing I came up with called the open source contribution funnel, which is basically saying a bit like a sales funnel that you're always gonna have a lot more users than you have contributors and a lot more contributors than you have maintainers.
Who knows what I mean by a contributor and a maintainer, by the way? Okay. So, yeah, some people know everyone. A contributor, I would say, is someone who has submitted and had a pull request merged on a given project, so someone who's got involved, and a maintainer is someone who has commit access to that project, so they are reviewing the pull requests that other people make that come in.
So they would review the work by contributors and decide whether or not to merge it or not. So looking at Homebrew's numbers for this, we have from our, I guess, a combination of our like lowballing our analytics figures, have like definitely millions of users, we have over seven thousand contributors, and we have ten maintainers.
So you should consider these types of numbers when you're wondering why your open source project with a hundred users doesn't have ninety contributors or ten contributors or even five contributors, because ultimately it may just be that you haven't got enough people interested in your project yet that they're all gonna come along and help you out.
So finally, how to win. So let's see how to do things right instead. So the first thing that I guess I've touched on a little bit before, everything should be upstream. So by upstream, what we generally mean in open source is the upstream of a fork is the original project.
So if I have on GitHub say, like rails slash rails, that's the rails open source project. And if I fork that, that's gonna be Mike McQuaid slash rails, and that's gonna be my project instead. So basically, my goal should be whenever I'm making changes, how can I get them up to the other project?
In short, try and make it someone else's problem. When there's new security releases, I don't want to be having to manually apply all my little patches and all my little changes on top of every security release. If I can instead get that ups theirs to sorry, upstream to the main project, then that will be effectively maintained just by the matter, of course, of that project kind of day to day running of itself, and it doesn't require manual intervention from me.
So how to fork without failing? So firstly, you fork the project, you make your changes, you do some testing, and by that I mean both testing it yourself to make sure the changes work. If the project has a unit test suite, for example, write some unit tests in a comparable style to the project itself, install it on your servers, make sure that it's working for you in the, like, production case that you want it to.
After that, submit a pull request back to the project with the changes you've made and hopefully nice and in keeping with the style, and you verify that it works. Then after that, you're gonna get comments from the maintainers unless you're very, very lucky, and I never am.
You you're rarely gonna make a pull request where the maintainer just says, that's great and merge it straight away. They're gonna have some things. Maybe you've deviated from the house style. Maybe you haven't written enough tests yet. Whatever. I would strongly encourage you to try and address those comments and not get too, like, worked up about whether you agree with them or not because, ultimately, if you're wanting to hand over responsibility to them to maintain the project, you need to get your stuff in a way that they are happy to maintain.
Finally, that means after that, as soon as there's a new version released that has hopefully your stuff in it that's been merged, you can just throw away your fork and you can just update to the latest version and know that that change will be in there.
Then you can avoid having to maintain all these internal forks, which will cause you pain. So what if you don't feel confident yet making those changes? Well, one of the first things and the easiest things you can do is help others by helping yourself.
So how can you help yourself? First thing, really basic with open source projects, read the documentation before you ask other people to help you. Again, this sounds basic, but you'd be surprised how many issues this would avoid if people did this. Similarly, who knows what I mean by a minimally reproduced issue?
Cool. Awesome. So some people, not everyone. So by that I mean, if I make an issue that says, okay, here's this, you know, to make a slightly silly example, here's a hundred thousand line program, and when I call that and run that program, there's some weird behavior that relates to your library.
Which do you think is gonna be easier to debug? Either that or when someone says, here's two lines of code in a file. When I run this, it reproduces this bug in the library. Obviously, the latter one is. So basically, if you can do the work to try and figure out the minimum possible thing to reproduce the bug, and by reproducible, I mean it should ideally produce the bug and replicate it every single time, if not often enough that you're kinda confident that this is something that someone else will be able to see on their
machine, then it's gonna make life debugging a lot easier. But then if you've done that already, then you may as well, if you can see, you know, get it down to a couple of lines, you may as well have a look in the library itself at what code is being called by those lines.
Maybe there's something in there that you might be able to see, and then if you do see it, then you can try and fix the code. And then if you manage to fix the code yourself, then you can submit a fix to a pull request.
I just tricked you into going from helping yourself to submitting a pull request back to fix it in the project. So if you follow that, and this may seem that I'm kinda making big jumps here, but I do feel that like if you work through projects this way and if you work through this type of process, it will both make you a better programmer, but then it will also help you whatever stage you stop at at this level, you will get a lot more people who are willing to help you out.
So other things that will get people more willing to help you out, have reasonable expectations. As I alluded to before, a bunch of open source maintainers are doing this stuff in their evenings and weekends, and you may well be, like, asking for help in your place of work.
That's fine. Like, I think we are have mostly accepted that that's just the fact of life. But let me just say that when someone behaves in a very rude or entitled manner in my evenings and weekends, I don't want to help them. I want to go outside and instead do something else.
Whereas when someone behaves in a really nice, pleasant way, then I'm more likely to help them out. Prioritize maintainers' time as well. As I said, whether they're doing it as their full time job or not, there's gonna be a lot fewer maintainers than there is people contributing or using the project.
So you need to bear in mind that they can't spend as much time helping you as you will need to spend helping yourself. Again, defer to them. Ultimately, they decide how the project is run and arguing about whether or not the way they test their files or whatever is not a good use of anyone's time, and try and help other people where you can.
Again, even from the stuff in this talk, you'll know enough to help other people out a little bit. If you wanna know more about open source kind of contribution, starting projects, etcetera, I really recommend the open source guides. I worked a little bit on this with some of my coworkers, but this is not it's affiliated with GitHub, but it's not specific to GitHub in any way, and I think it's the single best resource on the Internet for learning how to do open source better.
So a very short summary. Why should you use open source? Well, it doesn't cost not because it doesn't cost money, not because others will help you out for free, but because everyone does it now. You can fail pretty hard by setting on really old versions of forks, old libraries with outdated versions and security updates that haven't been applied.
You can be as whiny and entitled as possible on issues to make sure that everyone thinks that you're a big jerk, and make sure that you stomp up and down and demand that people spend their evenings and weekends helping you make more money.
And you can win open source by getting everything upstream to the original project, by trying to help yourself out as much as you can before you ask other people to help them, and in general, you can win open source the same way you win at life, which is by being a nice, kind human.
On which note, thank you very much. If you have any questions about open source, then get in touch with either of these, or I think there's a little q and a session later on, and thanks for having me. Cheers.