Open Source & Saying "No"

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 pull requests.

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.