Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recap of the `funding` experiment

feross.org

Post reply on HN
Print view View original

21–30 of 72 posts

Re: Recap of the `funding` experiment

#21

Post by wakeywakeywakey »

feross wrote: post #18
wakeywakeywakey wrote: post #4

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…

The Ad space has developed an elaborate set of acronyms and jargon (CPC, CPM, ..) precisely because advertisers care to track such things to determine how effectively they are budgeting.

You start with no tracking, then two months later we get another blog post explaining how you still haven't recouped your time investment and now need to do "just a tiny bit of anonymous reporting". This power creep is what turns people off.

Re: Recap of the `funding` experiment

#22

Post by luckylion »

danShumway wrote: post #7

I'm in the early stages of building some tools to automatically lock new issues in my own Open Source repos, and to give Patreon supporters automatic access to comment on locked issues. Anyone will be able to read existing Github/Gitlab issues, but only supporters will be able to join the conversation or file new issues. It's loosely based on some ideas that William Gross[0] and a few other sources have proposed. You…

At some point, this becomes a complicated way to say "here's the code, and I'm available for commercial support", doesn't it?

Another thing you might try is "paying" for features, i.e. somebody has a feature request that you think is an improvement you'd accept but don't give a high priority to (basically "PR welcome, but there's more important stuff to work on right now"). There's a potential risk of including features that you wouldn't otherwise because they make you money, but that aside, it could help both with funding and responsiveness towards users.

Re: Recap of the `funding` experiment

#23

Post by netsensei »

gvkhna wrote: post #3

Thank you for this in depth discussion about sponsoring open source. I think there aren’t great solutions out there and it was definitely worth trying something new. I remember reading the original post proposing this concept. Is it possible the system is working fine as-is and has been for decades? Although maintainers do not get great funding, the community is constantly proposing new solutions, improving standards…

I suppose the entire point of open sourcing software is to take a step back from generating revenue through IP.

That doesn't exclude charging for the hours one put in solving specific issues or requests raised by third parties.

Open source only provides a legal framework that defines the terms by which one distributes code. It was never intended to be a business model in the first place. Not does the entire concept claim to be a business model.

As such, all software projects being equal, choosing a permissive or proprietary license is just a fork in the road.

The bigger picture here is the intent and motivation of developers that drives them to build software and share it with the world. Sadly, the hard truth is that there's no such thing as a free lunch. If you provide the output and the labour for free, discussing that such efforts are unsustainable is a bit of a cognitive dissonance on the part of the maintainers.

It's totally valid to write code, release it for free and then charge users for the maintenance of the tool. That is, put a figure to issues and only solve them as a maintainer when enough users care to chip in the hard currency to cover the time.

Sure, many FOSS maintainers don't do it for the money. They simply want to have a positive impact on the world. Share something cool with the world. Assert their identity as the author of their own creative vision. But if history teaches anything, great artists have always walked this tight rope between covering living costs through patronage and finding freedom and artistic license to actualise their own vision.

Re: Recap of the `funding` experiment

#24

Post by zawerf »

djake wrote: post #11

Why don't npm/yarn/github/etc have explicit support for premium packages that cost money? It can provide revenue for the registry, too. Napster and LimeWire were cool because people got something for free and, all else being equal, people prefer free to not free; but all else is not equal because free is not necessarily sustainable. If there were literally no way to monetize music at scale, it would not have worked o…

I think github is already trying to do many of those things. They started Github Sponsors[1] and Github Package Registry[2] recently.

Regular github already makes it pretty easy to choose an open source license for your project. If they add better support for creating a commercial license integrated with their package registry and automating revenue splitting among contributors, I can see it working.

[1] https://github.com/sponsors [2] https://github.com/features/package-registry

Re: Recap of the `funding` experiment

#25

Post by wakeywakeywakey »

JMTQp8lwXL wrote: post #16
riffraff wrote: post #15

