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.
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.
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.
> 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.
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?
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.
> 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
(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.)
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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?
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.
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.
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...
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.)
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.
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.
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.
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).
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.
> 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.
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.
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).
> 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?
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.
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.
183 comments
[ 885 ms ] story [ 4141 ms ] threadEDIT: 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.
[0] https://flattr.com/
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:
https://wiki.snowdrift.coop/about/existing-mechanisms https://wiki.snowdrift.coop/about/economics
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
Cheers
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.
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.
[0] https://octoverse.github.com/
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.
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.
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.
I wish I had more than one upvote to give.
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.
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.
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.
* 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.
[0] https://gitcoin.co/
[1] https://vitalik.ca/general/2019/12/07/quadratic.html
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'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.
Why?
I drew a picture of a giraffe. I should deserve to get paid because art.
There's plenty of crucial work that does not lead to any github star:
- Linux distribution work, including packaging, reliability, security
- Security research: finding vulnerabilities and notifying the authors
- Configuration, tuning, benchmarking, finding bugs...
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.
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.
>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.[1]
[1] https://increment.com/open-source/the-rise-of-few-maintainer...
[2] https://www.researchgate.net/publication/308894462
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.
https://www.debian.org/CD/vendors/
https://snowdrift.coop/
Minor nitpick: I don't think a badge is really considered virtue signaling because you've already put your wallet where your mouth is.
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
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.
[edit] I added a footnote to address this.
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.
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.
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.
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 [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...
[1]: https://stripe.com/docs/payments/sepa-debit#disputed-payment...
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:
https://www.fordfoundation.org/work/learning/research-report...
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...
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.)
Patreon vs. Humble Bundle, as I said elsewhere.
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.
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.
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.
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-...
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.
https://github.com/sponsors#:~:text=GitHub%20does%20not%20ch....
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.
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.
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 gitlab implemented this feature Id probably move tomorrow.
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.
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.