Hacker News new | past | comments | ask | show | jobs | submit login
GitHub Sponsors (github.com/sponsors)
2082 points by Heliosmaster on May 23, 2019 | hide | past | favorite | 501 comments

This is a nice start for allowing sending "coffee money" between persons. If however you want to drive Serious Money into actually funding OSS projects please remember this: While virtually no company has a donations budget, almost every company has a $$$ marketing budget.

Please let me give you some of that money that would otherwise be spent on blue pens with logos and endless display ads to GitHub projects. I'd be happy to drive $xxK/mo to open source projects my company depends on or that are simply being used by an audience that aligns with our own. To sell that internally, I need (as in, I would be laughed out of the room to propose it without):

- My sponsoring company logo on the GitHub project page

- UTM links and all that jazz to attribute traffic and campaigns to the specific projects that we sponsor

See https://webpack.js.org/ for a good example of a successful sponsorship program. Literally the biggest hurdle remaining for BigCorp to sponsor something like Webpack today is selling your boss on "Patreon" and "OpenCollective". But if you just increase our GitHub budget by a few K/month, AND the marketers get attributable traffic to boot that we can point to, well that's an easy sell!

If however you want to drive Serious Money into actually funding OSS projects please remember this: While virtually no company has a donations budget, almost every company has a $$$ marketing budget.

I've done a lot of volunteer work over the years and I've spent a lot of years developing web projects (not as a programmer).

The thing is that idealistic efforts and commercial efforts tend to have an inherent conflict of interest that a donation model helps get around.

I take tips and Patreon on my projects, plus I do a certain amount of paid work. The minute you start commercializing it, you need to do it for the money and someone else will be telling you what matters to them. It actively interferes with you doing what you think is best organically.

Once in a while, someone manages to find some sweet spot where their career and their ideals fit together nicely. But most folks need to do drudge work that they don't find morally objectionable to pay the bills, then find other avenues to express their ideals.

I think it's a great thing that it is now possible for some people to do a thing for idealistic reasons or the like and have a few bucks kicked their way for their trouble. But I think it kind of misses the point if you want to suggest ways to commercialize it. People can already do that by starting a regular, old fashioned business.

OSS is generally about doing a thing that serves humanity in some important metrics. And I wish serving humanity and making a profit were easier to marry together. But, in practical terms, I think that's just a hard thing to do.

Giving people a third option to do a thing they believe in and have a few bucks kicked their way seems like a way out of that trap so more people can try to do things "for the right reason" rather than for the almighty dollar.

I completely agree with you in some cases.

However as a data engineer I strongly doubt that many (any) of the dozens of open source projects I use on a weekly basis were created for idealistic reasons.

They were almost all tools (or collections of tools) that were created to fill a business need, or to make a developer's life easier, and then open sourced for one reason or another.

I don't see any conflict with corporate sponsorship of these projects.

I'm not at my best. Maybe someone other than me can find Patrick McKenzie's HN comment about "please make it easy for me to get an invoice instead of calling it a donation because I have to comply with tax laws and yadda, but would be happy to support your open source project if I actually use it for business purposes and can get the piece of paper called an invoice that my accountant and the government insist on."

I think that's a good direction that is probably underdeveloped currently, though every single time I mention it someone points to a tweet of his rather than the actual HN comment. (Which is not the end of the world and maybe there's a better way to frame that, I'm just not at my best )

Yes, that's the one (with accompanying pertinent discussion).


The parent of this thread is someone in marketing suggesting ways this could come out of the marketing budget, very similar to the workaround of invoicing suggested in your linked comment. Both are ways to make donating to OSS a business expense rather than a charitable donation.

No, not really. Adding logos and yadda in exchange for remuneration is a really well established form of commercial monetization. In contrast, invoicing OSS is a new and innovative way to get cash for what you already do, just like a donation.

If people want to go that route, my comments on the internet aren't some kind of bar to that approach, so I'm not sure why you seem to feel some need to argue it.

But if you are doing open source for idealistic reasons and yadda, as per my comment, then invoicing per Patrick McKenzie's explanation is actually something new and innovative that serves a similar function to the donation model in terms of preserving an element of the OSS model that matters to some folks/projects, but opens up the possibility of getting it from a company. In addition to being something of a green field for the donation model and extra source of money, companies generally have deeper pockets than individuals.

I'm not telling anyone they aren't allowed to commercialize their project. I'm just saying it's a space I've thought long and hard about for many years and researched and yadda, and if you are in open source because a business model is antithetical to your mental models and goals for the project, then invoicing may suit your needs in cases where corporate sponsorship feels like the wrong answer.

Invoicing support, maintenance and custom development of open-source software is a more established practice than patreon-style donations to open-source developers.

I'm aware that OSS sometimes makes money on activities like customer support and custom development. That's not what's being discussed here.

We’re discussing it right now... I’m referring to the concept of “invoicing open-source” which you describe as “new and innovative”. I’m arguing that it’s not. It’s a variation of the support and custom development model which is already very common.

You don't need an invoice to make something a business expenses and or tax deduction.

Even in the case of an audit, the bank or credit card statement showing who the money was paid to is enough.

Now, if you are giving cash, you would definitely need an invoice.

This is just flat wrong advice in every jurisdiction I’ve worked in and further wouldn’t fly at any employer. The bank statement may provide the WHO in the transaction, but the invoice / receipt / similar provides the most important part, the WHAT that was paid for.

No, you are wrong. Sure, employers will all have their own rules. But I am talking about IRS substantiation.

The IRS lists out the different forms of documentation needed to support your expenses.


You can see right there under Expenses that credit card statements as well as cancelled checks are valid documentation for a write-off.

From your link:

> Your supporting documents should show the amount paid and a description that shows the amount was for a business expense.

A credit card statement typically doesn’t fulfill the second half of that requirement. That doesn’t mean the card statement isn’t a valid supporting document, just that it wasn’t enough by itself.

I too read an IRS document once, that doesn’t make me an expert on accounting. However, when every single finance person has stated that the WHAT was as important and then your own link says that too, I generally would back down and admit maybe I misunderstood and/or made a mistake. YMMV.

That is not gonna fly where I am from. Our external accountant, CPA type guy, will absolutely hound our ass, and charge his hourly rate doing it, for the invoice corresponding to the VISA card charge.

Well of course the business can have their own policies. I am just saying what the law is and what the IRS is allowed to require you to keep. You don't have to keep receipts. There are lots of other acceptable forms of documentation.


This is actually great in so many aspects for companies. GitHub could even change the way companies handle open-source development (in the same way Uber changed taxi market).

Instead of hiring (and keeping) full-time developer (and paying insurance, taxes, etc.) company can abuse this system and 'convince' employee that they can continue working for their project as a contract-free open-source developer and get same 'salary' (or more when this project become successful).

In such case they will be able to fire him (or replace with 'cheaper' one) and no one will be able to complain. I'm sure it can happen in some countries with weak labour rights.

So they can chase two rabbits ($$$ for marketing and $ for developemnt).

Yep 100% agree, this is how both Vue.js and Laravel have succeeded with "donations" on Patreon which are actually companies paying for advertising space on the project's respective websites. Both are doing 6 figures annually in recurring "donations", which is almost entirely from $xxxx/mo tiers targeted at businesses.

I think the other thing that is better about doing things this way is that when a company is buying ad-space from you, it's very clear what they are paying for. With the current peer-to-peer setup that was shipped this week, I guarantee the "please fix my issue I donate $10/month!" problem is much more likely than it is with a company who is paying to have their logo on your website.

This is a good idea, but also the behavior will probably be emergent with the introduction of this feature - I can definitely see OSS maintainers offering logos/links in the README in exchange for monthly sponsorship. I bet we'll see the emergence of "Gold/Silver/Bronze" tiers too, just like at conferences.

I think there would be significant benefits to all parties if GitHub just put the proper automated scaffolding for large scale sponsoring in place instead of relying on such ad-hoc conventions:

1) Individual developers and the companies that want to sponsor projects will otherwise just continue to talk past each other. The developers ask "Why aren't companies donating?" while the very use of the word donation is already a complete showstopper for a company that otherwise doesn't flinch at dropping $50K on a one-day booth at a developer conference that draws maybe 15K visitors at best (a website like Material UI or Webpack probably does 10x that in a month, a perfect fit!). If GitHub doesn't set the system in place, large players like Webpack will continue to "get it" (they offer invoices for sponsors!) while Bob with his 5K stars project will be left out.

2) If the attribution is on a case-per-case basis, companies will continue to select just a few big showcase projects. If the handling is uniform it would be much easier for companies to do things like spreading their spend out all over some segments like "top-100 Go projects" or "libraries built on top of D3" or whatever audience they'd like to target.

3) If there is actually significant uptake in a project, meaning more than a handful of sponsors, it quickly becomes a serious timesink for developers just to track who is active which month at which tier, which sponsors churned etc. and then to actually attribute everything correctly. How about, sponsor picks the project, developer does nothing except gets paid, and all campaign links, logos etc. automatically taken care of. Hmm, I guess what I'm describing is sort of like an AdWords for GitHub now that I think of it :)

Take a look at the Webpack page that GP mentioned. This is already happening

This has been happening since at least the late 90's when I started to get involved in open source.

Heck, I've sponsored a number of projects back then as a teenager with a fledgling Internet business - with the express purpose of advertising to highly technical users I wanted to potentially sell to.

I'm not sure if it was terribly effective at sales marketing, but it was highly effective at marketing towards the types of employees I wanted to work with. I see sponsoring open source projects as more of a recruitment thing than sales thing these days.

Debian is looking for corporate sponsors for our annual conference:


This line of discussion ("Make it so we can pay you $xxK/mo, don't ask for donations.") comes up a lot on HN.

Here's what I did:

First, I spent four years developing security libraries for PHP developers that can be considered core infrastructure. Random_compat was an API-compatible polyfill of PHP 7's random_bytes() and random_int() functions for PHP 5 projects (and has over 100 million downloads). sodium_compat reimplemented most of libsodium in pure-PHP, and currently powers WordPress's signature verification functions. That's just two examples, I have over a dozen of distinct and useful libraries-- many of which have been adopted into popular frameworks-- that make your software materially more secure. If you're a serious player in the industry and your code base is PHP, you're running my code.

