Live data from Hacker News

Recap of the `funding` experiment

feross.org

61–70 of 72 posts

Re: Recap of the `funding` experiment

#61
post #50
post #49

Earlier quoted context omitted.

of course. i'm just pointing out that having a 'critical' infrastructure which components have been obtained for free and then complaining about those components asking for money in one way or another is rude; unless the OP already donates and didn't say so, in which case please accept my sincere apologies.

That's a deeply flawed line of thinking. Those components were obtained at a price of 0 moneys, which at the time of "obtaining" was agreed upon by both sides. In this situation, yes, asking for money later is very rude, in my opinion.

Just to make sure I understand you correctly — you believe that because a maintainer releases an open source artifact at a given point in time, you are entitled to dictate the terms that any future artifacts are released under?

You might want to reread the MIT license provided with the software to see which guarantees it actually (doesn’t) provide to you.

Re: Recap of the `funding` experiment

#62
post #61
post #50

Earlier quoted context omitted.

That's a deeply flawed line of thinking. Those components were obtained at a price of 0 moneys, which at the time of "obtaining" was agreed upon by both sides. In this situation, yes, asking for money later is very rude, in my opinion.

Just to make sure I understand you correctly — you believe that because a maintainer releases an open source artifact at a given point in time, you are entitled to dictate the terms that any future artifacts are released under? You might want to reread the MIT license provided with the software to see which guarantees it actually (doesn’t) provide to you.

In your blog post, you complain about a startup's product that charges $50 per month per developer to check if the open source software they're using is licensed in a way that won't cause them massive legal and financial headaches. This is why that product can exist and make money.

As you point out, the license of open source software provides zero protection against someone creating a snappily-named, heavily promoted open source project, waiting for it to become widely adopted, and then slipping a nasty surprise license change into the next release - and some open source developers think that the idea they shouldn't do this is unfair entitlement. In this low-trust world, providing a way of checking that none of their thousands of little dependencies has done that is far more vital than most of those dependencies, and certainly provides more value than some linter config files.

Re: Recap of the `funding` experiment

#63
post #62
post #61

Earlier quoted context omitted.

Just to make sure I understand you correctly — you believe that because a maintainer releases an open source artifact at a given point in time, you are entitled to dictate the terms that any future artifacts are released under? You might want to reread the MIT license provided with the software to see which guarantees it actually (doesn’t) provide to you.

In your blog post, you complain about a startup's product that charges $50 per month per developer to check if the open source software they're using is licensed in a way that won't cause them massive legal and financial headaches. This is why that product can exist and make money. As you point out, the license of open source software provides zero protection against someone creating a snappily-named, heavily promote…

but why can't that product be open source?

Re: Recap of the `funding` experiment

#64
post #51
post #41

It makes me sad to see the negativity that this experiment has attracted, even in this HN discussion thread there seem to be a lot of dismissive and patronising comments directed towards Feross. I'm genuinely unsure if this is because people think that Feross has much lower ability than he actually has, or if they are jealous of the attention he has received for Standard.js, or if it is just because JS programmers ar…

The negativity is because people do not want to see this becoming a trend, where CLI tools start advertising. One practical way to fight against new forms of advertising is to complain in public, complain to the advertiser, and make sure that form of advertising is associated with user complaints. That seemed to work here. I don’t think the majority of the pushback was about Feross personally. But when people see a n…

Yes. We've seen where this trend of people building and promoting useful free utilities, waiting until they build up a large audience and lots of trust, and then turning them into adware ends - it happened before with freeware on Windows. That's reached the point where the older well-known, formerly trustworthy utilities for tracking down the software spamming you with ads are now obnoxious adware themselves. The entire ecosystem is so poisoned that Apple created a hugely successful series of ad campaigns around the fact that their platform wasn't like that and technical people direct their friends elsewhere.

Re: Recap of the `funding` experiment

#65
post #26
post #20

Earlier quoted context omitted.

It's not you, it's the norms that you were challenging. Developers don't want other people to realize that the only thing stopping them from running "extra" stuff like this on someone else's build machine is convention. After the leftpad fiasco and the recent purescript installer "malware," people have gotten really sensitive about this sort of thing. Everybody knows that npm is a house of cards, but it's easier to h…

