Hacker News Reader

Comment by ivanhoe | Hacker News Reader

On one hand it sounds as a totally crappy move, but on the other hand if we don't like it we're free to fork it and try to maintain our own ads free version - which most of us will not do ever, because frankly we're all lazy bastards used to someone else do that shit for us...

View on HN

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.

If the ads are a real world problem and there's alternative we would know about it, marketing or not. It's not a shower gel or mascara, it's a lib used by a lot of people to do their work, so people will eventually converge into using the one that does the job best (or the one that pisses them off the least)

I'm not as convinced as you are that people will simply converge to the better alternative. Sheer inertia from npm activity and accumulated GitHub stars can disadvantage new, better options from gaining traction because it's not easy for developers to take a risk on a new project that could be abandoned at any time, and because they have to be pretty comfortable with the technology to confidently decide that the current crowd wisdom is wrong - something that may not be the case if the developer is working outside of their area of expertise. standard/standard is particularly interesting because someone who's not completely in their element could easily see

  "devDependencies": {
    "standard": "*"
  }

in a package.json or

  npm install standard

in a script, either online or in another project at work, and copy it into a new project along with the rest of the boilerplate common packages they need, not realizing what they've signed up for. This would create the appearance of continuing growth and support for the package even though these users are totally oblivious. It's not clear to me that, with that kind of tailwind, an objectively inferior package couldn't continue to be ubiquitous and never be "converged" out of relevance.

Still, I have to agree that the view you describe is a plausible one. If Feross does indeed think that way - which I have no reason to doubt - then that means that he's acting at least in better faith than some are giving him credit for.

Reply on news.ycombinator.com