Okay, value delivered through open source? Check.

All of the above was also published through an LLC rather than just under an individual's name.

Then, I began offering the usual HN recommendations (support contracts, especially for EOL versions of PHP for Enterprise Linux customers).

I even created a streamlined workflow section on the company website and linked all of our open source projects to it: https://paragonie.com/enterprise

To date, the SQL tables that power that section of our website only has test records I created to make sure it was turned on correctly.

So I believe this to mean one of two things:

1. There's a missing step that I'm not doing that, once executed, will rake in the dollars.

2. The prescribed advice on message boards about how to run an open source business doesn't work.

(Until I figure out which it is, I'll have to continue doing code audits and penetration tests. Not exactly hurting for money, but it's not coming from the channels that people expect for open source. Enjoy the anecdata.)




Or this: It should come out your R&D budget because it is critical tech, and some marketing funds should be diverted to R&D.

Marketing and Sales budgets are bigger than R&D at most tech companies. So, you can work with the people who's job is literally to spend that allocated pot of money every single month. Or you can try to change how businesses operate.

If your ultimate goal is to work on OSS and to get companies to chip in, I'm quite convinced the former will yield better results and be less frustrating for everyone involved.

Is this an offer? Because we would do it :)

But your company probably doesn’t depend on our software.

This seems like it's needed and (dareisay) overdue?

Integrating sponsorship subscriptions into the core experience is sure to increase payments, a la twitch subscriptions/payments (which Youtube is just now copying).

I imagine this will change the fundamental dynamics around OSS projects, but not sure how, nor whether it is all positive.

- If maintainers can see who donated, do they prioritize issues / pull requests? (I think that could be a good thing actually).

- Do companies use GitHub sponsorships to judge the health of dependencies? Will they create budgets to support their dependencies systematically?

- Does this hurt FOSS contributions, because now people start to expect to be paid rather than doing it for inherent motivations? Will this generate toxic politics among project contributors regarding who gets credit + gets paid?

- Will this mean that microsoft gets a bunch of PII on top-notch developers (have to enter name + address info to receive or send payments), and get much more value from that data than I can imagine?

> This seems like it's needed and (dareisay) overdue?

Seems what they are planning to offer is not better nor different than what others already are providing (see OpenCollective or LiberaPay).

In fact, it seems less than the existing options. The existing options are open platforms with open source code. What GitHub is introducing, seems to be a loss-leader (they give free cash away) for the sole purpose of getting attention. It's obvious the feature they are now introducing is not for making the ecosystem better, but to lock the ecosystem harder to GitHub.

> Seems what they are planning to offer is not better nor different than what others already are providing (see OpenCollective or LiberaPay).

It's got a major company with deep and signficant expertise in security, payments, and accouting. A name that people and companies already trust with a raft of compliance all handled already. It might just be me, but if I were to speculate I would guess that OpenCollective and LiberaPay can't quite claim the same. I know that if I want to, I can get a SOC 2 report from GitHub.

These are nor minor administrative details to be brushed aside idly. They matter, particularly to a company keen to ensure that they never have to apologize for a partner fucking up credit card handling or to someone with a corporate card who has to be careful how they use it. These things are major features.

You make a good point. I sponsor a couple of projects on opencollective, but it took an hour or so of reading before I trusted it enough to use. I think if it had been built into GitHub, I would have been much quicker to sponsor.

I agree with diggan’s point too, but the reality is this is likely to get more people paying more open source maintainers. I just wish it could be on an open platform.

> I just wish it could be on an open platform.

It could be. Letting GitHub get away with this without criticism feels like a failure of imagination. They could have done integration of an open platform (heck, even one they created) if they gave a fuck :(

The way I see it, it isn't an alternative to Open Collective that they're after. They've seen that it's fashionable for people to give money based on parasocial interaction. It's sort of like gambling, where there's a dopamine hit, but where the behavior doesn't get you meaningfully more involved with the community, whether it be Twitch, YouTube, or Facebook (just like gambling doesn't make you wealthier). I fell into that trap with Twitch for a while but cancelled all my subscriptions after realizing that my rationalizations for subscribing didn't hold up, and the real reason was the excitement of feeling like I was hanging out with a chess champion. I think there will probably be backlash after some stories of people spending more they can afford on Twitch subscriptions get out. https://en.wikipedia.org/wiki/Parasocial_interaction

It is nice to see people make money doing what they love, but I wonder how much they can really make if people aren't influenced by parasocial interaction.

The motivation for Open Collective of giving back to say thanks is a much more pure one than paying $5/mo on Twitch, of which Amazon gets a huge cut, to get a sense of belonging bolstered by custom emoji and subscriber-only programming.

> It's got a major company with deep and signficant expertise in security, payments, and accouting. A name that people and companies already trust with a raft of compliance all handled already.

Yes, and they are absolutely _robbing_ the opportunity from others to build in this space, when there are already some really capable players who would have gotten somewhere great. This is a total asshole, closed source company approach. The "loss leader" thing feels totally malicious, and designed to starve the open competition. This is classic Microsoft and rolls back all the positive feelings that had been growing about their growing in the right direction. Amazon does the same shit, to starve competition: "Yeah, you've a spot on our system, but we're going to steal every feature and embed our deeper and drive you out."

For a real example of how OPEN companies work together: Balanced Payments was a daring effort to run an open source payment processor. When they wanted a way to fund and support Gratipay, they went in and submitted a pull request to incorporate their own open source payment processor into the Gratipay platform. If GitHub were in the true spirit of open source, it would have engaged OpenCollective in such a capacity.

I am really disappointed about the hooray optimism and lack of criticism in this thread. I feel like we're all failing to engage in critical engagement with this idea and premise.

What kind of critical engagement do you think we are failing to offer? What kind of response would leave you thinking "This person engaged critically with the issue at hand, but still came away with a strongly positive position"?

For my own part, I don't think anybody is owed a position in a space. I also don't think the existence of small players that get displaced by a big player means that the small players were destined to become big players. It's worth considering that LiberaPay and OpenCollective would never have gotten somewhere great. Perhaps they would always have been doomed to be small and essentially irrelevant. We'll never know, obviously, but it's worth considering.

But let's talk about OpenCollective and how Github could have worked with them. Do you think OpenCollective would have passed a security audit? Are they SOC compliant? Could they have handle the scale?

An even more interesting question: has Github ever claimed to be an OPEN company? I'm certainly not aware of such, though of course my knowledge is less than comprehensive. Charging them with failing to be something that they've never claimed to be seems odd.

Yes. Your charge is correct in an important detail. Github isn't an open source company. As far as I can tell they never have been. It's perhaps somewhat less than maximally reasonable to expect them to become one.

For my own part, this enhances my positive feelings about Microsoft running Github. They're making changes to popularize the idea that it's OK to pay developers to do open source, and doing so in a way that lets developers get paid in a manner of their choice.

It could still be an open platform, of course. Someone just needs to be able to do it better than Github. As Dependabot shows, that's absolutely possible.

> I also don't think the existence of small players that get displaced by a big player means that the small players were destined to become big players. It's worth considering that LiberaPay and OpenCollective would never have gotten somewhere great. Perhaps they would always have been doomed to be small and essentially irrelevant.

I think the difference between small and big players depends also on what their goals are. If the goals of (first Gratipay and then) Liberapay are to fund cool people and cool work, it doesn't matter how much of the funding space they take up as long as they're paying the bills and surviving. If the goal of GitHub is to make $$$ on fees, then yeah, they're going to feel like every other platform is a threat to that goal.

IMHO, there is much more space for different multiple funding platforms than people realize.

> It could still be an open platform, of course. Someone just needs to be able to do it better than Github. As Dependabot shows, that's absolutely possible.

Awkward, this literally happened today: https://dependabot.com/blog/hello-github/

(I agree with the thrust of your comment; I just think the timing here is funny.)

That's actually exactly my point. Dependabot did Github security alerts so much better than Github did, that Github gave up on trying to compete entirely.

Which is to say that it's incontrovertibly possible to beat Github at their own game and on their own platform. To the point where even Github agrees they've been beat.

Your comment reads that you're angry at Github for not taking a more open source approach. That's a fine opinion to have, but it doesn't make sense to demonize them for being a for-profit company. They are not robbing anyone of anything.

Starving the competition with loss-leader tactics is not an unbeatable strategy. If, however, you don't have anything to offer other than a run of the mill payment processing platform, then yea, you're going to have a tough time beating someone who can cut costs. They have a feature you don't, you should lose.

> That's a fine opinion to have, but it doesn't make sense to demonize them for being a for-profit company.

Because some people are just born as for-profit companies?

Labels are useful to classify behaviour, but that doesn't automatically excuse that behaviour.

I guess our perspectives are different. You seem to see this from GitHubs point of view, I'm seeing it from the view of open source developers. Both perspectives are equally valuable.

I agree that our perspectives are different.

I see this from the perspective of someone who wants to see developers get paid. Safely and securely, in a way that makes it easy for them to get paid the next time too.

I'm also looking at this from the angle of "What non-nefarious reasons would GitHub have for making these decisions?". One of the first that sprang to mind is credit card security, which touches on quite a few issues at once.

Further, my experience is that most of the time decisions that can be interpreted as being done for nefarious reasons were rarely actually made that way. I am willing to extend the HN-guideline principle of charity to GitHub, especially because I can see clear, real, valid reasons for standing up their own service over a partnership with a third-party service. I understand that some people will find these unconvincing or decide they are just a ploy.

I haven't even touched on AML or KYC issues!

You are definitely right about the importance of infrastructure made entirely of open source software. My perspective is, in essence, that there are other features that matter that may not fully live in code.

   What non-nefarious reasons would GitHub have for making these decisions?
GitHub is owned by Microsoft now- they can afford to do this at a loss / zero sum amount because Microsoft thinks it's a good idea.

As long as Microsoft is being altruistic here, we should be fine.

I think.

