Linux

There's a few different things getting wrapped in here together, so let me break down my take:

1. Licensing - if you intend to only use FOSS software, it wouldn't matter if a corporate/proprietary version of something exists or not. If you intend to release something and make it free, you would need to include only license-compatible libraries. I don't see why Microsoft having a proprietary version of something that is better would be a problem, because that's not the focus of your goal of releasing something for free. Similarly if you start a company and bootstrap a product off of open libraries, you will steer towards projects that are license-compatible. Whether there is a better version is irrelevant.

2. Scope of license - Your comments seem to focus on larger product-complete projects. You mentioned Paint.net as an example. So say Adobe forks GIMP, and drops a bunch of proprietary Photoshop libraries into it to make it beefier or whatever. Similar to the above, people who intend to only use FOSS software still wouldn't adopt it.

3. Death by license - there have been some cases where FOSS project maintainers get picked up by corporate sponsors and sort of "acquired". This is on the maintainers to make that choice of course, not the community, and contributing members of that community have every right to be pissed about that. Those contributing members also have the right to immediately fork that project, and release their own as a competitive product. Redis vs Valkey, and Terraform vs OpenTofu, are examples. Some people flock away, some people don't, but in most cases ts a guaranteed way to turn the community against you, and towards a fork of said project. Happens a lot.

I think what you're not seeing here is that these companies buying out projects really don't intend to put a lot of money back into them after they get their bags of money. Whether or not people continue to use the originals is less important than the forks being available and supported. If companies believe in the project, they kick in PRs to keep things rolling along because they need that particular part of their stack. I myself am a maintainer in multiple public projects, and also work with companies that contributed to dozens of different public projects because the products they make revolve around them: everything from ffmpeg, to the torch ecosystem. You find a bug you can fix, you submit a PR. That's what keeps this ecosystem going.

Smaller scale startups to mid-sized companies contribute all the time to public projects, though it may not be apparent. Larger corporations do as well, but it's more of legal thing than an obligation to the community. Rewriting entire batches of libraries isn't feasible for these larger companies unless there is a monetary reward on the backend, because paying dev teams millions of dollars to rewrite something like, I don't know, memcache doesn't make sense unless they can sell it, and keeping an internal fork of an open project downstream is a huge mess that no engineer wants to be saddled with.

Once a public project or library is adopted, it's very unlikely to be taken over by corporate interests, and it's been that way for almost fifty years now (if we're going back to Bell and Xerox Labs). Don't see that changing anytime soon based on the above, and being in the space and seeing it all work in action. Though there are scant cases, there's no trend of this becoming more prevalent at the moment. The biggest threat I see to this model is the dumbing down of engineers by "AI" and loss of will and independent thought to keep producing new and novel code out in the world.

I suppose it's true that neither would have been called feature complete by its authors, proprietisation is much more likely when there is still a lot missing. But I would still caution against thinking that having all the features you need means you're immune to it.