Funding open-source software without compromising it
21 points by yorickpeterse
21 points by yorickpeterse
If you're starting from "paying for a programming language is something that developers or companies just don't want to do these days", you've already taken a position of defeat.
If you haven't asked yourself, I think it's worth mulling over why you care about the project being under an open-source license. Evan Czaplicki was interviewed by Kris Jenkins on this topic, some quotes:
https://m.youtube.com/watch?v=ABdpAjDDh-c&pp=ygUbZXZhbiBjemFwbGlja2kga3JpcyBqZW5raW5z
"I think part of what had been so powerful about open source, is that it captured this [..] anti-corporate sentiment, but when you go to the founding documents, it really is from a specifically Libertarian perspective [..] It is ultimately a politically specific analysis of our industry. For me personally, I look at it differently. I think a family business and a publicly traded business are categorically different entities. Once you do a thorough analysis, the energy that is against large companies taking advantage of small people... you can have a more interesting conversation than whether the code is free or not free. Are we able to support small creators or not? One classic issue when you have a system which doesn't have any kind of power distribution analysis, is that it ends up being very favorable to powerful institutions
I'm not starting from the position of "people won't pay for a programming language", rather it's an observation based on years of observing paid programming language just fail. Matlab/Wolfram may be an exception, but it's really also the only exception that I can think of and I suspect in part it works there because it's operating in a very specific/niche market.
I'm not sure I'd refer to Evan for advice on running open source projects, given his way of handling Elm can only be described as "bizarre" at best. My reason for wanting the product to be truly open source is because I strongly support the idea behind FOSS: being able to modify it when necessary, being able to share those modifications with others, the general resistance towards enshittification this brings with it, and so on.
Open-core goes against that because the model actively depends on you offering a open-source version that's basically so useless beyond basic use that users are more or less forced to use the proprietary version. Or at least that's what pretty much every existing open-core project does.
rather it's an observation based on years of observing paid programming language just fail
Could you share what examples you have in mind here? There are lots of causes for failure in the startup world:
and so on. Lumping all of these into "people aren't willing to pay" seems like an incorrect conclusion?
I'm not sure I'd refer to Evan for advice on running open source projects, given his way of handling Elm can only be described as "bizarre" at best.
Fwiw, I also don't necessarily agree with how Evan has done things, or at least if I were in his place, I think I would've done things differently.
That said, if you look at the bits I quoted, it's about power dynamics and the challenging the often implicit expectations around open source, and whether as consumers and producers, should we change those based on who is producing the software. It's not about how to run an open source project.
being able to modify it when necessary, being able to share those modifications with others, the general resistance towards enshittification this brings with it, and so on.
None of this requires open source, does it? E.g. Sentry's BSL allows you to modify and share changes, so long as it's not for commercial use. Yes, it's not useful for non-SaaS things as such, but is potentially a good reference point.
Enshittification is really about product direction & leadership. At least in my own use, I've seen more than a few examples of closed-source software that I've paid for and am happy to continue using, or paying a subscription for.
My reason for wanting the product to be truly open source is because I strongly support the idea behind FOSS: being able to modify it when necessary, being able to share those modifications with others, the general resistance towards enshittification this brings with it, and so on.
If you intend to be able to grant commercial licenses, you need a special position anyway, so you can write the temporary restriction on distribution into the license while still giving some of the rights immediately? I think some version of QNX allowed sharing modifications to the source code to people already having the license to the original code; initial license giving a delayed right to use under another license seems to be a well-known thing to do, too.
It's difficult to have a sensible conversation about Open Source today, because it is such a powerful 'brand' that many people wants to use the Open Source label when they really have different objectives.
Not only this limits the creation of other licenses, it also creates a lot of confusion to what Open Source is.
At its core, Open Source is the right to modify the source code by the user and redistribute the code again for any purpose.
The user can be your friendly neighbour or an evil corporation. They may use it to solve the world hunger or create an atomic bomb, but the right to use, study, change and redistribute cannot be violated.
Also, it doesn't imply the code is distributed without economic compensation, so a commercial payment is completely legal. And the other way around, Freeware is something that you don't pay but you don't get the rights of Open Source.
Finally and more importantly Open Source is not a certain kind of community... many commercial software have strong communities and they don't distribute the software code.
So, I don't understand all these posts about 'funding' and 'compromising its ethics'. There are many ways of making a software sustainable, but for many people Open Source is not the way of doing it. Have no fear of doing something different.
Are there examples of where many people pay for things which are not open-source and they're glad to have that product at that price, even when there are free alternatives? Yes: Fastmail
I'm not really disagreeing with your main point, but I'm not sure Fastmail is a good choice of example here. In what sense is not Fastmail not open-source? They appear to have a good history of participating in open-source: https://en.wikipedia.org/wiki/Fastmail#Technology
This is indeed the approach currently taken by AFL++: https://github.com/AFLplusplus/AFLplusplus#license
I'm increasingly convinced that the best option for funding your own projects, if it's available to you, is to get a job at today's insane salaries and stick it out for a few years. I have multiple friends with 7 figure TC right now (all of them in non-AI systems engineering roles).
Think of it as a massive research grant with an unusually long application process :)
This only works if you can in fact work two jobs at the same time. I did that for years with Inko and eventually realized it was far too draining, hence I left GitLab (well that was one of the reasons at least).
In other words, "just do it in your spare time" isn't exactly great advice.
I wasn't suggesting working on both at the same time. Rather work on something that pays well for a few years, and then work on the thing you care about for a few decades. If you're able to land a 500-750k usd salary (which is harder to get as a remote european, but I don't think out of reach) then each year of working is equivalent to many years of grants/donations.
I think this can work if your project is going to have a bus factor of 1, with optional support from volunteers.
It seems less clear as to whether this is workable for a whole programming language toolchain.
E.g. for Rust's crates.io, I believe there were just 1-2 people for the on-call rotation for a long time, which led them to having burnout (recollecting based on some talk I watched, not 100% sure).
I want to point out, there is no need to be in Germany to be awarded a grant by the STA
Second thing, the fundamental problem is not that funding for opensource is hard. It is that noone even realise that the lower level exist. It happens that the lower level is mostly FOSS, but it became FOSS because getting funding for it at all was hard to begin with.
It seems their setup has changed a bit in recent times. I recall they only had one fund available and that required you be in Germany. Now it seems that the fellowship requires that you are in Germany unless you're willing to go with a freelancer setup (not clear what that entails exactly), while the tech fund doesn't but does make it pretty clear they focus on more established projects instead of up and coming ones ("The Sovereign Tech Fund invests in open digital base technologies that are vital to the development of other software or enable digital networking" and "We do not finance the development of prototypes.").
I took another look at the fellowship, and it too seems to exclude up and coming projects due to the following requirements:
It seems the fellowship is also more like an incubator where you learn about certain aspects of maintaining a project and less of "here's a pile of money, go maintain it", but I could be misreading things.
The tech fund has similar requirements, unfortunately.
No that was always the case. The reason for their setup was always so you can be anywhere. That is why they needed some goals and not just a "keep maintaining" grant. Because yeah rules on public spending. They exist for a reason.
Just relying on donations is something I don't see working out in the long-term as it's just not reliable enough when it comes to providing a steady income.
With Gleam I've found it to be extremely stable. Frustratingly so even, as whatever I do seems to have little impact on the amount of funding.
Do donations approach the compensation of a staff/principal engineer? From what I've seen of Gleam, it looks like you're operating at that level. So, 500-750k USD? I don't mean to put you down or discourage you, but I suspect your donations are extremely stable at an extremely low level. And for the entrepreneur-level risk you take trying to popularize a project, I think you should have the potential to significantly exceed that range.
I think this post is a good writeup of the current problems of open source sustainability. (I have a marvelous idea how to solve this, which this textarea is too narrow to contain.)
No, not even close. I make a good London wage, but it is not comparable to what I would make if I was employed as an engineer.
I think this means Gleam anomalously successful for a non-productised open-source project, which is a sad statement really.
I probably should've done a better job at including this, but with donations there generally seem to be two groups of projects: those that get little to no money, and those that get a lot. Transitioning from the first group to the second appears extremely difficult and in large part requires a lot of luck, or snake oil sales tactics.
Outside of that what you describe is I think part of that problem: donations are ultimately based on the goodwill of people and it's really difficult to increase that so you get more (or just some) money, but it is pretty easy to reduce it (e.g. by doing something your sponsors disagree with, even if it's something benign).
Basically it feels like you have to use a d20 dice to roll a 15 or higher for it to work out, then periodically re-roll to determine if it keeps working out.
I think the problem you have is that "open-source software" is just anything with a specific group of licenses. One can stick it on a script that counts the grains of sand in the desert, or generates 1 billion haiku's per second. I would unkindly translate the problem of "funding open source-software" as trying to generically solve the eternal question: "How to make other people pay for me doing whatever". The "whatever" is where the crunch is. If you start with a problem enough people find worthwhile having solved and a convincing path towards a solution, they will at some point draw their wallets. Not because they like you, but because it helps them. If you primarily scratch your own itch, the set of people interested might be just you and some drive-by commenters on the web.
A new programming language is typically something that comes into life in an environment that can afford the runway. Because it is a huge trajectory, as you don't just have to make something great - you have to follow up and need to find developers willing to risk part of their career on it taking off. And if you don't have that runway, you are better of bundling your efforts with the most like-minded language out there rather than going at it by yourself.
You've somehow gotten both NLNet and Sovereign Tech Agency wrong. Sovereign Tech Agency invests in open source infrastructure projects and has no requirement that the maintainers be in Germany. NLNet doesn't only fund large projects, and a look at their funding portfolio clearly shows that.
I understand the frustrations with the current funding landscape, there's certainly a need to better compensate maintainers for their work by several orders of magnitudes of what is happening how. To your private/public repo structure, I tried to read it several times to understand what would be the advantage there, but to be honest it just reads as source-available with extra steps. I'm not a lawyer, but my understanding is that you can't have agreements on top of AGPL that restrict a right granted by AGPL (in this case, redistribution).
Sovereign Tech Agency invests in open source infrastructure projects and has no requirement that the maintainers be in Germany.
See my comment here on Sovereign Tech.
NLNet doesn't only fund large projects, and a look at their funding portfolio clearly shows that.
I am well aware, and Inko was such a project. The problem with NLnet is that their current criteria exclude up and coming projects, and that during my past application it became clear they normally don't fund programming languages. In fact, they explicitly stated that the only reason they did fund Inko was because I only asked for €5000 (which I thought was already a lot) instead of the more usual €10 000 - €50 000 grant requests they get.
I'm not a lawyer, but my understanding is that you can't have agreements on top of AGPL that restrict a right granted by AGPL (in this case, redistribution).
The proposal is not to restrict the license of the software but rather the license of the platform it is hosted on. This is no different from say GitHub imposing additional requirements on its users regardless of what the project license is.
In other words, if you have a copy of the source code then you can do whatever the GPL/AGPL/whatever allows you to do. That however doesn't mean the owner of the project can't restrict access to the up-to-date upstream repository in some way, because that is handled through a separate agreement that is signed when you sign up to the hosting service.
To illustrate: if I host my project on a Forgejo instance I can put up some sort of requirement that says "If you host a copy of my source code your access to the instance will be revoked". That doesn't violate the (A)GPL (or any other license for that matter) at all, because it's an agreement in relation to access to the Forgejo instance and not an agreement on what you can do with the source code once you have a copy of it.
The idea is pretty simple: the product is open-source, licensed using a strict license such as the AGPL [...]
Crucially, to gain access to the private repository you must "sign" (i.e. this could just be a "Yes I agree to these terms" checkbox) an agreement of sorts which states that if you publicly host a copy of the private repository your access to this private repository will be revoked.
Quoting the AGPL: (but this clause is in the GPL too)
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.
Not sure how it'd be possible to rectify those two things!
Other than that, I'd say it's not a bad idea; it's just not something you could use the GPL for.
I tried to clarify this a bit more in this comment, but the idea is that there's a license agreement for the source code (e.g. the AGPL), and an agreement for the platform that hosts it and the latter comes with the "you can't mirror the repository" agreement. This isn't really any different from say GitHub saying "If you post illegal content on GitHub you'll be banned": you can't access the platform any more, but you can still use the source code in accordance to its license.
Aha, OK. Making a clear distinction between "license to the codebase" vs "ongoing access to updated versions" is subtle but seems clever. Someone who paid for access and then stopped paying would be well within their rights to distribute the code they received, but not while they retained ongoing access to new versions, and rights covered by the GPL do not in any way imply ongoing access to updates.
Thanks for clarifying.
There's a few vendors out there that basically threaten their customers if they exercise their right under GPL, they will cancel all support contracts. Often, those are codebases that they don't hold all copyright for. So it's not even a new idea, it's generally considered legally sketchy.
If you hold the copyright you can choose to distribute the work under multiple licenses, which may themselves be inconsistent.
You apply AGPL terms to the public version that is not current, you provide a commercial license for customers who want it, and do not offer them access to the source code under the AGPL.
TBH, I’m not sure that three months delay is really that load bearing. But some companies will pay to be able to link AGPL software to their closed source codebase, if it’s for something important. Sencha did this for ExtJS (regular GPL, since it was client side JS).
The legal argument says that you are not imposing restrictions on the code that they receive, you are imposing restrictions on their ability to access future versions of the code. You may either exercise all of the rights under the AGPL, in which case you don't get the next version but you retain the ability to exercise all of the rights to this version, or you may exercise a subset of them and then get access to the next version.
Several lawyers have had strong opinions on this strategy. They did not agree.
The other issue is that licenses such as the AGPL pass on these rights to all downstream people. And you can't restrict what they do. So you're effectively saying 'don't distribute this'.
The problem is that it's missing why people want open-source languages. They have decades of experience being locked into vendor-specific toolchains. The thing that they want from open source is either a second source or a strong possibility of a second source, including doing in-house things that integrate the tooling. That often rules out GPL-family licenses and definitely rules out anything where the project is structured to ensure that outside contributors cannot become maintainers of a fork.