I think the key perspective here is that of “the average GitHub user who mostly ends up there in the process of attempting to fetch a library” (a.k.a. to use GitHub as the ecosystem-library package manager of last resort, for libraries nobody bothered to put into an actual package; or for special feature-branches or tracking bleeding-edge development.)

If such users will be more attracted to donating to developers via GitHub itself, than via other systems linked to through the GitHub README they land on, then donations will spike.

And if, at some point, this program becomes opt-out instead of opt-in, then these users might decide to donate to all sorts of people who never considered themselves “open-source developers” but who just happen to slap code up on the internet for free, mostly as a way of proving the provenance of the binary releases they make. For example, developers in the game-console homebrew community, or the Hackintosh driver community, might suddenly see financial support.

And yet the open alternatives don’t seem to have amounted to anyone making a living from open source. Centralizing it offers a nicer UX - it’s not just about feature parity.

I am, using Patreon.

Doing this took ten years of operating as a commercial entity earning respect, and then ramping up my productivity hugely to compensate for earning about a quarter what I'd be making as a commercial entity. On the other hand, it's predictable and steady, whereas operating as the commercial entity proved wildly unpredictable and stressful in a whole different, darker way.

UX is fine but the platform will never give people a survivable income by itself. You need to build a business like any other, and then be able to take a MASSIVE hit to your income for the sake of your principles.

I'm happy with my choices but other people really can't do likewise. Certainly not from scratch: you wouldn't gain enough traction. I work in the music business. There's a saying, how do you earn a million dollars running a recording studio? Start with ten million. It's a lot like that, and no payment platform is really going to help.

So, for me that indicates that the problem is not that there is any service for making payments, but rather that open source developers who lives on donations, needs to be paid more by more people.

It would be cool if GitHub integrated with existing platforms and helped that to happen. Instead, they signal nothing about this problem and shipped yet-another platform.

They could have easily have contributed to solving the problem for real, but instead go their own way.

From GH’s perspective, why would they create a dependency on an open service (that could disappear at any moment) when they could roll their own? Especially with all the trust issues that come around payments.

Are there any guarantees that Liberapay could even handle an integration at GH scale without it falling over? They opened 900 accounts last month.

GitHub’s promise is something akin to ‘it just works’ - which means that they take care of this stuff rather than give you yet another tool to integrate with.

GH can’t win in this scenario with some people. GH invest in Liberapay, give it a coat of paint, these same people will then complain that Liberapay has ‘sold out’ / gone ‘too enterprise’ (see Chef, Docker) (or the Microsoft variant - Oh noes, MSFT is working with open source tech it must be EEE) and demand that GH integrate with the next half-baked service with a Bootstrap website.

> why would they create a dependency on an open service (that could disappear at any moment) when they could roll their own?

Because by creating the dependency on an open service and collaborating with them, they help them survive long term and to not disappear at any moment.

Yes, it's nice that "it just works" but sometimes the easiest way of doing something doesn't mean it's the right way. Especially when it comes to hard things like "How do we ensure open source developers can get paid?"

Having worked with human beings before, I would say that it is considerably easier and more predictable if you just do some things yourself.

Working with folks outside of your employ (even if you pay them good money to do the work) will fail you far more often than working with one or more of your own employees.

I can't blame GitHub for doing this completely in-house.

Sure, the easy way is easier. But more often than not, the easiest way is not the best way for the entire ecosystem.

Rather than saying "How can we get money moving around on our platform as soon as possible?" they should have asked "How can we make open source work sustainable?".

But who can blame them really, it's a for-profit and closed source company on every level.

> It would be cool if GitHub integrated with existing platforms and helped that to happen

They did that as well today today with support for a .github/FUNDING.yml. This file lets people provide links to Open Collective, Patreon, Community Bridge, Tidelift, Ko-Fi, a custom link and they show up as alternative sponsoring options for a repo: https://github.blog/2019-05-23-announcing-github-sponsors-a-....

Money movements are not just calls to some external API - there's a lot of legal regulations around money movements.

Yeah, but they are Github, so they will clearly win out over those companies I’ve never heard of.

Everyone with a big report for your OSS project is already on your Github page. Its perfect.

The Patreon product is 10% payment processing and 90% the marketing/branding/placement/ease-of-use/trust/normalisation, or whatever it is that makes people open their wallets.

If GitHub Sponsors is stronger at whatever-it-is-that-makes-people-donate, that would be their advantage.

That's the scary part!

OpenCollective for example, being developed via their own platform, need to make sure the platform is sustainable, and can't just throw cash wherever they want to gain marketshare.

The result is a sustainable funding platform that will survive for as long as people fund it.

GitHub on the other hand, can develop the wrong features, spend too much, give cash away and a whole bunch of other things, while not actually achieving sustainability in itself in the long-term. Microsoft will cover all of this, until they wont.

But GH in this space will mean OSS developers will start to get paid for real, the phenomenon will grow and become standard and expected, and if GH stops doing it, the need for it will be so clear and people's expectation of having such a product so strong, that any drop in replacement service will instantly convert most users to their platform.

GH right now is growing the market by bringing millions of eyes onto this problem. The same as Patreon did. And if Patreon dies today, do you think no one will bring up an alternative? And that supporters won't transition with creators to that platform?

It's the same idea as Paypal creating and growing the e-payment system. Down the line, the market of e-payment has grown enough and is legitimized enough that if Paypal was to stop service, there'd be plenty of alternatives, and people are already using plenty of alternatives.

OpenCollective and the likes haven't been growing this market the way GH will be doing, and the result is only a net positive for OSS and developers.

I have never heard of OpenCollective, but I have been using Github for 10 years. And “collective” in the name scares me because it makes me feel like it’s a bunch of street artists squatting in a warehouse in Oakland — perhaps fun and nice people, but not the type of people I’d want to trust with distributing money and compliance.

More options is better in this case.


Please don't break the site guidelines by making insinuations about astroturfing or shillage. It's a toxic trope that people bring up as cheap ammunition in arguments, and unless you have something approaching real evidence, it's off topic.


Don’t think that will happen anytime soon (India).

> Does this hurt FOSS contributions, because now people start to expect to be paid rather than doing it for inherent motivations? Will this generate toxic politics among project contributors regarding who gets credit + gets paid?

I'd also be concerned about features being implemented because there's money behind it, forgoing more important technical reasons.

Of course there are many projects that already implement this 'quid pro quo' development strategy, and open source projects with big corporate backers. How do these projects currently handle monetary influence in their decision making?

> Do companies use GitHub sponsorships to judge the health of dependencies? Will they create budgets to support their dependencies systematically?

In my past I've worked with multiple places that absolutely loved open-source. Because to them it was "free". Something they could use in their products and then charge customers for. Often these opportunistic parasites would never contribute anything back; going out of their way to work around missing features or bugs rather than trying to fix or contribute towards the codebase.

I doubt that these companies now, despite depending on such OS, would pay paying money/contribute; no matter how administratively trivial it became.

I've also worked at multiple companies where they were afraid of open source because the project might be abandoned.

They would happily pay thousands for a closed source dependency because they could guarantee it would be supported.

This could offer a nice medium where a company can be pretty sure that it will stick around (based on funding) and contribute to make sure that it does.

I like open source software projects and use them extensively on behalf of my employer. I care that they are healthy.

That said, there is a huge difference between getting authorization to spend company money on a subscription or support contract (easy), vs. getting authorization to donate company money to a person, informal group or nonprofit (extremely difficult).

A license or support contract is easy for the lawyers to understand, easy for procurement to understand, easy for finance to understand. That's how work gets done at a corporation, and they do those types of deals all day. Depending on the amount, I can sometimes turn around approval in hours.

A donation is not "how work gets done". It has no strings attached, which looks scary to lawyers and finance and PR folks. In my company at least, donations have a separate approval path that loops in the PR and corporate citizenship folks... and they want to see that money go to something fuzzy and feel good, like a charity. "Donations" is a line in the budget; it's not a big one and it's not mine.

So, I still think that the way forward for open source projects who want financial support from companies is to organize somehow (incorporate, nonprofit, etc) and sell support subscriptions. This aligns very well with how the corporation manages other dependencies, like office space, phone service, etc.

> Often these opportunistic parasites would never contribute anything back

So a user of open source to make money is a parasite? Are people that use LibreOffice to type legal documents they charge money for considered parasites if they don’t contribute to source code or financially to LibreOffice? If that’s the case, there is an incentive to use closed source software and just pay for it so as to avoid having to be called parasites and incur the pontifications. How many people here use Postgres but never contribute to it? I might guess it’s 99.99%. If I am running a business and there is an expectation that I pay for open source either in time or money, then that makes it no different from a cost perspective than paying for closed source — which lowers the incentive to use open source in the first place. “It’s free software, but if you use it for free, you’ll be called a parasite.” Sure. That’s a great way to promote open source. If open source people want to get paid for open source, then charge money for it, don’t simply use a passive-aggressive guilt trip, just be upfront.

Yeah I disagree that the users have to contribute something back. Half the value of a project comes from the users. The other half comes from the developers. If no one uses your software then it's worthless and it wouldn't matter if you spent all day playing video games instead. If someone else does end up using your software and builds a business around it and you don't like it then you should either start a business yourself or alternatively think of your work as returning the favor to all the other open source developers who have worked for free and will benefit from your project directly or indirectly by making proprietary software cheaper.

> Does this hurt FOSS contributions, because now people start to expect to be paid rather than doing it for inherent motivations?

I think having donatiom payments integrated with the platform will shift the motivation of programmers from intrinsic to extrinsic one. The design seems to show a call to action to 'sponsor' right in the github profile. That's a big emphasis.

Will such shift 'hurt' the FOSS contribution? I'm not sure because the answer depends what we mean by 'hurt'. But I fear that it's not going to be quite the same.

Interesting. I agree that it's not going to be the same, but I welcome that. Currently open source is just a tool for big tech to advance their agenda.

I think this is a brilliant move from MS. They gain goodwill and at the same time help shift expectations of OSS developers towards being paid for work. Given that both of Azure rivals are using FOSS extensively, while MS is not (much?), this could help weaken the rivals.