If the only thing this whole saga accomplishes is that npm post-install scripts are replaced with proper pre-built binary support, then I'll say this was all worth it. :)

The post-install scripts are installed from the same source as the actual library - the library itself could contain whatever malicious code an attacker wants. Pre-built binaries don't help here.

Re: Recap of the `funding` experiment

#66
post #18

Some suggestions that may see future attempts better received: 1. Try it on a repo with more substance. There were many comments about this project being a light wrapper around eslint config. It may be popular in GitHub stars, but intuition tells me the type of dev who installs a dependency to generate a JSON file is not the type to want to pay for anything; they're looking for a quick `npm install free-solution` for…

> devs I know are very sensitive to ads/privacy, much more so than to paying money In case it's not clear to other readers: `funding` had no tracking, no data collection, and no code from untrusted third parties. It was a `console.log` with some fancy formatting. > Despite your good intentions, your ads will involve analytics/tracking, which you ultimately can't control They certainly would not . I was very clear to…

> In case it's not clear to other readers: `funding` had no tracking, no data collection, and no code from untrusted third parties. It was a `console.log` with some fancy formatting.

It starts as that, but is the community right to question where it might ends? Today is plain ASCII -- tomorrow is HTTP requests to ad companies in postinstall. Even if wasn't in 'funding', it could happen somewhere else. Somebody (not you) quietly adds a new NPM dependency to a popular project, and in that new module, the advertiser now has analytics on that package's usage, in addition to the console real estate space.

Re: Recap of the `funding` experiment

#67
One model that might work for getting paid for FOSS is having X.0.0 releases be free and all other X.X.X releases under some kinda paywall. Things like bug fixes, small features that individual users want would be available for purchase. However, the vast majority of the package, especially the base functionality would be available for use.

For large commercial uses, not having access to individual bug updates and/or security fixes would potentially outweigh the cost of purchasing a paid subscription. OTOH, for personal use exploring a project and its capabilities wouldn’t cost anything.

I’m sure there’s going to be adverse selection involved here, but if you don’t have a good enough X.0.0 product, getting people to pay for the X.X.X version is unlikely.

Re: Recap of the `funding` experiment

#68
post #59
post #51

Earlier quoted context omitted.

The negativity is because people do not want to see this becoming a trend, where CLI tools start advertising. One practical way to fight against new forms of advertising is to complain in public, complain to the advertiser, and make sure that form of advertising is associated with user complaints. That seemed to work here. I don’t think the majority of the pushback was about Feross personally. But when people see a n…

The feedback on HN was harsh but not personal. The 1k comment thread on /r/programming was very nasty and made me less likely to engage with that community again.

Just took a look at the Reddit thread in question -> https://www.reddit.com/r/programming/comments/cus0zu/a_3mil_...

Not good.

Re: Recap of the `funding` experiment

#69
post #41

It makes me sad to see the negativity that this experiment has attracted, even in this HN discussion thread there seem to be a lot of dismissive and patronising comments directed towards Feross. I'm genuinely unsure if this is because people think that Feross has much lower ability than he actually has, or if they are jealous of the attention he has received for Standard.js, or if it is just because JS programmers ar…

If the comments in such a critique cross into personal attack or otherwise break the site guidelines, we'd appreciate users alerting us to that at hn@ycombinator.com. That's not ok on HN and we moderate such comments when we know about them. We just don't always know about them because we can't read all the posts here.

https://news.ycombinator.com/newsguidelines.html

Re: Recap of the `funding` experiment

#70
post #61
post #50

Earlier quoted context omitted.

That's a deeply flawed line of thinking. Those components were obtained at a price of 0 moneys, which at the time of "obtaining" was agreed upon by both sides. In this situation, yes, asking for money later is very rude, in my opinion.

Just to make sure I understand you correctly — you believe that because a maintainer releases an open source artifact at a given point in time, you are entitled to dictate the terms that any future artifacts are released under? You might want to reread the MIT license provided with the software to see which guarantees it actually (doesn’t) provide to you.

No, the subthread was discussing paying later for services already provided (quoting: "mailing a check in return for services provided").

Not for any future services, which, obviously and as you correctly point out, are not necessarily subject to the past agreement.

Post reply on HN