Open Source vs Commercial
The following clarifies or refutes claims by Juan Linietsky made in the presentation titled “Advantages of Open Source in GameDev: A comparison of Godot vs commercial alternatives.” If you’re in search of a substitute for Godot, you might want to explore some potential alternatives to Godot Engine.
It’s worth noting that when Juan Linietsky discusses commercial game engines, he primarily refers to Unity without explicitly mentioning it. Also, Unity’s splash screen is now optional.
Plus you yourself used this same feature as an "advantage of open source engine over commercial ones" why make it a big deal just because it is on a meme format?https://t.co/wwMPgknzyk pic.twitter.com/cdigo5DC3N
— .pig//Dev (@pigdev) January 5, 2020
Moreover, it’s also vital to point out that the debate over Godot versus engines like Unity and Unreal creates a false dilemma. Unity and Unreal have established themselves as industry standards for a reason—they provide the necessary tools to tackle the complexities of professional game development, unlike Godot. Even Juan Linietsky himself says that you should use Open 3D Engine if you want something made by industry engineers.
GDC space was rented/donated by W4 in order to increase industry presence (which is the aim of the company).
— Juan Linietsky (@reduzio) February 16, 2023
Its a small part on what is spent contributing to Godot. Godot is independent and must procure its own funding.
Use O3DE if you want something made by industry engineers.
For more information on W4 Games, a commercial company co-founded by Juan Linietsky and others, please refer to the Community-Driven chapter.
The tables below present Godot’s statements on open-source and commercial software in the leftmost columns (the first or second column), while the actual reality is described in the rightmost columns (the second or third column).
| Open Source | Reality |
|---|---|
| Traditional software industry prefers Open Source tools. | The traditional software industry prefers commercial tools. The modern software industry may find value in leveraging Open Source without being heavily dependent on the underlying open-source technology. |
| Game industry is trailing behind, due to the traditional high secrecy on technology, hardware and hardware constraints. | The gaming industry has a somewhat hedonistic essence and relies heavily on innovation, often requiring more than just Open Source tools. This innovation is driven by the competitive landscape among commercial companies. |
| The trend is slowly shifting. | Although we’ll observe a growing use of Open Source in the gaming industry, commercial solutions will remain pivotal and central. Open Source shouldn’t be seen as a complete replacement for all commercial solutions. However, if such a shift occurs, we may find ourselves in a future where innovation diminishes significantly. |
| Godot | Commercial | Reality |
|---|---|---|
| Codebase is well organized and easy to understand. | Codebase is closed, engine is a black box. | The quality and readability of code are entirely contingent on the competence of project leaders and the type of contributions the project receives. Read also Do Repeat Yourself section. |
| Code access is a bliss for experienced developers. | Sometimes code is available (with restrictions), but development is still not public. | Having access to the code is just one of the benefits among various factors; it’s not a panacea. Read also Customization and Not Invented Here sections. |
| The more complex the project, the more you benefit from source access. Several developers who understand the engine internals will be glad to help. | The more complex the project, the less resources are found. Trying to work around problems results in a reduction of game quality or an increase in development time. | While having access to source code is undoubtedly advantageous for developers using such software, the truth is that commercial solutions are generally robust, flexible, and feature-complete to the extent that source code access is often unnecessary. Moreover, dealing with technical debt from Godot falls on the user’s shoulders, and not resolving this technical debt will surely result in reduction of game quality or an increase in development time. Read also Freedom section. |
| If paid support is required, Godot has dozens of developers with deep knowledge of the code base. | Only the company making the engine has deep knowledge of the codebase. Support is very costly. | If a profound understanding of Godot’s code base is portrayed as a prerequisite for commercial projects using Godot, it raises questions about whether Godot possesses sufficient built-in capabilities to address any slightly less trivial use cases out of the box. |
| Contributions of new features will most likely be added to the engine. Most commonly used features are provided out of the box, and integrated to the core engine. Less often used features are provided via asset library, for free. | New features or improvements will need to be maintained separately. Core engine features missing because of the business model. Need to be purchased from third parties. Not always updated to the latest version and no official support. | Many new features in Godot get rejected in Godot. Features end up being abandoned and handed over to third parties because of insufficient maintenance. The additional features contributed by the Godot community through plugins are perceived as a potential threat to Godot’s commercial agenda, including ventures like W4 Games or the upcoming Godot’s commercial Asset Store. Read also Extensibility section. |
| Godot is developed under the very permissive MIT license. Use it as if it was your own in-house engine. Of course, no fees or revenue share. | Free binary blob, pay to remove splash or change editor theme. Pay a high price for source code that few developers understand. Pay for a sizable % of your income. | The fervent fanaticism within the Godot community often leads developers to feel a sense of obligation to promote Godot for free, financially donate to the project even if they don’t use the engine based on a perceived belief in Godot’s so-called bright future, and so on. Read also Freedom section. |
| Godot has more than 550 contributors and dozens of core developers. Once popular, open source projects live forever, and only keep getting better over time. | Even widely popular technologies are discontinued or development stalled if they are not profitable or their market stops growing. | The presence of contributors doesn’t guarantee immunity from abandonment. Both commercial and open-source projects are susceptible to being discontinued, and it hinges on various factors beyond just the count of employees or volunteers. This ignores potential challenges such as technical debt, changes in project direction, conflicts among contributors, or shifting priorities that might hinder continuous improvement. Popularity is an unreliable predictor of future success. It doesn’t consider changes in technology trends, evolving user needs, or emerging competitive alternatives that might impact the project’s popularity, even in the Open Source arena. |
| Godot users and developers all benefit equally of each other’s contributions. We want to focus on making great games, so let’s solve our technology needs together. | The profit of a company making technology is more important than your game. No consensus exists, engine direction is dictated behind closed doors. | The claim of equal benefits is ambiguous. Both open-source and commercial solutions have the potential to offer an equitable distribution of value. However, with Godot, there is an increased risk of developers finding themselves in a perpetual state of incompleteness, diverting their attention and wasting resources for engine development rather than focusing on game development specifically. |
Downsides of Open Source Software
Considering the Open Source ethos, the list of alternatives is comprised of open-source or source-available game engines and tools. However, I encourage you not to limit yourself to just open-source options; please refer to the Freedom and Cults sections for further rationale.
As a proponent of open-source software myself, it is important to acknowledge its limitations. Many self-proclaimed “advocates” for Open Source often overlook the downsides of using and adopting such software. While you can explore this topic on your own, allow me to offer my perspective in a down-to-earth manner, especially regarding indie game developers. I intentionally focus on discussing the downsides here, as the benefits of Open Source are already well-known to many, so there is no need to reiterate them here.
Open Source software is often developed by volunteers, which can create an environment with an underdeveloped sense of responsibility. This lack of responsibility can result in negligence when it comes to providing comprehensive features or polished solutions. In the long term, this may place a burden on independent developers who need to invest additional time and effort to customize, enhance, or refine the software to meet their specific needs or match the quality of commercial products.
While it is true that bug-free software is a myth, and the level of quality is not always directly correlated with whether software is open-source or commercial, commercial software tends to foster a stronger sense of responsibility. This is because it involves an explicit relationship based on monetary transactions, which in turn creates a stronger incentive to produce high-quality software. Consequently, opting for software that is software-available rather than exclusively relying on pure open-source projects may provide a better compromise to leverage the best of both worlds.
When it comes to Godot Engine and its developers, including those who are paid, there is a distinct absence of any sense of obligation or responsibility when discussing donations. The core developers reside in countries with a lower cost of living, enabling them to sustain themselves for a considerable period solely through Patreon without immediate pressure to deliver significant improvements. Therefore, if a feature is not already present and functioning, it is unreliable to expect it to be available in the near future under these conditions.
Remarkably, there are numerous leaders who voluntarily decide to refund donations in the event of project failure (as often the case with many start-up projects), even though donations are typically non-refundable. They understand that any form of monetary support creates some level of obligation, albeit weaker in the case of donations compared to direct financial compensation. But this truly commendable behavior does not describe Godot leadership. They might mention responsibility, but only to manipulate contributors into behaving according to the desires of Godot leaders. The fundamental concept of responsibility is completely alien to them in the first place.
Should you contribute to Open Source projects?
Don’t contribute to open-source projects unless necessary.
While it may seem enticing for students to contribute to an open-source project to enhance their experience and build portfolio, based on my experience, unless you’re contributing to a well-known open-source project, say, in the web development industry, the game is not worth the candle. There are several reasons for this, including an overly zealous liberal approach in the Free/Libre Open Source Software (FLOSS) philosophy and the cultivation of the ideology that working on things for free is a privilege, as remotely evident from jokes such as this one. Therefore, ensure that you are being paid by the company and that the company contributes something meaningful to the open-source project that you care about, at the very least.
Remember, you are not obligated to contribute if you use FLOSS. You don’t owe anything to anyone when it comes to software with permissive licenses, other than what a license requires you to do. Any attempts by project leaders to guilt-trip you into “contributing back” (which is a peculiar phrase that implies an obligation) should be seen as a red flag, and it’s best to avoid such projects.
If you feel like you want to contribute, take a moment and contemplate your deeply-rooted motivations: do you want to contribute to improve software, or just gain a superficial level of recognition by your peers? Answering these kinds of questions may help you to build and follow your own path. Instead of supporting the endeavors of toxic leaders, direct your time and effort towards pursuing healthy endeavors that align with your life purpose.
Godot is predominantly developed by and for hobbyists. Godot might tackle some complexities, but it naturally gravitates toward a peculiar audience. Unlike healthy open-source projects, Godot has no vision, philosophy, principles, or roadmap. Therefore, Godot is a happenstance.
I caution against contributing to Godot or even using Godot, regardless of whether you consider yourself an amateur or a professional. The risk lies in the insular nature of Godot’s community, which limits exposure to industry best practices. If you get stuck in Godot, it can be tough to break free from its deceptively simple structure.