> Right now, the status quo is that maintainers create massive amounts of value and then for-profit companies and SaaS startups capture almost all of it. it's almost like we'd need a license that allows free users and restricts people who profit, or dual licensing. We've had those for a while, haven't we?

The projects would be immensely less valued, less used, and less popular if restricted to non-commercial use. Can you name me a single NPM module that limits to non-commerical use that would be widely known within the JavaScript community? ...Maybe GSAP?

It doesn't have to be all-or-nothing. See redis, mongo.

Re: Recap of the `funding` experiment

#26

Post by feross »

ohazi wrote: post #20
feross wrote: post #19

Earlier quoted context omitted.

> They also tend to be sensitive about arbitrary code execution Presumably, if you're already downloading and executing code that I wrote, you trust me to use `console.log` correctly?

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

Re: Recap of the `funding` experiment

#27

Post by juliusmusseau »

justsubmit wrote: post #14
danShumway wrote: post #7

I'm in the early stages of building some tools to automatically lock new issues in my own Open Source repos, and to give Patreon supporters automatic access to comment on locked issues. Anyone will be able to read existing Github/Gitlab issues, but only supporters will be able to join the conversation or file new issues. It's loosely based on some ideas that William Gross[0] and a few other sources have proposed. You…

That attitude is very strange to me. I care about the quality and usefulness of my software. I give it away to give back, because I have been given much. There are bugs in my software which I will never discover on my own. When a user offers me a bug report or a patch, that user is also giving back. The bug report is a form of contribution. It gives me information I wouldn't otherwise have, which I can use to improve…

Monetizing our work is not strange. It might require some contortions compared to the most direct approach (step 1. write software. step 2. git push), but that doesn't make it a bad thing.

Here is Charles Dickens writing about his own contortions to monetize his work:

There must be a special design to overcome that specially trying mode of publication, and I cannot better express the difficulty and labour of it than by asking you to turn over any two weekly numbers of "A Tale of Two Cities," or "Great Expectations," [...] Notice how patiently and expressly the [serialized novel] has to be planned for presentation in fragments, and yet for afterwards fusing together as an uninterrupted whole.

I think holding onto bugfixes and feature enhancements and letting Patreon subscribers have first dibs on these makes sense.

Re: Recap of the `funding` experiment

#28

Post by weq »

My company wants to move to open source to reduce costs.

IP based software = High level management get involved and balance against other costs.

FOSS software = Engineer tells management there will be no cost, so management goes out and spends on other things.

A single site where a company can go to contract a maintainer for a single peice of work or consulting may be a good start....

Re: Recap of the `funding` experiment

#29

Post by k__ »

JMTQp8lwXL wrote: post #16
riffraff wrote: post #15

> Right now, the status quo is that maintainers create massive amounts of value and then for-profit companies and SaaS startups capture almost all of it. it's almost like we'd need a license that allows free users and restricts people who profit, or dual licensing. We've had those for a while, haven't we?

The projects would be immensely less valued, less used, and less popular if restricted to non-commercial use. Can you name me a single NPM module that limits to non-commerical use that would be widely known within the JavaScript community? ...Maybe GSAP?

Somehow this sounds to me like saying "Don't charge what you're worth to the company or they won't hire you!"

Re: Recap of the `funding` experiment

#30

Post by quantummkv »

feross wrote: post #18
wakeywakeywakey wrote: post #4

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.

The same was said about the early banner ads, early popup ads, early..... Well I think you get the point.

> They certainly would not. I was very clear to the sponsors that there would be no analytics.

The real danger is not that you are untrustworthy to uphold this on your packages. The real danger here is the normalisation of this behaviour. You might not add tracking. But once the big advertisers jump, they will want analytics. How much time would it take for a fork with tracking to appear? And thanks to the incentives and pressures, this will overtake and become the standard, as it happened across the web.

You might not do it, but there is no guarantee others will not. It's best to not keep the temptation there.

Post reply on HN