NPM Bans Terminal Ads

Please reread my reply to OP carefully and notice I did not say he endorsed NPM ads. Instead, I specifically disagreed with his suggestion to redirect the discussion away from the NPM ads to the general topic of open-source funding.

>He's asking the same question I am, how do we get sufficient funding for these projects.

To be clear, that's a different question and I wasn't even attempting to answer it. I mentioned funding like Patreon as examples of social acceptability and not as examples of income sustainability.

>Kind of defeats your point.

My point was a narrow one : others are criticizing the unwelcome ad solicitation and that's a correct area of focus.

The other question of how to get sustainable open-source funding is also an important topic -- but that doesn't mean it forbids discussion of unacceptable spam/ads. They can be 2 parallel discussions.

It is simply not possible for us to add a "donation" cost to our projects. That will not get past accounting.

A license, on the other hand, we would have no issues purchasing that.

We purchase (expensive) licenses to proprietary software all the time. We could and would do the same for the open source software, we use, but without being able to purchase a license, there really isn't any practical way of doing that.

Free for everyone, except for enterprise production environments, would work for us. As long as we get a license key and an invoice.

There are limits to explore in this area, for example, I doubt anyone would disagree with censoring obvious malware. But for the rest? It is deeply political, and politicizing the distribution of free software is frankly repugnant. This puts me off spending much time with the JS ecosystem (not that I would have already), and worried about it setting precedents for ecosystems I actually do care about.

A glorified FTP server should never be telling you what kind of software you can write or how you package it. In this scenario, the glorified FTP server is no longer fit for purpose, and if such changes have community support, in my eyes that community is no longer a free software community.

Sure, Standard on the face of it seems simple technologically, and compared to many other things it is. But it's value lies in completely removing long winded and often unnecessary conversations within teams about code style.

Standard represents a standard style of writing JS that has gained widespread support (similar to Airbnb's linter config). It's value is that a team can adopt broadly sane conventions then never think about it again - which leaves those dev cycles for shipping features. Without widespread use, Standard would be just another linter config - but large parts of the JS ecosystem (regardless of what people think of JS) have adopted it and as a result it has saved the world a million conversations that "didn't need to happen".

If you care enough about style to not pick their choices, you're free not to use it. But for a lot of us we just want a broadly accepted opinion so we can focus on features.

And as it turns out, maintaining a style guide for how to write JS for the masses takes quite a lot of work. Not writing code necessarily, but considering and replying to all the feedback on that style.

Not for or against the funding project - but within the JS ecosystem Standard has meant many hundreds of hours that might have been spent biked shedding, have been spent shipping features.

Standard has been genuinely useful to myself and pretty much every other JS developer I know. And whilst I'm in no position to speak to weather I'm junior or not I know a lot of the most experienced programmers in the JS ecosystem reach for Standard so they can focus on more important matters.

It's not JS that has such opinions enshrined in law, Python for example has pep8.