The reason I welcome this is that too often OSS is simply not good enough and would be (imho) much better if developers were paid for their work.

It wouldn't surprise me if maintainers suddenly start ignoring issues from non-sponsors because they can't handle all of them.

> If maintainers can see who donated, do they prioritize issues / pull requests? (I think that could be a good thing actually).

This is one step away from consumers being able to put bug bounties on issues too

> If maintainers can see who donated, do they prioritize issues / pull requests? (I think that could be a good thing actually).

This actually seems like it would be terrible. Contributions should be evaluated on merit, not on bribes.

The overall concept seemed good at first but you raised some real concerns.

Sometimes fine PR'S just sit without review or merging because the maintainer is busy with their life. If some money rewards them to look, great.

How so? If anything, it would be cool to have issue bounties to put your money to get the stuff you want solved.

For the same reason lobbying is harmful. The many should be served, not just those who can pay.

Really neat! As someone who works on open-source full time and is largely sponsored by my users, here's my take:

The good:

- gets money into open source with an intuitive and accessible interface that will get it to the forefront of people's minds

- they're the only platform that isn't taking a slice off the top (yet)

- (temporary) donation matching and eating payment processing fees

The bad:

- a few projects on github are disproportionately large and influential and will probably receive a majority of the funds from this

- this risks creating a stronger form of platform lock-in than ever: who's going to switch to sourcehut when their github repo makes them real world money?

I find this interesting because it runs into a place where my interests are seriously split. I depend on funding for my open source projects and this seems like a really necessary and powerful move that fills a gaping hole in the ecosystem, and might do it really well. At the same time, I'm working on a competing platform to GitHub and I'm worried about getting people locked into a proprietary platform. I have always recommended that people who accept donations for their open-source work avoid putting all of their eggs into one basket, like Patreon, in case that platform changes in a way they dislike. I encourage that for anyone interested in this GitHub offering as well, and I signed up for the waitlist to see how it goes. I still keep a number of projects there and will for the foreseeable future, so it might be a nice revenue source.

I have put a lot of thought into open source funding in general, I'd love to sit down with the team and chat if they have the time. Shoot me an email: sir@cmpwn.com.

It'll also be interesting to see how GitHub competitors respond.

GitLab may be in a position to do so, unsure about others.

> a few projects on github are disproportionately large and influential

Since this is github though, this is probably more of a marketplace than a donation-market. There is definitely some supply-demand dynamics rather than just patronship

Is there any reason why you couldn't mirror your repo on github for the donations platform?

I run community sites for which I am paid donations to cover running costs including writing code, bug fixes, servers, etc.

Today I take donations via PayPal, but the catch with this is that it's hard to provide visibility to donors of how healthy this is (WRT to costs), and whilst I considered Patreon that seemed to be very focused on creative deliverables to donors of a non-code/service nature.

I am trying Browser Attention Tokens, but these feel to be detached from the delivery of code, and still don't provide enough visibility to the donors of the overall health of the projects.

This though... this could be good. If Github sponsorship were attached to projects and people donated to a given org or repo, and then that were visible "this repo receives $500 per month" it would encourage code contribution whilst providing visibility over the health of a project.

I know my donors would appreciate the visibility (as would I, I manually create periodic reports on income and costs - at least this solves the income side).

The only question I have is how easy it would be for those who don't use Github to subscribe to a recurring donation?

Edit: Signed up for the waitlist, received a link to https://help.github.com/en/articles/about-github-sponsors which appears to clarify that you'd be sponsoring a developer not a repo/org... which means popularity/celebrity is everything. Oh well.

Hey, Devon here. :)

> The only question I have is how easy it would be for those who don’t use Github to subscribe to a recurring donation?

Thanks for the question buro9! All it takes to become a sponsor is an email address and payment method. Our goal is to make sponsorships as friction-free as possible.

Re: individual/repo/org question, GitHub Sponsors is launching small and simple, and as we learn from the initial beta program, we’ll look to expand the ways to participate. One thing we’ve done is put together an advisory panel of open source teams to better understand their unique needs. We’d love to have your voice on the panel, if you’re interested! Send me an email -- devonzuegel@github.com.

