Hacker News new | past | comments | ask | show | jobs | submit login
Recap of the `funding` experiment (feross.org)
108 points by feross on Aug 29, 2019 | hide | past | favorite | 71 comments

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 are still looked down upon.

Either way we are talking about somebody with a pretty impressive CV who has made countless meaningful contributions to Open Source. Personally I think the work that he has done around WebTorrent is amazing, and WebTorrents may even end up saving humanity by making it possible to recentralise the web (only slight hyperbole, and if they dont, it will be something very similar).

Its true that Open Source is now an industry that generates billions if not trillions of dollars a year, yet very little of that makes its way to the people who actually make the stuff. Feross is right to explore ways to pay OS maintainers, even if those attempts sometimes fail. We will all be better off for it.

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 new form of advertising that seems especially annoying, it is quite logical to respond negatively.

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.

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.

What about making a trend to actually pay for the tools one uses?

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.


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

2. Don't focus on ads, specifically. Anecdotally, devs I know are very sensitive to ads/privacy, much more so than to paying money. Despite your good intentions, your ads will involve analytics/tracking, which you ultimately can't control.

3. Your various posts and web profiles eagerly mention how many downloads you have. The numbers are great. But, it comes across as your primary focus. Here's a test you can use to see if you are truly creating value: stop pushing code. When people start begging for updates, I suspect you will have more success with git bounties than ads.

> 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 sponsors that there would be no analytics. I even took pains to ensure only plain ASCII (excluding control characters) could be printed out. https://github.com/feross/funding/blob/58b090c51ce94de32107d...

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

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.

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

> Anecdotally, devs I know are very sensitive to ads/privacy, much more so than to paying money.

They also tend to be sensitive about arbitrary code execution, especially when running in a build system, which may be near things like deployment keys.

The only thing keeping npm from turning into a minefield are norms around what is socially acceptable, so developers tend to get super angry when this norm is challenged.

> 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 hide the problem than to fix it.

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.

Sure, but using it incorrectly - or even unusually - is going to be grounds to revoke that trust, obviously.

You must be aware that some non-zero number of developers have moved away from your code precisely because they no longer trust you, right? (Not saying that's right, just that it's a thing at least a few devs will have done.)

Personally, if you’re trying to inject advertising scripts into my critical infrastructure, then no, I absolutely don’t trust you. Like many others, I put a lot of effort into trying to sanely manage my dependencies, finding adware in there would be an enormous red flag.

You’re probably a good person, and you seem to be trying to do something good. But I know almost nothing about you, and even if I did, the fact that you think build pipelines are a good place for adware instantaneously eliminates any trust I might ever have in your judgement.

so i guess you're mailing a check in return for services provided?

False dichotomy; the world is not solely consist of adware and paid software.

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.

I contribute to various open source projects in various ways. But that’s really besides the point. I’m not against open source maintainers seeking funding, but in my opinion, this is just a remarkably terrible way of doing that, and undermines the credibility of the work they have done.

I also take issue with your implication that if somebody releases some work for free, that anybody who uses it now owes them something. I’ve released open source work before, and I’ve never even had the audacity to think that the people who use it are somehow indebted to me. Open source projects gaining a community following and then deciding ‘time to pay up’ and changing the license has happened in a few recent high-profile incidents, and it honestly makes reliance on open-source software a risk for anybody doing anything serious with it.

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.

but why can't that product be open source?

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.

>Anecdotally, devs I know are very sensitive to ads/privacy, much more so than to paying money.

Thank you for qualifying this as devs you know. In reality, this is a very privileged position to take and I'd bet would be a minority if polled globally (between paying in cash or in ads)

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're on Patreon, but most of the experiments you've run so far are around traditional sponsorship, ads, and donations. Is there an ethical/logistical reason you've mostly stuck to that path, or is that just the stuff you've happened to try so far?

This is still in the experimental stages for me, but if I built this in a way that other people could use, I'm curious about whether anyone else would be interested in trying it out -- or if the potential to suppress community involvement is part of the reason why developers have steered away from strategies like this.

[0]: http://wgross.net/essays/give-away-your-code-but-never-your-...

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 my software, which can make it more reliable and useful to others.

Most users who encounter a bug don't take the time to report it. Those who do report bugs contribute their time and effort, and the fruits of their contributions help not only myself, but other users of the software.

