 I'm going to be talking about contributing to open source or how the fork do you contribute to open source software. I'm Trevor Hess at Trevor G Hess. You may not be from the rest of DevOps or I work as a senior consultant at Tenth Magnitude. So what is open source? Open source is any software package tool that you might build or work on that you share with others or others may share with you where you have access to the source code and you can modify and make changes and put that back. Why should you contribute? Well, you really ought to, you know, we get so much free information and free value from the internet, you really need to pay it forward and give back to the community. It's a really important step in the entire ecosystem. So what should you contribute? Really, in my opinion, anything that you think is valuable that helps you save time that isn't like super intricately specific to the stuff that you do that won't help other people is worth putting out as an open source project. You can build something specifically to contribute. So you can build a tool that you know is going to fix a problem that you've been having in general and will help others. You can also, not talk as fast, you can abstract something you've built that may not have been quite worthy of being open source because it's a little specific or maybe very specific to what you do. But the general concept is something that you can share with others and will provide value. You can also fix or enhance existing projects. You know, if you pull down a JavaScript repo and you decide that you need to run the function in there and you add it and it's valuable, you should go ahead and try and put that back up there or if you make changes to a cookbook that are valuable, you put that back up there. Most of the things that you're gonna find nowadays, the thing that I use mostly is GitHub. Your mileage may vary, you may have other areas you have open source software. But GitHub is primarily where I contribute. So if you go on there, you can look up the repository that you're working with and if you find that there's problems in a given repository, even if you can't contribute yourself, you can submit an issue on that repository and contribute that way. So if nobody knows there's a problem, how are they gonna fix it? So you may not be able to fix it, but they can. But if you can fix it, you can fork the repository on GitHub and forking the repository basically creates a copy of that repository linked back to the original repository so that you can actually make changes in a way that doesn't affect the original repository. But when you need to put stuff back in the original repository, you create what's called a pull request. A pull request basically takes whatever changes you select from the changes that you've made on your fork and lets you send them back to the main repository. Now you're probably gonna get some comments when you do this because it doesn't automatically go right back into that repository. It has to be approved by the owner or owners of that repository. So you're gonna get some feedback about what you've done. You also might get rejected. So if you may file a pull request and you get told there's not enough tests or we don't feel the thing that you did is useful. Don't get discouraged, just you can reach out and find out what wasn't quite right about that. You can talk to the owner of that repository and figure out how you can contribute in a better way or in a different way. Or retool the thing that you did build in a way that the owner agrees is also useful with what they have planned for the project. You can also own your own open-source repository. So if you built a tool or something that you wanna share with the community, you can go ahead and put it right out on GitHub and others can share and experience the thing that you've built and make each other's lives easier. Now one thing that comes with that is you also need to maintain the things that you put out on GitHub and share with others. So you'll find very quickly that as people start using your tools, they're gonna file issues or they're gonna file pull requests against your repository and it can be hard when it's not your full-time job to work open-source to change those things. But also another important thing is to test the things that you put out there. So you can put little status icons about the test coverage and the build status of your repository so that others know how safe your code is and you can contribute to the ones that you are contributing to as well. Now in terms of publicizing the things that you make you can blast it out on Twitter, you can talk about it at your local meetup, a lot of people show the things that they make at meetups and it's a really interesting way to expose each other to these tools as well as talking about it at conferences like this. Now bigger repositories like for example, Microsoft has open-source C-Sharp or components of C-Sharp and they will do public review sessions of pull requests to determine whether or not they go in and so you'll see that's an actual planned time to do that. So that's how you contribute to open-source. I'm Trevor Hess, thank you so much for listening and at Trevor G. Hess I may not tweet often but I'll respond if you tweet to me.