Hacker News Reader

Here's the changes between the last 13.x tag and the latest (at the moment) 14.x tag (14.0.2): https://github.com/standard/standard/compare/v13.1.0...v14.0...

Analyzing the changes I leave as an exercise to the reader.

Regardless of the effort etc. and whether or not these changes were primarily functional or related to marketing, I personally support FOS maintainers doing whatever they want with the software they offer for free. It would be trivial to make a fork of Standard without the adware if you wanted, and the MIT license explicitly allows it. So more power to feross for his free offerings! And complainers: put your fork where your mouth is.

For a more complete look at the changes, this should also include the diffs of the project-internal dependencies that were bumped.

https://github.com/standard/eslint-config-standard/compare/v...

https://github.com/standard/eslint-config-standard-jsx/compa...

https://github.com/standard/standard-engine/compare/v11.0.1....

This honestly makes it worse. I'm not even sure how you could call this stuff major version bumps.

The main repo has a testing script to make sure changes that cause previously-passing code to fail lint checks only happen in new major versions. Like SemVer, but for linter configuration files.

This would be an admirable commitment to stability if the project wasn't on its fourteenth major version.

While a lot of commits, the actual content shows very few functional changes. Actually, most of the changes are indeed ads for companies that use the package.

It just seems like they changed documentation and moved some ES5 constructs to ES6, there isn't even a behavior change in those commits. Is this what took 40 hours to update? Why is this worth a major version bump?

If you've ever tried to configure ESLint for a preexisting style guide, or to maintain a configuration's consistency across successive ESLint releases, you may have some idea what's involved. If not, take a look at the kinds of rules those files are invoking, the extent of change they've undergone across time and language versions, and their interactions.

Whether it's a code file or a configuration file doesn't accurately predict complexity. Von Neumann and all that.

As for the maintainer, we're friends. He's been involved in JavaScript and Node.js development since very early on. Standard is not by any means his only work, or his only popular work. He's also the only one I'd trust to maintain it right now---technically and design-wise---and I know he has many other demands on his time. He goes out of his way to acknowledge that he's not alone on many projects, but by any measure, Feross has done the vast majority of work on Standard thus far, for the past five years or so.

If it took him five days to get v14 out the door, it took five days. I'm not going to go and try to second-guess his hour-by-hour through amateur GitHub forensics. But I'd expect a fair amount of the labor came not just from the code itself, but from issue management, changelog, repo hygiene, and associated joys of maintaining a developer-facing tool with name recognition that's first point of contact for lots of folks who don't contribute in kind.

All software, done well, looks easy from the outside. Standard is not the Linux kernel, but it's good software that users interact with constantly. It's been carefully maintained primarily by just one dev for several years. It has been one huge, reliable constant in a language ecosystem with a lot of churn.

I completely agree with everything you said.

We pay managers salaries even though they often don't write any code, why is management of a widely used OSS project not deserving of funding on its own?

I've used standard for years, and I've never once had an issue with breaking changes. They've added features, fixed bugs, and even made changes that fixed issues that I personally raised with the project.

It's good software, and even though it looks trivial at a glance it took a LONG time and a lot of effort to get there, and every time I'm working on a project that doesn't use standard I'm quickly reminded of just how many of those edge cases they have handled for me.

I'm happy about the parts of this discussion that are about the way they are funding the project (and I don't actually like the specific way funding is being managed for this project), but all of it seems wrapped in dismissive comments about the library itself.

I don't use Standard, but I am a (mostly) frontend developer, and I agree with your take on things. It's a shame, because feross is a very productive open source developer, but it does look like this is a ill-conceived attempt at monetization of his most popular project that has the largest audience.

And hey, I'm all for monetization of open source projects: I have no problem with ads on READMEs, etc.

But no, no ads in my terminal when I'm working. Not normal and not OK.

I think the shame is he has written some software I find valuable, and some tens of thousands others, but we refuse to value the author's ongoing commitment too.

Software that doesn't require a major ongoing effort can still be in dire need of support, like OpenSSL.

https://en.wikipedia.org/wiki/OpenSSL#Heartbleed

OpenSSL falling over was a wakeup call that we continue to ignore even as NPM, Ruby and other packages are converted to malware because there's nothing in it for the original developer except more work.

NPM and RubyGems are going to be steamrollered in short order by Github repos, so there is an opportunity to start afresh.

What do you mean? Is there some announcement/feature I was unaware of?

goatinaboat was probably talking about this: https://github.com/features/package-registry

The standard experience of maintainers trying to support their work is that everyone else makes a public point of standing in support of maintainer funding as a general matter, but strongly opposes whatever specific approach the maintainer actually happens to be trying.

To be frank, I'm not a fan of ad-based models. But it's the example here, and we see the same pattern. Ads in general? Sure. Ads where people will see them, as via popups in Atom or messages to stdout? For shame.

This is not Feross' first attempt to fund his open work. Past approaches haven't failed because Feross wasn't churning out valuable software. He's been doing that the whole time.

The "well conceived" approaches that cost consuming developers literally nothing---no money, no time, no attention---don't repeatably solve funding problems for producing developers.

I don't use standard, but FWIW I like this approach. npm install can output thousands of ads for all I care if it means software I depend on is better maintained. At that point I'd probably never see most of the ads, but, eh, I do know what LogRocket is now, so this ad at least did its job.

