The role of GitHub in paying for Open Source Software
I have been doing Open Source work for just under twenty years at this point. I have been paying my mortgage from Open Source software for about 15. I’m stating that to explain that I have spent quite a lot of time struggling with the inherent tension between having an Open Source project and getting paid.
I wrote about it a few times in the past. It is not a trivial problem, and the core of the issue is not something that you can easily solve with technical means. I ran into this fascinating thread on Twitter that over the weekend:
you just described licensing. As you missed 1 important aspect: if an org isn't obligated to pay, they won't. So you need a form of making them pay by giving them a token they paid which then makes them able to use your software. Any other form will fail.
— Frans Bouma (@FransBouma) August 11, 2023
And another part of that is here:
The thing is, businesses spend significant amounts of money on software licenses, whether on-prem or as-a-service.
— Udi Dahan (@UdiDahan) August 11, 2023
They understand and accept this, as do their shareholders and investors. It is a cost of doing business.
Donations? Not so much.
I’m quoting the most relevant pieces, but the idea is pretty simple.
Donations don’t work, period. They don’t work not because companies are evil or developers don’t want to pay for Open Source. They don’t work because it takes a huge amount of effort to actually get paid.
If you are an independent developer, your purchasing process goes something like this:
- I would like to use this thing
- I need to pay for that
- The price matches the value I’m getting
- Where is my credit card…
- Paid!
Did you note step 2? The part about needing to pay?
If you don’t have that step, what will happen? Same scenario, an independent developer:
- I would like to use this thing
- I use this thing
- It would be great to pay something to show my appreciation
- Where did I put the credit card? Oh, it’s down the hall… I’ll get to that later (never).
That is in the best-case scenario where the thought of donating actually crossed your mind. In most likelihood, the process is more:
- I would like to use this thing
- I use this thing
- Ticket closed, what is the next one… ?
Now, what happens if you are not an independent developer? Let’s say that you are a contract worker for a company. You need to talk to your contact person, they will need to get purchasing approval. Depending on the amount, that may require escalating upward a few levels, etc.
Let’s say that the amount is under 100$, so basically within the budgetary discretion of the first manager you run into. They would still need to know what they are paying for, what they are getting out of that (they need to justify that). If this is a donation, welcome to the beauty of tax codes in multiple jurisdictions and what counts as such. If this is not a donation, what do they get? That means that you now have to do a meeting, potentially multiple ones. Present your case, open a new supplier at the company, etc.
The cost of all of those is high, both in time and money. Or… you can just nuget add-package and move on.
In the case of RavenDB, it is an Open Source software (a license to match, code is freely available), but we treat it as a commercial project for all intents and purposes. If you want to install RavenDB, you’ll get a popup saying you need a license, directing you to a page where you see how much we would like to get and what do you get in return, etc. That means that from a commercial perspective, we are in a familiar ground for companies. They are used to paying for software, and there isn’t an option to just move on to the next task.
There is another really important consideration here. In the ideal Open Source donation model, money just shows up in your account. In the commercial world, there is a huge amount of work that is required to get things done. That is when you have a model where “the software does not work without a purchase”. To give some context, 22% is Sales & Marketing and they spent around 21.8 billion in 2022 on Sales & Marketing. That is literally billions being spent to make sales.
If you want to make money, you are going to invest in sales, sales strategy, etc. I’m ignoring marketing here because if you are expected to make money from Open Source, you likely already have a project well-known enough to at least get started.
That means that you need to figure out what you are charging for, how do you get customers, etc. In the case of RavenDB, we use the per-core model, which is a good indication of how much use the user is getting from RavenDB. LLBLGen Pro, on the other hand, they are charging per seat. Particular’s NServiceBus uses a per endpoint / number of messages a day model.
There is no one model that fits all. And you need to be able to tailor your pricing model to how your users think about your software.
So pricing strategy, creating a proper incentive to purchase (hard limit, usually) and some sales organization to actually drive all of that are absolutely required.
Notice what is missing here? GitHub. It simply has no role at all up to this point. So why the title of this post?
There is one really big problem with getting paid that GitHub can solve for Open Source (and in general, I guess).
The whole process of actually getting paid is absolutely atrocious. In the best case, you need to create a supplier at the customer, fill up various forms (no, we don’t use child labor or slaves, indeed), figure out all sorts of weird roles (German tax authority requires special dispensation, and let’s not talk about getting paid from India, etc). Welcome to Anti Money Laundering roles and GDPR compliance with Known Your Customer and SOC 2 regulations. The last sentence is basically nonsense words, but I understand that if you chant it long enough, you get money in the end.
What GitHub can do is be a payment pipe. Since presumably your organization is already set up with them in place, you can get them to do the invoicing, collecting the payment, etc. And in the end, you get the money.
That sounds exactly like GitHub Sponsorships, right? Except that in this case, this is no a donation. This is a flat-out simple transaction, with GitHub as the medium. The idea is that you have a limit, which you enforce, on your usage, and GitHub is how you are paid. The ability to do it in this fashion may make things easier, but I would assume that there are about three books worth of regulations and EULAs to go through to make it actually successful.
Yet, as far as I’m concerned, that is really the only important role that we have for GitHub here.
That is not a small thing, mind. But it isn’t a magic bullet.
Comments
And a random organization might be more willing to pay GitHub instead some unknown small company in country they haven't heard of. And some companies might treat GitHub as the vendor, thus reducing the bureaucracy after the first purchase is done, not requiring it for every new author.
K,
Yes, that is the point. You use GitHub as a payment processor. That works, but it is a different model than sponsorship.
And from the GitHub side, it would require a very different setup. For example, how do you handle disputes?
Comment preview