Ramblings of a Tampa engineer
A figurine of an oktokat in the center, in the background a laptop with the main page of the GitHub open.
Photo by Roman Synkevych 🇺🇦 / Unsplash

A few weeks ago I was digging into a pretty complex issue that was only affecting less than 1% of users in the field with an application. With a constant mix of emotions working with React Native I appreciate how I can normally go all the way to the source during an investigation.

So I stumble upon a library known as react-native-fs and I learn what I need to, but also find some interesting discoveries.

  • It has ~500 open issues.
  • It has ~60 open pull requests.
  • It has a built in HTTP library for downloading files.
  • It has a library built in for uploading files.

So while I'm trying to just research a tiny charset issue with a created file - I learned the feature set of this project is quite large. So in a situation like this I believe the author inherits a good deal of tech debt of things to maintain.

So I get a bit selfish and wonder if the library was specific to just the filesystem and ignored all those extra features - could I anticipate a more stable solution?

From an Open Source maintainer myself I think its extremely important to say "no" to requests/features that bloat your library too much. What I've seen occur many times played out is something like this:

  • Talented contributor Z delivers feature X to project Y.
  • Project Y accepts it.
  • Feature X has an issue in latest release.
  • Project Y didn't start that feature so asks contributor Z for some help.
  • Contributor Z is not around and the fix is taken in by the project.

So a project shouldn't think about the short term benefit of a new feature, but understand the long term implication of supporting such feature.

I may have accepted a feature to re-add support for 32 bit binaries in Apktool, but I struggled for hours to figure out how to re-add that support when the upstream AOSP project released a new major version of Android.

I did however say "No" to adding Apktool support for the actual Android platform. Since I feared that support of keeping that feature added would be extremely difficult.

So moving back to the filesystem research I started with. I began exploring for a package that might be scoped to just filesystem operations and nothing else.

I found the reversal with rn-fetch-blob an interesting project that started because React Native struggled with properly uploading Blob (binary) contents.

The package exploded with popularity and sure enough added a filesystem implementation to it. So much like we saw with the other filesystem package:

  • Forked and continued under a new owner.
  • ~450 open issues.
  • ~50 open issues.

So I get selfish again. I'd really wish this library was split between file access and network module. It seems in my research that the smaller a library's feature set is - the more stable it is.

This is probably the Unix philosophy at the end of day and I think I'm pretty aligned with it now. I just want libraries to stay true to a small feature set and do it well.

I'm exhausted from seeing a library abandoned because it expanded too much in features.

I'm exhaused from seeing a library buggy because it expanded too much in features.

I'm exhaused from internal debates rewriting a package and assuming that responsibility to have a smaller isolated feature set.

All in all I'm being much more careful when researching dependencies and libraries before bringing them in.

You’ve successfully subscribed to Connor Tumbleson
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Success! Your email is updated.
Your link has expired
Success! Check your email for magic link to sign-in.