To me that's one of the icky aspects of this. He's parked on the very nice `standard/standard` repo, with a project named "JavaScript Standard Style," emblazoned on the iconic JavaScript yellow... If you take the time to read the readme it does say clearly about halfway down that the project isn't really a standard at all, just one guy's idea of a helpful linter configuration. But if you don't scroll down past all the company logos, it would be pretty easy to get the wrong idea.

I'm not saying that a lot of work didn't go into it, or that the repo name alone is a slam dunk for tricking tons of people. It's not like domain squatting - this is a real project. But I do wonder if a fork would be able to compete on equal footing without the advantage of the name. We like to think that the availability of at least the possibility of forking provides a sort of guarantee that projects which make enough bad decisions will always be leapfrogged by competitors and great software will rise to the top. I guess I'm not surprised that it's raising eyebrows that this maintainer at least seems to be deliberately pressing a marketing advantage which is just inaccessible to potential forks.

I'm not sure what to suggest as the solution to the underlying problem of coveted or potentially confusing package names. Namespacing library names under user/project names was supposed to be the solution to this! Just repeating the same word twice is a clever way around it. Maybe npm should step in and eliminate this loophole.