> ## Content Index > Fetch the complete content index at: https://connortumbleson.com/llms.txt > Use this file to discover other available public pages before exploring further. # Open Source & Saying "No" - URL: https://connortumbleson.com/2022/11/28/open-source-saying-no/ - Published: 2022-11-28T03:30:32.000Z - Updated: 2025-02-04T11:42:42.000Z - Description: An Open Source project can balloon to extreme sizes and then lose purpose of why it started - a rant. - Author: Connor Tumbleson - Tags: Developer ![A figurine of an oktokat in the center, in the background a laptop with the main page of the GitHub open.](https://connortumbleson.com/content/images/2022/11/photo-1618401471353-b98afee0b2eb-1.jpeg) Photo by [Roman Synkevych πŸ‡ΊπŸ‡¦](https://unsplash.com/@synkevych?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) 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](https://github.com/itinance/react-native-fs?ref=connortumbleson.com) 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](https://github.com/joltup/rn-fetch-blob?ref=connortumbleson.com) 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. ![](https://connortumbleson.com/content/images/2022/11/Screenshot-from-2022-11-27-06-49-28.png) [https://github.com/joltup/rn-fetch-blob](https://github.com/joltup/rn-fetch-blob?ref=connortumbleson.com) 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](https://en.wikipedia.org/wiki/Unix%5Fphilosophy?ref=connortumbleson.com) 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.