Choosing an old gem that is stale (hasn't been updated in a couple of years) is common. Then again, the team I work with did an exhaustive internet search for some gem code that had to do with image optimization. They told me that one or more of the gems they were looking at hadn't been updated since 2015. We all laughed and thought to ourselves that meant it was a stale codebase.

Then upon more digging, we realized that the code from 2015 actually worked fine, and we just hadn't spent enough time trying to make it work for us. So in that case, it wasn't that no one had worked on image optimization since 2015, it was because that problem was solved in 2015 (in that example), and didn't need more work because it continued to work in 2017.

As far as Canada Post, we use EasyPost for our shipping labels (https://www.easypost.com), which is NOT a gem, but in fact a SAS service. (It, incidentally, does have an open-source gem that has the API for communicating with EasyPost. But you pay them a small fee to generate each label).

Before you email the author of the gem, I'd like to take a small moment to expound on the nature of open-source software:

They said this back in the 90s, but it's so important and so relevant to you I'm gonna say it again:

"Free as in speech, not free as in beer."

"Free software" (what we called open source back in the 90s) isn't "free" like you don't have to pay for it. If that's what you think, you are totally wrong and need to adjust your mindset. It is "free as in speech" — can be copied, modified, etc, without limits imposed on it.

So consider that someone — two years ago — wrote some code to interface with Canada Post. They put their code on Github. Putting OS code on Github has no guarantee that that author is going to continue to maintain it.

And take a step back and think about this: Why would they? You have a need to have Ruby code that works with Canada Post. Maybe they do too, or maybe they have moved on an work somewhere else now, or maybe they won the lottery and retired, or maybe they got sick of being a Ruby developer and got a new profession. Or maybe (heavens to betsy!) they switched to Node.JS.

It's kind of like Ray Bradbury's great The Martian Chronicles: Someone was here once, they left some artifacts, you get to enjoy those artifacts, but you don't get to be them or live in their (ancient, bygone) society. (Ok so that Martian Chronicles analogy was a stretch. I'll work on it. But that is actually the core thesis of the Martian Chronicles — one of the best books of all time.)

My point is that unless you are offering to pay him or her, you need to think about the implicit need-dynamics of emailing him to "get his take on it." Obviously, there's nothing wrong with that on the face of it. But "free software" isn't "free" like you don't have to pay for it ("free as in beer"), it's "free" like the 1st amendment of the US Constitution (sorry Canadians!), there can be no laws recognized that limit it ("free speech").

This is a crucial and important concept to understand as you navigate the world of old gems that are no longer usable.

Oh and since you're new to the community: Check out that "Fork" button on Github!

Fork the Gem, fix it, and submit your changes back to the original repository — you will then be contributing to the whole community. If you think the author is gone (like the martians in the Martian Chronicles), dead (that happens too— in fact I've corresponded with Github tech support over their policy regarding passed-away authors), or no longer cares, you can detach your fork from the origin repository and make a "V2" (or whatever) of the gem, upgraded with your fixes, rename it, and then you'll be the Gem's author.

Then in 2 years from now when Canada Post changes their API again, some aspiring Ruby code will email YOU and say "why doesn't this gem work"!