When your code updates don’t get accepted to an open-source project. Whether to fork, forget, or build elsewhere: sometimes it’s a combination of approaches that is the winning strategy.
One of the issues in working with external open source in commercial application development, is that these external libraries are not going to be able to do everything that you want. One of the things that you can do is become a contributor and send a pull request to the project, building out the feature set yourself. But then what happens if these changes aren’t accepted? Your use case may indeed be different from the library’s author’s. Let’s take a look at one example that we encountered.
Some time ago, we made a Pull Request to the authentication library we use in our project, however the changes were not merged. While the code itself we created was sound, the issue turned out to be with the use case that we were proposing. In the end, the author did not want to support initial automatic token refreshing, if wasn’t working with other subsequent requests to the API. Our PR (Pull Request) assumes that the token could only be expired during the initial page load period - which is correct if you build a pop up Chrome Extension and each token expires after 24 hours.
We provided more info about our problem (that the Chrome Extension which needs to fetch user data - to enable redirection to a specific page based on the user’s data - when the pop up opens). Ultimately if the author of a library doesn’t want to accept your changes they do not have to - the code’s design and intentions is entirely up to them. This means that we will have to fork their code if we want to include our changes for use. However, in order to maintain our fork as easily as possible (meaning: avoid as many conflicts as possible with upstream code - the main repository where the author pushes new changes), we decided to move as much code as possible from this add-on layer to the application layer instead, to support our use case.
Unfortunately, we still need a fork in order to refresh the token automatically when it expires and log a user out if refreshing wasn't successful. By moving as much of the logic as possible to the application layer, we have a minor fork to the author’s main repository, so that updates/merges are as as painless as possible.
Our team of expert devs encounter these sorts of interesting quandaries throughout the course of their work. With a wealth of experience and tech knowledge behind them, they are able to make clever, informed decisions to help projects advance smoothly and efficiently. If you are looking for enhanced business-oriented software development, then have a chat to the iRonin team to learn about what we can do for you.
