>If FOSS was broken, the internet as we know it today wouldn’t exist; the countless marvels of technology that we take for granted and techno-economies that thrive on them wouldn’t exist;
I guess I just vehemently disagree. Nearly all of the early open-source software that made the internet possible was produced in universities. The only reason it was sustainable was because it was professors being paid by the university, or students doing it for free. Implying that means it's viable for all these other projects that were created and maintained outside of a university setting is just not accurate. There's also this fallacy of: it worked this long so it will continue working forever.
For me the long and short of it is: the only way I can foresee open source working in the way the purists want is if there is a universal basic income. SOMEONE has to pay the bills, and as we've seen time and again, hoping to feed your family on donations is a fool's errand. With UBI, artists of all kinds (including developers) can pursue things that would otherwise be impossible. Without it, we're left with the constant push and pull of people either burning out maintaining stuff in their spare time, or hoping a given corporate maintainer wants the same features and functionality as the community.
In rebuttal I'll paraphrase a little from Paul Ramsey (maintainer of 20-year open source project PostGIS)[0]
His basic view is that Open Source is the dominant model today, but tension comes as very little of the value produced comes back to the community that creates this value. He argues this will always be 'the bare minimum' by virtue of economics, but that if something important slows down too much someone will put some money in it. But this is a model that operates and works. It is borne out by his history in postgis, which is maintained by a small number of people mostly in moderately-profitable service companies, in the red-hat mould. He's concerned about value being captured by cloud companies though who frequently don't employ open-source maintainers however. Some of this is further expounded in another talk by him here [1] (slides at [2]) on the future of open-source where he is very bullish.
This personally rings true for me. My company is getting literally billions of dollars worth of value from a couple of applications (one of which I created and maintain) built upon the foundation of Postgres and PostGIS. And we benefit immensely from active development of it: PostGIS version 3.1 released a new more efficient overlay algorithm which probably saves us $5k a year in compute costs alone, and untold thousands with the ability to deprecate a hacked house of cards that was ready to crumble.
And yet every time I have mentioned to my management that it would be great if we could take 1% of our consulting budget and funnel it towards PostGIS, they respond almost bewildered...why willingly pay for something that we already get for free? It's frustrating and I have no idea how to remedy it.
I can’t speak to this directly, as I haven’t had to deal with this at the management level.
My thought though is that this is preventative care. This is going to the Doctor regularly so you don’t get surprised when something goes awry. Likewise, making sure the OSS project you’re totally dependent on doesn’t suffer a catastrophic failure or abandonment is a worthy investment.
> why willingly pay for something that we already get for free?
That pretty much sums it up.
It's why money is unlikely to flow from businesses into open source projects unless the developers are employed by those businesses, in which case the question often becomes "why are we paying to develop software that will be given away free to our competitors?"
Too true. If you are a dev, ask yourself how large your budget is to distribute for projects that are among your business critical core dependencies, but are developed externally under free software licences. I am not blaming you if you don't even know the word budget.
Of course the best business strategy under current rules would be to let other companies pay here. That would net you a competitive advantage. Perhaps GPL was right in the end and companies need to be forced to either contribute or pay for commercial alternatives. Maybe some would learn how expensive software really is and that it requires constant investment of maintenance as most other products do as well.
universities are going to continue to exist and students will be attending them. what exactly suggests that this will not continue forever?
of course FOSS has always depended on people who had the resources to work on it. in the beginning this was only universities and as FOSS got more popular more funding sources appeared.
the problem that we are facing is not one of funding. there is plenty of funding available. the problem is a generational shift of that funding.
people who used to be able to afford working on FOSS no longer can because their life changed. they are no longer students, they have a family and so on.
FOSS development will continue. the fallacy is to believe that an individual contributor will always be able to keep contributing for the rest of their life. we need to acknowledge that unpaid FOSS contributions are limited to a few years of an individuals life. and after that they need to move on. and most do. those that didn't move on but continued contributing were those who managed to find additional funding sources.
the problem and the difficulty is that we get more and more software that is not new but needs to be maintained. most of those using their own funds will want to work on their own new software and not maintain someone elses.
so the questions is not how do we fund FOSS development, but rather how do we fund FOSS maintenance. that is the new thing that we didn't have to deal with a few decades ago
There are a lot of people who are very good at coding who don't care for high salaries. Despite mainstream pop being the most profitable, many musicians pursue niche genres.
This still doesn't make UBI relevant to this discussion. It's already fairly trivial for a talented SWE to make UBI-level income working 10 hours a week by picking up software contracts here and there. Eng already have access to the levels of income that UBI would provide, with plenty of time left over to dedicate to open source, and yet this path is relatively untrodden.
Plenty of engineers (myself included) already leverage the flexibility and surplus pay of the industry to opt out of the "40 years of 40 hours" ratrace. But they do so to varying degrees, and evidently aren't spending enough of that surplus on OSS to fix the problem we're discussing.
I don't see what UBI would materially contribute to this dynamic.
If picking up software contracts here and there is consistent enough for you to count on then it's either already a full time job or the end result of years of networking and experience.
UBI would let people devoted to a subject pursue only that.
Sure, I'm not suggesting that it's as easy or as comprehensive as UBI, of which I'm a strong and longtime supporter.
I'm saying that the existence of this weaker alternative is illuminating: there's a non-trivial subset of the population for whom this is an option, including many OSS maintainers, and they don't seem especially jazzed about the idea of making an income that's 10% of what their skills could bring in.
Personally speaking I wouldn't see that as an alternative. Just doing a little above-the-table consulting work comes with periodic obligations. Why make a fraction of your income to still deal with the distractions?
I think you could just ask retired people who volunteer about the subject and get a good take on it.
> It's already fairly trivial for a talented SWE to make UBI-level income working 10 hours a week by picking up software contracts here and there.
What about less talented ones that can still contribute, but need to work 20 hours a week? Or 30 hours a week? Or gasp 40 hours a week?
> Eng already have access to the levels of income that UBI would provide, with plenty of time left over
No. There isn't plenty of time left over. Moreover, why wouldn't I want to work on something full time, and not in my "left over time"?
> Plenty of engineers
Which means: not even the majority of engineers.
> I don't see what UBI would materially contribute to this dynamic.
"I don't see how giving all engineers, and not some percent of engineers, the option to pursue projects they like would materially contribute to this dynamic".
This is a textbook Gish gallop, so I'll avoid the trap of responding point-by-point and address all the irrelevance and inaccuracy of your comment simultaneously.
The premise I responded to was that UBI was the only way to free up OSS maintainers, and that they wouldn't care about the lost hundreds of thousands of income if their basic needs were met. My point was that if this was the case, you would already see the low-hours-per-week strategy in place as a non-trivial factor in OSS funding. And yet you don't, because the foundational assumption is incorrect.
Also note that 10 hours a week is hyper-conservative. The population of people maintaining OSS projects are more than capable of pulling eg $70/hr for contracts[1], especially at the low volumes we're talking about. To reach UBI levels of income at this rate would require _1.5 hrs/wk_ of work, or 6 hrs per MONTH. This allows you to drop the required talent level pretty low, despite already pulling from a population that's selected for "ability to maintain a useful OSS project".
[1] also very conservative: I wouldn't be surprised if a median estimate came closer to $150/hr for your average OSS maintainer
> This is a textbook Gish gallop, so I'll avoid the trap of responding point-by-point
And this is textbook avoiding an answer
> My point was that if this was the case, you would already see the low-hours-per-week strategy in place as a non-trivial factor in OSS funding.
Yes, and your point is based on the flawed premise that there are many engineers who can do that.
> The population of people maintaining OSS projects are more than capable of pulling eg $70/hr for contracts[1], especially at the low volumes we're talking about.
And you pulled this estimation out of which crevice?
> To reach UBI levels of income at this rate would require _1.5 hrs/wk_ of work, or 6 hrs per MONTH.
Ah yes. Because there are plenty of jobs which will gladly pay you for 6 hours of work a month.
I'm not sure if we have misaligned expectations of how much income a reasonable UBI is likely to provide, or of how much income you can make contracting.
The range of incomes I've seen from UBI proposals range from 10-20k/yr, with the high end generally applying to people with 2+ children. This is partially constrained by political reality, but politics aren't the only thing putting an implicit ceiling on the amount of UBI (as a reductio ad absurdum, consider why we wouldn't just give everyone $500k a year and all just retire onto our yachts).
Taking the midpoint, $15k pa means $1250/month, which means you'd need to make _$30/hr_ on software contracts to match UBI. You don't think it's plausible to fill the pipe with a 10-hr week of contracts over $30? Bear in mind that this means you'd need 3 hours a week or _12 hours a month_ with a more realistic (yet still quite conservative) income estimate of $100/hr, and that the type of person who's currently maintaining an OSS project is already increasing the quality of the talent/income potential distribution.
Sure it's _plausible_. I even used to think that kind of thing was _possible_, long ago.
But I've come to the conclusion since that it's virtually impossible to "scale down" your income like that. And that you can't actually choose to accept lower pay to obtain more options (in software anyway), contrary to highly plausible economic theories.
Do you have any real world evidence other than that it sounds plausible?
I don't think I currently do, but that's sort of my point: people don't want to do this, for reasons ranging from the income left on the table to the type of work not being fulfilling.
Note that both of these are handled by the premise, which was that OSS maintainers would be materially unblocked to focus on OSS by a UBI-level income. This assumes that there are a non-trivial amount of OSS maintainers that don't care about the couple hundred thousand dollars they're forgoing, and that they have at least 30 hours of their week filled with fulfilling work.
Tangentially, I match the motivations you're asking about, but not the exact implementation. I spent the early half of my 20s with a far higher income than I wanted, and definitely didn't (and don't) enjoy working 40 hours a week. Given how motivated I am by intellectual challenge, I came to the realization that it was damnably hard to find a job that would give me a suitable intellectual challenge but not require me to be full-time. I "solved" this by interleaving 2-3 years of working with 1-2 years of travel/personal development a couple of times during my 20s.
That’s probably how most people do that. I have to admit that programming less than full-time was hard for me, because I tended to go flat out. And then burn out, LOL.
Only if you're incapable of making basic inferences and uncomfortable with thinking about distributions and error bars instead of forcing everything into artificial certainty.
If, like many people, you need things shoved into an imaginary concrete, low-dimensional, binary box: "the type of person maintaining an OSS project can trivially make >$30/hr[1] on 10 hrs of contract work a week". If you still think this is too subjective to infer anything from, enjoy your onanistic "nobody can ever really know anything maaaan" perspective, but it's not really relevant to this conversation.
[1] See another comment of mine in this thread for back-of-the-envelope math
> …the only way I can foresee open source working in the way the purists want…
Well the point of open source is it works however the person opening the work wants. There’s a license compatible with every philosophy out there. Take your pick.
Open source isn’t broken because it can’t really break at all. For something to break it would have to have a concrete form to begin with.
Agreed. It's only broken if there were some ideal Utopian open source world that we were falling short of, where if only everyone can work out some issues, then that world will come into existence.
When people are growing up it's easy to get swept up in ideas like, "if only everyone saw things the way I did, everything would be perfect and so much better than it is right now".
There will always be lots of conflicting ideas about how software should be developed and distributed and so far none of them have proven so effective that all of the others have fallen by the wayside. IMO the best anyone can do is advocate for whatever makes the most sense to them, but not make the mistake of thinking that anyone has all the answers.
Even if the licenses are abused, there will still be free and open source software. It's a beautiful idea that won't die as long as there are tinkerers in the world.
> Nearly all of the early open-source software that made the internet possible was produced in universities. The only reason it was sustainable was because it was professors being paid by the university, or students doing it for free.
I'm surprised no one mentioned that there was no personal computer. Where else would you get a computer to develop free software back then?
> For me the long and short of it is: the only way I can foresee open source working in the way the purists want is if there is a universal basic income.
I suspect I'm a "purist" by your measure, and I disagree completely. University professors, students and volunteer contributors/maintainers will continue to exist going forward. Nothing has to change.
The problem is that this doesn't "scale" at the rate demanded by corporations, and corporate engineers[1]. The problem is not with FOSS - it is on the voracious consumption side. I suspect the volunteer vs corp usage will follow the Predator-Prey cycle, with volunteers being the prey. When the predator population grows too large, it will set off events that will lead to its population collapsing to a sustainable level. The onus is on startups/medium & large corps to help scale FOSS - not UBI or the like where the corps continue to freeride (which is fine, to a point)
1. Disclosure: I'm also one, in addition to being a volunteer contributor. I volunteer as a way to give back to an amazing project, and I earn a salary that meets all my needs.
In my opinion, corporations and govt entities should switch to a model in which they don't purchase software but instead have internal staff work on the FOSS that's used in the group.
This could help the FOSS ecosystem while removing the profit incentives that people have to make shitty pointless web apps. Although I'm sure some shitty pointless web apps will still get made, I think this could shift the dynamic of the software production ecosystem for the better.
> Nearly all of the early open-source software that made the internet possible was produced in universities.
Well... BSD unix was. Unix itself was Bell Labs, the original TCP/IP spec was done by DARPA contractors (mostly BBN). HTTP was CERN but the breakthrough "browser" product was venture funded. GNU was a private organization, though RMS's office was provided by MIT for years and years. Linux obviously was an established community effort long before anyone with deep pockets showed up. Post-90's "corporate" open source has emerged basically everywhere, with Google and Intel being big early players (Facebook and Microsoft have been late to the game but done very well for themselves too).
I think if anything what this proves is that "Open Source" is going to pop up basically anywhere it's allowed to, and that any pronouncements about where it "really" came from are probably not informative.
UNIX was only free beer because AT&T wasn't allowed to sell it initially, the lawsuit against BSD and forbidding the Lion's commentary came rather fast as soon as they were allowed to take commercial advantage of their research work.
Sure sure, but my point was really that all nitpicking aside, Open Source is everywhere. Given the opportunity, engineers everywhere will share their work with others and build on that shared work to do more stuff, then share it.
An argument from a frame of "Open Source only succeeded because ..." just seems obviously wrong to me. If not ITS then Unix. If not BSD then Linux. If not Mosaic then Chrome. If not gcc then clang. On and on. Opportunities for success are everywhere, nowhere is a critical path. Take any hero out of equation and there's someone else standing behind her to repeat the work.
Linux only evolved beyond a hobby project, because IBM, Oracle, Compaq, Sun decided to cut down costs on their own UNIX (thus we are back again into corporations and their relation with FOSS), and yet many still have to reverse engineer hardware capabilities despite the big names involved in it.
clang is the more recent example, it is becoming visible how it is lagging behind other compilers in C++20 support, not everything is landing upstream as it used to.
Again, though, Linux needing that stuff[1] doesn't explain why BSD happened, which needed different stuff. clang needed other stuff still. But... they all got their stuff!
It's a Jurassic Park point, really: life will find a way. Free software beat the world already, and it really strains logic to argue that that only happened because of a giant phonebook filled with special advantages for every individual piece. The much simpler theory is that it was clearly going to happen regardless.
[1] In fact that's really not the way it happened anyway. Linux on whitebox PCs was dominant in the early internet world for pure cost reasons, long before any corporate names got behind it, and that leveraged it into datacenter environments where it became clear people were willing to pay real money. Red Hat's IPO was well in the past and Google had launched on custom Linux motherboards long, long before Oracle or IBM got serious about the OS.
Dominat where? We were all using Solaris, HP-UX and Aix boxes when real money was at play.
In fact, after university during the 1990's (where we initially were on DG/UX), it was only in 2003 that I first used GNU/Linux in production as CERN was moving away from Solaris into Linux and the first alpha releases of Scientific Linux started to become available on the institut.
And even there, most researchers were moving into Windows or OS X on their local workstations.
All of the commercial Unix vendors had as their fundamental technical goal user lock-in, while Linus had technical goal of performance + stability and maybe popularity.
For some types of software, we really do not want students doing it, for free or otherwise. There are whole classes of software, like database engines, that are non-obvious and require many years of real-world domain experience before it is plausible that someone will design a competent, scalable architecture and implementation. If open source is going to run critical infrastructure, we don't want naive and inefficient software design but that is frequently what we get; this isn't a criticism of the people that create many of these projects, more the process in practice and our expectations of it.
UBI is not a solution because it would, at best, pay poverty wages. People with the skills to be effective core contributors also have the skills to be paid much, much more for their time. Few people, and definitely not enough, are going to sacrifice the living standards of themselves or their family for some ideal of OSS.
There are strong adverse incentives that make it improbable that the people designing and building OSS are who we as users of OSS would want to be in that role in an ideal world. This has been getting worse with time. The risk for OSS is that those adverse incentives are never addressed.
> For some types of software, we really do not want students doing it, for free or otherwise. There are whole classes of software, like database engines, that are non-obvious and require many years of real-world domain experience before it is plausible that someone will design a competent, scalable architecture and implementation.
Of course as with all things the situation is more nuanced than this. Since you mention database engines we should keep in mind that without Stonebraker and 39 of his students[1] there would be no Postgres. Yet without incentives and many years of contributions from professionals (and students who would become professionals) we would not have PostgreSQL. A healthy system has a place for contributors of all levels of experience.
Database development has changed quite a lot since then. When I first started working on databases in the 1990s, two things were true that made it much easier for relatively inexperienced developers (like myself at the time) to produce a reasonably good result. First, the state-of-the-art implementations at the time were incredibly well-documented in an accessible way and the academic literature also reflected those designs. Second, the implementations were relatively simple and straightforward; you did not need esoteric systems knowledge and design theory to write code that was competitive with other implementations. The most complicated thing you had to worry about was lock structures and concurrency control. Not only were there relatively simple examples to copy and study, the gap between those examples and the state-of-the-art was pretty small.
Neither of these is true today. The design of state-of-the-art implementations are often poorly documented; the computer science has evolved radically since the 1990s with significant gaps in the literature; competitive implementations require real expertise in silicon architecture and Linux kernel internals, you can't just write something obvious in C and expect a good result. And that's without even getting into difficult topics like distributed execution, parallel orchestration, scheduler design, etc that we didn't have to worry about back then.
I'm not sure I'd be able to bootstrap the necessary expertise to build database engines today like I did back then.
* First, state-of-the-art was accessible and well-documented with designs reflected in academic literature.
* Second, implementations were relatively simple and straightforward.
* Neither of these is true today.
Again the situation is more nuanced than this. Before the web systems were expensive, resources were scarce and connections to research were critical. Now anyone with time and a laptop can watch youtube lectures, read recent research, clone a repo and join the party. Different things are hard now. Such is the way of competition. Hardware and economic trends move the state-of-the-art quickly. Ideas offering competitive advantage are rarely documented to the degree one may like. But they do find their way to entrepreneurial practitioners and students. Their time, energy, attention and motivation builds new and better systems and we should welcome their efforts when they advance open-source projects.
> I'm not sure I'd be able to bootstrap the necessary expertise to build database engines today like I did back then.
Far more private money went into open source than the military put it via professors. Almost of the big successful projects would be viable without significant private investment into them.
You're simply wrong in a way I can't succinctly summarize historically; you really have to get to know the spirit of the people who made this stuff. But FOSS is the difference between the VERY free and open (at least optionally, if not in practice, but like, basically anyone can put up a website and do anything on it) internet we have vs. what would have happened, which probably would have been slight incremental improvements in phone and TV. More" on demand," but damn sure no Youtube.
Having worked with people in industry who understand the point and value of giving back this is a little naive I would argue.
A fraction of some talented persons time from say HP is probably worth 100x first year developers who aren't paid to understand the tools the company is using.
To turn your argument on its head how much would every company have to invest to build a modern website from complete scratch in isolation? Then think why do that when you can effectively spread the cost?
Both approaches have ups and downs but I'm not sure the "someone always picks up the cost" isn't anything other than a statement of realism. It is a good reason to explain why nobody just works on a project in their basement for free and do nothing else, but doesn't role out being able to do this if responsible companies pick up a fraction of the tab they should be paying via donations.
As others have said a huge amount of the value comes from support, community and the contributions from many people, be they working on the same tools for a product they sell, to make a product or service they plan to sell or to scratch that itch on that project in their spare time they're playing with.
I dont understand how exactly is open source supposed to be broken. It is accepted and respected these days. There is tons of it too.
If does not produces flawless miracles, but commercial software is not flawless either. The log4j bug has impact it has literally because open source was successful.
OSS or Free software is not broken. To claim that it's broken, there must be some outspoken intent that has been violated. For example that said software should be used by big mega corps for free and that there should never be any bugs in it. That is not the case, thus it's not broken. Most free software is made to scratch an itch. Some projects grow big and serious. Some is abandoned when the original author grows tired of it. A responsible organization would be expected to take the support responsibility for any free software that it uses as none is included in the price ($0). Or pay another company to offer that support if the task is too big. If you don't agree to these terms, refrain from using such software in your product.
Can’t speak for the GP, but from my perspective: misaligned incentives (financial and technical), poor documentation, buggy important edge cases, toxic attitudes, egos, and so on. In short: it’s broken the same way any other development is, except it also includes the extreme end of economic exploitation.
I (obviously) can't speak for everyone, but in my own case "toxic attitudes" tend to be a symptom of abuse at the hands of a variety of far more "actually toxic" people. People who wrongfully expect people like me to be their free whipping-boy and tech-support "guru" despite them being a total stranger who's never done anything to benefit me. Then when I refuse to help an abusive and entitled piece of shit, I'm labeled as "toxic" and "gate-keeping" and any number of other (often outright hateful) things that I've never been, but am learning to be because I'm sick to death of unjustified and unjustifiable abuse. Want "toxic"? Keep abusing people who are literally only trying to do and share a little good in the world (for themselves, and others). See how things go when there's nobody left on the planet who even wants to do good anymore, because it's literally more trouble than it's worth to do anything positive or beneficial in this life. People love to bandy that "toxic" label around when speaking of the Linux community, but almost nobody ever considers that toxicity (in the rare cases that it's even actually real, and not totally made up in some Win-Troll's head) might have some actual cause behind it, such as y'know… bein' sick and tired of abuse at the hands of actually and truly toxic people.
That all sounds like project specific issues. A lot of FOSS projects are exceptionally well documented. The same with the attitude, some are wrose, some better. It doesn't seem like this is specific to FOSS licensing.
I work with a company that contributes to some open source but most of the code is closed-source.
I feel that the reason many enterprises pay for the software is that when there's an exotic bug that only happens with LDAP with a certain cypher being used, they know it will get fixed (because it's funded by support/maintenance fees).
While there may be exceptions, I just don't see OSS contributors going out of their way to fix such edge cases.
So perhaps the solution for some open source project issues might be to not-opensource it.
Point of FOSS is that you can fix exotic issues yourself, at your timeline and perhaps share your fixes with the original project, if you also want other people to distrute the fix for you via some standard Linux distro.
That's the main freedom you get from FOSS. FOSS != free support. It's empowering.
I just feel like we can do something better than a this model. If there’s UBI than the next steps is also owning the production. That is a slippery slope. Consolidated power is not very Open Source.
But each according to their needs in the end devolves into each according to their abilities. There was never a need for computers, there was never a need for the internet. I would say that it is tough to say whether there is any need for a person to live. On the other hand if you let people define their own needs, you end up with the scenario where one needs 1 billion dollars.
That citation appears as irrelevant completely to the topic.
If you want more relevant citation then this: "A journey of a thousand miles begins with a single step" (C) Lao Tzu
For that matter I would say that first major step to real FOSS was made in 1917. But it was too early and shouldn't that brutally enforced. Evolution is the only reasonable way to get anywhere in such complex systems.
Relevant fact: all hardware and software in USSR was Open Source. Any non-trivial product must be and was accompanied by full schematics. Software sources must be printed out, etc. By law.
"That citation appears as irrelevant completely to the topic."
The point was, that marxism as a theory is only a plan - and that plan did not really worked out in reality so far.
And if you want to paint the USSR in a golden FOSS picture, well I would suggest talking with people who actually lived there and were not in a privileged party position. And it would be news to me, that the USSR published their tank, aircraft or rockets schematics.
"Marx specifically avoided any such planning and explained why."
Where did he say so?
Because marxism as I know it, surely is and has a plan. A plan to completely reshape society and economy. Dictatorship of the proletariat ... until the state of real communism is achieved.
Can it be, you only heard of the capital, but not the communist Manifest?
Marx did use the phrase commonly translated "dictatorship of the proletariat." But he certainly did not publish a plan for how to achieve it.
He did the exact opposite, he explained why he thought such a plan should not be published.
> Can it be, you only heard of the capital, but not the communist Manifest?
The Communist Manifesto -- which is a statement of the Communist Party rather than Marx, though he wrote it -- includes a political platform, but read the platform and you see, it is mostly just social democratic reforms. At most, it approaches "revolutionary reform" (i.e., reforms meant to make revolution possible). It certainly isn't a description of the "dictatorship of the proletariat." You won't ever find that and cite it.
I guess I just vehemently disagree. Nearly all of the early open-source software that made the internet possible was produced in universities. The only reason it was sustainable was because it was professors being paid by the university, or students doing it for free. Implying that means it's viable for all these other projects that were created and maintained outside of a university setting is just not accurate. There's also this fallacy of: it worked this long so it will continue working forever.
For me the long and short of it is: the only way I can foresee open source working in the way the purists want is if there is a universal basic income. SOMEONE has to pay the bills, and as we've seen time and again, hoping to feed your family on donations is a fool's errand. With UBI, artists of all kinds (including developers) can pursue things that would otherwise be impossible. Without it, we're left with the constant push and pull of people either burning out maintaining stuff in their spare time, or hoping a given corporate maintainer wants the same features and functionality as the community.