sometimes oss is slow
Working at several startups throughout my career, there have been several times where I’ve relied heavily on open source libraries. When I’ve been tasked with something big and generic, my first go-to move is to see if someone else has already done it. Chances are, they have, they did it better than you would have done, and they’ve shared their knowledge. If they have a “Donate” button, you better believe I reward them with $$$ for all the time and energy that they’ve saved me.
There have been a few times where I’ve come across an OSS project that has almost everything I need it to do. At that point I dig around in the GitHub Issues and Pull Requests to see if anyone else has the same problem as I do. If I’m lucky that day, someone has already filed an Issue and contributed a PR. And if I’m really really lucky, the maintainers of the project are quick to merge these PRs and I can wait a little while for the feature additions that I want.
If I’m not so lucky, the maintainers are either very strict or very slow to merge. I see the Pull Requests I need just sitting there waiting for a merge. Recently, I’ve come across a project where it’s been literal years since a PR was merged, but the maintainer has left recent comments on the Issues. I give them the benefit of the doubt, they probably have other jobs or families to attend to. And it is at this point where there is only one viable option to quickly get what I want out of this situation – forking.
gui rules!
The GitHub web interfaces gives us the ability to quickly fork a repository, and our fork will still point to every other fork of that repository. That is the key feature we will leverage here for our quest to get the as-of-yet unmerged functionality we need. Without it, this whole forking process would be extremely tedious.
To further elaborate, I’ll be using the OpenClover project as our example (an automated code coverage tool with awesome reports for Maven/Java). So here I first check the Issues – and I can see that there is a linked PR for it:
I can also see that the author of the Issue (satob in this case) has multiple Issues with multiple PRs, and seems to generally be a reliable contributor to the codebase already. With that knowledge, I feel comfortable forking. The plan is to fork our own, then merge in his PRs (from his own fork) into ours. So let’s look at that Issue and see what the name of his branch is.
We see the name of the branch and fork that we are targeting here. It’s in the bottom right of the screen. Take note of this, as we’ll be using that to merge into our own fork.
Next , we click “Fork” in the top right of that UI to create our own repository fork. It will look just like the original, but it will live under our GitHub username space. Now we’re going to create a PR from satob‘s and merge it into our fork.
On the right of the arrow is our source of the PR. In this case, it’s the branch we noted previously from satob. Make sure the head repository and compare dropdowns are set correctly.
To the left of that arrow is our destination, which is our own fork. You can see the “base repository” is our fork in our namespace, and the target branch is master. If you want to be extra careful, you can create a new branch before this step and merge into that one to preserve master in this case. That may be very beneficial in the future if/when we want to sync back up with the original repository. Go ahead and “Create pull request”. Now you’ll have a PR that looks like the image below. Go ahead and click the green Merge button whenever you’re ready. We can always delete our fork and start over if anything looks weird.
We’ve now successfully merged someone else’s PR into our own fork of the main repository. We need to remain aware of any updates to the original repo that we forked so we can stay in sync with it. You can continue to merge in other PRs from other people’s forks as well – just know that one day, once the source repository has an update to the main branch, if you’ve been merging to your fork’s main branch, you may have to resolve merge conflicts. Otherwise, enjoy all the cool new features you wanted but were not yet merged!
If you want to use this as a dependency in your project, you will have to host it yourself in a private artifact repository, as you will not be able to host it for the general public. In this case, it’s a Java/Maven project, so I host the artifact from my custom fork in my hosted private Maven repo (Nexus or Artifactory). You can do the same thing for Python (PyPI), NPM, etc. That’s beyond the scope of this post but feel free to ask questions in the comments below.