Written by 
23 May 2022
•
1 min read
A common complaint I see in the Kotlin/Java/Android community is that someone is “blocked” waiting for an open source library release.
This is a bit of a red flag from a developer standpoint and a nuisance as an OSS maintainer. It leads to folks making noise in the issue trackers of those projects, varying from demanding immediate release to complaining about the lack of one.
It’s easy to let your frustration boil over into impatience, I’m certainly not perfect in this either. However, I’ve found there are solutions for this in basically every case. Not all of them are perfect and none of them are as convenient as a simple version bump, but there is always something else you can do to temporarily unblock yourself.
- Build from source, host on your own internal artifactory or GitHub packages. This is the ideal case and a worthwhile investment.
- Use a source-based repository like jitpack.io.
- Use a snapshot, many libraries publish them.
- Build from source, check the jar/aar into your repo + a Gradle substitution rule.
Complaints don’t make maintainers release faster. It may be with intent to imply urgency, but your urgency is not theirs. However well-intended, it is more likely than not going to come off as entitled and you are never entitled to something that is free.
The most effective way to speed up a release is to test the bugfix or feature ahead of time through any of the means mentioned above and report that on the issue tracker.
Circling back to confirm the fix resolves it for us!
We tried out the new API and it works great!
Or the most important of all:
We tried out the new change and found an issue, here are the details!
Constructive actions like these water two plants with one hose: you build rapport with the maintainer and you give them confidence that releasing the desired change is safe. Those are infinitely more valuable than a drive-by release request or complaint.
If you’re an OSS maintainer, feel free to link this post as a response to commenters that would benefit from this insight. I also highly recommend Tony George’s Etiquette in open source projects post.
*There are of course some projects very specific situations that waiting is their only option, such as an SDK that depends on a third party library in its public API.
Thanks Jesse for reviewing this.