As someone who's worked in AAA game engines this is like saying because C# is now open source it will be easy to just copy code into Swift without any hassle.
The part that makes game engines both interesting and difficult is they made a series of discrete trade-offs to support the use cases of the types of games they ship. This is true from tooling workflows to rendering stacks to core engine layout like if they do heavy arena allocation or more open world dynamic entities.
We extended the engine we licensed with some fairly reasonable features and even doing the uplevel was a brutal, 4-6 month process to reconsile those changes.
I am not saying it would be easy, it would definitely be work that someone would have to do. I'm more saying that the Godot authors would not try to threaten you or consider you a threat, it's more likely they would want to help you. Of course as a business you would not do it if your customers weren't going to pay the cost to make it worth it.
I don't know enough about the implementation of C# and Swift to say for sure, but it does seem like the open sourcing of that would making it easier to do things like port some standard library component or algorithm over from one to the other, or perhaps do something like building a Swift implementation for the CLR.
Let me try to be a bit more to the point, game engine features are not just "drop-in", by adding a feature to one part of the engine there's a high probability that you make another part of the engine worse.
There's a reason that they say performance is the most leaky abstraction.
Then that sounds like you would want it to be an optional plugin, or a compile time flag that could be enabled for customers who want it? Why not do it, if that's what the customers asked for?
I get what you are saying and it definitely applies to the core architecture of the product, but if you have a large number of customers each with their own needs then I would be surprised if there were zero parts of the product that were modular or interchangeable.
> then I would be surprised if there were zero parts of the product that were modular or interchangeable.
You'd be surprised. Game engines are extremely monolithic.
There are some modular components and techniques (eg pathfinding, rendering, physics engine), but most of the effort that goes into an engine like Godot is integrating these components to their specific architecture. While the component is transferable (eg you can always use the Bullet engine in your own project), the integration work isn't.
The part that makes game engines both interesting and difficult is they made a series of discrete trade-offs to support the use cases of the types of games they ship. This is true from tooling workflows to rendering stacks to core engine layout like if they do heavy arena allocation or more open world dynamic entities.
We extended the engine we licensed with some fairly reasonable features and even doing the uplevel was a brutal, 4-6 month process to reconsile those changes.