If it's a money-making project, this is actually a good thing--competition means there's a market, people are willing to buy what you're making. You'll have to stand out in some way, of course, but it's much better to compete for your share of a lively market than to be building the world's best app nobody wants.
If it's a learning project, it doesn't much matter what already exists. There are thousands of to-do apps out there, but I built one anyway and learned a ton in the process.
If it's an open-source, "giving back" project, there's an argument to be made for abandoning your own project and helping out with the existing one. But there are also several examples of people building their own thing--a module bundler, a framework, a functional toolkit--that ended up having a major influence on the future of existing projects, or even overtook them to become the default solution.
Don't give up just because it's been done before. Unoriginality is one of the foundations of creativity.
I've often said...
"Unoriginality is one of the foundations of creativity." 👈🔥 100%.
Good that you have made the attempt of looking for some rule and special cases.
I am with you in that open source project should not be duplicated too much.
Big companies reuse all they propietary software code as much as possible.
We might forget the past but, the fact that we can use opensource projects today was because of the free software community and the preasure they gave to the market.
They could only achieve that because of they phylosophy of build and reuse.
Big companies don't use to make redundant solutions, they just concentrate resources on a good, competitive one.
If the opensource community has twenty projects to make the same thing, that is beauty and very dynamic, but from the economical perspective... "the resources are divided".
Also there are other costs for the community like the increase of second level dependencies with redundant functionality.
So another criteria would be.. Is it a top level (appliance) project or is it one framework that would be used by many projects?
I would say more basic dependencies sould try to don't repeat themselves.
For the propietary software and componentware marketplace it is something different. I would say.. You have the right to push the market but if you don't contribute back to the opensource projects used, a lot of complexity might accumulate in your customizations and the manteniance costs will grow up to the stress point.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.