Well feel free to enable my GH account... @buro9 there too (verified by https://keybase.io/buro9 )

> visible "this repo receives $500 per month" it would encourage code contribution whilst providing visibility over the health of a project.

I fear this might snowball. Many people don't donate if they see a project with very small donations. It goes like this: "well, my contribution would not make any difference anyway"...

The reverse is also true: "this guy is OBVIOUSLY doing something right if he gets $500 a month for OSS work, I'll donate!". Yet another example of whales vs. small fish.

As you said in your edit, it will likely encourage celebrity cheering and everybody else won't get a cent as before.

Funny, I act completely opposite to this with respect to Patreon. If I see content that I enjoy is only getting minor donations I'm very likely to donate, even if Patreon sponsorship doesn't get me anything more. On the other hand, if a project has high donations I am unlikely to donate unless sponsorship gets me access to something additional, and even then I am more critical with the decision.

I think GitHub is more like the first scenario. You're already getting the content (code) regardless if you pay for support or not.

I'm curious if, in the long term, GitHub will extend this functionality to integrate benefits: faster support, pay for features, even access to repos for various tiers.

I'm exactly like you but my anecdotal evidence shows that we are the minority.

And yep, I'd like to see those same additional features. One-off small payments instead of a recurring donation is a must as well; many can't afford to donate on a regular basis.

Well what I'd like to do is establish a stack of budgets against a project, e.g. Kickstarter Goals.

$500 p/m = all hosting and domain costs paid for

$750 p/m = we'll use some paid service that makes the service better in some way

$1k p/m = we'll reward contributors $250 p/m distributed across those who contributed to PRs but exact distribution determined by repo admins

And then to have a budget associated to the lowest one being the means for the project to survive... with a running total on that one, showing deficits (because I do have to still cover raw costs and those end up on my credit card the months I fall short, so future months should help recoup that).

In this way, it would be extremely clear what funds a project needs to survive and how donations and support makes a difference.

NB: My projects do fine... we get enough support to be viable. But damn it would be great to not manage it all manually, it's a chore I'd like to give up so I can code more.

I like your tiers idea - optionally you could even make that happen by tying it to the Marketplace. IOW - "Help pay for our <SAAS> subscription!"

I'm sure it's possible to put that info in README.md and handle things according to that month's donation amount.

I don't know that a GitHub-run tier system will suit everyone, when a developer (the primary users of GH, of course) could easily just automate the update of the relevant info in the README or some other relevant document in the repo on a cadence that suits the project and the developer.

Huh? Am I the only one that has exactly the opposite line of thinking? If I see an underfunded project that I enjoy, I’m much more likely to donate than if something already makes many digits money.

Don't get me wrong, I agree.

I was just commenting what I have been witnessing over the years is all.

This logic is strange.

If this repo receives $20 a month, if I donate $5 I'll increase their budget by 1/4, a huge impact.

If this repo receives $500 a month, my $5 will increase their budget by 1%, barely visible.

In practice, it is not strange at all.

The person you replied to tried to highlight why that particular framing a bad metric to highlight in an OSS project.

People respond better to something like:

this repo needs $500/mo to achieve X;

$1000/mo to achieve Y and;

$2000/mo to achieve Z. We have received $200 in funding for this month."

rather than the example given above:

"this repo receives $500 per month"

The first framing emphasizes your needs, the second framing emphasizes your current situation. The first is better because it gives any potential donor actionable information to decide whether you need a donation or not, and more importantly, how much impact their donation will make if they choose to donate.

A donor can make an out-sized impact on a project with a stretch goal of "$2000/mo to achieve Z" that has only received $200 in donor funds by providing the $1800 balance for instance.

Many people who get paid this way prefer the 1% case to the 25% case. It's much more stable. This means if you decide to stop, they only lose 1%, not 25%.

I mean, people are still going to enjoy getting more money, don't get me wrong. But they'd rather have 1000 people giving a dollar than two people giving 500.

Exactly your last. We could all take a page out of the Twitch streamers' books -- they do exactly like this: (a) set donation or subscription goals and (b) make it really cheap and (c) aim for volume.

I don't disagree. I'm sharing what I have been observing in the past.

It would be really neat if the eventually introduce some type of dependency sharing.

Ie, huge project X built on top of Y and Z show that 30% of donations go to Y and Z.

If Github can start automatically recognizing dependencies it could also incentivize people to "properly" (whatever that means) share donations.

>If Github can start automatically recognizing dependencies

I think that they already do this for JavaScript, Ruby, and Python dependencies[0]. However I don't think doing it automatically is the way to go, one dependency may be "worth" way more than another, and some dependencies may go undetected (e.g. if I conditionally sneak -lfoo into my LDLIBS somewhere)

[0]: https://github.blog/2017-11-16-introducing-security-alerts-o...

Yea, definitely agree about automatically. For me the biggest problem with automatic is, exactly as you said, the worth of varying projects.

I think automatic inclusion would also run the risk of OSS becoming less integrated. Ie, if I include another dependency I risk losing money, incentivizing me to reinvent wheels so long as I have the ability.

Have you looked at other alternatives like OpenCollective or LiberaPay?

Basically identical to what GitHub is now introducing, but with the nice feature of being open platforms and not seen as loss-leaders for their owner.

LiberaPay seems popular with developers. But Patreon is not unheard of either. The guy that codes Inkscape is on Patreon for instance.

To summarize,

- OSS contributors on GitHub can apply to become "sponsored developer" to accept donations

- Developer sets monthly sponsorship tiers (amounts & benefits)

- GitHub will match upto $5k in donation in Developer's first year (1:1 match)

- GitHub will not charge any fees in the first year

- In the future, they may charge a nominal processing fee

- Currently only individuals can donate to individuals, org/team support (on both sides) to come soon

I don’t like this. There has always been a purity around writing open source software simply for the benefit of mankind.

Let’s not kid ourselves, probably no one is going to make a living from github sponsors, and projects that bring in any significant money are probably written by developers who already make good money do something else anyway. This would basically be beer money to them.

You would be amazed at how people that do not contribute any sort of money to an open source software project will come in and make demands to the creator to implement some feature or fix some bug. Now imagine if they donate $10 and suddenly feel like there is a debt the creator must pay to them by doing what they want.

I will not be using github sponsors for my open source projects. Instead I will continue to ask for things like tickets to conferences or speaking engagements where I can better develop my brand and clout. That’s the way it should be, but that’s just my opinion.

Agree with everything you're saying, I really am surprised at how overwhelmingly positive the response has been for the most part on hacker news. I really don't see 99% of OSS project contributors making money from this, let alone enough money to make a living, but it's hard for me to interpret the response as much less than delusion.

People are probably going to get jealous/upset if they find out other contributors are getting more donations than them, especially if they feel their project/contributions are inferior to their own. A lot of people are suggesting they change things to make it so you donate to projects instead of individuals, but I feel this would be even worse. The politics of open source projects can already be big head aches, but throw money into the mix and it will get even worse, as someone will have to decide how to divide things up, and then we might get into a situation where people refuse to even contribute to a project unless they're guaranteed some sort of payment for their contribution.

It's obviously still a little early to be completely shitting on the idea, none of us really know what's going to happen, I just think everyone needs to temper the excitement a bit and take a moment for a reality check.

I generally share your concerns. Much of the current rewards in open source are intrinsic: the satisfaction of making something good, helping other people, the joy of working with others.

I think those incentives, to a pretty good degree, align with goals I have for software: for it to be high quality, holistically designed, and making the lives of the developers working on it more gratifying.

> There has always been a purity around writing open source software simply for the benefit of mankind.

At the same time, there is a downside to this purity. The freedom to spend time on open source "simply for the benefit of mankind" is a luxury only available to those who are already able to put food on the table.

I think this is a major reason why the open source demographics are aligned so strongly with traditionally privileged groups, and I think that's bad for humankind.

Pumping money into the system might help underrepresented groups participate in open source, which in turn means we'll get software that is better tuned to the needs of everyone and not just the privileged.

I probably wouldn't use GitHub sponsors either. I want to retain my sense of freedom over the direction I take my projects and I worry that cash payments would undermine that freedom and also undercut the intrinsic rewards I get for creating.

At the same time, I realize my choice to not take sponsorship is a luxury I have because I've got a fantastic day job and come from a position of privilege.

Very shortsighted view. The purity view is the thing that prevented open source from taking over for the longest time.

No, there will definitely be people making money from this. Say Evan You, creator of vue is making 18k a month in patreon https://www.patreon.com/evanyo. Why wouldn't people use github now instead?

> I will not be using github sponsors for my open source projects...

Why not? There's no shame in asking people to support your work if they are benefiting. In fact, some of the people using your projects might be making money from your work. To you it's about purity, to me it's about you letting yourself be exploited.

I’d be thrilled if people were making money from my work, that’s the point.

OK you should also get a part of that. Donations are very non commital for both sides. You aren't expected to do what your donors tell you to. It will help you spend more time on your projects. Like it's in the interest of the users to give you money.

It’s not in their interest to give me money, they have no interest in that at all. They simply want me to continue working and updating my project so they can keep making money.

I don’t need a part of their money. Those weren’t the terms that I put out my software with. Imagine if you had to donate money for every package and library you used. Building applications would get very expensive quickly, when it could just as easily be cheap and free.

Which is why it's optional.

Don't let them manipulate you. Assert your policy that they are paying for the software as it is at the time of donation. I would donate with the same thought without any expectations of further development because of my donation. Only that the software has already helped me in its current state.

Exactly this. The "purity" of OSS development needs to be reflected in the "purity" of donations for this to work. Small donations should represent nothing more than a token of appreciation. Large donations, well... money shouldn't buy project influence, though that is easier said. It's a complicated matter of corporate sponsored engineers contributing both good and bad (influence wise) patches back to OSS, but people need to make a living somehow.

Just wanted to add that you as a developer put the work up-front so there absolutely should be no expectation that the donation is for future work but instead for the work that has already been done.

I personally don't like this whole sponsorship thing. This sets up people to optimize for getting and retaining sponsors instead of doing things that they would have wanted. A better approach could have been to offer money o fix issue or implement feature. For example, you could file issue/feature request on a project where developer has indicated that they have no time to work on and then offer $1000 to fix it. This is small amount if you depend on it for your business. The developer can decide if its worth their time and interest.

You'd be amazed at how many people "make demands to the creator to implement some feature or fix some bug" already when they're not paying any money.

I think it's a very compelling deal: under the patreon model (company takes a cut to fund the funding mechanism), the "platform tax" is a permanent sore that makes donating feel less good than it could. Am I giving to the cause or am I giving to the platform? An independent zero fee platform run entirely on altruism will always be in the edge of failure, with one of the failure modes being transfer to untrustworthy operators.

A commercial zero fee platform run as a loss leader on a perfectly obvious business case just makes sense. It's clear that both ends of the transaction "pay" by adding relevance to the platform, but that's a positive sum game.

What about the Liberapay model? The platform is just one explicit project to which you can donate, just like any other. It's not a tax, nor running only on the creators' donations.

Is that something different than "An independent zero fee platform run entirely on altruism"? My critique of those want particularly strong: basically "nice if it works, but will it?".

I have to admit that it looks kind of promising now, but at current funding levels the organisation could still disappear faster than a Google API. And if it was more successful a new threat could become visible at the horizon, the failure mode of uncontrolled bloat, funded basically by threatening to allow an important institution to disappear. (Yes I'm talking about you, Wikimedia)

PS: thanks for bringing it up, looks interesting!

Great case of Dogfooding. Contribute here: https://liberapay.com/LiberapayOrg/

>GitHub will not charge fees for GitHub Sponsors. And to celebrate the launch, we’ll cover payment processing costs for the first year, too! One-hundred percent of your sponsorship goes to the developer.

My reading is that they're only going to forgo the fees for the first year, and after that it's going to be basically similar to Patreon in terms of where the money goes.

From a few pages deeper: >In the future, we may charge a nominal processing fee.

That might be where they're headed, but from their diction I'm guessing they plan to try and keep this part of their business cost neutral. Who knows, maybe this is part of the ol' embrace extend extinguish, but I'm guessing they value the goodwill above the money in this case.

They should just use Google Pay API if that is the case. As far as I know they still don't charge fees.

Maybe they meant credit card interchange fees of 1-3%?

If there is money being moved around on GitHub's platform, you can be sure that they are interested in grabbing a piece of it. Otherwise, why not integrate with existing open platforms?

Because they can control it and use it as a moat.

Maybe so, but when did we suddenly start giving companies like Microsoft the benefit of the doubt on stuff like this?

They do not need donation cut because they already sell Windows etc.

No, they will take much less than Patreon. They will only charge the Stripe fees, which are much lower. And they will withhold nothing for Github by themselves, only for Stripe, their payment processor.

I’m glad open-source maintainers will get one more way to get paid... But it feels wrong to lock this into a git hosting platform. Maintainer payment is important enough to be a first-class product, open and accessible to all... instead it’s being used as a bargaining chip to keep developers on a hosting platform. The subtext is pretty clear: “if you want to get paid, you better not leave Github!”.

Meanwhile nonprofits and startups focused on solving the problem of open-source sustainability for everyone, not just Github customers, will suffer from this announcement.

I think that’s a shame.

I also think that is is effectively a pretty underhanded move to cement Github and monopolize open source development. It may not be intended to work this way, but if this campaign is successful, it will have this chilling effect. Once development funds go mostly through Github, the platform's influence over a project is greatly increased. Projects would have little choice but to comply with whatever ToS change Github would want to impose.

MS playing nice with open source starts to smell a bit like an attempt to ensnare and trap developers in an MS ecosystem. But this time around it is not about Windows as a target platform, but about dependencies on tools (VSCode), libraries (.NET Standard) and services (Github, Azure) provided by them.

Github's TOS already contains highly questionable language about a "license grant to us". I removed my code from Github when they added that, because I have no interest in risking giving Microsoft additional licenses to my software beyond those I give everyone.

The $5k matching would not even pay for a lawyer's time to review the current TOS and determine if that language in it actually does grant them an additional license.

Yeah, it's a shame the GitHub is starting to actually take advantage of their hosting monopoly, to the detriment of solutions like OpenCollective and Liberapay.

On the other hand, Git is distributed. Can't you just use GitHub as a mirror, and direct users elsewhere for actual development through the README?

Then again I didn't know about liberapay or OpenCollective up until now and I do open source for a living.

Or just include external donation links in the readme?

I assume you can't just do that since GitHub might offer to give donors regular activity updates.

> Meanwhile nonprofits and startups focused on solving the problem of open-source sustainability for everyone, not just Github customers, will suffer from this announcement.

Frankly, those startups/nonprofits haven't done a good enough job. If you want to be paid well in OSS it usually means you have to take on consulting work. If people were able to be paid well for working on OSS directly, there wouldn't be a problem for Github/MS to be solving here

> The subtext is pretty clear: “if you want to get paid, you better not leave Github!”

If you want to get paid as a video creator, you better not leave Youtube either

> If you want to get paid as a video creator, you better not leave Youtube either

That is of course Youtube's message to creators. But platform-neutral competitors like Patreon are keeping them in check. I hope the same thing happens with Github.

Replying to myself with a different perspective...

On the other hand, from Github’s point of view it just makes sense to do this. And in a way, it raises the bar for dedicated providers of open-source sponsorships. If they can’t provide something clearly better than Github’s built-in feature, then maybe their service just isn’t good enough.

Of course maybe they can’t compete properly unless Github plays fair and opens the required APIs to the competition.

Arguably, it's going to take the popularity of Github to make this a thing. Others have tried and failed (more or less) to establish an independent, first-class product to fund software developers. Some devs are getting some play on Patreon, but Patreon is more oriented toward areas other than FOSS.

Assuming this succeeds, it will be a function of the network effect. Github has a large enough base of users to sustain this kind of project.

On the other hand it provides a way to measure the performance of the people being sponsored. it's a good fit.


Some Feature Requests:

1) Let me sponsor a project, not a person

2) Let a project have a private, or a public, allocation of how funding goes. At first, simple percents would be awesome.

