Of course it can help. For example, when Oracle bought MySQL, it was forked and we got Maria. When Emby pissed off people, it was forked and we got Jellyfin. There are plenty of other examples.
Whether or not you like these products, the point is that open source gives the community the ability to continue development if the original project gets bought and/or otherwise changes its philosophy for the worse.
Except you can fork the last open source version and continue as before. See ... mariadb?
Forking is easy. Maintaining a fork, keeping the quality and innovation alive, and the community involved is hard.
There are many more failed forks than successful forks. So saying "you can fork" is utopist at best. Sure you can, but you'll probably be the only one maintaining it and it will slowly rot as there won't be a community to keep it bug-free and compatible with new hardware/standards.
Are those really the exception? Do we have examples of large projects that made a monetization TOS change and didn't immediately get forked?
The only one I can think of is Docker maybe?
LibreOffice is doing pretty well compared to OpenOffice:
* https://news.ycombinator.com/item?id=37645160
EGCS was eventually merged back into GCC (or rather it became the new GCC?). I don't pay attention recently, but XEmacs was/is pretty active along with Emacs.
It's hard, but the FOSS model has a long, successful history at this point.
With a proprietary solution, you might get A, but you have zero hope of B. It's an objectively worse proposition.
You do need to innovate on the foundation if you plan to maintain your game long term: new consoles support, new hardware support, obsolescence of old platforms, etc...
You do not need to innovate if you plan to let your game rot and become unplayable 10-20 years later.
Yes having a FOSS solution for the foundation would be ideal. That was not the topic of the discussion. The topic was about the claim "we can fork if we're not in agreement".
No, as a game developer you won't be forking and maintaining a game engine. No a "just fork it" is not a viable solution in the majority of cases as you need a strong community behind you and your fork to make it last long term and not rot after 2 weeks.
The examples of successful forks are anecdotal, they are the exceptions not the rule. This is survivor's bias.
Oh but you do. Unless you want to be one of those 10000 asset store games that no one buys.
> You do not need to innovate if you plan to let your game rot and become unplayable 10-20 years later.
They stop maintaining games in 2-3 years, not 10. The few exceptions that maintain sales forever are just that, exceptions.
Are you thinking of multiplayer free to play games? Those aren't games, they're predatory grinding treadmills and I don't care what happens to them.
Don't worry about it. Other people will literally solve that problem for you if they like your game enough no matter what you do. They won't even bother asking for permission.
True, but there's no rule that says you have to update when they do. You can just stick with what you have until/unless you find or create another option.
I wonder if it's less about the source code here but about the people involved, and how to prevent a consolidation of capital and power in the hands of greedy financiers. Maybe developing the projects as nonprofits (like Blender or Mozilla), or at least employee co-ownership rather than VC money or institutional funders?
If only the laid off FAANGers could pool their fat checks and start up something employee-driven and not subject to outside influences, in the style of Valve or similar. And preferably with legal protections against "selling out".