My open-source principles

This document is my way of promising you that you can rely on my work. Open-source is amazing but you can't fully rely on it. Repos are abounded, removed, introduce vulnerabilities, become bloated over time, and won't make the fix you need. My goal is to avoid this.

Also, I wish that other developers may see this, like some of my principles, and apply them to their work.

Principles

My strategy against project abandonment. I don't open-source often because it's hard to determine the things that you won't abandon. I've made that mistake before and I believe it's destroying more value than it's creating. I test if a repo is worth open-sourcing by privately using it for 6 to 12 months. If I continue using it, I put it in a list of candidates. I have over 150 local modules waiting and around 20 in the list of candidates.

Activity. Most of my responses are within 24 hours. I hate stale bots. I am conscientious enough to keep track of my issues. I am quite consistent at working on my libraries. Here are more than 2 years of contributions for use-local-storage-state.

Helping you choose. npm search engines aren't great. Finding the right library isn't trivial. I often struggle with this. That's why, at the end of each readme, I will list repos that, support something my library doesn't, have some advantage over it, or have a smaller bundle size. The only requirement is that they are actively maintained. I will remove any library that becomes stale. If there is a repo that's better than mine, I will put it on top of the readme.

Reliable. I do a few things to ensure that the library is reliable and works well:

• 100% test coverage.
• My super strict ESLint rules — eslint-config-strictest.
• If there is a bug, when fixing it, I also create a test for it.
• Every repo I open-source is used in my own products. Either Nota or iBar.
• TypeScript with all strict options enabled (including noUncheckedIndexedAccess).

No bloat. I am inspired by Sindre Sorhus. I aim to create small and focused modules. I commonly decline feature requests and propose an alternative ad-hoc solution to the user. When the request is valid and can't be implemented outside the library, I usually refactor enough so the bundle size remains almost the same. Take a look at the history of use-local-storage-state through the last versions. The size got smaller! If the feature is too big, I may consider splitting the problems into two repos.

Learn from the code. I commonly read and learn from the code of other libraries. That's why I decided to write a lot of comments — example. This way you can learn more about the domain and implement a custom solution if you need it.