3) Let a project assign funding to another project. Probably one it depends on.

4) For a given project, let me see which other projects are funding it.

5) Allow the set up of Unions. These five projects all have one pool where all the money goes, which is then divided back to the projects by some percentage.

6) Fund a charity. If this person or project receives money, please directly send it to a specified charity instead. (Don't make the person who receives the donation have to handle the paperwork for it.)

7) Try to make it easy to set up a sponsorship in your will

8) Let a project use their funding to pay for hosting, directly. So, I give to some project, they pay for CPU and Storage on some cloud host.

I'm certain there are legal complications with all of these ideas. If you solve the legal issues, that would be amazing. Cheers!

For #1, it looks like that's coming? The documentation[1] has been updated for project sponsor buttons to include up to 4 github-sponsor enabled users. I can't find a project using it yet, but I imagine this divides your donation to the project among the 4?

[1]: https://help.github.com/en/articles/displaying-a-sponsor-but...

Open Collective already offers many of these features.

They can have all these if they allow "pay with Ethereum".

This is NOT about helping us out, fellow maintainer-kids, it's about owning the playground and burning the forest.

This fee structure is predatory af & straight outta amazon's playbook. (2x matching funds and all fees waived for first year?[1])

There has been an ecosystem. If this was about anything except market capture through burning VC/reserve funding, GitHub would have engaged in existing nacent and experimental spaces. They haven't: http://opencollective.com/github

If a company is truly trying to be embody open culture, they support and and-yes existing projects as step 1. Case in point: https://words.steveklabnik.com/why-im-partnering-with-balanc...

If we have a problem or idea for OpenCollective/Liberapay/etc, the staff live on open chat rooms -- the github issue queues are public -- the code is interrogable by the curious and adventurous. With GitHub, we get bupkis. Or wait, we get coaxed into a one-on-one email support channel where we can't see one another, speak together, nor find fellow travellers. Or we get the unofficial wailing wall that is https://github.com/isaacs/github

Really disappointed in the lack of critical reflection from technologists. This is not good for us as executed.

[1]: https://help.github.com/en/articles/about-github-sponsors#ab...

If you felt like being cynical, you could say that this (along with the package repository stuff) is the beginning of the "extend" phase of the "embrace, extend, extinguish" of Microsoft of old.

On its face it's nothing but positive. But at the same time, many of us are recognizing that there's just something that feels a little bit off about this.

Thanks for validating the concern. Truly appreciate that.

I don't like to be cynical! I promise it's not my default mode!

There are a hundred more funding experiments to run in open source. And open source is the playground for the wider world to improve funding! (Non-profit land is effed, and they need help from our learning :) We need to try/fail/win at designing these imaginaries together! That's perhaps what offends me most about the funding distortions they're applying.

It's disingenuous for GitHub to suggest they be trusted to lead the funding ecosystem when they kick it off with these shenanigans and huge distortions :)

You can add sponsor button next to Watch/Star button [1] which supports opencollective. For example, ReactiveUI [2] repo has one.

[1] https://help.github.com/en/articles/displaying-a-sponsor-but...

[2] https://github.com/reactiveui/ReactiveUI

Thanks! I realize that :)

Interestingly, diapers.com could have legally sold their diapers as a vendor on Amazon as well.[1] That doesn't really affect the predatory nature of Amazon's steep and unsustainable 20% discount, which went away after diapers.com went under.

[1]: https://slate.com/technology/2013/10/amazon-book-how-jeff-be...

Also what is up with “These external links will take you off GitHub to pages we haven't verified, so beware.” ?

You can put links to stuff in all other places without warnings. Now ok I guess they can argue that most other places do not entail with people sending money. But why not at least keep a list of “trusted” places?

I'd wager this is more of a "cover your ass" kind of situation for GitHub.

Can I ask where you're getting that info. on the fee structure, I can't see that on their pages easily.

From reading the FAQ it sounds like there are no fees in the first year at all and afterwards it's a payment processing fee?

Also I got the impression that matching was Github adding additional funds to the payment, sounds like not a bad thing really?

First off, thanks so so much for engaging. Truly grateful <3

From the FAQ[1]:

> In the first year, GitHub will not charge any fees, so 100% of sponsorships will go to the sponsored developer. In the future, we may charge a nominal processing fee


And yes, money feels nice. But there are politics here that are real. The meaning of a sum of money is also wrapped up in the future that it creates. Decision-makers at GitHub aren't stupid, and so the future their money creates should be assumed to be the one they intended.

If someone comes into a town with boatloads of outsider money, and set up shop next door to a critical local business, but selling at loss leader rates that burn money, with plans to bump up prices once the locals flail and weaken -- that's understood as anti-social and kinda asshole behaviour.

It feels no different here. We shouldn't be applauding, despite the good deal.

Money ain't free. We're being paid off to accept a future of collapsed possibilities.

imho of course :)

> Decision-makers at GitHub aren't stupid, and so the future their money creates should be assumed to be the one they intended.

This is always true, for any person or organization at any level of scale. They spend money to bend the world in the direction they want.

This is not a instrinsically bad thing. It's only a priori bad if you assume the world is zero sum and any change to benefit party A is necessarily a harm to all other parties.

I think you have to have a little more sophisticated analysis to see if something a business does is a net good or ill to the world. When I buy cookies, I acknowledge that I'm helping create a world where more cookies are bought and consumed. But I'm pretty on board with that world too, so that's OK.

In this case, I don't think anyone can accurately predict the large scale consequences of what GitHub is doing.

Thanks for the generous thoughts :) I know it's not intrinsically bad. But I suppose I am saying that this specific event is bad, in non-shallow analysis.

Yes, all things are aspiring to "bend the world" (i like that term) -- a kid putting up a poster for selling cookies from their pantry for 10c is trying to affect people.

But then there's greater bending, of almost all possible paths of significance. GitHub/GitLab are THE places in our digital lives as coders. The scale at which this intervention/distortion is happening is important.

The unfair squelching of funding experiments in open source land WILL affect paths outside software. OpenCollective was using their learnings and profits in serving FOSS, to affect non-digital projects in the social fabric of physical cities: https://opencollective.com/brussels

This unfair buying of the opportunity space -- afforded only by deep pockets of Microsoft -- will affects paths that were leading to much more collateral benefit for all of us. Most maintainers would need to be irrational to use anything BUT their system while the distortions are in place. Those supporting this launch bear some real responsibility for what becomes LESS possible in the world when this feature "takes the ball and goes home". (at least in terms of open source funding)

I truly don't feel I'm doing a shallow analysis here.

Anyhow, I really appreciate the attention you may have given this.

Disclaimer: I work adjacent to civic technology, government procurement and the distributed web. There are many exciting paths dancing around these things, and the execution of this launch (separate from the feature itself) is certainly not one of them imho

Ah I see, so if I understand correctly, it's more that you feel there is ill-intent behind Gihtub's move and their plan is to undercut existing players, and then to increase prices?

That feels to me, like one interpretation for sure, but there are others.

MS (like some other large tech. companies) make their money these days more from subscription services to cloud hosted systems.

Github feels, to me, like a play to provide a compelling ecosystem for developers, in the hopes that it translates to revenue from cloud.

Doing as you describe (upping charges on a service after getting rid of the competition) seems like it would backfire horribly on them from a PR perspective and the amount of money involved (a small percentage of the donations provided) would be a rounding error on Microsoft's income.

I think there's an ulterior motive, for sure, but the one I see as more likely is providing more stickiness to the MS developer ecosystem in efforts to translate to more ammunition in the cloud war with Google and Amazon...

Dan Ariely's 2008 book "Predictably Irrational" [1], which presents experiments in behavioral economics, has one chapter [2] that discusses the introduction of money ("market norms") in an otherwise money-free social context, typically of favors being exchanged ("social norms")

To summarize, the introduction of hard currency completely disrupts the social dynamics and the resulting work quality, usually for the worst.

You can find an more in-depth summary in the links:

[1] https://en.wikipedia.org/wiki/Predictably_Irrational

[2] http://bookoutlines.pbworks.com/w/page/14422685/Predictably%... "Chapter 4: The Cost of Social Norms"

I mean yes, this is obviously a thing, no argument. But I'm not sure that means that Open Source maintainers are feeding themselves off the goodwill and feelgoodness they are getting from maintaining these projects.

I would gander to guess that most maintainers are supported by a small minority of enterprisy agreements they have, either through large sponsorship or by working for a company that is supporting their Open Source work.

And I think that's a bad thing. I would much rather see them supported by 10,000 $1 monthly donations than 5, $2,000 donations. That is more likely to lead to features and attention focused on the needs of the masses than the enterprise.

I say this as someone who maintains an Open Source platform primarily funded by a single enterprise. I would love to flip that on its head.

Hi, I’m Devon the product manager behind GitHub Sponsors. We’re excited to launch the beta program today and learn how we can best serve the community.

It’s great to already see the conversation on this thread! We’re eager to hear all of your feedback, and feel free to email me at devonzuegel@github.com as well.

Hi Devon, I posted this comment elsewhere in this thread [1], but now feel that here is a better place to write it:

It would be very cool if there was an easy way to sponsor all the projects I've starred. Then I could just pay (say) $10 per month to "support open source", without having to worry about any of the details such as picking projects. If you as GitHub then also reach out to the project maintainers and say "hey, there's someone who'd sponsor you", then I feel this could significantly increase the uptake of this feature on both the sponsor and the maintainer side.

[1]: https://news.ycombinator.com/item?id=19990110

Am I using stars wrong? I have starred 771 projects on GitHub. To me, a star means anything from "I use this" to "I think this is a cool project". Giving $10 a month to 771 projects would result in about a penny for each project.

I'd rather separate starred from sponsored. If I could select a subset of that 771 and say "split $10 among these projects" then I'd be happy.

I'm in your shoes too. I've got 457 stars (and I don't think I've ever un-starred a project).

I think it'd be a reasonable default for most people to start with though.

Perhaps offering the projects that you `watch` a higher priority than those you've starred would be a fairer default?

