Not Invented Here
Juan Linietsky. Source: Godot Contributors Chat
The NIH syndrome describes the tendency to avoid using third-party solutions. This term is usually used in pejorative meaning, but Godot core developers do not see this as a negative thing and take this approach deliberately, with a contrived rationale that Godot’s architecture is unique and requires independent development decisions because of this, all without trying to fit third-party solutions into Godot’s allegedly specific design. A lot was tested and dumped in Godot over years like SDL, Lua, Squirrel1, Assimp, Box2D, Bullet etc. According to Juan, it has worked well:
Godot is a very NIH engine and it has worked very well
Godot strives not to rely on platform-specific libraries, and in some cases doesn’t rely on third-party at all, for example, to render GUI components. However, Godot is not completely allergic to third-party solutions, but tends to prefer smaller sized libraries whenever possible, with varying degrees of quality…
Due to the above, Godot is a very NIH engine. Godot ends up doing a lot of things their own way. But this is not innovation either, because most of their work is based on cloning existing solutions, and the rest of the work is just the reinvention of the wheel. Godot developers say that it allows them to achieve “freedom”, or a compromise of “glue vs politics”, as lead developer says:
And I can definitely say that this because in my experience, you are having in one end of the scale NIH and Freedom, and on the other Glue and Politics, and choosing this wisely on a case by case basis is best.
But for experienced game developers to make meaningful contributions to Godot, this so-called “NIH and Freedom” approach clearly creates a problem:
Welcome to Godot where it's either "their way" or "no way", no matter if you're right or wrong.
— Kornel Kisielewicz (@epyoncf) February 3, 2024
Dig up the reasons why using SDL, bgfx, physics libs (before the built-in collaps) and other industry standard libraries were rejected just because Godot is a NIH engine.
In an intriguing pursuit of irony, Juan has amusingly proclaimed his disinterest in politics dozens of times, all the while actively being involved in a myriad of political and ideological debates on Twitter/X, ranging from technical topics to more serious ones, like military, gambling, etc. As we venture further into subsequent chapters, do bear this revelation in mind, quoting Juan2:
I am only here for gamedev, not for the politics.
Because Juan is a political maestro when it comes to handling tech, you can clearly see how he sticks to his guns and adopts a rather snobbish stance on, let’s say, rendering backends like BGFX, quote3:
Guys, thanks a lot for your enthusiasm, but I am the one doing the rendering work in Godot, not you. I’ve been working on 3D rendering for 25 years so, if I am telling you that things as they are now are optimal and BGFX will just stand in the way to being productive I hope you believe me.
Godot is often criticized for being extremely NIH, so much so that Juan himself wrote a post about it, literally claiming that no one has managed to make a game engine with pre-built stuff, which is obviously a false claim:
> why nobody managed to do it yet?
— Бранимир Караџић (@bkaradzic) March 19, 2024
Many people actually do this, just not as generic engines. They use these libraries to make engine tailored for game they are making. Game is glue of bunch of 3rd party stuff.
Godot’s NIH approach is further confirmed by reviews of those who use Godot in production and face its limitations, emphasis mine4:
Godot is absolutely amazing at a lot of things, and terrible at a lot of other things at the same time. A potential idea would be to rip things apart, scrap a lot of the bad parts, and rebuild internals to be less brittle.
I was told in IRC back when godot dev team used IRC for communication, that godot src is very NIH (not invented here) by design. I wasn't familiar with this term but boy am I now. (NIH is the tendency to avoid using any third party code other than your own). (14/25)
— Winterpixel Games (@winterpixelco) July 7, 2021
Developers often have to customize Godot by rebuilding it from source just to make it work for their use cases in production. Ripping things apart is often necessary to achieve anything slightly more demanding in Godot, see Customization chapter.
While evaluations above may be accurate, they could arise due to the discrepancy between the initial expectations set by Juan (promising it to be absolutely amazing) and the actual performance experienced by the user (finding it terrible).
Godot developers might be grappling with feelings of disappointment and frustration, as their perception of the engine’s abilities clashes with the reality they encounter. This cognitive dissonance may lead them to express both positive and negative sentiments concurrently as they attempt to reconcile their initial excitement with the encountered limitations.
Yup, but I've also worked on many-a Godot projects-- there's a lot of limitations in the engine due to poor engine/feature design and the "NIH syndrome".
— LillyByte (@LillyByteGames) March 14, 2024
Godot is, by far, the engine I've had the most number of problems with, where even the most basic features need work arounds.
Yet they continue to use Godot, even when they admit it’s the engine that they’ve had the most trouble with in their entire lives. This social phenomenon mainly originates from the belief in a utopian “bright future” that many Godot users stubbornly hold onto, despite facing critical limitations:
Here is a detailed list of everything wrong with Godot. I hope people will realize that I am not the enemy of Godot. I care about the future of this engine if you do too then you should start talking about this.#GodotEngine https://t.co/5YBXEgTKoW pic.twitter.com/w0Res4CzLM
— Abruh (@abrasivetroop) February 25, 2024
Conclusion
Due to this syndrome, Godot won’t prioritize features like C# over GDScript because their priorities account for independence, see Simplicity chapter. This way, they achieve their so-called freedom, but end up making others dependent on their in-house technology, see Freedom.
Of course, Godot leadership would like to see their engine adopted by big players out there, and goes out of their ways in order to do so. As a consequence, leadership and core maintainers would be seen as experts in the game development industry, so they could provide paid services via a syndicate of commercial companies such as W4 Games that they founded. Regardless of their intentions, the above is one of the reasons why Godot is NIH. There are other important factors why Godot adheres to this approach as you’ll find out in the following chapters.
References
Juan Linietsky talks about Godot’s past - Twitter.
Juan Linietsky discusses Twitter policies - By Juan Linietsky.
Juan Linietsky on integrating a rendering backend - Godot, GitHub.