One of the stock critiques for any new project is that it’s been done before. You’re working on a new module, format, etc: what about this existing format?
Most projects attract neither users nor contributors and are forgotten within a year of their development.
Some lucky projects acquire users.
Only the very luckiest projects get contributors, probably less than 1% of projects. These have more than one maintainer who really feels continuing ownership and has the time to contribute, and the open source dream can be achieved.
Most projects will cost you time. Your responsibilities to maintain them and their users will add up. The more things you create, the more time you spend helping users and doing their bidding, and less time you have to create new things.
Your ability to write code quickly or answer issues or anything else doesn’t matter if you don’t know what to do, and people don’t start out knowing what to do. The experienced builder knows what to prioritize when, and this is what make them effective.
Optimize for performance when you need to. Write minimal docs and expand them once the project is ready. Avoid implementing anything that isn’t necessary. If you expand the mission of a project, do so knowing that it’ll cost time and could sacrifice focus.
Most importantly, don’t build things that are impossible or that you’re sure will turn out bad just because that’s what the plan entails: change the plan and build possible, good things.
Learn to dig into codebases, read code, and understand other people’s styles, and you’ll save yourself thousands of annoying back-and-forth conversations.
Research is underrated. Computer Science history is short, but many problems have established, proven solutions. Knowing those solutions and the principles with which they were solved will give you the power of the ancients.