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.
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 )
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.
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.
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.
> 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 :)
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.
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.)
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.
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!