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.
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.
I might have selection bias because I support an OSS dev there but isn’t that a pretty efficient way of directly supporting specific projects?
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.
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
As I understand it with global popularity.
If 9 people watch A and 1 person watches B and C equally and each pay $10 then:
Total money is $100. A gets $90, B and C get $5 each (as they get 1/20 total viewership).
This seems to be same as local pooling? Am I misunderstanding the terms?
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.
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.
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.
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.
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.
You can see other options out there too via https://www.oss.fund
In general, donations/sponsors I don't think will scale for many reasons: https://www.aniszczyk.org/2019/03/25/troubles-with-the-open-...
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.
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.
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.
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'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?
From a customer's perspective, fraudulent transactions are handled in the best way possible. Here's Stripes docs on it :
> 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...
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.
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:
It's a recommended read on this topic.
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,...)
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.
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.
Or as Mike Monteiro puts it: https://www.youtube.com/watch?v=oEa6PdOG2ts
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.)
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.
They even cover payment fees.
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.
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).
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 wouldn't get your hopes up.
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.
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.
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?
I'm not saying github can't do that, just disagreeing that github is the ONLY one capable of doing it.
> But then you go on to suggest Facebook, Apple or Google...
They are not worse than Microsoft in that regard. If Microsofts Github is acceptable, then so are them.
> Is Trump president where you are?
His ponyranch is not even on the same continent as me.
If gitlab implemented this feature Id probably move tomorrow.
Patreon vs. Humble Bundle, as I said elsewhere.
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.
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.
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.
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.
Edit: Another comment got it. It's Flattr
EDIT: This model is used by Flattr . 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.
The wiki there also has reviews of the issues:
and this is a thorough review of all the existing funding platforms: https://wiki.snowdrift.coop/market-research/other-crowdfundi...
There's a long history of failed efforts, some mentioned at https://wiki.snowdrift.coop/market-research/history/software
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.
>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.
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.
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.
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.
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.
I think the term you're looking for is "public goods", which combines non-rivalrous and the author chooses not to exclude people through legal means.
Running out of time to comment before I need to get to work so I'll just link our economics page here: https://wiki.snowdrift.coop/about/economics
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.
This allows you to cut-off the trickle-down funds in bad faith.
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.
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).
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.
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.
Though the ability to curate your personal pool is an important piece of the puzzle.
Minor nitpick: I don't think a badge is really considered virtue signaling because you've already put your wallet where your mouth is.
"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.
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.
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 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?
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 added a footnote to address this.
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.
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.
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.
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.
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.
I wish I had more than one upvote to give.
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.
But setting up an explicit trust arrangement needs to be done with great care as well, especially since trust laws vary from place to place.
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.
Forcing donors to fund their wallets with ACH transfers seems like an easy way to sidestep a lot of this (except the trustee issues).
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.
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 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.
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.
Before you jump the gun here, please read the GNU page about selling free software - https://www.gnu.org/philosophy/selling.html.
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.
Hope funding in OSS gets more momentum!
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.
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.
* 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.
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.
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.
Some related listening and reading:
Episode 205 – The State of Open Source Security with Alyssa Miller from Snyk
Episode 185 – Is it even possible to fix open source security?
Episode 182 – Does open source owe us anything?
Whether you're donating to one person, one project, or a pool of projects, the business model just doesn't work out.
How much do I get paid?
Zero? But I wrote open source code that solves a real problem. It's open source. I should deserve to get paid. Because open source software.
I don't think your funding model works.
And if nobody knows that software exists, then it's not helping anybody. My phrasing sounds cruel, but I can't think of a better way to express it
I drew a picture of a giraffe. I should deserve to get paid because art.
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”.
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.
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.
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.
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 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.
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.
Or, to put it another way, if you are doing open source, why are you so hung up on getting paid for it?
Is this true? It seems to me that open source small projects flourish and continue to grow . 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.
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 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.
Sell direction of the project.
Offer roadmap milestones. Sell priority over features maybe even bug features.
Sell hats/logos/branded hosting environments.
Sell access to internal conversation. Sell invites to internal product Zoom meetings. Sell access to private jira boards/trello cards.
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.
Is it just a thank you gift?
MIT isn’t going to fly anymore if the intention is to make money off of that.
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.
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! 
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.
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)