Edit: There are some good arguments here. I'm on the fence. In most cases I don't look at npm output, in which case the ads would be useless, and when I do need to actually look at npm output they'd be in the way. I can also get behind considering the terminal an "ad-free zone".

> The standard experience of maintainers trying to support their work is that everyone else makes a public point of standing in support of maintainer funding as a general matter, but strongly opposes whatever specific approach the maintainer actually happens to be trying.

If you're suggesting that I'm guilty of that behavior, I should mention that I've never opposed developer using ads on their software's website, or on the software's README. In fact, I've done so myself.

I've also been a big supporter of GoFundMe, Patreon,-and like websites for open source developers.

Believe me, if there were a better way for open source software to be funded, I'd probably spend more time on my open source projects. But not by spamming ads on stdout.

jnbiche, I didn't mean to say anything about you specifically!

If you're experimenting with funding models, I support your experiments, too. But without looking into specifics, I'm guessing you had the usual experience with README and website ads, sponsorship badges, or the like. I hope it was able to cement some new relationships, and perhaps make you more aware of who's relying on your work. But I wouldn't bet it made you significant money, or significantly changed how much you could or did contribute.

As for stdout versus README and so on, the lines aren't sharp, but I think there's a basic distinction to draw between an advertisement and something more like a credit or acknowledgment. As long as those who go looking for their credit can find it and point it out to others, all seems to be right. Sponsorship in a README fits there, in my view. Ads go where people will notice them, even when they don't go looking. They're frequently invasive. I don't like invasive, but that's where `funding` seems to fit.

There are middle grounds, too. Actors often negotiate for fair billing in relation to other players, for instance. And donors to cultural centers and other physical venues often get their names on plaques or stonework in the foyer. In my mind, all of that just points out how many conventions and expectations we've developed about funding in nearly every field but software.

In my comment above, I was reacting to your mention that Feross' approach seemed ill-conceived. I thought that was one-sided: It's not just about whether user-developers like it. It's also about whether it effectively gets devs paid. It's not well conceived if it doesn't work.

Fair enough. I apologize for getting overly defensive.

That said, I do not think that this approach by Feross will work at all. Advertisers hate controversy, and given the fairly negative reception this approach has garnered, most of his sponsors (if they're aware) have now likely pulled their support or at least requested that he not put their ads on the terminal.

jnbiche, nothing to apologize for!

I've shared your concerns about the ad-based approach from the get-go. I sincerely hope ads of the kind don't become the norm for open developer funding. We know their cost from funding other kinds of open work so well.

I'm interested in this mostly because I see distaste for ads trampling respect for maintainer autonomy, and that is wrong. I've endured the cycle of harassment that follows any credible attempt to fund development work in a new way, seen friends go through it, and saw Feross going into it. It's psychologically impossible for us to experiment our way to approaches that work with peer support.

> I've endured the cycle of harassment that follows any credible attempt to fund development work in a new way, seen friends go through it, and saw Feross going into it. It's psychologically impossible for us to experiment our way to approaches that work with peer support.

I'm sorry to hear you (or any open source dev) has experienced harassment because of funding attempts. I disagree with Feross, but I condemn any organized harassment.

I would add that it's fairly predicable that any funding that hinges on innovative uses of ad technology are going to run up against heavy resistance in our communities. There's just not a lot of patience for advertising among techies.

But outside of advertising, I hope developers do experiment with new funding approaches. It's greatly needed.

Having read through a lot of the threads that this initiative by Feross has touched off, I've somewhat revised by opinion: I still think the terminal ads are a very bad move, but I appreciate the fact that we're all talking about this now. I'm not entitled to compensation for any open source work, but it would be nice if I could receive some compensation in order to do more maintenance/improvements and/or revive abandoned projects.

So it's good we're talking about this.

> Five days to do what? Five full 8 hour days? Does it take 5 days to cut a GitHub release and push it to NPM?

I'm not OP, but I gotta say whenever I've faced questions like these in my career, I find I'm not actually being asked any questions at all, I'm being accused of lying, and it's time to walk.

One angle to look at this: consider opportunity cost. The developer could spend X number of hours working for someone else making $Y. The value of their time to make the change might cost that much.

If OSS maintainers struggle to monetize their work, they should switch to coding for businesses if the primary objective is to code for money. If nobody wants to pay you to maintain a project, then you shouldn't maintain it (unless doing it for free makes you happy). Otherwise -- if anybody else wants work done on the project, but doesn't want to pay, they'll submit PRs themself, or assume the role of being the maintainer themself.

Keep in mind that the JS ecosystem on the whole is a garbage fire, and anything even vaguely configuration-related is likely to catch fire and explode the moment a dependency or a dependency's dependency or a dependency's dependency's dependency changes something.

For example, it recently took me most of a day just to get ESLint, Jest, and Babel working for a monorepo based off the same Babel config,

Whether this particular project deserves funding or not, I think the problem is a real one and the solution is valid. It's unfortunate that we live in a society where common goods require private funding to survive, but given that we do, (non-tracking) advertisement is, I think, a necessary evil that we need to be tolerant of.

It’s sad that this arrogant criticism of the work involved in maintaining a popular OSS package is the top comment.

Yep, tiny packages are awfully common. The most notorious of them being `left-pad`.

While I think its great that open source projects get funded, it would eventually turn into a game of who can make as many people as possible dependent on your code using clever marketing. Dependencies are not chosen by technical merits, they are chosen by popularity.