~redstrate

Lack of updates is not a bad thing

Posted on (Updated on )

If you’ve been a part of any language that upheaves the traditional C way of pulling in dependencies, like Rust or Go - you might have heard of this statement before, or something like it:

“I suggest not choosing X, it hasn’t received updates in a couple of months. You’d better choose Y.”

However, when I gave it some more thought and reflected on my own projects this is not necessarily a bad thing - in context. For example, I was looking for SHA1 crates for Rust and I came across one called sha1-smol. However, look at when it last received an update:

Screenshot of the sha1_smol crates.io page, showing it was updated 10 months ago.
Screenshot of the sha1_smol crates.io page, showing it was updated 10 months ago.

Now if this made you shudder a little, I don’t blame you. I don’t know when I started to pay attention to when something got updated and I naturally gave this SHA1 crate a second thought because of this. However if you give it a couple minutes of thought, maybe it’s okay that this isn’t updated?

Relevant GitHub issue comment: <em>&ldquo;This crate seems unmaintained as it have no commit since 2018.&rdquo;</em> For context, this comment as shown above was about concerns in the API design for this crate. Yes really, in a SHA1 library.
Relevant GitHub issue comment: “This crate seems unmaintained as it have no commit since 2018.” For context, this comment as shown above was about concerns in the API design for this crate. Yes really, in a SHA1 library.

Think about it, this is not a GUI crate or anything that else is high maintenance with moving targets, many maintainers or complex stacks. This is a SHA1 crate, for an algorithm that hasn’t been changed since 1995. This crate is not “unmaintained”, in fact it’s pretty well maintained as there is a commit fixing some small things in January of 2022 (as of writing). The fact of the matter is that the surface area of this crate is so small, the scope of functionality is too simple that it’s actually better to not change anything at all. This library serves it’s purpose very well and I’ve used it without trouble. If it doesn’t need changes, but yet still has a maintainer that will make fixes as needed - is it truly unmaintained and should we be counting the last commit as a good indicator of maintainability?

I think this is a much newer problem that these languages face because crates.io makes it very clear which libraries are “updated” and which ones aren’t:

Crates.io displaying a list of crates named &ldquo;sha1&rdquo;
Crates.io displaying a list of crates named “sha1”

Now I’m no crates.io designer, but it is a really odd choice that they choose to display “Updated” and not some clear “maintained” or “unmaintained” symbol. After all, it’s possible that “sha1” could become unmaintained despite it appearing more “maintained” due to the last update date. Just a thought though.

For my own projects, I practice “dogfooding” as in - I create software that I personally want to use and then improvements and bugfixes naturally come1. If I don’t use my own software, there’s a good chance that it won’t be updated as often. Astra and Silica Viewer are examples of software that isn’t frequently updated but still maintained - I still use this software but they’re mature enough where I don’t need to make hundreds of commits each month.


  1. This is one reason why I highly, highly recommend for programmers to not get so keen on completing tutorials. There’s only so many examples you can replicate out there. However everyone has a niche, a problem that other software can’t solve. That niche you fill will teach you much, much more than any canned tutorial will and make it all the more memorable to learn. ↩︎

See Also

Comments

I posted this to my Mastodon! You can use any Fediverse account (Mastodon, Pleroma, etc) to reply.