I expected Youtube Red to work like this. Each person has its own pool. Channels should have been weighed by watch time with a minimum weight so that small channels get something as well. If I watch one channel then that channel should get the whole $10 (minus youtube cut).
Instead we got a stupid global pool based on global popularity that primarily benefits PewDiePie even if I don't watch him. The compensation was barely enough to cover the lost ad revenue so it failed to actually provide a viable funding alternative for channels that aren't getting millions of views.
I hope the same thing doesn't happen with this model. If 100 people sign up at $10/month to only support CatacylsmDDA and minetest then these two projects should get $500 each (minus transaction fees). That money should not be diverted to Angular, React, Vue, ... and then when its time for the two mentioned projects they only get a pittance like $5 per month.
I generally agree, though I'd say donated money should go to every sponsored individual/party equally by default, with donors able to set weights to recipients in their preferences.
Weighting videos on watch time, or GitHub sponsorship amounts based on number of repos, creates perverse incentives. High quality tutorial videos that get to the point and communicate ideas efficiently get less money than those with a minute-and-a-half intro and two minutes talking up a sponsorship at the end. Similarly, GitHub projects that are broken up into many repos, even needlessly, get more money. Same as the microservices hell that many software companies have faced when they drink too much of that koolaid.
Almost, except for the low end. It would be perfect if it grouped donations and charges, and let you allocate any arbitrarily small amount to any creator. As it is, it charges fees per creator you patronize, and limits donation to being at least $1 per creator. I'd put $30/month there easily if I could spread it over 100-200 creators with fees of $0.30 + 2.9% on the $30, but the current $0.10 + 5% on each $1 donation means a lot less of my money is going to the creator (who also gets charged those fees + 5-12% for Patreon services when cashing out) than I think is useful, and that's even after downsizing the pool of creators I'd like to donate to in order to meet the minimum $1/each.
To be fair, in looking this up, I did find it's a lot better than when I cancelled my Patreon account, since at the time they were proposing $0.30 + something% even for $1 donations. But the bundling of donations was my whole point in using them, and when they clearly said they weren't going that way, that was it for me. That's why I like the Brave/flattr/"sponsor pool" approach so much more. It lets me support creators (especially web comics, bloggers, and video creators) in a much more similar scale to the advertising model, which many were on before, and for which I think we need a popular replacement.
> As it is, it charges fees per creator you patronize, and limits donation to being at least $1 per creator. I'd put $30/month there easily if I could spread it over 100-200 creators with fees of $0.30 + 2.9% on the $30, but the current $0.10 + 5% on each $1 donation means a lot less of my money is going to the creator (who also gets charged those fees + 5-12% for Patreon services when cashing out)
Liberapay lets you donate a minimum of ¢1 ($0.01, and they also support 32 other currencies) a week https://liberapay.com/about/faq#maximum-amount, and IIUC lets creators choose the cut that goes to them
Patreon has the same issue described in the OP: the marginal cost (both psychological and financial) of supporting additional creators is too high. Since YouTube Premium distributes payments automatically based on watch time it doesn't suffer from that issue.
The difference is that if 9 people watch 99 hours of A's let's plays or last 2 music videos on repeat, and one person watched 1 hour of B's 20 well-researched and edited 3-minute educational videos, A-watchers put in $90, B-watchers put in $10, and under global popularity A gets $99 and B gets $1. Local pooling would mean that A gets $90 and B gets $10. This is my main complaint against Youtube Red too.
I think that this essay is fundamentally brilliant, but doesn't come out and yell the self-evident truth: the ONLY way this ever takes off is if Github does it.
And man, do I ever hope that they do.
There's no other entity in the ecosystem that even approaches the role Github plays, with all due respect to Gitlab and the rest of the also-rans. It'd be wonderful if they did the same thing, but in the end, they are going to be the contrarian 2%.
It's important to remember that GH sponsors isn't even out of beta, yet - you still have to apply and make sure that all of your tax docs are in order.
One small proposal I'd make is that I suggest Sponsors and Pool could exist happily in parallel. I believe that there's a meaningful difference between being the patron of a developer and feeling like you're backing a creator with feelings and a story and a family... and wanting to be a good citizen that has an approved list of projects that I benefit from and want to support.
I can sponsor Matz, get his updates and feel good about knowing I am counted as a supporter AND set aside $$$ per month to contribute to all of the tools I use in my projects simply because it's the right thing to do and I want those projects to exist for the long term. They are completely different initiatives. Patreon vs Humble Bundle, if you will.
Perhaps most critically, Github could keep absorbing the cost of processing payments to sponsored developers but also announce that they plan to hold back 3% of your monthly pool amount to cover CC processing fees. I think most people would be more than fine with this.
But if Github isn't on board, this is all just speculative fiction. Please, if you work at Github, make this happen.
So we delegate complete control over open source financing channel to Microsoft, because it's most conveniant option? Sounds a bit insane.
I do use both GitHub and its Sponsors feature, but I'm still hoping for open source community to come to consensus to use a service from non-profit organization like Mozilla or EFF.
Friend, you are going to be waiting for a very, very long time.
In the meantime, every day OSS project maintainers get burned out, depressed, and often called mean names and there is no viable mechanism for them to get paid for it. CodeFund shut down, Flattr is not a significant player - I first heard of it in this thread.
Frankly, the network effects of GH make them the only viable place for this to happen in the medium future.
I agree with all your points, but I'm still optimistic.
The biggest two issues are that anything related to finances is heavily regulated, and that third-party services integrated into repositories/blogs/posts create lot of friction for users. It should come down to 1 button: donate fixed amount immediately. It's easy to press that button few times, or to press the button every time you update to new version. Simple is good.
One way around regulation would be for each online service to have a independent credit system. Like karma, but you can also spend it to reward others. Communities would reward each other for creating content. Independent entities could offer to exchange your GitHub credits to Reddit credits. Those entities could also handle exchange to and from actual money, with credit card fees and necessary financial regulation isolated to just those entities. Let the market regulate itself.
Do you not see that the very thing that made GH a social hub for something that was previously totally disconnected is exactly what is required to push something like this anywhere close to a critical mass?
What other service is going to provide a consistent, trusted interface with payment details already stored that is so close to the projects that you're using?
Maybe the npm registry... oh wait. :P
Seriously, if what you want was going to happen, it would have happened by now. There isn't another force on the planet today that could make even a small dent.
To send someone money I'd have to know their address (not viable). If they only accept money through GitHub sponsorship, then I'm prevented from donating in any other way.
Which option do we (content creators) endorse? We definitely need to transition to better funding model. Seeking out donations and sponsorships is frustrating and that time could be better spent. GitHub Sponsors managed to solve most problems on technical level, but I'd like to see other options.
> To send someone money I'd have to know their address
You could just ask them? I recently donated to an OSS project for which the maintainer didn't publish any means of accepting donations - I simply asked and he sent his PayPal address.
Another option would be for maintainers to publish a Bitcoin address in their profile - but again, if not already present, just ask.
Yes, I got that; I was suggesting you can just ask the author for their address or other means of payment, but in addition made a suggestion of authors publishing Bitcoin address (in reality many would likely prefer fiat currency though).
With my tongue firmly pressed in cheek, I think you're being charitable to imply that most loud FOSS champions are currently making any meaningful attempt to send money to developers.
No, this is all about hating Github/Microsoft because they are big and because they won. Nothing in my comment is remotely controversial to realists.
Author here - 100% agree on all fronts! I was dancing around this conclusion but it really does need to be GitHub.
And I agree people would be fine paying their own fees if it came to that. Also, in that case, if someone is donating a non-trivial amount, they're incentivized to fund their wallet with a cheaper payment method like an ACH transfer.
I just want to point out that in Europe we have 0-fee SEPA transfers that also work for regular payments.
I'm not sure why nobody makes use of that more really. There are simple-as-paypal solutions for it, and given the amount that CC processing costs I'd have expected it to be picked up more. Maybe someone here has practical experience to share on why it's not that easy?
Yes SEPA transfers are free in the Eurozone, which as you know is a subset of “Europe,” but there is the tricky issue of VAT — which might be due on your donations.
This might actually be the right question to ask, thanks for poking. :)
From a customer's perspective, fraudulent transactions are handled in the best way possible. Here's Stripes docs on it [1]:
> Customers can dispute a payment through their bank on a “no questions asked” basis up to eight weeks after their account is debited. Any disputes within this period are automatically honored.
> After eight weeks and up to 13 months, a customer can only dispute a payment with their bank if the debit is considered unauthorized. If this occurs, we automatically provide the bank with the mandate that the customer approved. This does not guarantee cancellation of the dispute; the bank can still decide that the debit was unauthorized and the customer is entitled to a refund.
> Unlike credit card disputes, SEPA Direct Debit disputes are final and there is no process for appeal. If a customer successfully disputes a payment, you must contact them if you want to resolve the situation.
So for a small company I can see how this process would be stressful. Although I'm not sure what the rate of fraud by the customers would be. After all, the customer still signed a contract. But that would likely need litigation then.
So, I haven't been on the vendor side of that. Not sure how much more stressful it is than CC, and if it's worth a few % of your revenue...
What you are describing here are SEPA direct debits. Many countries including the USA have a similar instrument. While it is free for the consumer from whom money is being collected, it is generally not free for the business that is collecting the money. So in that way, it is the same as credit cards, but the fee is a lot less.
True, but if the fees are a lot less then the question remains if they're just not worth the hassle, or if there are other reasons why adoption in companies (that I have seen) has been slow.
Regardless, an organization like github should be able to handle this, if they wanted to.
Your article does raise a few great points... about Github specifically. But not about funding sustainable OSS development in general.
Open source also is not a business model. It's a principle that relates to intellectual rights and copyright: the author explicitly stating that they won't exercise their rights as to what others do with their work, provided then that others share any modifications under the same terms of use. That's open source in a nutshell.
The direct implication, then, is that any business model that hinges on selling licenses that give a very restricted permission on the use of (a copy of) the software, is excluded. Which is exactly how games and products from Adobe or Microsoft are sold: you buy a license - a permission from the original author - to use the software.
Github itself has never been a marketplace to sell software. There are no affordances that allows anyone to sell and buy license keys or whatever. It's always been a descendant in the spirit of SourceForge or Freshmeat: a platform for hosting codebases via version control. No more, no less. Github pushes open source as a matter of principle because it's - above all - excellent marketing that doesn't need complex tooling: simply adding a LICENSE.md file with the GPL or MIT license is already enough.
Open source is not flawed, as you state. It's above all a principled choice you make. And it's a choice you make depending on the type of value you want to extract from the project you're writing.
In your article, you are lamenting the low income numbers from publishing code under an open source license on Github. Well, ask yourself this: Maybe it's not open source that's flawed, but the other way around: The tools you choose to extract value not fitting your expectations. If you really want to monetize software, then maybe you're better off looking into a closed source license and a platform that does allow you to sell license keys. Much like what Sublime or InteliJ and such do.
It's true though that funding Open Source projects is problematic. But this has always been true for any non-profit venture: Ranging from charity, culture, environmentalist causes or other types of citizen activism that doesn't involve setting up a private business. Open Source software is no exception, and unless you're able to charge for consultancy or derivative products (e.g. a service build on top of OSS software), you're funding options are very much limited to grants, philanthropy or donations.
Nadia Eghbal did an excellent study for the Ford Foundation that sums up the issues with funding open source nicely: Roads & Bridges, the unseen labor behind our digital infrastructure:
Beyond that, the pool & wallet solution you're proposing is above all an attempt to incentivise a specific type of funding: private, individual donations. I think it's a great idea in it's own right, and something worth considering. But it should be clear that it's a far cry from a silver bullet that will solve the disparity between the many profiting from labor of a few against a low financial reward for their efforts.
Personally, I think that if you're willing to work on your own open source projects, you have to mindful that you exclude the possibility to directly derive wealth from what you've build.
It's up to you then to figure out the alternatives: e.g. selling training, workshops, support,... or maybe getting hired by a company who are willing to let you work part time on your OSS project, or getting publicly funded because your project caters to the public good (e.g. culture, health, education, mobility,...)
I'm cognizant that I'm replying to someone named CaptArmchair. Based on your handle, I say: well-named.
Look, I'm sure you remember the heartbleed scenario a few years back... the moment when we all realized that the human behind one of the most critical pieces of our infrastructure stack was a slave to his sense of responsibility, but he lacked charisma and hustle and social presence such that he wasn't able to keep it together. His mental and emotional health were sorely suffering. Once people realized what was happening, the plate got passed around and from what I understand, things are a lot better now, for that one guy on that one project. Maybe it's wrong to over-focus on one guy, but his example is top of mind as I say the following:
You could not write the above if you weren't in a position of being privileged to do so. You can wax poetic about how writing free software is an expression of the divine all you want, but meanwhile the entire world is reconfiguring itself around software and a lot of those folks are going to need a source of income even if you're already doing well enough that you don't care to push the issue.
Essentially: you are not factoring in the way the world is changing. Most people building software and publishing it on Github, by numbers, are people who are using their Github profile as a resume. It's not been about RMS and ESR for a long time.
It's cool if you don't need to pay the bills, but don't demonize people who are hoping all of this energy invested in learning to code need to eat.
Hm... that's not at all what I intended to convey. And I think you're putting things in quite extreme terms.
The field of software / digital engineering has grown an exploitative side. This is absolutely true. To be crystal clear, without diving into detail and derailing the thread: I find this evolution reprehensible and not how humans ought to be treated.
Is that dynamic then the result of Open Source as a princple of intellectual rights? Is it really, truly an inevitability that taking on Open Source projects and pushing code on Github now singularly serves as a resume of sorts for applying for a paid job? Is giving up your intellectual rights by default really the only way to ensure that you can make a living from writing code?
Because of it is, well, that should rather lead to bleak conclusions about the state of the value that developers are willing to attribute to the time and effort they pour into their craft, the labour market, labour protection, and societal values as a whole. Instead of concluding that Open Source itself is the problem (it is not) and people ought to donate a buck-and-a-half to anyone who has a repo with an arbitrary number of stars on Github.
You could draw parallels with other fields such as academics, film, music, games, books, fashion and so on. So, exploitation is not an entirely new dynamic either. Plenty of aspiring graduates, actors, writers, musicians, models, graphic designers,... are scrounging by, and get exploited in the process, while relatively few end up in a good place. Usually, their complaints are met with a short, unsympathetic "should have chosen a real career/job instead!" quip. If I'm allowed to play the devil's advocate: Should we add software developers to that list as well?
Of course not! In fact, nobody deserves to be outright reviled for the professional career they pursue.
The problems you describe are societal. They are the net result of larger economic dynamics in a rapidly globalized, free and unregulated marketplace. A markpetlace in which a few smart people understood how to leverage open source software in order to accumulate enough leverage to enter the financial market, moving on to accrue even far greater wealth. And what you describe is just another take on the Tragedy of the Commons.
Like I said, if the world is reconfiguring around software, it should be held to pay the true price of maintaining that infrastructure. Much as is pointed out exactly by Eghbal's study. After all, there is no such thing as a free lunch.
You're making some good, if aspirational points, but I'm still not convinced. After all, artists have had patrons for a long time. The gallery system is a relatively new invention.
Do I believe that artistic creators are a net-win to society? 100% Do I wish that artistic professions were seen as worthy of support? Yes I do. But in actual today reality, most artists can announce that they are doing a show, staging a production, what have you, and make some money.
I would argue that the only way for someone to approximate this in 2020 as a developer of creative but not economy-driving things is for Github to adopt a pool as described by the OP.
One thing I want to be really clear about is that people shouldn't support projects with lots of stars just because they have lots of stars. Stars are a passible metric for evaluating which tool to choose, perhaps. But I think the power of the pool concept is that Github could hit you up when you git clone, or maybe even occasionally ping you with a "hey, are you finding this useful? consider adding it to your pool". Or how about opt-in reminders like "hey, you're about to add your 80th project to the pool, but at $80 pledged that would put your contribution below $1 for each project. no shade intended, but how cool would it be if you kept your pool >$2/project? it'll be the best value for $160 this month."
It's perfectly valid to leverage Github and open source as a means to an end: either to secure an income as an employee through public exposure of your work, or secure patronage through donations in order to attain a type of (partial) financial independence that allows for creative freedom.
Either way, every line of code that gets pushed in this way, was never directly commissioned nor sold to a paying customer. And that, well, that's a choice between different business models. It's not an inevitability as you make it seem.
It's wonderful to see how open source has flourished, and people ought to be compensated for the work they willingly and consciously distribute u free. I'm more then happy to pledge a small donation left or right, or contribute a patch, a piece of documentation or do a bit of mouth-to-mouth promotion.
Lamenting then that you can't cover your living expenses through donations and shifting the responsibility towards Github e.g. they should provide more affordances to funnel more people towards donating? That's quite an explicit take on monetization which is deserving of critique. Especially if the alternative entails, well, starting to properly value, market and sell your work, which is how the market essentially works.
As I said, that doesn't exclude me from acknowledging wealth disparity, and the fact that loads of people try to use open source and Github as a jumping board to secure a steady wage. I think that's really important: I've hired people in the past for enthusiastically showing and discussing their work, as it shows so much over who they are a a person, what drives them, and how they think.
Finally, let's not forget that Github isn't a charity nor a public administration: it's a private company with a profit motive as well. Which is a can of worm into itself if you start considering centralization, walled gardens and the nefarious consequences of those dynamics.
(By the way, patronage or philanthropy, as you mentioned, historically wasn't driven by purel altruistic motives: nobility employed artists as a way to flaunt their wealth and their power towards their peers.)
> the ONLY way this ever takes off is if Github does it.
Yes, let's encourage another walled-garden controlled by a dominant player which would be benefiting from FOSS donations (keeping % of it) while doing nothing to make GitHub a FOSS platform at the same time.
First, they don't even cover the cost of their credit card processing. They even used to match donations up to $5000. This is clearly not a profit center for them.
What it is, actually, is excellent long-term business sense. They know that maintaining open source is draining, often thankless and demoralizing. Making sure that their best assets are provided for is just smart.
But also, your attitude is wishful thinking, like Linux on grandma's desktop. And are you seriously implying that Github isn't a FOSS platform? That seems intellectually dishonest at this stage.
My grandma runs Linux on her desktop (I set her up with Fedora).
GitHub hosts lots of FLOSS, of course. The platform itself is fully proprietary, although apparently they plan to liberate some amount of the core. That's why snowdrift.coop choose gitlab.com, although even that's a compromise (we used to use their githost.io offering so we could stay on gitlab CE, but that service closed down and we had to weigh staying on fully-FLO tools vs network effects).
I just met a grandma that runs Linux. That surprised me. But it goes to show that sometimes wishful thinking can be achieved.
If we make something as a community that can replace GitHub in convenience and spread awareness of the problems with GitHub being our main code hosting platform, we may be able to convince the wider community to use a platform for FOSS that is itself FOSS (which is what I believe ekianjo was talking about).
I mean, if GitLab and the rest of the also-rans can't make a dent in Github's market share, I don't understand where you think this market disrupter is going to emerge from unless there's a grand migration to something Next that Github inexplicably is not able to adapt to.
Many on HN have noticed, I have a serious philosophical issue with centralization and closed source software.
Every time I see people say “X is the only one who can do it, I hope X is gonna do it but they won’t” this is part of the problem.
I am going to post this link right now on HN, under the title “A decentralized model for funding open source” which an entirely decentralized approach to funding open source projects, journalism and more. And we are launching it Q4 of this year. Once we do, it will spur permissionless innovation.
Look, VOIP disrupted phone companies, Web disrupted AOL, drove many costs to almost zero. Just in the last 20 years. We can do the same here. Stop waiting “Please” for GitHub.
> the ONLY way this ever takes off is if Github does it.
I disagree. What this need is a popular, well known and trustable organisation with enough money to invest into this. Github could be this organisation, but other could do that to, like Mozilla for example, or the FSF, Patreon, Facebook, Apple, maybe even google if they can sell a vision of them not shutting it down 6 monts later.
What is needed is awarness of such an option. Which would work better of course when integrated into the platform. But patreon seems to have proofen that it's also possible to do this with external services.
Also a trustable institution to handle the money
And finally a decent interface to manage your sponsorings, which also means someone doing the work in the background to figure out whether a project accepts donations and how. Would be easy if the platform supports it somewhat automatically, but could also be done manually for projects on other platforms.
I would even go a step further and not limit this to open source projects, but the whole web. Add a simple button into the browser to allow sponsoring for the actual visited url. With some background-service which is smart enough to figure out whether the visited url is a project on github/gitlab/sourceforge, or a blog, a podcast, some content-company , a streamer, or some dude on twitter with something you wanna support.
And if nothing can found to support, an issue is created and the humans in the background will figure out how to support what you consider as supportable, and will inform you if something was found. And with time some schemas and APIs will grow so platforms will allow automation fof this.
I am completely puzzled why you'd say that you need a "popular, well known and trustable organization with enough money to invest in this". How is the largest developer ecosystem in human history not the exact entity to do this?
But then you go on to suggest Facebook, Apple or Google... I'm not sure we're experiencing the same zeitgeist. Is Trump president where you are?
This is probably meant to be a feature request aimed at the Github team. They introduced a sponsorship program and now that it's gaining traction people want a more streamlined and optimized product.
Models like these existed. Flattr and Liberapay. The latter had to switch away from the pooling model because turns out when you do the pooling you essentially become a bank and that’s difficult to do legally.
Those models only work if users actually visit your website or your Github. I’m developing an app targeted at end users and I bet 90% of them have never been on Github or even know what that is.
I totally take your second point. But for the niche of apps that is developed for tech folks (think sth like ripgrep) this seems pretty viable.
For user-facing apps, it should always be the platform(s) distributing it that should have a pool mechanism.
So google for android apps, Apple for iOS. Yeah, I know, that'll be a cold day in hell...
PC software is a tough one there since there's no one app store. Which is the PC platform's strength, but yeah, that makes a pool difficult. As you said, Liberapay tried something like this. Would be cool if something like this could become big enough to justify the legal legwork necessary for this.
I think an even larger issue is that, I might know what OSS projects I make use of and will elect to support. But I might not have visibility into the OSS projects that _those_ projects themselves rely upon and really should be getting a cut.
So as I see it the proposed solution does remove friction to supporting a large number of projects, but doesn't solve the visibility issue very well as I expect most projects to be in that "used by something I use" category.
But if you're targetting end users who haven't been to GitHub... aren't you just billing them for access to your app? Seems like a different problem to getting paid for OSS by people who do know how to find and use it for free.
You have an account, filled with a monthly recurring amount, what ever amount that is. Then you click these "contribute" buttons, placed by the open source project webmasters in their pages.
Each click of button registers that project to your account and the site distributes your monthly amount among those registered projects.
Not able to recollect the name of the company though. Spreadrr, or Poolr or something.
OP here. I'd love to see something like this exist. Let me know if it does already, or if someone is trying, and I'll link it below.
EDIT: This model is used by Flattr [0]. Unfortunately Flattr isn't targeted at open-source software; an OSS-specific approach (ideally implemented by a highly visible, established player) is (probably) necessary for something like this to reach its potential.
Liberapay sort of does it that way, though their payment processor has made it somewhat difficult. Basically you pay them 50$ and then you decide how much you're going to sent to projects and how often.
For example, I donate about 0.50ct each month to mastodon (sadly I do not have much expendable income at the moment). But it means I can spread little money into donations over an entire year.
I think they still need to make a percentage-mode, where I allocate money from my pool on percentages (ie, 20% of the money to mastodon over a year, every month, results in 0.83$ every month being transferred, or 10$ over the year)
We actually planned on a wallet approach early on, and still consider it the superior option in many ways Not all), but we're launching with a monthly charge model because holding money is more complicated legally. To avoid higher fees for microtransactions, we're delaying donations until they total high enough to keep fees below 10%, then doing one charge for several months (ie, charging in arrears).
You don't need a wallet approach to do one-click, though. Just the ability to do many:many charges, which several payment platforms support (usually under "services for ecommerce platforms", like Stripe connect, if I'm remembering the name correctly). That lets you send one bill to each patron that totals their donations to projects, and one paycheck to each project, that totals all the individual donations from various patrons, avoiding a fee per patron-project-month combination.
---
Broadly, we don't agree that friction is the core barrier to donations (although lower friction certainly helps!). Instead, we think the barrier is people's reluctance to be the first to donate. Colloquially: people would pitch in if they knew it would lead to enough funding to be useful (ie, actually pay full time developer salaries), but nobody wants to be the chump wasting their money on 2 minutes of developer time per month (which will really be 0 minutes per month, because you can't hire 0.01% of a developer). That's why crowdmatching donations start small and grow as more people support the same project as you.
Coming back to the article, I'd argue that both big and small projects alike have trouble soliciting donations from individuals (for the reason above). The difference is, large infrastructure projects can solicit funding from large companies that depend on them. These companies can donate enough money to single-handedly make a difference, so there's no coordination problem. Consider LibreOffice: they're a large project, and their potential audience is even larger. But, their primary benefactors are end users, and they struggle to make ends meet.
Snowdrift.coop won't address the small-project funding issue right away, since in order to actually get launched some time this decade we're restricting our initial scope to large projects with the potential to really change the software landscape if they were well funded -- but we do want to expand our focus later, both to smaller projects and areas outside of software, like journalism, music, and research, which suffer from similar coordination problems.
It hasn't made enough impact over its long history. That's not necessarily because the model doesn't work. However, it does set up a zero-sum game. Each click to another project takes away from the ones you already support. Thus, it won't really change the overall economic situation much.
There are also foundations that sponsor multiple projects. E.g. Apache. There are meta-level projects like Ubuntu. In principle these larger downstream projects should do what's necessary to support their upstream dependencies. That doesn't always happen though.
Tidelift does funding that emphasizes awareness of upstream dependencies and supporting them.
## On microdonations and fees
This is a payment-processor issue. I believe that Stripe and some others have the capacity to process aggregate charges without all separate. So, if in a platform, you donate $10 to 15 different projects and so do many others, they could charge you the one charge of $10 and give the recipients their single payment from everyone. Each donor would get one processing fee, not one for every project they support.
This is key. And it cannot be solved at the platform level because holding funds in escrow is only feasible if you are a limited specific set of incorporated projects (that's what Open Collective helps support, they can do this approach with one donation fee for each Collective you donate to, even though the Collective could include a lot of projects. A specific Collective there could offer your system.
In other words: Open Collective could do what you're asking somewhat. You donate to a Collective. They don't just have the money for any of their members, the Collective offers a tool for you to vote on which of the members you want to support.
That's another way to see your proposal: An org that accepts donations and you get to vote on which projects they give grants to.
## On downstream vs upstream funding
Anyway, the bigger problem in free/libre/open funding is that it relies too much on proprietary end-user products that have paywalls or ad-driven business models. If a product is designed to reach all the way to downstream users, everyone can freeride. So, freerider problem, game-theory dilemmas.
You might be interested in the ideas at https://snowdrift.coop which is aiming to build downstream patronage via crowdmatching.
One thing that Flattr and many others like them got wrong, in my view, was collecting too little and levying too little from it. Too many schemes were $5/month or $3/month, then collecting 10% or thereabouts. You cannot build a sustainable business with high risk exposure for less than a fraction of cup of coffee per customer per month. But people kept bloody trying.
If anyone is interested, I have a simulator for pool-based funding as I'm working on a side project that uses the same approach: http://syd.jjcm.org/soci/
My project is essentially a reddit-esque site that hosts images/blogs/video/audio content. Each vote on a piece of content gives it one share of your funding pool for that month. The pool based approach is definitely the best for simple usability, but there's another aspect to it as well: it means you weigh your vote more. In the case of a social sharing/news site, low-effort content will get upvoted less, as you have to consider that every vote will dilute the pool.
I'm really bought in on this as an overall concept and I think it's something that will be extremely healthy for the web overall. Previously this was a model that was used by Flattr, but they had a major issue that not everyone was on their platform, so often times creators wouldn't get money out of a donation (because they didn't know the donation existed). I definitely agree with the author here that if this were to be done, Github themselves would have to implement it. As soon as a third party who isn't hosting the content implements it, an enormous percentage of creators wont know they have funding waiting for them and things fall apart.
Everyone thinks they deserve a dollar and can never imagine that the relative value of their code is effectively zero no matter how much it solves a particular problem.
>Big projects — operating systems, frameworks, CMSs, or fully self-hostable applications — are in a privileged position to extract more value from their users, especially corporate ones
Big projects aren't privileged to extract more value. They're privileged to solve enough of a problem for enough people that the scraps thrown their way amount to a meaningful warchest. Corporate big projects are privileged to extract wealth. That's the part that pays crazy SWE salaries.
You seem to be reacting against the term "privileged" in a way I didn't intend. I don't mean to say that they have some unfair advantage. They just have a more foundational role in the tech stack of the products built on top of them, so companies have a bigger incentive to keep the wheels turning.
I'd love to learn more specific details about your leveraging strategy. Keep in mind even someone like Torvalds only serves at the pleasure of big corporations. Let's keep gift economies in alignment with public interest folks. It's difficult to imagine a competent developer needing to squeeze people, for cash money to pay rent, considering how much coders get paid.
Two-thirds of projects on GitHub have 1-2 maintainers, as of 2015.[1][2] I’m sure many of those people are in other areas or occupations, or in other countries, where these high-paying jobs may not exist. Some people simply don’t wish to work at a company, and those folks still may produce value to those other than themselves.
Let’s not appeal to productivity too hard; learners and those of lesser coding capability also create value in the form of skills and knowledge.
It’s hard to identify and quantify those whose contributions helped most, but I feel all contributions are worthwhile. Not all code may be tip-worthy, but I don’t feel chagrin toward those collecting, however they do so.
> Only three projects—less than 3 percent of the study’s sample—had more than 50 contributors.[1]
> those folks still may produce value to those other than themselves.
They may, but my point here is that the reason a corporate SWE's code is so valuable isn't because of the code itself. It's because of the ecosystem that the SWE and corp are a part of. That ecosystem serves to multiply a meaningless block of code into a couple million dollars that can be split nicely with all the non-coders who made it useful. Without that ecosystem, an open source project can never hope to monetize to the same level. That big open source projects have substantial funding is an effect of being so imminently usable in those million dollar ecosystems that the forgotten scraps of the corporations are enough to sustain them.
I generally agree with your interpretation, but I don’t see what you’re advocating for. What do you think are the flaws/benefits of big open source projects receiving the lion’s share of open source donations? What funding model makes sense for those smaller projects? For many groups doing fundraising, the work of doing the fundraising itself is extremely labor and time intensive compared to the actual work the group does. Fundraising costs incentivize projects to become bigger and higher-profile to enhance their fundraising ability, but this increase in size and reach may not be helpful to all projects in all ways equally. More bugs may be squashed from more eyes; more cooks in the kitchen may make for lower quality standards of releases. It’s all a double-edged sword. I’m curious about your thoughts on this conundrum.
Yeah, the market value for most of these open source packages is $0. There's nothing about charging for software that goes against the spirit of libre software. (In the 2000s, Debian and Ubuntu made money by charging for CDs of the installers.) The reason these npm-type packages can't charge is that they're extremely fungible. Left-pad, react-router, etc. are trivial and nearly identical to the next one that is given away for free. It's like news articles. The NYT article throws up a hard paywall? Then I'll just search for another story on Business Insider, Bloomberg, Reuters, some blog, etc. until I find one that's not paywalled.
What kind of software are people actually willing to pay for? Microsoft Office, Qt, AAA games, Bloomberg Terminal. You need to step your game up significantly if you want to enforce payment.
> The reason these npm-type packages can't charge is that they're extremely fungible.
I'd say it's less that they're highly substitutable (which I was I think you mean, instead of fungible) and more that they are non-excludable goods. A seller has no way to exclude a buyer from consuming opensource; that is in fact part of the definition. But without excludability, there's no incentive for a buyer to buy, other than charitable feeling. Put another way, it's a textbook example of the free-rider problem or collective action problem.
These are usually solved either with compulsion, such as taxes, subsidy or command-and-control; or they are solved by benefaction. Benefaction is what we have, as a rule. It's like how a rich patron of the arts donates to an opera company without capturing all of the subsequent value the opera creates (most is captured by the rest of the audience). Very large portions of OSS is developed by fulltime professionals whose time is essentially being given away without any meaningful way to exclude non-payers.
The other means is bundling. Mix the non-excludable part with an excludable part, such as a services contract. But OSS can always be unbundled from services or packaging . In my experience, most unbundlers radically discount the cost of doing so.
Yes, but with a twist. OSS in itself behaves like a public good, but most business models for OSS and closed-source software revolve around bundling to create excludability (since software is de facto non-rivalrous). That makes them club goods.
The most effective excludability is SaaS offerings, because total exclusion can be enforced easily. That's why hyperscalers make far more from OSS than companies devoted to it.
(btw: the snowdrift docs are really impressive, kudos)
It doesn't matter why they might be exclusive. If it's through technical means like DRM (even absent legal support for it) or (blurry, admittedly) needing an exclusive tool such an Open Source plugin for Photoshop, then it's not really a public good. The latter case is arguably a public-good within the "public" of Photoshop-users.
I like the idea but instead of pools going arbitrarily every which way or to the discretion of the donator, it should be automatically applied across that open source project's dependencies as well. If I am open source software A, and I make ample use of open source software B within my project, your pool donation should automatically apply some to B, relative to it's usage in the project.
Agreed this would be nice, though this layer of complexity introduces a bigger attack surface for bad actors. They could try to get their modules listed as dependencies of popular projects to piggyback on their downloads. On the flip side there are some low-level tools (say, the `stylis` CSS autoprefixer) that are almost never used in their "raw form" but are the backbone of several massively popular projects. It's a tricky balance.
Is this really a concern though? In this situation, adding a dependency to your project means making a decision to divert some of your funding to them as well. It gives an incentive to avoid adding unnecessary dependencies.
If you're willing to do the extra maintenance of keeping them up to date (or else on the hook for their issues) ... maybe that's 'ok'?
I don't mean that it's a service worth paying for, just that maybe it doesn't seem like it's worth the extra (presumably minor) cut of initial donation and people wouldn't really do it (more than once / for long / on a big project with significant donations) anyway.
Distribution indeed seems to be tricky. Out of the myriad of utilities you use, e.g. React & a string sorting library. Should they both receive the same remuneration? That feels wrong.
No. The amount you donate, the majority goes to the primary project, since that's directly what you the user are receiving the value from, even if it's for the sake of the author pulling those dependencies together in a usable convenient fashion for you. The discussion simply becomes how much goes to the primary and how many goes downstream. I think 51% to the primary dependency at minimum as a starting point for debate.
I had a similar idea to this while reading the article. Basically, people donate primarily to end-user facing projects, like they do anyway (if at all). Each dependency gets 10% of the donation, which gets capped at 50:50. If there are more than 5 dependencies, these share the 50% among them.
So for example, in case I described it bad: Project A (1 dep.) gets 90%, the dep. 10%; Project B (5 dep.) gets 50%, each dep. gets 10%; Project C (10 dep.) gets 50%, each dep. gets 5%.
Now for the loopholes:
How to track dependencies? Well, I think the fear of public-shaming and pulling back of donations in case of bad acting would stop the end-user facing projects from lying. This donation system (ideally run by a trustful brand like Mozilla etc.) has a website, where you can look up projects and the dependencies they list. Since being open source is a requirement, claims can be checked.
Should all dependencies be weighted the same? The massive UI library, and the tiny bare-bones A*-implementation, or the NPM micropackages? This needs a metric that can't be rigged, so things like number of contributors, LoC or number of commits are not really sufficient.
What about MIT-licensed libraries? They may get used a lot by proprietary projects, but these can't receive donations in first place, so there is nothing to share to the libraries. Now the opinions on MIT are kinda mixed, but simply saying "your fault, pick a viral licence" is too easy, imo.
__
Footnote: How the [user]--donation-->[end-user facing project] chain works in first place, is not really part of my idea, I wanted to focus on how to get the money to the people whose project names nobody knows (until things like Heartbleed happen).
It's worth looking at Tidelift (https://tidelift.com): they're making the model work with pooled corporate subscriptions that create the right incentives.
That actually seems to be working. I maintain ruby grape, a mid sized project. We get $144/month from Tidelift. As more companies signup for corporate sponsorship the $ amount increases. It’s a pool.
This doesn't sound like a way for open source projects to get money to me. It sounds like a way to get thousands and thousands of bad developers to spam me to support their tiny open source no effort project. For them to fork someone else's project and ask for money for their fork. etc...
Note, a similar thing already happens on patreon where people ask for support for their piracy activities. They run a blogspot blog with pirated movies/anime/porn and expect you to sign up to support them on patreon for helping you pirate stuff.
Basically the easier you make it collect money from random people the stronger the incentive is for bad actors to try to get some of it. I don't have a solution but in my defense I do sponsor 3 open source projects at $!00 a month each. But I'm sure my money is going to people/teams who are really dedicated to their project and not just one hoping for some coffee money for their tiny thing.
> That's because there's currently no way to make a donation to the abstract concept of "open source software"
This isn't absolutely true, there are the FSF and the Software Freedom Conservancy, who fund many medium-ish projects, including ones that include some small utilities.
Right, there's not a perfect way to make a donation to open source software, and this proposal seems absolutely worth trying as a way to make it more easy to contribute to more projects that are more valuable to you.
(IOW, their idea of supporting the abstract idea of open source software. Although I'm not sure who you're talking about: Stallman I guess fits the description now but wrote his fair share of code in his day.)
I like that idea too. Though it definitely may lead to some troubling scenarios where bad actors try to get their modules listed as dependencies of popular projects to piggyback on their downloads. You could alleviate this by not funding dependencies of dependencies but there are some low-level tools (say, CSS autoprefixers) that are rarely used in their "raw form". It's tricky.
I see this being a major issue in the NPM ecosystem, lol. One thing is you could make transitive dependencies strictly opt-in, or have a decay function.
Or each package's maintainer can set a proportion for each of its dependencies, so that every time a donation is received, a certain amount of that donation is automatically transferred to those dependencies according to the proportion set by the maintainer. The donation sent to those dependencies is then propagated to their dependencies automatically according to ratios set by the maintainers of those dependencies.
It has to be scaled correctly somehow. For instance some big project uses isEven, which depends on isOdd, which depends on isNumber. All different npm modules. There are some people notoriously making these really small functions, and then creating a huge web by depending on other modules by the same author. Then just hoping one of them will get traction.
"sponsor pools" "sponsorships" and "donations" are all words that imply optional, not required requests for money as a favor. i.e. begging.
The way to monetise open source is for payments to be required in some way. i.e. provide a core feature set that is valuable on its own and monetise by providing additional valuable features under a commercial license.
You're missing the point here. The point is not to find ways to sell/rent out software (these already exist) but to monetize open source projects in a non-forced, non-compulsory way.
So, instead of selling your songs on a CD for a fixed price, that approach would be more like busking or having your music streamed on music services (Spotify, Apple Music, YouTube Music, etc.). It's unlike begging in that you do provide valuable goods with the expectation that the community is paying, and that providing better value (more catchy songs) will get you more revenue.
Non-required payments already work ok in a number of shapes for music and video creators, and we've seen some success in terms of feature bounties and direct sponsorship in software.
Given that enough people are willing to support the software they use, there are two things missing in the equation
- an entity collecting, pooling, and distributing money in a transparent (enough) fashion - the prime candidate would be GitHub because it already has sponsorships and the necessary bits of information
- an attribution model; and this is a bit harder for software than for music or videos where you can simply use watchtime as an attribution metric. Software has a more complex dependency graph, and arguably open source software is the silver bullet that allows us to stand on the shoulders of a herd of giants instead of implementing our bloom filters, routers etc. ourselves. This is a hard problem, and arguably one in danger of not being solved "correctly" in that an entity collecting money could do something intransparent and unfair and people might still sign up because it's the only game in town and they want the warm fuzzy feels and the convenience of not having to write 0.50$ checks to a gazillion small-project maintainers.
This "open core" model has been used for a long time, and it might work for commercial vendors that have large products with a plugin architecture, but it's a constant source of friction and inefficiency. Not everybody can or will be able to pay, and introducing licensing and payment systems complicates everything.
This is amazing and I have a gut feeling that it will revolutionize OSS.
I usually want to give say $30/month to OSS (personal use) and as a professional, I would have the authority to donate $300/month.
This would be great to not worry about individual donations, and just based on one-click or even just divide up the funds equally amongst all of my starred projects.
The root of the problem is that open-source donations are made on a per-project basis. To support a project via GitHub Sponsors or OpenCollective, you must create hyet another auto-renewing monthly subscription for each project you want to support.
I don't think the author's description of GitHub Sponsors is exactly correct. Technically, the sponsorship is at the user/organization level, so if you make a donation it goes to the organization/user, which may have MULTIPLE projects going on. This is the way I have set it up for our company Plyint (https://github.com/sponsors/plyint).
Although I would very much like GitHub to implement a pool of organizations/users, which is maybe what the author meant?
Good point, that characterization isn't exactly accurate. Though the first-order point is that you have to go through a separate "checkout process" each time you want to sponsor a new thing.
I actually think it's important that the pools themselves contain projects not users/organizations. There are definitely complications I hadn't considered if multiple entities/organizations are listed as maintainers of a particular project. Presumably the set of maintainers would have a way to "split" the incoming donations among themselves as they see fit.
I think this is probably inherent to donations, at least if you're targeting individuals. My priorities can be shifted with respect to what I might donate to, but I'm not likely to substantially increase the total amount I donate in a given year.
> The marginal cost — both psychological and financial — of supporting additional projects would drop to zero
Great idea for redistributing existing funds and preventing winner take all, but the bigger hurdle is increasing the overall funds (eg, getting more people to give a shit in the first place)
I have a lot of experience with non profits and independent projects, and funding success is partly based on merit, but more frequently on how clear, consistent and obvious calls to action for funding are.
At some point it stops being a problem you can fix with software. It's not like there's a mountain of funding that just needs to be unlocked. It's more about growing the funding in the first place, which when successfully done (in my experience) starts to look a lot like aggressive marketing, advertising, and tweaking of missions to appeal to whatever is hot/fundable at the time, similar to the VC industry. True story, and kind of an anecdote that money turns everything to shit eventually.
I termed this model "microsubscriptions" when I was pursuing it in the context of website funding.
There are difficulties.
Gaming the system
Folks will absolutely distort their software, buy fake github stars, spam out bazillions of typosquatting packages etc. We know this because there is already a weak financial incentive to subvert: supply chain attacks for cryptominers. Direct cash will be a much stronger incentive for fuckery.
Banking
In general, financial institutions don't like services that aggregate and transmit funds. They attract extensive regulatory burden and more importantly, they attract fraud and chargebacks.
Chargebacks and fraud are expensive to deal with, banks hate it, so they generally tell you to just sod off entirely.
Regulation
You are on the hook too. Anti money laundering laws are complex and can come with criminal charges for failures. Taxes are complicated and you need to keep correct books. Got it wrong? Too bad, you owe the taxman cash you don't have.
Credit card money laundering in general
This is where someone with a stolen card uses your service to launder money taken from it. They sign up with the card, patronise their own software, then run off with the cash. Later a chargeback arrives which is levied against you, not the attacker.
The easiest defense is to limit the subscription amount, so that an attacker with a stolen card can't benefit much. But they can still use you to test that the card is active. A second defense is to hold the funds for a period of time, so that you can pay chargebacks. Even so, you will be looked at poorly by any banks or processor companies if your chargebacks pile up, regardless of whether you could cover them or not.
Trusts
This one is the biggest mistake I see, and I see it again and again.
If you receive money from person A so that you can pay it to person B on A's behalf, you are a trustee. You generally don't need a document to become a trustee and you don't even need to intend to be a trustee. Trusteeship arises from the facts.
What does trusteeship entail? Fiduciary duty. That is a high bar and you almost certainly don't meet it.
Mingling funds from multiple donors without incredibly scrupulous accounting? Problematic. Mingling donor funds with your own funds? You're in deep shit.
Further: trusts have purposes, which the trustee has to abide by. These again can arise from the mere facts. If you said you would take funds from A to pay to B, that's all you can do with it. Can't find B? Stiff shit. B doesn't want the funds? Stiff shit again. You now have money that is like radioactive waste: it's dangerous, you are responsible for it and it won't go away.
----
In general I like microsubscriptions as a model for some things. I spent a lot of time, emotion and treasure on doing it myself. But it is harder than it looks.
You sound like my legal council, accountant, financial advisors, investor friends and former colleagues from the bank used to work for when I was having the same thoughts about building a micro-payments service.
Yes, if you take credit cards, you'll have loads of issues. But for example supporting the eurozone (most of the EU) is both easier and better accomplished by only taking SEPA push transfers. While there is fraud risk, it's significantly less and shouldn't cost you as the processor. Worst case, I think, it'd be the cents you have to pay to send the money back.
And regarding the issue with being a trust: sure that's a thing, but contract terms should be able to fix the problem by making you send it back (minus nominal fees?) if the designated recipient's registered IBAN refuses your payout. And just don't offer to collect money for anyone who didn't register.
One of the most enlightening blog responses I have ever read and so important because there are so many issues where one that hasn't dived deep into the topic likely will not have uncovered going in. Especially from a technical perspective.
Many mock engineering challenges in banking but boy, given the complex environment that they operate it, you can see why the technology stack is a mess that mirrors that environment.
I don't see them as dealbreakers for a sufficiently well-resourced organisation. After all, I wanted to pursue a related model for websites, so I wanted them to be surmountable. But for a startup they would be high barriers, especially since most software folks have never even heard of trusts.
Mind you I had an advantage in that my scheme, payment and usage were tightly linked. I had a protocol that could prove a user had visited a given website, without needing to reveal that user's identity to the website and without the ability for the user to falsify visits. But with opensource software there's currently no good way to verify usage, there's no expensive signal that the code is being consumed. All that's left are cheap signals, easily gamed, like github stars.
At $DAYJOB I've pitched a concept of universal asset accounting which would actually make such a consumption signal possible in theory. For inspiration I was looking to inventory accounting and cost accounting, particularly resource consumption accounting.
Change "open source projet" with "online newspaper" and everything applies.
I want to be able to give 20€/month to whatever news article I read with just one click. Instead of liking something, I want to be able to pay quality writings.
The browser is the perfect way to do this. I don't understand why Mozilla did not implement that.
Brave is close, but Brave wants us to view ads. I don't want to pay for a newspaper article talking about climate change through watching their ad for the latest diesel SUV. I want to pay them, but without filling my bank details for a monthly payment.
In France, the largest national newspaper lemonde.fr lets you subscribe in 1 click for 1€, but then you have to send them an tracked postal letter costing 7€ to cancel your subscription.
I would love something like this + automatically adding all the NPM packages I use to the pool (or similar for Cargo, PIP etc). So that I don't have to manually find the packages, and can easily contribute to everyone who's code I'm using.
This addresses the lack of convenience in existing tooling, but not the core of the problem of FOSS sustainability.
I believe to solve the problem two things must happen:
* Users evaluate how exactly much they benefit from particular software and services, and how much they'd lose in utility if their option of choice disappeared.
* Maintainers find out what matters to real users and offer them good bargains to fund their development roadmap and maintenance service level.
Concept is very similar to Coil.com s "donation" for web content. But Coil actually does "pay by usage" and should therefore be more fair at distributing the money.
Its hard to define usage for an open source project.
It could work for a select group. The reason why other donation models are successful is because they offer something (insider access/game earlier) that makes you feel special without the badge.
This is something else I've been thinking about! Caleb Porzio's post from last month describes a Patreon-style
"insider access" service built on top of GitHub Sponsors. I think it's a phenomenal idea. Ideally GitHub would also implement something like that "natively" as part of the Sponsors program.
I am glad people are thinking more about Open Source software and how to fund them. I think among other problems, Open Source have 2 main root issues when it comes to funding.
1. Silver bullet is a myth. The OSS users are forced to use one medium for funding the software. Maybe Patreon, Github Sponsors, Paypal, Librepay and more not than one or all of them in most cases. Using more funding method have their own challenges, but it depending on the prject should definitely be more than one.
I take the inspiration from POSSE concept from Indieweb (https://indieweb.org/POSSE). It talks about publishing your content (blogs etc) once and distributing through various channels like FB, Twitter, HN etc instead of forcing people to your website which is just one medium. We should give the same level or freedom and choices to people who want to donate to your OSS project so that they will use a method which they are already using. Reducing the friction. And Flattr or the new proposed will only be one of the ways or should be one of the ways.
2. A lot of people don't know the difference between FOSS/FLOSS and OSS. Especially people after the Millennials (i think). To them, it is a FREE material. It is not! We should make awareness about what free software movement was.
Open Source forever have been about "free as in freedom" not about "free as in beer". The whole reason for it to start was because the software was not allowed to be redistributed and modified among other things. There definitely was freeware and other software models which were FREE even before Open Source was coined. Stop using FOSS/FLOSS everywhere if you don't mean it and make awareness about the differences about FOSS/FLOSS and OSS.
The effort and time of the maintainer should be rewarded with whatever he/she/they want, either recognition or money. We should make it a new normal. Making money from OSS should be OK. Being rich (if you can that is :D )from OSS should be OK.
I'm going to offer users something if they sponsor the project by looking in the GraphQL data. Today there are no simple ways of just asking github: "for how much $ does user X sponsor user Y" and much less per project!
I think that is the only way to get open source revenue! Unfortunately that means you either need a service or some closed source part that guarantees that revenue.
I added a footnote to address this. I admit I hadn't thought this bit out fully.
Basically there needs to be a mechanism by which the set of maintainers divvy up the money.
A pattern I expect will arise (actually it probably already exists): there can be different "contribution tiers", a fixed percentage of the proceeds go to each tier, for each tier the allocated percentage is be distributed evenly.
An odd side effect of trying to monetise an open source project is another repo popping up just outright copying it with no attribution. Amazingly, some people expect that if you make an open source project on GitHub therefore every single feature related to that project should also be open sourced. It's very disheartening.
I think the open source model is fundamentally flawed and enables the big corporations to profit at the cost of the little people. The large corporations benefit disproportionately from open source as opposed to the maintainers. I thing what would be useful would be a programmer's "guild".
* There is a yearly due - say $100/year
* When you write software, you assign a license to anyone in the programmer's guild to be able to use that software. The requirement is that you have to contribute back changes.
* Only people in the programmer's guild can use that code.
* Anyone can join the programmer's guild, as long as they pay.
* A guild member can allocate up to half their year due to support a guild open source project or projects.
* You use the annual dues, to support widely used infrastructure that a lot of programmers are using. A big example would be NNTP
This has number of very nice benefits. First of all, it ensures a massive pool of money to support worthwhile open source projects, that everybody is using (think NNTP, or projects like that). With that pool of money, we could add benefits for guild members such as employment contract legal review, immigration assistance, etc. If you increased the annual dues, you would be able to do more, but at the cost of excluding more people.
Everything is fundamentally flawed so it doesn’t say much to state it.
But personally I think the open source model has been wildly successful.
Before open source you needed to get a job working for a company to see any really cool code.
Now you can see and play with a world class version of almost anything: a world class OS, a world class 3D rendering engine, a world class video editor... it’s awesome.
Yet another model that has probably been never used on high scale: letting people sponsor tickets (GitHub issues). The donation would go to the contributor who closes the ticket to the satisfaction of the main contributors. The amount, of course, will be decided by how a ticket is perceived as important.
The entities that most benefit monetarily from OpenSource are companies that sell products and services based on them. Why would they contribute to this? It's an added expense they don't have to pay. In fact a major tenant of OpenSource is that you can choose to make money or give. it away for free, but you generally have to release the source code, which is what the companies want, so again, why would they pay for it? To make a more sustainable ecosystem? Hahaha.
As for individuals funding this, Open Source developers are not cheap, to make it worthwhile (e.g. comparable to a part time contracting gig) we're talking a minimum of tens of thousands of dollars per year per developer. We're not going to get anywhere near these numbers with individuals contributing.
I write this as the guy that tried to help the OpenSource world by assigning CVEs for security issues (several thousand...), I'd have had to charge 1-200$ per CVE to make a living at this while I was doing it. That's not going to be sustained by personal donations. And even though a CVE will easily save companies a few tens to hundreds of dollars (time spent tracking all these issues when they don't have CVEs...) there's no way I'm going to get companies to pay me.
The good news is that this doesn't really matter. We've had many decades of OpenSource, there's enough good people working on this because it's their passion/hobby/day job that it's mostly sustainable on average, but specific bits may be sickly, and that's ok.
Another good idea would be for projects to list other projects they depend on, and set aside a certain amount of their GitHub sponsor income to go to those projects. Thus Users -> Projects -> Dependencies flows naturally with the same model.
If I may, a totally different way of funding open source projects is possible too, that doesn’t rely on charity mechanisms:
I will submit it to HN now as a link under the title “A Decentralized Model for Funding Open Source”. Look tor it there.
You don't get paid unless someone adds you to their sponsor pool. If no one knows about your thing, you don't get paid. Am I misunderstanding your question?
I don't think the article made the argument that you should be paid unconditionally. It only suggested that it should become easier to donate to multiple projects with a single click.
I'm not convinced that a funding model doesn't work because it pays nothing to a project nobody (not even its own creator) has heard of.
That being said, I wonder how well this would work out for smaller projects. Spotify uses a very similar model, and from what I hear, lesser known artists make very little money on their platform.
The key difference is that while users pay into the pool, they don’t determine determine how the pool, or their portion of the pool, is distributed. Plays determine distribution, but not a single users plays, all plays.
If all github users donations entered a single pool, and that pool was distributed to projects based on the number of clones each repo received, that would be similar to the spotify model.
But I don’t believe that’s being proposed.
Rather, a user sets up a donation amount, which is then distributed to the projects they include in their “sponsor pool”.
If you're willing to move away from your proposed GitHub route, you could try implementing it on something like Gitcoin. The "wallet" you mentioned in the article could be a smart-contract that by the end of each month (or any desired period) would automatically make the donations directly to the crypto wallets of the projects that you chose to include in your sponsor pool.
That way, you jump over some of the implementational and regulatory hurdles. There would be no intermediary, such as GitHub, paying for the transaction fees. The transaction fees necessary for using the smart-contract on a given blockchain would be paid directly by the person making the donations.
> There would be no intermediary, such as GitHub, paying for the transaction fees
It sounds like there would also be no intermediary handling taxes. Each person receiving donations would be liable for dealing with taxes themselves, which could involve having to deal with the tax systems in every country/state in which one of their donors resides.
Unless your plan is to just ignore taxes and hope any tax authority that might want to come after you won't be able to obtain jurisdiction, you really want anything that involves accepting money from all over the world to go through some intermediary that operates in such a way as that intermediary is the merchant of record for the transaction.
There also might be issues with sanctions. If your country has sanctions against country X and you accept donations from someone in country X that might violate your country's laws. An intermediary can handle keeping track of that, making sure you only get donations from places that your country allows.
This could be even worse than the tax issues--at least with the tax issues it is other countries that might be trying to sue and/or prosecute you. With sanctions violations it is your own country, which is usually a lot harder to successful blow off.
Blockchain-based solutions are a legal minefield. They attract AML and tax scrutiny and, if you've become a trustee, make it incredibly difficult to unwind the mess. "Your Honour, blockchain transactions are immutable and ledgers are composed of mixed units of account that can't be controlled and smart contracts are irreversible" will attract about as much sympathy as spitting on the gavel. When a court decides to impose equitable remedies, it won't care that you can't return gitcoin. It will seize, lien or garnish any old thing you own, because actual law is smart and smart contracts aren't.
Old-school financial arrangements aren't as cool, are much more complicated and much more expensive. But they are also vastly more robust against many, many edge conditions. High-level expertise is plentifully available to pretty much any degree of specialisation required.
> The "wallet" you mentioned in the article could be a smart-contract that by the end of each month (or any desired period) would automatically make the donations
Ethereum smart contracts don't work like that. It is push, not pull. The Ethereum world computer cannot schedule or initiate tasks without you creating and signing a transaction. Cryptocurrency just can't do subscriptions. The workaround is to send the cryptocurrency to a third-party custodial which then disburses subscription payments, but now you have regulatory hurdles, because there's a trusted entity that is holding your money.
This is amazing and I have a gut feeling that it will revolutionize OSS.
I usually want to give say $30/month to OSS (personal use) and as a professional, I would have the authority to donate $300/month.
This would be great to not worry about individual donations, and just based on one-click or even just divide up the funds equally amongst all of my starred projects.
I termed this model "microsubscriptions" when I was pursuing it in the context of website funding.
There are difficulties.
Gaming the system
Folks will absolutely distort their software, buy fake github stars, spam out bazillions of typosquatting packages etc. We know this because there is already a weak financial incentive to subvert: supply chain attacks for cryptominers. Direct cash will be a much stronger incentive for fuckery.
https://www.bloggerzune.com/2020/06/How-to-improve-your-blog...
FYI I'm not going to do it. I'm not going to put a recurring amount of money into open source software. It isn't that it's hard. I just don't want to do it.
Seems like solution to a problem that does not exist, there are many motivations for open source projects and not all of them have generating income purpose. Furthermore, generating income via dual licensing is fairly straight forward way, assuming you have solution that is in demand and works.
> Existing open source funding models don't work for small projects.
Is this true? It seems to me that open source small projects flourish and continue to grow [0]. Although, oddly, I can’t find a simple chart of python or npm packages added over time, I expect it is.
Since the article is based on a seemingly false premise, it’s hard to consider the rest of the article.
Everyone speaks their own idiolect, and it appears you have used your idiolect to interpret “Existing open source funding models don't work for small projects.” I suggest putting more effort into guessing what the author might mean before writing off the article with snark. After reading the article, I think it’s clear the author was referring to small projects being able to receive funds.
That page argues (convincingly!) that open source is growing faster and faster in terms of contributors, projects, commits, etc. This is definitely the case, despite the fact that the funding problem is unsolved. But who knows how much faster OSS would be growing if it was solved?
> But who knows how much faster OSS would be growing if it was solved?
Not just how much faster it would grow, but how much existing projects would improve. Maintainer burnout is real, and I think that OSS would benefit a lot from long-term maintenance being encouraged by even a few dollars a year.
Even $3/year would make OSS maintenance a lot more fulfilling for me personally, because that $3 shows that I'm actually helping people.
I think there are challenges with how to make money from open source projects, but that is very different than “ Existing open source funding models don't work for small projects.”
I think the fundamental funding model seems to work well based on the number and rate of growth in small projects- philanthropy. The vast majority of small projects don’t require funding because their authors donate their time and code produced.
This seems to work really well based on how many people do it.
Perhaps more would do it if there was funding, perhaps less. We do have a large commercial software industry and they have a pretty figured out model.
One of the projects I had in mind when writing this post is the "color" module on npm. It's a fantastic utility for reading in colors in different formats (hex, decimal, CMYK), applying transformations, and getting a modified color back (in your format of choice).
For all intents and purposes this module is "done". It's extremely mature and has already implemented everything it set out to do. It has 3.3k stars and 8M monthly downloads.
When I look at your list of proposals, none of them really apply to "color". The projects you have in your head are big, ambitious projects, not the smaller utility projects I describe in the article.
If the kind of open source you mention were actually valuable, there would be a market for it. You make a common mistake many people make when trying to calculate value: it has nothing to do with how much something is used, it has to do with the incentives for those creating it.
People do not casually write open source to make money (unless sponsored by a company). They do it for the recognition and for vanity, and I’d argue that popular open source software is not scarce as evidenced by how much there is of it. People will in fact rush to fill the void of open source such that the popular open source is more of a fluke than anything: if it wasn’t the react-router it would be something other nearly identical, where there are plenty of people waiting in line behind that.
I have a very nice pet project with a user base in the single digits and I'd like to keep it that way. I know all my users personally and I am even using it for several hours per week myself. I couldn't care less about recognition or vanity.
People create opensource software because they have an itch they need to scratch, not because they want to get attention. Attention is expensive and involves scratching other people's itches, not yours. It means nagging users who demand things from you and drain your sanity all while making money off of your work. It's only natural that you want something in return.
>If the kind of open source you mention were actually valuable, there would be a market for it.
This argument makes no sense. If the software isn't valuable (as in worth a lot) then nobody would use it. Opensource software cannot become popular without providing value. Open source software is not valuable in the sense that it cannot be valued. You can't put a price tag on a non exclusive good if you're not selling it in the first place. Another flaw in your argument is that you are assuming that because there is no market for something there will never be one. Github sponorships, liberapay, patreon and lots of other platforms are clearly in the process of creating a market for these things. People are clearly willing to fund opensource software if it is possible. Just take a look at neovim! [0]
> People do not casually write open source to make money (unless sponsored by a company). They do it for the recognition and for vanity.
1. I would like to make a little bit of money from my open source projects. I like money. But if no money comes ... that's okay too. It won't stop me coding for fun.
2. I write open source code because I enjoy the freedom to work on what interests me, and I can devote some time to it. I expect many developers would like to contribute to open source but can't; they have to put their time and effort into other areas of their life.
People are weird. They often do stuff without the need for an incentive to do it. Code up a pet project, write poetry or stories in their diaries, build an entire constructed world that nobody else will ever be interested in - all just for the fun of it.
1. It feels like you are at risk of some survivorship bias here. Yes, the software that currently exist were apparently made anyway, and is popular enough to be replaced if it went missing. But you have no way to quantify how many possibly useful or innovative OSS projects were never made because of the lack of financial opportunities.
2. I feel the whole idea of this kind of open source patronage / funding is to decouple the market value of the software (which is $0) from the compensation to the contributors for their time and effort (which I think should be above $0 in an ideal world)
Instead we got a stupid global pool based on global popularity that primarily benefits PewDiePie even if I don't watch him. The compensation was barely enough to cover the lost ad revenue so it failed to actually provide a viable funding alternative for channels that aren't getting millions of views.
I hope the same thing doesn't happen with this model. If 100 people sign up at $10/month to only support CatacylsmDDA and minetest then these two projects should get $500 each (minus transaction fees). That money should not be diverted to Angular, React, Vue, ... and then when its time for the two mentioned projects they only get a pittance like $5 per month.