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".
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.
Obligatory relevant Godot-related links:
* https://docs.godotengine.org/en/4.1/tutorials/platform/conso...
* https://godotengine.org/article/godot-consoles-all-you-need-...
* https://w4games.com/2023/08/06/w4-games-unveils-w4-consoles-...
Couple of Godot-based games available on console:
* https://en.wikipedia.org/wiki/Cassette_Beasts#Development / https://godotengine.org/article/godot-showcase-cassette-beas...
The fact developers have been able to ship Godot games on console doesn’t help much unless those developers are willing to share whatever proprietary engine-to-console-SDK-interface code they wrote.
Unity and Unreal, in contrast, will happily license equivalent code to you.
I think this section of the second Godot link is worth pulling out and quoting:
> … it is impossible for Godot to include first-party console support out of the box. Even if someone would contribute it, we simply could not host this code legally in our Git repository for anyone to use.
> Additionally, it would not be possible to distribute this code under the same license that Godot uses (MIT) because this is in direct conflict with the proprietary licenses and non-disclosure terms that console manufacturers require to have access to the knowledge needed to write this code.
> To make it simple, it is not possible for Godot to support consoles as an open source project.
That was my intention.
> The fact developers have been able to ship Godot games on console doesn’t help much [...]
Well, it demonstrates that it's entirely possible, either via DIY, hiring an in-house specialist or contracting to one of the companies who has already implemented the functionality.
> [...] unless those developers are willing to share whatever proprietary engine-to-console-SDK-interface code they wrote.
The third party porting companies are willing to "share" that code--for a fee. They could also do the same for free as long as they respect the terms of their contract with the console platform (which probably is along the lines of "don't disclose anything to people who don't also have a contact with the console platform").
A group of companies could even cooperate on this but we'd presumably not know the details.
> Unity and Unreal, in contrast, will happily license equivalent code to you.
Sure, but it's also neither free[0] nor Open Source, e.g.:
"Build and deploy to closed platforms such as Nintendo Switch™, PlayStation®, and Xbox®. An active Unity Pro subscription is required to access these build modules via developer platform forums."
The nuance of "it is not possible for Godot to support consoles as an open source project" is that "it is not possible for [the] Godot [Project] to support consoles as an open source project [but the Godot Engine can be used on consoles if you write the support code yourself or license it from someone]".
Despite detailed explanations (from the devs) of the nuances, too many people interpret the situation as "you can't deploy Godot-based games on consoles" rather than "you can deploy Godot-based games on consoles but you can't get the code to do so from the Godot Project itself because vendors won't let it".
But perhaps for some people this isn't a significant distinction.
At the end of the day the situation is entirely driven by the requirements of the console platform owners.
You can choose to:
* depend on a closed source proprietary game engine & console integration and associated risks/benefits; or,
* an open source game engine & console integration via one of multiple vendors or DIY and associated risks/benefits.
The question developers are asking themselves is ‘if I start out building a game for the next two or three years, when I come to commercialize this, will I have palatable and viable options to do so?
Unity’s random adjustment of their terms is precisely what is driving developers away. But at least Unity is making it clear what those terms are. ‘Talk to one of us privately when you get to the point where you’re ready to port to a console’ is even less certain.
In short, no.
The most detailed explanation of why is probably this section of this article: https://godotengine.org/article/godot-consoles-all-you-need-...
A key aspect is that neither Godot (the project--which doesn't exist as a legal entity) nor Godot Foundation (which exists as a legal entity but AIUI has restrictions on what activities it can perform) would be able to satisfy the requirements of the console platform vendors in terms of qualifying for access to a platform SDK.
Godot, for example, doesn't support console builds, only working with a third party to facilitate porting to those platforms (that may change in the future now that they're getting a lot more support from the community after all this).
For the full nuanced details I've listed the relevant links here:
Nintendo Switch and Playstation and titles from Sony and Nintendo incorporate BSD-licensed open source code, so it is obvious that “open source is banned” is not true. It’s only GPL and other viral licenses that lawyers argue is too risky, because it might require disclosing proprietary source when linked.
Same goes for Apple App Store as well
Technically, they could. It would require someone who hasn't actually licensed the SDK, and so aren't subjected to an NDA, to reverse-engineer things and produce their own implementation under an open source license.
Certainly would be an enormous project, but it is well within the realm of the possible. It's been done with complex systems before.
Yes, I know it's possible to reverse engineer the consoles, but that doesn't make it a viable alternative for the games industry.
It makes it legally viable, in that it would allow the production of an SDK that isn't restricted by any NDA, and therefore could be incorporated into opens source projects.
- The platform holders can and will ban software built without the official SDK
- You'd get delayed access to patches, which might break compatibility with new OS versions
- You're relying on someone being able to reverse engineer new versions for the life of the console. This is a rare skill.
It's like saying you can write your own C compiler. Yeah you can, but you wouldn't use it in production at your job.
None of your points appear insurmountable or showstoppers to me, to be honest, but they would require approaches to mitigate them.