This applies not only to bug reports, but to suggestions and feature requests as well, because all of them can help make the software more useful to others.

The only interaction that has negative value is to be asked a question that's already answered in the documentation. But even those can be valuable when they indicate a weakness in the documentation that makes the information hard to find or understand, which can be improved, which helps other users. And even the questions which are trivially answered by the documentation can lead to valuable interactions later.

So to charge a user for the privilege of interacting with me would be like asking the user to pay me for the privilege of helping me, for the privilege of giving back. It would be rude, and it would deny many the privilege of contributing through the means at their disposal. It would almost be like keeping a fellow human being in a kind of moral debt, rejecting their contributions out-of-hand, leaving them obliged, with no means to repay (or to "pay it forward").

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.

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

You're answering the question you want to answer, not the one that was asked. It's important that you get paid for your work so you can eat, and it's good to figure out ways to monetize your work. Charging people for reporting bugs is strange because knowing about bugs helps you and the rest of your users more than it helps the reporter.

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

I think that could make sense, too, but neither of those things are reporting bugs or suggesting features. I don't have a quote.

Ok, but if I’m using your thing and I’ve found a bug, asking me to jump through some hoops and/or pay to report it means I just won’t bother.

  There are bugs in my software
  which I will never discover
  on my own. [...] The bug report
  is a form of contribution.
Well, there are at least two ways of viewing a bug report:

1. A bug report is a helpful contribution towards more perfect software, giving the developer new information but no obligation.

For example, pointing out a security bug.

2. A bug report is a request for support, asking the developer to work on a code path they themselves don't use (as if they did, they'd have triggered the bug themselves).

For example, asking them to fix graphics support on 3dfx on Windows NT 4.0 :)

The second one is strange. Just because I tell you your software is broken doesn't obligate you to fix it, and if anybody is confused by that, you can tell them. The weird thing is not having a way to be informed about the bug by unpaid users.

