I'd disagree that the problem of large organizations are different from the problems of the FOSS ecosystem. Organizations just have a financial incentive to fix them, the FOSS ecosystem does not. If mutually incompatible dependencies and security updates breaking software weren't problems for both corporate and FOSS ecoystems, these new technologies wouldn't have needed to exist. They'd just use the existing platforms.
And mind you, this is not a corporate/open source split. The burgeoning ecosystems are also full of FOSS technologies doing new and exciting things, they just don't break when a dependency updates!
>Anything I install with a package manager just works, 100% of the time
I run into issues with packages weekly. So much so I've spent engineer days purging references to system packages. It's universal too - yum, apt, pacman, brew, macports, I have to make sure nothing tries to reference packages installed outside a local working directory for an application because of mutual incompatibilities. Maybe it's because I'm trying to write software that runs on multiple targets and not use software where someone else has already spent the time and money to resolve these issues.
> I know you know this, but just to be clear, that's not a solution to the problem of "making things easier for maintainers to distribute", that's cutting maintainers out of the loop. The whole point of my focus on ecosystems is that this is something that I, as a user, don't want to happen.
They should be cut out of the loop. Maintainers don't have a right to dictate what design decisions I put into my applications because they don't think it adds value (the value is, it doesn't just run on their distro!). Another comment in this thread put it better, maintainers shouldn't place themselves in the development process.
This is a valid point but there are a few counterpoints that come to mind:
* FOSS now, while complex and intimidating, at least has the possibility of allowing for bug fixing and alteration (and having those alterations fold back into the main project) whereas proprietary software almost surely does not.
* The situation is not as dire as you suggest for many projects, especially ones that are self contained or smaller in scope. Arduino libraries can be understood and updated. There's a lot of scientific software that can have parts isolated, updated and fixed for someone knowledgeable enough.
Technical tasks like fixing headers, patching code or even using Git, are intimidating and difficult. Many projects are so complex now that on-ramps, even for highly technical users, are difficult. I don't see that changing anytime soon. FOSS at least offers people who can understand these technical tasks the possibility to take actionable response.
Convenience is absolutely something that should be prioritized but proprietary software and closed standards favor ease of use at the cost of freedom and, ultimately, longevity. My view is that FOSS is a necessary but insufficient element to a healthy ecosystem. FOSS, especially compared with proprietary software, is at least a step in the right direction.
The problem is that there are /two/ aims; one which people agree on, and the second which people disagree on.
The first is source /must/ be available and /modifiable/; on that all proponents of FOSS are agreed; exactly for the reasons you've stated.
The second is that we want /more/ FOSS software; not less. How we achieve that is essentially where people differ. The issue with big companies which contribute nothing or very little back to the ecosystem is the tragedy of the commons. Eventually, the number of people working on FOSS will dwindle and we won't /have/ FOSS alternatives or communities.
For the record, I don't even think that AWS are the worst offenders. I've worked at places which refused to even contribute bug reports or patches to upstream systems.
I just witnessed how complete ecosystems are destroyed all the time in the name of incremental updates.
Some prominent example are Python3, Gnome3 or KDE4. Every time such a transition takes place lots of people that are not full time programmers but are using and creating in the FOSS realm mainly in their spare time have to spend a lot of time to adjust to the radical changes. And every time some useful legacy software just gets lost because the maintainers don't bother with porting and just scrap the thing altogether. A permanently moving target makes FOSS that is dependent on many hobbyists just impossible. Just stop changing things all the time. FOSS is clearly reliant on hobbyists and those usually have real jobs and other things to do in their life.
The point is, an organization at that scale can solve problems at that level because they have the resources to fund development of an alternative that e.g. doesn't rely on DOS. Individual users don't have the funds to do that, or the skills to develop new features themselves, so once it's no longer supported they're equally screwed whether the software they rely on is FOSS or proprietary.
The dead simple solution to this nobody is talking about is to fork it. If you want to ensure that some random stranger (our friendly FOSS maintainer) isn't going to sabotage your product, the only solution short of negotiating a support contract with them (which some FOSS developers are not amenable to) is to bring that software internal. You still benefit from FOSS because you get a huge head-start from all the up-front work, but software maintenance going forward should be the responsibility of the user of that software, not of some random stranger.
But commercially this is unpopular because it means that companies have to actually account for the cost of maintaining a complex software stack instead of pretending all the open source dependencies maintain themselves.
Especially since FOSS pretty much runs the web, and has only grown in scope since the 80s & 90s when it was birthed.
FOSS has its problems, yes, but it's shown staying power and growth so far. I'm not so sure it's ultimately unsustainable. Mind you, I've never been a maintainer.
You're saying that they should make their software proprietary to solve the problem of FOSS maintenance. That's forgetting the implicit requirement that it should remain FOSS.
This is what is so hard for many FOSS fans to understand.
The ecosystem has only expanded to the extent big corporations are willing to invest money on it.
If IBM, Google and others had not invested into FOSS as a means to help them sell services, most likely the situation would be quite similar to the mid 80's, in what concerns software development tools.
In the markets where you cannot sell services, it is very hard to make a living from FOSS.
You could have the exact same problem with FOSS: a piece of software that the organization relies on that's ancient, crufty, and barely maintained and the org won't invest in the resources to get rid of the technical debt.
Likewise. This is precisely how it happens, and no amount of wishful thinking about how companies are going to insource the maintainance of some major FOSS package is going to change that. It simply will not happen that way, companies want to focus on their business and not on the vast amount of tooling that underpins basic functionality, they'll just use another supplier.
I'm also a huge FOSS nerd and it makes my personal AND professional life a lot easier, and I totally agree with you.
If the problem is that the ruthless winner-take-all nature of professional environments is destroying open source, then you need to fix both problems, not one of them. Trying to fix only one won't help.
Beside the maintainer painful time, I find it interesting. We always see that FOSS is about freedom, if you don't agree, you can pick your own, fork, adapt ... except when a change impacts too much. The whole ecosystem is now changing forcing people to accept something too different, that's how things ends up emotional.
I don't think that's a failure of FOSS, just a scoping problem. Open source is a good thing and a contributor to a strong ecosystem, but it's not sufficient by itself.
Most big FOSS projects do have corporate sponsors, but what about their dependencies? And the dependencies of the dependencies? Eventually you end up with a situation like what you have with OpenSSL or NTP, where an obscure but important component is owned by someone who has a day job and can't properly look after it.
Yes, because it’s been twenty years of FOSS with zero DevEx. People ran back to corporate walled gardens. Which is just a rephrasing of what I said above.
This isn’t “users” and corporations making a mess of the software world together. It’s all of us. As you guys are so fond of telling everyone else, if you don’t like it, change.
Historically FOSS has been far more resistant to this cycle; not all FOSS projects, but many. It's much easier for FOSS projects to just say no, and they can spend years or even decades refining things. In the commercial world you can never say no. Not only that, but you have to constantly add features.
Now that corporate interests dominate in many corners of the FOSS sphere, this benefit of FOSS is diminishing. Which is a shame, because it's a big reason why FOSS was so successful, and why so many old commercial projects collapsed under their own weight, even though they always had more features than their FOSS counterparts and thus theoretically should have only grown their user base.
> This seems to be less and less the case. Because companies are more ruthlessly focused on the bottom line, and don't think they can afford to have anyone working on something they don't own or that might help a competitor? I dunno.
For one, if one's open source product is so good that BigTech wraps its software around it, then that's a cause for validation and celebration. For example, it is pointless for the Rust community to bemoan Google's use of Rust to improve ChromeOS' security; or for Dr. D. Richard Hipp to bemoan pretty much every company for building money making software around SQLite.
Besides, like Bryan Cantrill points out in the blog post I linked to from above, it is often trivial for BigTech to expend effort to re-implement the API surface (MongoDB -> DocumentDB) or even the rewrite whole software (MariaDB -> Aurora) if that's what they need to do to compete with anyone's FOSS / source-available offering.
> There's possibly "companies with FOSS products" that arne't "FOSS companies".
Of course, I am not saying FOSS is the one true way when just recently tech companies like Zoom and Snowflake have demonstrated the potential of proprietary tech; but just that FOSS will commodotize your core, may be half-heartedly, or even half as effectively, but it will happen and there are business opportunities to be built around it. In fact, FOSS is one of the last few avenues left to take on BigTech, as far as technology is concerned.
When I say FOSS, I don't mean the kind of throw-all-commits-over-the-wall, superficial-community-engagement FOSS Google does with Android and Chrome. Google can do so because they have got the money to keep funding "an open source loss leader". For any other upstart it'd be suicidal to keep such an iron-grip on their FOSSd codebase (like Elastic will find out in the coming years). The right approach for such upstarts is to create a Foundation around the tech (k8s) or donate to one (Cloudera / Hortonworks), and generally try to really rake in the benefits that being open-source brings.
And mind you, this is not a corporate/open source split. The burgeoning ecosystems are also full of FOSS technologies doing new and exciting things, they just don't break when a dependency updates!
>Anything I install with a package manager just works, 100% of the time
I run into issues with packages weekly. So much so I've spent engineer days purging references to system packages. It's universal too - yum, apt, pacman, brew, macports, I have to make sure nothing tries to reference packages installed outside a local working directory for an application because of mutual incompatibilities. Maybe it's because I'm trying to write software that runs on multiple targets and not use software where someone else has already spent the time and money to resolve these issues.
> I know you know this, but just to be clear, that's not a solution to the problem of "making things easier for maintainers to distribute", that's cutting maintainers out of the loop. The whole point of my focus on ecosystems is that this is something that I, as a user, don't want to happen.
They should be cut out of the loop. Maintainers don't have a right to dictate what design decisions I put into my applications because they don't think it adds value (the value is, it doesn't just run on their distro!). Another comment in this thread put it better, maintainers shouldn't place themselves in the development process.
reply