At Ximedes we love Open Source. Open Source software enables us to move fast, be transparent and pay it forward. Finding a well maintained and widely used Open Source library and using that in your project not only adds the code to the project, but also indirectly adds experienced people to your team.
Although downloading and using a binary can feel like a "free for all" it rarely isn't, and nor should it be. The quality of your software just became dependant of the quality of the selected library. And the quality of the selected library is something you can improve, by helping the maintainers.
Anybody in open source is more or less familiar with the following way of proposing changes to an Open Source project. The blue steps are ours; the gray steps are done by the maintainers of the project you want to contribute to:
Let's imagine we use version 1.0 of an Open Source library, and we find a bug or want to add a feature. In GitHub, we can create a clone of the original library and make changes to that copy. Of course, we could create an internal release from that copy, but that would mean that the community does not profit from our changes. Having a copy also means that any subsequent fixes in the original project will not be part of our copy. This called a "Fork", and statistically a fork is not likely to survive, and does not help you or the original project or the community.
The correct thing to do is to offer your changes to the original project maintainers by creating a pull request. This pull request is then reviewed by the maintainers and after everyone agrees that this is a welcome addition to the original project, it will be merged. The next official release of the software will contain your fix, you can stop maintaining your fork, and everybody profits.
The process explained above takes time and effort, which you can (and need) to factor into your project planning. It also introduces an interesting dependency problem: The maintainers are not very likely to adhere to your project planning. What happens when you create a fix and the original maintainers are not merging the fix into their sources fast enough, or are not releasing the software in time?
In our case, the answer is in what we do best: Create a release ourselves. Whether it is a fix you created, or a fix someone else created; the pull request that was sent to the maintainers should be online and available for the whole world to see. This means that we can have our buildserver check out the originating branch, build it, and publish it to our internal Artifactory. Since this is a temporary internal release, we need to make sure it doesn't contaminate the original source, and also does not conflict with future version numbers in the maven artifactory.
To prevent version number conflicts, we first use the mvn versioning plugin to update the version to a number that is very unlikely to be used by the original maintainers. This enables us to clearly identify our "local fixes" in our internal artifactory, as well as easily scan for any project still using this library after an official fix is released:
mvn versions:set -DnewVersion="1.0x" \
-DallowSnapshots=true -DgenerateBackupPoms=falseIn this case, the "x" after the minor version number indicates that this is version 1.0 of the original library, but with a fix from Ximedes in there, and is only available from our internal artifactory.
To be able to build and push this internal release to the internal artifactory the build server will usually have a maven settings.xml file containing a server configuration with credentials. For internal projects, we add a reference to this artifactory as a repository element in the pom.xml file of the project. In the case of an open source project we can not do this, so we tell maven to use our internal repository through command line parameters:
mvn clean test install deploy:deploy \
-DaltDeploymentRepository=artifactory.ximedes::default::http://artifactory.ximedes.int/internal-repoDone. The fix is now neatly built and unittested by a buildserver, uploaded to our internal artifactory, and available to our project. When the original project approves our pull request and creates a release, all we have to do is get rid of this build configuration and bump the version number to the official release with our fixes in there.
We hope that these simple steps inspire you to create fixes and contribute to open source too. Join us!