How to become an awesome Open Source contributor

Editor's Notes

• #7: Becoming an awesome open source contributor. Wow, how does one really become one? I know I never imagined I would be one even as my career progressed. In fact, my first brush with Open Source was quite accidental. About a year ago I joined a large corporation to work on a big customer facing project. The code base was in dire state so one of my first tasks was to tidy things up. If you are a .NET developer, you will already know that all our external libraries come through NuGet. Most of them anyway. NuGet is Visual Studio's package manager. NuGet works in 2 modes. Download all the packages locally and store them as part of the solution, or use the package config file to instruct the solution to download the packages the first time a developer or the CI runs the build. Obviously, I decided to implement option 2 and break everything! So once I broke the build for everyone, I started working on reverting the changes. Unfortunately, once you "go NuGet you never go back", so the roll back was a painful process of reaping out xml from our project files. Since I knew that I'm not the only one that has done this tragic error, I blogged about it. Next time I have to roll back, I'll know exactly what to do. I blogged and tweeted about it, in hope that one of my 740 following bots would retweeted ( by now I'm convinced that I have no human followers). Lo and behold, within a couple of hours, the NuGet team contacts me saying that they loved my post and whether I could add it to the official NuGet documentation. That same documentation that millions of .NET developers use around the world. Me? The next few hours are a blur. I'm in a mess of documentation trying to understand forks and pull requests etc etc. I finally mange to send the PR in and have it merged. This is my PR:
• #10: That first PR and Jeff’s encouragement were enough to create an extremely enthusiastic and passionate OSS developer. In the past year I've not only contributed to a large number of OSS projects but I've also managed to get my own projects published. And it all started off by chance.
• #11: The gist of it is that OSS is free and available for modification and distribution. You can use, copy and change the code as you see fit. One important thing to note, however, is that there are different OSS licences so you need to make sure that the code you wish to alter has the right licence attached to it.
• #12: Open Source is what makes the development world go round. At some point in your development career you've used, or you will use, Open Source in a project in order to implement a feature, solve a problem or enhance some existing functionality. Today, more than ever, we rely on Open Source when creating new applications, even if we don't realize it. There are thousands upon thousands of developers and millions of hours spent on developing and writing about Open Source. It's not just the code behind each project. It's the documentation, tests, reviews, roadmaps, planning, features, bugs and so on. And all these people do it because they love what they do and because they have a purpose. To help the community become bigger and better. Let’s look at some examples of interesting projects using open source:
• #13: Even big software companies today actively support and contribute to OSS. Companies that in the past were so against Open Source!
• #15: For me, one of the biggest benefits is the agility and ease of use that OSS provides. I can build better software by standing on the shoulders of giants! The first thing I do when I need to add new functionality is to look up for the library: What I can Do If I like a library or a project, I use it. If I find that it works but it's not exactly what I need, I fork the project and build something better. Then I have the option to contribute back to the original project through a Pull Request. If the owner likes it, then my changes can be incorporated into the project. If not we go our separate ways and continue to maintain our different versions of the software. What I don't have to do Wait for a patch release by the project owner Wait for the next major release in order to have my feature or bug resolved. Moan about the luck of features on the internet It doesn't get more agile than this!
• #16: Unfortunately, unless you're extremely lucky, your OSS won't make you rich. It will, however, benefit you in many ways and allow you to grow as a developer. There are different ways to get started. My journey to Open Source begun totally off chance. A good friend of mine made an excellent contribution last year during Microsoft's //Build conference. Scott Hanselman was on stage pressing the publish button on the .NET CoreFX project - the cross platform .NET framework. As this was live and the code available, Adam decided to pull it and run it locally out of curiosity. The first thing any developer does when faced with a new library is to go into the tests and run them to see how the code works. Within a couple of minutes, the tests failed due to different language culture settings. So he fixed it and made a PR request to the project owners, which was, surprise surprise, accepted an merged. AT the same time, Scott is on stage with Miguel De Icaza, the guy behind Mono.NET and Xamarin thinking that they are raising the first Pull Request. The whole thing was ruined! But not in a bad way. In fact, Scott commented live about how engaged the community is.
• #17: Your journey in OSS doesn't have to be the same. In fact, there are several ways one can get involved, contribute and add value. First, you need to find a language and project you're passionate about. The easiest way to find a project you can work on is through public repos, such as Github. Search for the language you like and find a project of interest. Another option is the Up-For-Grabs.net website that contains a list of projects that have issues that need attention and are open to the community.. If you're not comfortable with writing code, maybe you can contribute with documentation. There are thousands of projects that lack good documentation and some of them have none at all. Alternatively, you could contribute by writing unit tests. As with documentation, you'll find lots of projects that are in dire need of unit tests. Apparently there are still people that don't write tests? Shocked? Don't be! Once you overcome your initial "fear" and you feel brave enough, start forking and write some code. When you're done and you believe that your work is ready to be part of the original project you can send a Pull Request (PR), sit back and enjoy.
• #18: I believe that Git is the biggest barrier in getting started with Open Source. The workflow is sometimes daunting to new users so you need to have a good grasp of terms like: Pull Request Merging Rebasing Cherry Picking etc Github provides a good, solid GUI but eventually you’ll have to drop down to the command line. There’s plenty of written material and tutorials out there that can help you become a Git ninja! There is an etiquette for contributing, so make sure you read each project's contribution requirements first. Before you go ahead and code your awesome bug fix or feature, ensure that there isn't an open issue already. Contact the project owner to let them know that you wish to help. Inform them of your intentions and this will give your PR better chances in being accepted right away. Also, try not to change coding standards or use automated tools to suppress errors, white space or remove/add comments. It's important you follow the coding standards of the project even if you don't agree with them. You can certainly discuss them with the project owners but I can guarantee you're going to fail if you go ahead and be brave. No matter what happens, don't be discouraged if your PR is not accepted. Find out why and work harder to fix it accordingly before re-submitting.
• #19: To begin with, I would advise against you creating software for the sake of writing software. If you want your project to succeed, make it useful, make it meaningful and be passionate about it. Also, some of the most successful OSS projects started as someone's library (Automapper for example, has over 4M downloads and Underscore.js 8.3M downloads only last month!). Both these projects begun their lives as someone's utility and once the developers recognized the value, they shared their code.
• #20: If you've decided to create your first OSS then we, the community, would like to thank you for your awesome, awesome, effort. You don't get paid, yet you choose to create something and share it with us. You rock! It is at this point that I would like to stress out that the OSS community owes you, not the other way around. If you feel that you’re getting abuse for no reason or things are not working out, then don’t worry about it. Do’t feel guilty. Eventually someone will come along and pick up the project. OSS is awesome and it's what makes to development world go round. OSS is consumed everywhere and even large corporations, who once stood against OSS, are starting to not only support but actively contribute. Because we all want to make better software for everyone. We live through some really exciting times and I, for one, am thrilled to be part of this community, at this time. Note that we always need more contributors to help out with the load, so I would urge you to go out there today and share your knowledge and passion with the rest of us. Find a project that you love, use or hate and make it better :)