This is interesting, but it raises questions, mainly: if a project is abandoned and you've still given it a star, does it continue to send money to it? Will it cause people to un-star projects?

I could see having some kind of "tip amount" per project that gets taken from a pool would make a lot of sense, but not as stars.

Doesn't that problem still exist though? Say you sponsor a project individually and it eventually goes unsupported. Would your sponsorship live on if you never manually cancelled it?

Using stars as a proxy for sponsorship, I think, is the wrong idea anyhow. Sponsorship should imply star, but not the inverse. I think what would be best is an easy way to sift through your starred projects and "upgrade" them to a sponsorship. Then once you've done that once, you can manage stars and sponsorships independently going forward.

They could factor in the repo's "pulse". More active projects get a bigger slice.

No, they shouldn’t, because doing that would incentivise improper activity.

This would be a nice feature, less overhead for the donator too as the amount donated can automatically be split up among all of your starred projects. Bonus points to offset a sponsor dashboard where you can use a slider to change the percentage splits. In the future a budget feature can be added for sponsored projects and this dashboard can show which projects haven't yet met their budget for the month or quarter, similar to the banners that show on wikipedia, "this is an open source project and need x amount in order to keep operations going smoothly, if everyone donates y amount that will fund development for z time period."

This dashboard could also have suggestions for sponsoring projects that you either forked or use as a dependency in your project.

If I forked a repo it’s because I was making a PR to fix something. It says nothing about whether I’m still depending on that code.

Hello there Devon!

I'd be interested to hear what the main reasons for not either a) building on top of existing open platforms (like OpenCollective) or b) doing your own service but building it open source and as a open platform?

Also, once the one year period is over, how are you planning to setup the fee structure?

> doing your own service but building it open source and as a open platform

Why would they ever do this? Practically nothing they do is Open Source.

Well, they trying to put themselves in the middle of open source. Why wouldn't they, if they really care about their users, not just getting profits?

> if they really care about their users, not just getting profits?

[citation needed]

It's a for-profit company who "loves" open source and hosts a lot of it's projects. But the platform is still not open source. Go figure

This would be nice if there was some integration between the two.

Will this support micro payments like $1 or even $0.10 a month? Or would credit card fees eat all that up?

Would be great if they could get Stripe on board with this and support 0 fees due to the application.

interchange fees are attributable mostly to card networks (e.g. visa) and not stripe

$1 / month is already one of the options.

Devon, as a contributor to a major open source project, this is really really awesome news. Thanks for all the hard work on it.

In lieu of helping out OSS, your CEO put out a proposal awhile back about offering desk space to contributors of OSS [0]. Is this still in consideration?

[0] - https://twitter.com/natfriedman/status/1103919494894772226

1 - I can imagine sending money to every country isn't a simple deal. Which countries of residence will initially be allowed to receive (and send) payments?

2 - How a potential sponsor knows, without a lot of research, who is deserving of their sponsorship? Will this possibly cause people to change the way they contribute to OSS to make them more visible/noisy and create unhealthy competition?

This is a brilliant idea whose time has come, and I'm looking forward to seeing how it plays out.

I'm especially looking forward to seeing how it plays in the corporate arena; I'd love to see businesses that depend on open source every day (that is, all of them) throwing what is just pocket change to them at projects enabling their business. I hope you're planning on encouraging this behavior!

Really excited for this new feature!

Would the sponsorship be a subscription model or can you also do a one time payment donation?

How many sponsoring circles have you detected already ?

I can't believe people able to be sponsored aren't doing background stuff to make sure they get free $5K a month from github, since it's a simple as doing a reciprocal sponsoring.

Heck, anyone with a bit too much cash can just offer to be payed to sponsor, let's say you give me 1 unit, I sponsor 0,9 upon payment, you get 1,8 from github.

TL;DR : really surprised you went with matching sponsoring, aren't you worried about this, is this just cost of doing business, or are you actively detecting it ? (and how if discloseable ?)

GitHub is vetting applicants. If they do get hoodwinked, they are at least getting hoodwinked into giving money to somebody they thought was doing worthwhile work to begin with.

So your hypothesis is that they'd rather assume this potential cost for the sake of publicity ?

Also, in the "paid to sponsor" scenario they'd be hoodwinke into giving money both to someone worthwhile and someone totally unknown to them. I'd be really curious to know the technical or legal possibles responses.

The whole concept of giving away matching funds is for publicity.

That's a good point actually, I suppose it doesn't indeed really matters to them where it goes as long as they can say "we gave X to open source projects", X probably being already defined.

Can an organization get sponsored instead of an individual?

I love this. I do wonder though if anyone can educate me on the choice to do a monthly sponsorship? I think that's awesome but at the same time, there are a lot of developers I want to send 10 dollar tips to for that library that they made.

Just wondering if there's a reason to not have both. My guess is that foregoing one time transactions in favour of ensuring that people gravitate towards making a more sustainable donation seemed like a rational choice. Pure speculation there so if there's any other reason why it wasn't done I'd be really grateful if anyone from Github might be able to share.

I also think it's about sustainability. As a developer receiving an X amount every month (+/- Y%) can heavily reduce the financial risk and help plan better.

I'm currently not developing any open source software but if I was and worked as a freelancer knowing that by the end of the month I'll receive $500 for GitHub would allow me to balance my open source work with the freelance work, ensuring I have enough money to support myself.

If they offered both (monthly and one-time payments) then the solution would be to allow the project to allow only one or the other or both or neither. So you could select that you'd only receive monthly payments and people wouldn't be able to send you one-time payments.

Even better (imo), try to buffer one time payments over months. This (and other similar features) could allow a developer to see upcoming income from OSS, if it's declining, etc.

Being able to predict how much you're going to make it hugely helpful imo. Especially if you're a freelancer. You might see that in 3 months your funds are drying up, so plan accordingly.

Just brainstorming: But "similar features" could be trying to favor longer term donations. If a user wants to donate $20/m, maybe ask them for $10/m for 3 month increments?

Though, I suppose this isn't any better than the developer themself buffering funds in their bank. BUT, it seems like a meaningful concept, regardless.

Instead of enabling one-time donations, I see some value in sponsorships with a predetermined EOL: Instead of donating $10 one-time, get a 10-month sponsorship for $1 each and at the end of those 10 months, decide whether you want to continue supporting the developer. Github could charge you the $10 (or the interest-adjusted equivalent) up-front to decrease the transaction costs too.

This decreases the variation in the developer's income and lets them plan for the future accordingly, which is always a good thing.

nah it'd be better if you could just tip a developer, i'm more inclined to do a large one time "impulse" donation instead of a continuous drip feed

also i wouldn't want to be listed as a sponsor in case the dev wound up doing something controversial(as Opensource devs are wont to do)

I would like a onetime donation as well. Especially since there are a lot of small, usefull projects that don't need a lot of maintenance.

And some of those developers don't need the money, but would love for their tip-jar to auto-feed into a charity (or other project!) of their choice.

I only have experience in non-development creative work, but one-off payments/donations are much more anxious than monthly. Sales of t-shirts/songs/ebooks could be higher than what I get monthly on Patreon now, but:

1: I could never be sure. One month it was $0, the next it was $3, the next it was $40. This is impossible to plan around. It's even worse now with everything moving to SaaS. It's easier to justify a subscription to something like EastWest Composer Cloud or Splice when I have a bunch of people subscribing to my work who've been there for months or a year.

2: I didn't know who they were. This was fine in the good months, but then I hit long stretches with nothing coming in, and I had no idea why. Did the platform make some change? Did my products fall out of fashion? I was at the mercy of opaque storefront logic and priorities.

And I don't mean in the creepy surveillance state sense. I know most of the people subscribing to me on Patreon through Mastodon. When they unsubscribe, I know why because they tell me. I sold tens of t-shirts years ago. I've never seen someone wear one. Nobody sent me an email. Sales collapsed one day and never returned. Patreon subscribers tell me good things about my music and writing all the time.

Neither of these is 100% a problem with one-off contributions, but the level of communication never matched this.

This is my experience as well. I've done both, and made more money off one-time software sales (rather than patreon-supported OSS) but it was completely unpredictable. There are toxic outcomes from that: you start tailoring your output to what you think the market will do big numbers on, rather than what's good. Being a small business person can be brutal and it doesn't always lead to you doing good work: it can lead to very cynical exploitation of your perceived market, just to survive for another month.

Being able to vote with dollars on bug/features would be great.

Bug bounties would be amazing.

I'd drop a lot of money on a particular docker feature that hasn't been dealt with for the last 3 years running.

Also there are hundreds of way to receive one time donations on the internet currently. GitHub focusing on recurring subscription makes sense.

A logical next step would be to add bounty on specific bugs or features requests.

If a company is relying on open source, and has no capability to fix a critical bug (which is a bad strategy but it certainly happens), it would probably be ready to pay a hefty sum so that the maintainer, or anyone involved in the project, will have at least a look at it.

Today, unless you can contact directly the maintainer and hope he or she has some spare time, I don't know how you can solve that kind of issue.

However, I am not sure who will decide a bug is fixed or a feature properly implemented.

One not-so-bad solution could be similar to what StackOverflow does: The issuer of the bounty may decide who gets it. But even if they don't issue it to anyone, they don't receive their sum back. There there currency is points, but if it's real money, any unreleased bounties could go to some kind of general community pot for that project or whole Github after a while.

This 1000x. I spoke to a designer at GitHub specifically about this a few years ago. Their initial concern was over-complicating the UI/UX. There's no doubt they've discussed this internally and I'm very curious what the hold up is.

i think worklist.net has created a bidding platform that works that way. it's not popular, but something like that on github be pretty popular imho.

Seems like it would give people the wrong idea.

I support one project on Open Collective [1] on a monthly basis. They do take a cut from the money I donate to cover the credit card fees and their operational costs. GitHub Support does not take any fees and even matches donations... wow!

While this news sounds amazing on the surface, I am also concerned it might have negative effects on the OSS ecosystem overall. Let's see how this pans out!

[1] https://opencollective.com/