Not only that, writing a useful bug report can involve a surprising amount of work - sometimes far more than is required to write the fix. (For instance, a couple of bug reports I've filed against Pulseaudio fall firmly into that category. They were obnoxious, system-specific crashes that were a pain to pin down and would probably be really hard to reproduce elsewhere, but once pinned down there was an obvious one-line fix for each.)

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.

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 and disseminating breakthroughs.

If companies were all privately building their own stacks, then they would all maintain their IP as a competitive advantage but won’t be able to share common solutions that they could feasibly replicate as well given time and direction. Only by everyone contributing do we have such a great community.

Unfortunately companies that sit on top of open source code don’t derive all of their value from just the code, although it’s definitely a part of it. They provide usually more than just a technology implementation, including support staff, communication strategy and so on that their stack doesn’t provide them.

I wish more maintainers were better funded, it could definitely help but I think also it’s amazing to see what we’ve collectively been able to accomplish so quickly by people contributing for free and permissively for the general good.

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.

Even though I don't like ads either, I think this experiment was a glorious failure which will lead too much learning. That was supposed to be a compliment :)

I'm not sure if GitHub Sponsors is already planning this, but since they also track dependencies they could automatically distribute a part of the donations to all the transitive dependencies.

Also, I agree with others that Open Source by itself is not a business model. It's inherently altruistic, so self-sacrifice is a given and if you want to get paid, the best solution IMHO is to support companies who support FOSS by working for them (or founding one yourself). And while of course not everyone has that privilege, we collectively do have a lot of power to influence the job market and donation platforms:

- If you're currently interviewing, make it a point to ask about this.

- If you're currently employed, ask around what your company is sponsoring, or organize an effort to start doing so with a group of like-minded people.

- And lastly, if you're making a shitton of money, donate to the software you use in your private life.

I'm a maintainer of a 10K+ starred project with 1M+ monthly downloads and I know Feross personally.

I do not agree or support this movement.

Don't do Open Source if you can't afford it.

It is as simple as that.

Framing it as exploitation is misses the point of collaboration.

It has never been about us, it's been about giving value to the world.

We can't play the victim card. Nobody wants a whining Batman or Spiderman.

So what is Open Source about?

Here's an excellent talk on the psychology behind it:


I'm surprised nobody else has said this as well. If you want to get paid for your time or your projects then stop giving them away for free? Nobody is under any obligation to work on open source so it's peculiar that someone who chooses to do so would then complain afterwards...just stop working on it...

> Nobody is under any obligation to work on open source so it's peculiar that someone who chooses to do so would then complain afterwards..

Except more and more employers judge job candidates per their open source projects and contributions. It can create a positive feedback loop, where only people who can afford to work on open source projects do so, and thus get better offers in the future. While people who can't afford it will never be able to break through recruitment because of a mostly empty github profile.

> We can't play the victim card. Nobody wants a whining Batman or Spiderman.

I don't know my own opinion on this topic, but framing any form of work in terms of a selfless, uncomplaining heroism seems like ideal advertising copy for corporate exploitation. I know what you're saying which is effectively "only wear the cape if you can fly"...but the subtext could be interpreted as "hey kids be a superhero and by the way superheroes never feel pain or complain...so don't be one of those".

A perspective which may not have been considered yet is exactly what kind of value is being created in these open source projects: namely, value which is easily captured by SaaS startups. Is it really surprising that that <insert javascript library> is used by <insert techbro startup> to make <insert obscene valuation> without giving anything back?

End-user open source software doesn't face this problem as often and I would wager is a lot more important for creating an open source ecosystem which serves people rather than serving techbro startups. I'm not saying that libraries are unimportant, but rather that there's not a lot of use-cases for JavaScript layout library #1,480 other than making some web app for some techbro startup, which is pretty far removed from anything useful to end-source. If you write projects which enslave yourself to techbro startups, don't be surprised when you end up enslaved by techbro startups.

While this experiment was interesting, I think it was doomed from the get go.

One of the problems with advertising is that it works a lot off of a novelty factor. Like, you can come up with a new technique, and for a brief moment in time this new technique of advertising may be effective. Think popup ads, or those annoying newsletter popups, etc etc etc. But then everyone does it, people start ignoring it, and it becomes immediate noise.

The trouble is, why wouldn't anyone `npm install funding`? Soon npm install would have to block the ads just so its own user experience wouldn't be absolutely demolished. This idea simply wouldn't have scaled.

I love open source and I contribute as much as I can, and have definitely been a long time user and supporter, longer than I've worked in software professionally for sure, but along with all of the "Open source is not about you" points that were brought up, there is one point that may hurt but is nonetheless equally true: You are not entitled to make a living off of open source. There is no reason this would be guaranteed to be possible. It would be nice to live in a world like that, but if it doesn't work, it doesn't work. I'm not for solutions that will just deteriorate open source as I think it is much more valuable to society than just a way to make money, to basically all parties involved. I sympathize with people who pour hours of unpaid work into it, but when you donate your time and effort into something, you don't necessarily get anything in return, much like giving gifts to someone you love.

If you need to make a living, you can always sell software, or work for someone else. There's still opportunities to contribute to open source in both of those cases. I would love to see a detailed breakdown is between open source work that's donated versus funded by companies to understand what the open source community really is; I think it would help our understanding about how open source gets funded today.

Of course, though, it is absolutely people's right to do what they wish with their own projects, and I do wish everyone luck in finding a good way to make contributing to open source more sustainable as a source of income.

I worked for a company that used tons of open source software. The company itself never paid or contributed. Fortunately, individual developers on the team often built open source tools and contributed to other open source projects.

This issue of getting paid for the work you do hits home for me. I come from a writing background (before development), and the problem is very similar there. You're expected to write for free. For exposure. To better the community. But it sucks. People should be paid for the work they do.

Good luck on future experiments.

> 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!"

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

I think there were two problems here.

1. You hit a nerve with the distribution method. Everybody knows that npm is a ticking time bomb for malware delivery. Developers already tend to react poorly when weird things happen to their build system, and the paranoia around npm made them react explosively.

2. I think targeting developers is probably the wrong approach. If you're serious about tackling this problem, you should find a way target executives, marketing, or developer relations people at companies that use the open-source packages in question, and give them ways to support the project in an official capacity.

For example, give projects a standard way to offer 1-3 top-tier sponsorship spots, and 5-10 second-tier spots. Create an easy way for companies to bid for these spots across a handful of open-source projects that they use and like. The companies that pay $10-20k for a booth at the Open Source Summit conference will absolutely eat this up.

Re: 2 - he already does that.

I said something similar on a previous post, but more and more, it’s becoming more clear to that “open source” and “profit” are not very compatible.

The truth is simple: if you use a permissive license like MIT, you will probably never see a penny from the thousands of hours you put in, and while you are struggling and feeling drained, people who will never contribute more than a vague “it doesn’t work” GitHub issue are making tremendous profit on your back. The only way to prevent that (at least, that I know of), is using copyleft licenses like GPL, LGPL, etc.

I don’t find many compelling reasons to make anything other than command-line tools open source at this point, and even then, they’d all be GPL. For me, if someone could potentially profit from the work, it makes more sense to simply charge for it. That’s still an option, and we shouldn’t forget it.

Some open source projects are quite profitable. Bitcoin for example is an open source project.

There are also many people paid to work on open source. Projects like TypeScript or TensorFlow are good examples.

It just doesn’t work well to first write an open source library, give it away for free, and then later try to make money from it.

I applaud your effort. It did raise about quite a bit of unproductive discussion, but there were so many things worth discussing: how funding should happen, the privacy concerns surrounding the proposed format, etc. Though this model didn't quite work, it doesn't mean there aren't undiscovered models waiting out there -- or that there can't be an ongoing discussion about how to improve.

I did want to discuss this sentence from the article. Since it was in bold, it seems worthy of unpacking it a bit.

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

The thing is though, nobody would pay for a service that just left pads. People compose open source projects into novel ways to solve customer problems. A customer problem isn't: "I need to sort this array n log n efficiency". A customer problem might be: "I need to find my most recently updated accounts, and generate a report". To state this in other words: startups create value through their novel use of open source packages, combined in a way to solve a problem painful enough for other people to pay for.

If left pad was that hard to do, people would certainly pay for left pad as a service. But individual open source packages provide minimal economic value. It's how they are combined that creates value. And I think that's what makes it difficult to extract value from individual repositories.

If your primary objective is value extraction --which is totally fine, by the way, many people are coding for paychecks-- why not do it for a company? You clearly have so much skill and would undoubtedly be paid well. There's many remote companies these days, it'd give you the lifestyle you want-- the freedom to travel, etc. It's not as free as being able to say, "I want to work on X and Y and Z open source packages", but it isn't all that terrible. My company gives me bandwidth to contribute to OSS during working hours, too. I think wanting the freedom to 100% control what you work on inevitably comes with the tradeoff of a lower salary. At work, I might occasionally get stuck on a project that I'm not too interested in, but that's why I get paid a premium to do it. I think wanting a FANG salary, but also total control of your workstreams, is honestly asking for a lot. It's wanting the best of both worlds, with none of the drawbacks. If everyone could make six-figures a year working on dozens of open source projects, they'd probably switch to doing that, since it would be (hopefully) more rewarding.

I think the pandora box has been opened. I predict there are some people who will build startups around this idea (not me). pip install something / npm install someting/ brew install something, and you will see the ads. The startup will build a dashboard for advertisers. The terminal will be the next frontier for advertisements.

The storm is coming.

The links in the article to other blog posts from famous open-source developers really helps his points... don't skip them!

In my mind this is a problem that must be solved at a packagemanager level, where its both possible to dynamically allocate consumer money based on utilisation/download distrubutions, and other allocation factors, such as more sentimental ones.

In addition i think that just installing a module and then starting to recieve funding is a bad carrot, as i can already feel the drama of people who will refuse to give up abandoned packages and namespaces, just to claim their funding. If you had it a bit more centralised you could atleast punish that kind of behaviour and make people responsible if they want to participate in the ecosystem of payouts.

Just a thought experiment, lets say funding was solved, but in a way that package's funding is split between owner and all dependencies. Then there would be economic incentive to implement trivial bits yourself and only dependencies bringing true value would be pulled in. This in turn would weed out all the rubbish packages as there would be no reason to create them in the first place, since no one would be installing them. It can benefit whole ecosystem where rules of Darwin's evolution come into play.

I'm frustrated that there isn't work being done on what I'm convinced is the only option: sales people dialing companies for dollars to support open source. I wrote up how it would work imo: https://medium.com/@paulbiggar/how-to-fund-open-source-8790e...

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 out well for consumers in the long wrong, because there would be far less to consume.

People pay for software regularly. Package managers are marketplaces for software, so it doesn't seem like a huge leap for them to facilitate the exchange of funds. Then feross can charge money for standard if he wants, and people that don't think it's worth it won't pay him and won't see an ad and won't use the software.

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

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

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.

I use the AGPLv3 for most of my software, because I don't work for free, for the most part, and want to use the strongest copyleft license available to ensure this. That parasitic corporations fear copyleft and the AGPLv3 in particular is just icing on the cake.

If you don't want your software used in this way, then don't use a permissive license. I sometimes use the most permissive licensing, the CC0, when I write something truly trivial and don't believe I could get away with making it copyleft. Perhaps you understand this general approach, but also that people would simply use a different implementation of your libraries if you did this is the issue here. You don't mention Free Software once this entire article though, so I find that unlikely.

But telling maintainers to bury their appeals where no one bothers to look is not the answer, either.

I vehemently oppose giving Github even more influence in the form of financial payments to its users. That's asinine and I refuse to use Github.

No one knows the value of a sponsor message in the terminal since this has never been tried before. That’s why this was an experiment.

The value is nil. I don't need to take a flame to a rabbit to know it will burn.

Fellow open source maintainers and open source contributors have, by and large, been supportive of the experiment. Open source “consumers”, not so much.

I'm not an open source maintainer, but I write Free Software libraries and I've voiced my opinion in the other thread here. This paragraph creates the impression only those who don't contribute disliked what you did. For the record, I found it and continue to find it suitably amusing.

Many supporters expressed their dislike of advertising – even advertising where the sponsors are carefully selected and the implementation does not track users or collect data.

Advertising is inherently awful and nothing will change that.

Approximately 100% of the Fortune 500 use open source code. Maintainers are just starting to wake up to our own power. Expect to be surprised. This certainly won’t be the last open source funding experiment.

I suggest investing in Free Software and not open source; is it any surprise that the rebranding of software freedom specifically tailored to corporate interests encourages this?

Even for simple single-purpose packages, there’s a non-trivial ongoing maintenance burden. Especially when you’re maintaining hundreds of packages, as many in the Node.js community do.

I've taken a look and I could probably claim hundreds of packages as well, if I wrote many, trivial packages, which is most of what I saw under your name. I currently have five libraries, two or three of which are somewhat trivial, not counting complete programs and other such things. It seems unfair to claim hundreds of packages when many of them seem so trivial and this is also never mentioned.

Not to put too fine a point on it, "Free software" was invented to level the playing field. Copyleft was an attempt on building an ecosystem with a level playing field. Nobody has more or less abilities with respect to the code. The receiver of the code has the same abilities as the copyright holder (with the exception of being able to change the license).

When you choose a more permissive license, it may still be free software, but it may not promote a level playing field. This suits a lot of companies, but it's not that good for programmers (unless you are in the employ of said companies). As an independent programmer, copyleft (or share-alike) is your friend. I find it strange that this is a controversial point.

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.

The problems with this 'funding experiment':

- If he does advertising, everyone will eventually start doing it. Then everyone will start using adblockers, defeating the purpose originally planned for. It's a classic case of the Tragedy of the Commons situation [0]. This experiment would have never worked in the long term and only benefits those who do it in the beginning momentarily.

- He created a github issue thread asking for feedback from everyone [1], but then closed the issue thread. Later one he went on saying that he doesn't care what people say unless they're contributors to the library [2]. He could have just limited the thread to contributors only but he prefers pushing the goal post.

- If you can no longer support OSS, then hand it over to an organization open to the community, or archive the project. As an example, Fatih archived projects he could no longer support and the community had no issues at all [3]. People who can contribute will fork the project and continue with it.

- The core-js maintainer started doing ads like that first, promoting his own job advertisement [4]. It got to the point where he started deleting comments and blocking people on github which he disagreed with. Keep in mind that this is a package with million of weekly installs and used by babel libraries so people's output logs looked like this [5]. I believe it was violating NPM's terms of service too.

- Authors can do whatever they want with their own packages including spamming post install logs with ads, but expect the programming community to be very vocal against the practice [6]. A package meant for the community should listen to the feedback of the community, instead of calling them wrong.

[0] https://en.wikipedia.org/wiki/Tragedy_of_the_commons

[1] https://github.com/standard/standard/issues/1381

[2] https://twitter.com/feross/status/1165515455882096640?s=20

[3] https://arslan.io/2018/10/09/taking-an-indefinite-sabbatical...

[4] https://github.com/zloirock/core-js/issues/548

[5] https://github.com/zloirock/core-js/issues/548#issuecomment-...

[6] https://www.reddit.com/r/programming/comments/cus0zu/a_3mil_...

If your goal is profit then giving away your work for free isn't a good strategy.

What you gain with open source is free distribution and advertising (public git, free advertising in the form of package.json, mentions in readmes, articles demonstrating your code, and so forth). OS maintainers are also gifted free labor (I didn't read anything here about profit sharing with contributors/debuggers, or how that might work, or even if it could work). It may not feel nice, but if you're going to question the economics of a market you need to be honest about cost and value.

In fact OSS maintainers are massively subsidized by the community, by large companies (like Github) and so forth. And this is an automatic cost subsidy that operates outside of value. Most OS software has little (or negative) value, yet is allowed to survive, when in an open market (where it costs something to maintain market presence) most OS projects would be eliminated, reducing the massive cost to teams and companies doing the (free) work and assuming the large risk of eliminating bad products, work a real market would have done for free, by voting with their power to install (or not), ie. buy. If I install one NPM module I am essentially "blackmailed" into installing several others, which may introduce hidden costs that only I will be responsible for (and not the original product creator). It cuts both ways.

It is also disingenuous to elide the real financial benefit of maintaining a popular OSS product. A fair analysis demands a clear accounting of year over year income growth to OSS maintainers able to convert the (perceived) demand for their products into higher wages or other payments for their time in terms of design, engineering, community management, and so forth.

I feel the "good cause" argument is being misappropriated. If you believe in software and making the world a better place through development and sharing then there should be a dot at the end of that sentence. I write books (don't do it!) and give away a lot of software (do it!) because I think freedom is at the end of that work. I'm happy with that in this margin-focused, "if you're not making money you're a nobody" world. The relevant progenitor here is Stallman, not Smith. Idealism is low margin, typically.

Facebook and Google release a lot of open source software. Why aren't their Patreon numbers through the roof? Should they be? Have you used Linux? Git? Why haven't you paid Linus something (a lot!)? Still getting nagged on your code editor about paying for a license? Why haven't you paid it? Why aren't businesspeople who also give away their software for free (for a time) being paid by every single consumer using their software (see: https://www.sublimetext.com/buy?v=3.0)? Why is nagging even necessary?

There is more. Will a hypothetical "deserving" maintainer add features based on the requirements of her sponsor(s)? Will bug fixing priority be determined based on sponsorship amounts? This already happens. And it should! But that's a very different game, and please don't claim that this special class of human beings is beyond corruption. Beware the person who claims their purpose in making and giving away free stuff is "love ️ ", and then later asks for a donation. Cults work that way. Drug dealers work that way.

That being said, please do make money if you can. Money you earn. By delivering rare value that you can convince someone, at your own expense, to buy. Like everyone else. The consumer isn't obligated to pay for what they can get for free. If you are upset about the lack of income, stop doing free work. Those who intend to pay nothing for the OSS they use are "less ethical" in no way whatsoever. And claiming to deserve what amounts to charity isn't convincing to me, given that I expect every single one of the people who benefit from say the top 100 repos earn six figure salaries and may even get a free lunch, every day.

Keep giving. Be kind. Share. Don't covet.

Thought experiment for funding OSS:

tldr: Your avatar has a glowing halo that shows how much you contribute to the OSS ecosystem. People thus always know how much of an OSS saint you are.

* Instead of gravatar, OSS projects start using fundavatar by default.

* You can contribute $$ to fundavatar to support OSS.

* The more $$ you contribute to fundavatar, the bigger your halo is on your avatar for people to see.

* Fundavatar has a smart voting mechanism to distribute funds among OSS maintainers, that involves your preferences and delegation past the granularity that you don't have preferences. I will describe in more detail if people want to know.

* Crucially, you can get a big halo just through OSS contribution and not lose money by joining fundavatar, because as an OSS maintainer you can pump X% of your revenue back into fundavatar.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact