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!
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.
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 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 )
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.
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.
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.
> 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.
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).
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.
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 :)
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.
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.)
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.
But your company probably doesn’t depend on our software.
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?
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.
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.
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.
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 :(
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.
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.
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 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.
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.)
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.
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.
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 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?
As long as Microsoft is being altruistic here, we should be fine.
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.
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.
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.
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.
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?"
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.
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.
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-....
Everyone with a big report for your OSS project is already on your Github page. Its perfect.
If GitHub Sponsors is stronger at whatever-it-is-that-makes-people-donate, that would be their advantage.
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.
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'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?
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.
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.
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.
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.
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.
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.
This is one step away from consumers being able to put bug bounties on issues too
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.
- 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
- 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: email@example.com.
GitLab may be in a position to do so, unsure about others.
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
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.
> 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 -- firstname.lastname@example.org.
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.
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.
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.
$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 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.
I was just commenting what I have been witnessing over the years is all.
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.
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.
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.
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.
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.
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.
- 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
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.
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 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.
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 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.
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.
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!
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.
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.
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.
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.
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.
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?
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
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.
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.
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.
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!
This fee structure is predatory af & straight outta amazon's playbook. (2x matching funds and all fees waived for first year?)
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.
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.
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 :)
Interestingly, diapers.com could have legally sold their diapers as a vendor on Amazon as well. That doesn't really affect the predatory nature of Amazon's steep and unsustainable 20% discount, which went away after diapers.com went under.
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?
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?
From the FAQ:
> 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 :)
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.
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
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...
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:
 http://bookoutlines.pbworks.com/w/page/14422685/Predictably%... "Chapter 4: The Cost of Social Norms"
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.
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 email@example.com as well.
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.
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 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?
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.
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.
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?
Why would they ever do this? Practically nothing they do is Open Source.
In lieu of helping out OSS, your CEO put out a proposal awhile back about offering desk space to contributors of OSS . Is this still in consideration?
 - https://twitter.com/natfriedman/status/1103919494894772226
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?
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!
Would the sponsorship be a subscription model or can you also do a one time payment donation?
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 ?)
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.
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'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.
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.
This decreases the variation in the developer's income and lets them plan for the future accordingly, which is always a good thing.
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)
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.
I'd drop a lot of money on a particular docker feature that hasn't been dealt with for the last 3 years running.
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.
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!
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.
How are those different exactly?
The second may or may not be a loss leader, but it will contribute something in revenue for the business to stay afloat.
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.
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.
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.
What's to stop me^Wsomeone else and their friend from sponsoring each other for $5K to collect the $5K in matching funds?
Other than that, nothing. What's stopping you from conning an old lady out of her pension?
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.
(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.
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.
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.
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.
AML: anti money-laundering.
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.
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.
How is that good?
However, if people were getting paid for fixing bugs and cleaning up old code, maybe that'd improve.
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.
It appears they leverage Bountysource (not familiar with it).
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.
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.
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.
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.
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.
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?