> GitHub Support does not take any fees and even matches donations... wow!

Maybe I didn't fully understand what "cut" means, but ....

> In the first year, GitHub will not charge any fees, so 100% of sponsorships will go to the sponsored developer. In the future, we may charge a nominal processing fee.


Keep in mind that they will only take a payment processing fee, unlike other services that charge a cut from the payment in order to pay for their services, or at least that is what it says for now.

>Keep in mind that they will only take a payment processing fee, unlike other services that charge a cut from the payment in order to pay for their services...

How are those different exactly?

The first scenario is a loss leader -- it doesn't contribute any revenue for the business to stay afloat.

The second may or may not be a loss leader, but it will contribute something in revenue for the business to stay afloat.

That's charitable. Nowhere do they say that their "payment processing fee" will be limited to the fees charged by their payment processor. They could very well charge some multiple of that value to generate a profit.

There is: nominal processing fee.

payment processing fee = pay the payment provider (Stripe, PayPal, etc.)

a cut from the payment in order to pay for their services = additional fee on top on payment processing fee to cover operational expenses, employee salaries etc.

Credit Processing fees pay the bank/processing fees charged to Github. The Patreon “cut” pays processing fees but it also pays for Patreon’s electric bill, employee salaries, rent, profit.

Github already has the bills paid by paid GitHub accounts. So adding this is simply another feature and the only new real cost to this feature is credit card processing fees. If there are other costs (extra employees, etc.,) that could be counted as a marketing expense.

You're right I didn't read that passage at first glance. In a year, both donation matching and 0 fees may very well be gone.

If they only charge the card processing fee I'd say that's still pretty darn good.

Although I wouldn't necessarily be mad if they charged more than that. The incentives seem to align pretty well. GH makes money when people support OSS.

The big question is if they don't take fees then how do they match the donations? This is clearly unsustainable.

> To supercharge community funding, GitHub created the GitHub Sponsors Matching Fund, which matches up to $5000 per sponsored developer in their first year of sponsorship. In the first year, GitHub will not charge any fees, so 100% of sponsorships will go to the sponsored developer. In the future, we may charge a nominal processing fee.

What's to stop me^Wsomeone else and their friend from sponsoring each other for $5K to collect the $5K in matching funds?

Well, that would be fraud and illegal.

Other than that, nothing. What's stopping you from conning an old lady out of her pension?

Why would it be fraud? We both contribute to open source projects and appreciate the effort that the other contributes.

I don't know whether you're trolling or simply naive but that's clearly fraud and the scenario you describe explicitly aims to commit fraud.

At the very least it's violating the terms of service. But very clearly the two of you would have conspired to defraud GitHub and in this case there would even be evidence in the form of an HN comment where you literally ask if this would work.

You may think you're clever but trust me when I tell you that no, you're not, and I've seen enough people try to be exceptionally clever and think "plausible deniability" would cover their butts and then get sued for fraud.

How do you distinguish

(A) two random developers that met each other at several conferences over the years, have contributed to a few same projects and really like the efforts the other one is putting into their OSS project

(B) two random developers that met each other at several conferences over the years, have contributed to a few same projects and want to fraud GitHub for the donation match

I think this could be a real practical problem for GitHub. And lawyering up against developers supporting the campaign potentially counteracts the marketing benefit of it.

If I was GitHub, I'd make a distinction between two random people shuffling 10 bucks back and forth and two people shoving hundreds or thousands around. The first scenario is probably an accident, the second is not. Come to think of it, they probably should have capped individual contribution matching to something reasonable (maybe they'll still do that).

Option (A) is the exact situation I'm envisioning.

Rather than waiting for some third party fans to give money, we'd be immediately rewarding the work that the other has done over the years with a one-off $5K (to maximize the match) contribution.

I'm not the other guy, but I honestly don't see an argument for why this is fraud. Is this against the terms? Can you point to a specific line in the terms forbidding this? Your argument just seems like "this is clearly fraud and you can tell by looking at it"...

Here there's an offence known as "theft by deception" which would probably cover what is effectively a conspiracy to do so.

When joining the waitlist, they ask about a variety of open source projects you've been involved in. I imagine they'll vet what kind of contribution level people did on different repos they claim, or just on open source repos in general.

A fraud conviction.

"me", I mean "another github user", I mean "anyone on the internet who wants to create a github account & start cashing in."

This feature really makes no sense, either they figure the fraud will be low enough to not matter, or there's some oversight mechanism to prevent it. I am certain they don't want to try to sue ten thousand random people to attempt to claw back $5k each. I imagine there's some flag/approval process.

Idk, you can abuse everything. Does that mean nothing that could be abused should exist?

I expect them to at least verify that you're doing some useful work on GitHub. If you are, I don't even particularly mind you exploiting this, even if it's perhaps not ideal.

Perhaps you don't mind it, but it would be interesting to know more about GitHub's and Microsoft's thoughts/thought process on this topic.

If Github aren't doing KYC and AML, then their payment processor better have. Otherwise this is the swiftest way I've seen to make $5K.

Epic Games is doing stuff like this in order to own the concept of a video-game storefront. I don't think Microsoft would go quite so far as to subsidize massive fraud just to get people engaged with this scenario, but they're clearly prepared to throw some money at it.

I have been curious for a while what Microsoft plans for LinkedIn and GitHub.

It seems like one possible future here is that open source becomes less like passion projects that scratch an itch and more like driving for Uber.

Maybe that is good. Maybe GitHub just took a step toward becoming Fiverr. I really don't know.

> It seems like one possible future here is that open source becomes less like passion projects that scratch an itch and more like driving for Uber.

Is that a future we want? I would much rather work towards a future where everyone makes enough at their day job and can work on passion projects on the side.

Why are we okay with the idea that in order to get by, we should have to do work in our supposed off time as well? Uber/etc love to bring up the fact that it's often their drivers' second job, as a defense of their independent contractor status and pay. Which is, to me, a pretty damning indictment of how we've structured our society.

> Maybe that is good.

How is that good?

Maybe the quality would improve? There's a condition I call "open-source-itis" that a lot of projects suffer from, where tons of new features (usually of dubious merit) get added but nobody ever bothers to fix bugs or make sure the foundation is actually solid. It makes sense, because that's unsexy work that people generally don't want to do and they're all working for free, but it makes a lot of open source software really crap.

However, if people were getting paid for fixing bugs and cleaning up old code, maybe that'd improve.

You can describe any software that way.

Big new headline features are a marketers wet dream.

"We fixed that annoying bug that affected 4 people last year" not so much.

Also, "driving for uber" is hardly a great thing to aspire to.

I'd expect it to get worse. People pay for features over maintenance even more strongly than they allocate prestige.

Nah, there's a bug out there right now blocking my work I'd throw money at if I could. I can't be the only one who feels like this.

Rich, the creator of the Phaser framework, does something like this (I haven't dug into it much): https://github.com/photonstorm/phaser/issues/3390

It appears they leverage Bountysource (not familiar with it).

In my line of work there are perverse incentives for hyping up new stuff and then not dealing with bugs and problems. It's not been me doing that but I've suffered by comparison against others who embraced that dark pattern.

Complaints are publicity. They bump internet discussions, create buzz, and often go along with protestations of 'I really love (FooBazBar), I promise it's the best thing ever, now if you would only fix this bug…' and then angry flames over the bugs and defenders coming to protect the honor of FooBazBar.

Fix bugs and people are happy and stop talking. They return to happily using the product. Again, we're talking perverse incentives for just the sort of obnoxious behavior you describe, or worse.

a lot of abandoned project will get revived

I am cautiously optimistic about this. I recently built a prototype GPU-based 2D renderer which I think has huge potential, but obviously also needs quite a bit of work to become a real product. I've been considering various kinds of hybrid open source business models, where there's a free part but also parts people pay for. I'm pretty sure that can fly, but I'm also hesitating at the idea of spending a huge amount of my time and energy on building a business - I want to concentrate on the tech itself. If I can get close to paying cost of living through sponsorship, that's pretty appealing.

For this to really fly, though, needs to come revenue streams from businesses who depend on open source, rather than other individuals. I'm hopeful this can get there.

This is such a watershed moment in the history of software development that I don't think most of us can grasp its significance yet. Sure we're familiar with other services that do the same, but the adoption rate (like for GH itself) will be clearly different.

One could argue that this is more societally important than YouTube, Twitch, etc funded content for _consuming_ because this funds content for _leveraging_ to build/work on top of. And this is not just limited to the entrepreneurial devs out there, of which "the man" has new employment competition with now. It can also fund entire company departments.

I look forward to mass adoption of this, wallet in hand.

This is a sad commentary on software development as a profession, as well as society as well. A watershed moment is when private individuals might be able to get paid for the extremely valuable work that they do that allows thousands of companies to make a profit with some companies becoming worth billions. The fact that the ability to socially beg for money for valuable software makes the idea of writing valuable software more viable is a sad state of affairs.

What's the line between patronage and just hiring someone outright for a pet project?


While I understand why others are wary, I am also excited about the good that this could do for OSS projects.

I know I've struggled in the past to give money to projects that make me a profit. The third party tools are hardly brilliant, and maintainers have to set them up, and look after them.

This has the potential to be a really good thing.

The big unknown here is that the MVP is sponsoring individual contributors vs an entire project. Of course it is technically easier to build, and removes GitHub from having to build logic or tools on how to divide contributions fairly among contributors, but it opens up questions on perceived fairness among contributors to a given project e.g. what happens when one contributor, for whatever reason, receives far more contributions than another equal contributor? Will that lead to infighting, jealousy, turnover, lawsuits, loss of motivation?

Yes, nice to have the key people working on open source in Bill Gates pocket. Isn't this what the open source communtiy have been dreaming about all along..

Cynisism aside I get where you are comming from. As somone doing OS fulltime I applaud the effort. I guess it is to much to ask to have a source of income completely without bias.

> but the adoption rate (like for GH itself) will be clearly different.

How many individuals have a paid GH account vs a free one?

Now how many of those are willing to donate to a project/person but hasn't already done so?

LOL! I think you might be a tad overstating the significance of this.

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