5 ms·

> The sponsorship pays directly for maintainer time. That is, writing new features, fixing bugs, answering user questions, and improving documentation. As far

> The sponsorship pays directly for maintainer time. That is, writing new features, fixing bugs, answering user questions, and improving documentation. As far as I can tell, this project is literally just a 200 line configuration file for a linter. Not even editor integrations for the linter, just a configuration file for it. Is it truly something that requires funding to 'add new features'? How much time does it take out of your day to add a new line of JSON to a configuration file, or is the sponsorship there to pay for all the bikeshedding that's probably happening in the issues and comments on the project? What sort of bugs are there in a linter configuration file? I'm really confused by all of this. > The funds raised so far ($2,000) have paid for Feross's time to release Standard 14 which has taken around five days. 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? What about the other contributors that give up their time for free, are their contributions worthless? Rather than feeling like a way to support FOSS developers or FOSS projects, it feels like a rather backhanded attempt at monetization by the maintainer where Standard was picked out because it was the his most popular project, and therefore would return the greatest advertising revenue. Do JavaScript developers, or people that use this project, have a more nuanced opinion than me? I do zero web development, is this type of stuff normal?

Avamander 7y ago
Yep, tiny packages are awfully common. The most notorious of them being `left-pad`.
- z3t4 7y ago
  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.
jnbiche 7y ago
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.
- benologist 7y ago
  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 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.
  - goatinaboat 7y ago
    NPM and RubyGems are going to be steamrollered in short order by Github repos, so there is an opportunity to start afresh.
    - wolfd 7y ago
      What do you mean? Is there some announcement/feature I was unaware of?
      - deleted 7y ago
        [deleted]
      - JD557 7y ago
        goatinaboat was probably talking about this: https://github.com/features/package-registry https://github.com/features/package-registry
- kemitchell 7y ago
  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.
why-oh-why 7y ago
> What sort of bugs are there in a linter configuration file? Have you tried looking into the Issues tab? There are plenty. > Not even editor integrations for the linter, just a configuration file for it. Again, there are 1577 commits, some work was done and you can verify it. > 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 don’t know how to tell you this but it should be pretty obvious that’s not what the work was. Literally just look at the commits leading up to it. Releasing a major version is not just increasing a number by one.
- Nicksil 7y ago
  You've provided no additional insight and answered none of the questions you quoted. Your reply is at best dismissive of the questions raised by the poster you replied to. You've complained elsewhere about the replies in this post, but yours here sets no example.
kemitchell 7y ago
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.
- Klathmon 7y ago
  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.
sequoia 7y ago
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.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.
- hobofan 7y ago
  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/v13.0.1...v14.0.1 https://github.com/standard/eslint-config-standard/compare/v... https://github.com/standard/eslint-config-standard-jsx/compare/v7.0.0...v8.0.1 https://github.com/standard/eslint-config-standard-jsx/compa... https://github.com/standard/standard-engine/compare/v11.0.1...v12.0.0 https://github.com/standard/standard-engine/compare/v11.0.1....
  - duncan-donuts 7y ago
    This honestly makes it worse. I'm not even sure how you could call this stuff major version bumps.
    - csande17 7y ago
      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.
- wolfd 7y ago
  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.
JMTQp8lwXL 7y ago
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.
dcwca 7y ago
It’s sad that this arrogant criticism of the work involved in maintaining a popular OSS package is the top comment.
crooked-v 7y ago
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,
_bxg1 7y ago
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.
juliusmusseau 7y ago
> 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.

Avamander 7y ago

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

z3t4 7y ago
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.

jnbiche 7y ago

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.

benologist 7y ago
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 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.
- goatinaboat 7y ago
  NPM and RubyGems are going to be steamrollered in short order by Github repos, so there is an opportunity to start afresh.
  - wolfd 7y ago
    What do you mean? Is there some announcement/feature I was unaware of?
    - deleted 7y ago
      [deleted]
    - JD557 7y ago
      goatinaboat was probably talking about this: https://github.com/features/package-registry https://github.com/features/package-registry
kemitchell 7y ago
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.

why-oh-why 7y ago

> What sort of bugs are there in a linter configuration file? Have you tried looking into the Issues tab? There are plenty. > Not even editor integrations for the linter, just a configuration file for it. Again, there are 1577 commits, some work was done and you can verify it. > 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 don’t know how to tell you this but it should be pretty obvious that’s not what the work was. Literally just look at the commits leading up to it. Releasing a major version is not just increasing a number by one.

Nicksil 7y ago
You've provided no additional insight and answered none of the questions you quoted. Your reply is at best dismissive of the questions raised by the poster you replied to. You've complained elsewhere about the replies in this post, but yours here sets no example.

kemitchell 7y ago

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.

Klathmon 7y ago
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.

sequoia 7y ago

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.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.

hobofan 7y ago
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/v13.0.1...v14.0.1 https://github.com/standard/eslint-config-standard/compare/v... https://github.com/standard/eslint-config-standard-jsx/compare/v7.0.0...v8.0.1 https://github.com/standard/eslint-config-standard-jsx/compa... https://github.com/standard/standard-engine/compare/v11.0.1...v12.0.0 https://github.com/standard/standard-engine/compare/v11.0.1....
- duncan-donuts 7y ago
  This honestly makes it worse. I'm not even sure how you could call this stuff major version bumps.
  - csande17 7y ago
    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.
wolfd 7y ago
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.

JMTQp8lwXL 7y ago

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.

dcwca 7y ago

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

crooked-v 7y ago

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,

_bxg1 7y ago

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.

juliusmusseau 7y ago

> 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.