You recently downloaded a library from NPM but you’re not satisfied. You want to be like the cool cats from Silicon Valley. Hearing all the buzz about git forks, pull requests, commits and rebasing has you feeling left out. Maybe you were sitting at lunch with some coworkers and watching them buzz about sending a bug fix into MongoDB or maybe you just felt you really should try your hand at fixing a small bug but where do you start? How do you get down? Hi, I’m Cliff. You’re here because you don’t know if you fit in with the open source hype since you’re just starting your coding story. I’m here to tell you that you might already be an open source contributor without even knowing it. Getting involved is a lot easier than you think. If you haven’t seen my earlier post on open source give it a read as it explains exactly how to donate a small piece of code to an unsuspecting victim.
Let’s talk about what it means to contribute to open source. The sneaky not so often discussed truth is that if you have a Bitbucket or Github account and any snippet of code uploaded to it then you are already an open source contributor! The mere act of uploading source code to a public service like github is what open source is all about. You might not feel like Linus Torvalds but that’s because your project(s) have not amassed a heavy following. The simple action of uploading code to Github opens that source code up to the public and anyone else with a Github account can then improve on it. Improvements can be given via Facebook, Twitter, email, a phone call, etc. They do not have to come in a formal Github fork, push, pull request. When you send an improvement you are contributing to the project. If you need help working through some code that you have uploaded to Github or Bitbucket you can place a phone call to someone who has experience and they can download your code, run it and make suggestions. The barrier to entry is really just that low!
Let’s talk about contribution a little more. One of the bigger intimidating factors with open source is not knowing how to jump into somebody else’s project and add value. Let’s face it, if most people were to clone a major project like the Ruby compiler or even gulp, or JQuery they would get lost! However, if you paired with someone at your same level with not much source hanging on Github you might find a pleasant surprise! In my earlier post I found such a project to demonstrate how simple it is to get involved. The focus was on any individual who wanted to start collaborate on another project. This time around I want to explain how it feels when others collaborate on your project. The beauty of git based projects is that they are bi-directional. That means contributions can flow in both directions.
Let’s revisit the tipcalc project. I originally found a small improvement I could make then sent a pull request to the unsuspecting developer. I’ll frame a story around the way open source would work in the real world. Now suppose I was using that project as part of my own larger project. For example, if I were to host the tipcalc on a web host from within a public NodeJS express app and I wasn’t as familiar with the front-end HTML development work. I have a copy or fork of the original project and I could create an entire backend to serve the page. Over time the original developer, after accepting my earlier commit would have finished the project adding the ability to split checks and changing the look and feel of the page.
What if she were to help me enhance my site? She could contribute her updates back to me in the form of a pull request following the same steps I listed in my first article. I would then navigate to my fork of the project in github and notice an incoming pull request.
I could click on the pull request tab and see a summary of what she is trying to contribute. Clicking the actual pull request would give me a detailed list of the individual updates (or git commits) that were made since I last copied the project as well as a big green button to merge the updates into my forked copy of the project.
There’s an indicator that let’s me know if the pull request can be merged without conflicts and a section to add comments to the pull request. I would use the comment section to give feed back to the contributor and/or say thanks for collaborating with me.
As you can see it is quite simple to accept changes in this basic case. Of course I have simplified this most basic case and there is more to sharing code and merging others work. I am merely attempting to clarify the overall workflow and demonstrate how low the bar to entry can be for newcomers. It’s always a good idea to pair with someone at your same level so you both could learn to collaborate with git together. In my case I felt obligated to pick on someone I knew had been working diligently with a very clean source base and easy to follow project. There are other such examples out there and the more you share the more others may share with you.