Authoritarianism

The road to hell is paved with good intentions.

Initially, it may appear peculiar to characterize Godot’s governance as authoritarian. However, considering the presence of undue influence, primarily deceptive practices, such a characterization suits quite well within the frame of cultic groups1. While a facade of democratic representation is upheld within Godot’s community, delving deeper into the inner circle of developers and examining this situation from an insider’s perspective reveals the underlying dynamics that begin to fall into place.

The effect of Godot’s hierarchy is that the majority of users remain oblivious to the true nature of Godot’s governance. They continue to operate under the illusion of democracy, unaware of the hidden dynamics and manipulation taking place behind the scenes of Waiting for Godot.

Cult leader’s story about leadership

Godot’s current governance can be explained if we look at the reasons behind Juan’s understanding of leadership in the past. Here’s what kind of story he told to his cult followers2:

I will tell a story about how I learned about leadership. A long time ago, I got drunk at a business meeting with the then owner of one of the biggest gaming companies in Asia (and his subordinates, all industry veterans). Went for dinner, then to their hotel to keep drinking.

At some point, this person (over 70 I would guess) passes out, so I am like “Well, guess I should leave”. His subordinates ask me to stay a bit, ensuring me he will recover. They tell me if there is anything I would like to ask about how their company works to pass the time.

Even drunk, the mood got serious. I was confident in my skill, but was starting to have more responsibilities and was frightened of leadership. I asked them how do you make people do what I wanted, how do they handle leadership roles.

They laughed and told me that you don’t tell people what to do, that this is not being a leader. They told me that if you are a leader, you agree with them. So I am like “What if we don’t agree?”, and they answer “then you are just a boss, not a leader”.

This didn’t make sense at first to me, but it fully did over time and I was able to see the clear difference between both stances. Even today with Godot, I am obsessed that we must all get our points through and agree with things, before moving forward, Developers and community.

Oh, and hangover with wine is the worst.

Behold Juan’s intriguing story! Whether Juan’s tale holds any truth or not, one thing is clear: Juan was on a quest to unlock the secrets of controlling people’s minds, as he desired to figure out “how to make people do what he wanted.” How fascinating! Of course, those who laughed at Juan were absolutely justified because this train of thought characterizes a boss, not a leader!

Even now, presumably long after the events took place, Juan still possesses a boss mentality. He did listen to advice of Asian leaders though, but instead of becoming a healthy leader, he brilliantly ascended to the rank of a cult leader!

Juan’s persuasive abilities contribute to the reinforcement of his control over the community. By projecting an image of innovation and success, he effectively cultivates a sense of dependency among followers. They come to believe that their involvement in Godot is a privilege, further reinforcing their loyalty and diminishing the likelihood of questioning the leader’s authority.

Truly a stroke of genius! 🙃

Governance

The core problem is that Godot is trying hard to look like a community-driven project, but their actions show a complete disregard of principles such as open discussion if people try to:

  • discuss the governance model itself;
  • discuss the development philosophy (which does not exist);
  • discuss actions of members;
  • compare Godot to other technologies (which requires making analogies);
  • show inconsistencies in the development process (which often requires quoting);

For example, one of the Godot contributors suggested to remove mentions of “community-driven” from Godot’s documentation3, and such efforts were met with a great push-back from Godot leadership, saying that it’s done in “bad faith.”

Of course, people who bring up these issues may not be immediately banned, as most new contributors go through so-called educational process instead, a.k.a. brainwashing. However those people get on the radars of Godot’s community managers in any case. If people are found to be allegedly troublemaking, they may be labeled as outsiders, and outsiders cannot be trusted. If a contributor is incapable of conforming in alignment to Godot’s established status quo, Godot leadership first attempts to reproach those people in private. The punishment that contributors receive is directly proportional to the amount of time they committed to the project.

As a former member of Godot, I have personally received a private message from Godot’s project manager. Rémi suggested me to “stop quoting” them, and presented it as a potential violation of Code of Conduct. However, nothing in CoC stated this, especially if we take this together with the open discussion principle. In fact, they consistently violate their own CoC because it clearly states:

Always assume positive intent from others.

Unfortunately, they don’t assume positive intent, especially Rémi (aka Akien, aka akien-mga)4:

Comment
byu/akien-mga from discussion
ingodot

You can be excluded from participating in Godot communities even if you don’t break Godot’s Code of Conduct. Here’s a quote from one of the CoC members, Ilaria Cislaghi5, who also represents Godot leadership officially:

Note, people are not getting removed/banned because others wake up with the wrong foot one day. This just means that CoC is a guideline and if people are found to be disruptive to the development/community they may be removed even if they didn’t explicitly breach one of the rules in the CoC [emphasis added].

This is called permissiveness and iniquity. It means that the leadership of Godot allow themselves to do whatever they want with people, however they want it. This is also the moment when they figured that their governance model is trustocracy, exactly as they put it. From Godot Contributors Chat:

Yeah, it’s not really a meritocracy. Juan calls it a “do-ocracy”, where the ones who worked enough (and got their work merged) on some specific areas of the code can decide on what’s get merged. But ultimately, the fact you become a maintainer mostly relies on others maintainers and the PLC trust on you and you work I believe. There’s not really an “official guide to become a maintainer”. Can we call that a “trustocracy” ? xD

Ilaria responds to above:

I think that’s the most correct way of calling it. Trust is gained by good work and constructive attitude.

This further confirms that Godot’s governance is trustocratic. But do you know what trustocracy associates with6?

Slaveocracy and Trustocracy

Don’t be scared! This is not to say that Godot contributors are slaves, but the undue influence which Godot leadership has upon volunteers is definitely worrying. For example, here’s what Juan suggests in order to find free “manpower” to try volunteers to work on specific things in Godot7:

Yes, don’t get me wrong, that IS the case, but in general, the order of priorities is something like this:

1. Try to find a new or existing contributors to work on a specific area that is lacking a maintainer (or manpower) [emphasis added].

2. Try to see if we can get a grant from an interested party to hire contributors to work on this area (very often companies do direct or indirect hiring -via grants to Conservancy- ), or even via GSOC.

3. If all else fails, it goes to the agenda of one of the core contributors.

If we don’t do things this way, the project can’t scale. Core contributors often work in core areas and also spend a large amount of their time [emphasis added] helping other contributors.

I call this new phenomenon as VaaS, volunteers-as-a-service, because that’s exactly how Godot leadership treats and presents volunteers to corporate customers of Godot, which segues us into the next topic.

Behavior control

Leadership

As we have covered in Companies vs FOSS section, Juan says that they don’t compete with Unity, Unreal, etc, and that they make Godot because they enjoy to innovate, and that engines like Unity can take Godot’s code. Yet Juan discourages people from comparing Godot to any other technology, saying that they should not cross this line if they care about Godot8:

This post was made by Godot Engine gang

Juan’s reply to the meme above:

I would much prefer the community discusses strengths and weaknesses of Godot and don’t go around comparing to other technologies. Also none of the core Godot contributors or PLC have anything to do with this, so the logo and signature are very misleading. Please don’t do this.

As a result of this response, a follower of Godot is compelled to apologize to the cult leader:

My bad, I thought it was funny and wanted to share some humor, but I can understand how if one hasn’t seen the origins of this meme format, it can seem malicious. No bad intent there, just misunderstanding.

Juan then responds once more:

It’s fine I understand there was no intention of harm myself, but because of things like this, a lot of people will form a very wrong idea about Godot users or contributors [emphasis added], so if you care about the project, please don’t cross this line again in the future.

What kind of so-called “wrong ideas” could people form about Godot users and contributors? Could they come up with a conclusion that Godot is a cult? 😉

Some people expressed outrage at Juan’s inadequate response to an innocent meme:

Why make this a big deal? It’s just a meme. A community of people that take memes that seriously doesn’t sound that good as well tbh. Is it supposed to be a community of robots [emphasis mine] that only do Q&A, tutorials, docs and code? No fun and play between the members of this community?

Critical thinkers understand that strengths and weaknesses are identified through a process called comparison, which is how humans learn. However, many waiters for Godot appear to reject this process.

Community

Another case of this kind of behavior control is also present on the level of not just Godot leadership, but Godot community moderators. The admin and moderators of Godot Discord server are known to ban people left and right for the wrongthink. A notable case is “Pepe the Frog meme” drama9, while ironically, the admin have skeletons in his own closet. Here’s a quote by someone in that thread:

It’s wild that they are so ban happy when the main active mod has a history of posting n-word (hard r) in the Godot server. He had defended multiple times leaving a live history of hard r n-word, but is now on sight banning people for having a discussion about pepe? It’s just so so wild.

Comment
byu/VenomousInc from discussion
ingodot

Another comment:

Wow, the plot twist. I did not expect this from an open source project’s discord server! FOSS communities tend to be very friendly and welcoming.

I guess that explains the wording on the discord server’s rules and some other places. That screenshot shows the mod being plainly rude and more of a bully rather than a facilitator for its users.

Godot leadership immediately deleted the post, literally labeling most comments as breaching Godot’s Code of Conduct. They also came up with various newspeak and bogus policies mentioned there: “Ban fast, unban easily”. Nothing can be further from the truth. To lift the ban, you must either admit guilt or follow a lengthy process until the moderators persuade you that you are at fault and require an apology. However, you may not have committed any offense that would justify a permanent ban in the first place.

Eventually, the person who created that thread was unbanned. However, as the author stated:

I have to agree, I was unbanned as of now, but that doesn’t make me feel better about partaking in the future.

If not this drama, the author of that thread could remain banned forever, just like most of the people out there who don’t speak out in Godot community. This discourages critical thinking, not to mention other issues. With each such case, slowly, but steadily, Godot degrades further.

In a cult environment, there is no room for mistakes. The manipulation of perception and the requirement of unquestioning adherence become fundamental elements of such groups. In Godot, those who hold power through the ‘ban hammer’ maintain a tight grip over the community, perpetuating their influence. This control allows them to exploit vulnerabilities and desires, reinforcing their authority and suppressing dissenting voices.

Ends justify means

I once talked to Juan, bringing up the issue that what Juan says to the public goes contrary and contradictory to what he actually does, so this confuses contributors and users. His reply was this:

People are not confused or deluded, I think people are actually pretty smart. I also don’t have the ability to manipulate people or anything like that, I just say what I think and everyone can agree or not, but I don’t force anyone. Those who contribute to Godot are those who agree to some extent, those who do not don’t contribute and its fine.

Ultimately what matters is the result, and so far I think the results are quite positive.

It’s a myth that cult leaders know they deceive, cult leaders may even believe their own lies due to their pathology10. Regardless of intelligence, all people are vulnerable to cult indoctrination. This is due to the manipulation of trust. Even then, Juan’s last phrase crosses out everything that was said before, telling that what ultimately matters is the result.

Here’s another example, where love bombing is mixed with dehumanization rhetoric11:

To all of you, thank you from the bottom of our hearts. You are the fuel [emphasis added] of this project and there aren’t words to express how much that means to Godot.

This rhetoric implies that the leadership values contributors only as a means to an end. The leadership’s focus is on achieving success for Godot, be it fame, status, money, or otherwise, without much regard for the contributors’ interpersonal relationships or impact. In contrast, healthy open-source organizations prioritize treating contributors as ends rather than means.

Quantity over quality

Juan Linietsky about Godot's user base growth

"With just a snap of the infinity gauntlet the Godot community size doubled" - Meme by Juan Linietsky

To manipulate the perception of importance, leaders of Godot consistently employ grandiose rhetoric about the ever-increasing size of their community to captivate their followers. See how Juan literally fixates on growing the number of contributors12:

We have dozens of core developers and more than 400 contributors working on Godot, and this number keeps growing exponentially [emphasis added] month by month.

At the time of writing this book, Godot has over 2000 contributors, although most of them are one-time committers. While this is not exponential growth, Juan uses this grandiose narrative for propagandist purposes. It is peculiar that Juan consistently emphasizes the number of contributors in Godot as if it is the project’s most significant aspect.

Here’s how they fixate on number of “stars” in Godot as well13:

Have you starred Godot on Github? We are only 12 stars short to reach 50000! Who will be the lucky soul [emphasis added] to hit this number?

As you see, even their rhetoric such as “lucky soul” expose them as real cultists! 😵

Recall Juan’s carelessness? It is also apparent in the source code of Godot. Sergey Vasiliev’s analysis of Godot’s codebase reinforce these observations14. One day, Rémi attempted to enforce a policy of treating all code warnings as errors, which may suggest that Godot values quality. However, the usage of static analyzers in Godot exist primarily to create the illusion of a diligent and hardworking community. Law of triviality states that people tend to focus on trivial matters, even when more important issues are at hand. This phenomenon is evident in Godot, where occasional contributors often prioritize trivial tasks.

The additional workload is amplified by the presence of strict static analyzers integrated into Godot’s continuous integration (CI) system. This situation becomes even more perplexing when considering that the emphasis on trivial matters is unwarranted, given the persistent existence of major bugs and limitations in Godot that remain unresolved for years. One might attempt to rationalize this by attributing it to a lack of manpower within Godot, despite having “thousands of contributors.” However, let us recall what Juan stated about hiring developers to work on Godot in Recruiting; they are simply not interested in doing so!

Despite Rémi’s efforts, be rest assured that Juan and others will undo years of quality assurance work with yet another major rewrite, going from bad to worse. 😁

This is what Juan said when talking about catching regressions15:

There are a lot of tests for Godot functionality, but unit testing is not magical. If a bug was not found, it simply was not found.

At that time, Godot did not have many tests, so we can see a rhetorical emphasis on quantity even at this level.

Those who appreciate the advantages of unit testing may find Juan’s stance on this matter peculiar. Considering that Godot’s codebase is frequently rewritten between major versions, it would be sensible to use testing to avoid regressions. What could account for Juan’s position? In short, they may not be overly concerned about regressions because this ensures there’s always something for new contributors to work on. While this is illogical, this is the way of Godot. Instead of preventing regressions during development, they rely on the community of users to catch them in production.

The focus is on the satisfaction that contributors feel from contributing to the project, rather than on the impact of such contributions on games developed with Godot. Stating that they care about quality is a facade to attract new contributors (see previous Recruiting), especially students who tend to choose to work on unit tests. Any community efforts to establish solid unit testing coverage will eventually be nullified by Juan’s carelessness.

Godot leadership and the community are in a tug of war. The leaders aim to promote Godot and increase the number of users, while the community desires a high-quality product. In the end, leadership prevails. The community often sides with Godot’s leadership, believing that quantity is more important. However, they fail to recognize that quality is what could make Godot a preferred choice for industry experts, leading to adoption by the general public of developers. Unity serves as a prominent example. Even then, there is no implication that Godot should become as big as Unity in terms of adoption. Many smaller projects exist that do their job well.

Due to this, Godot Engine appears to be popular for game jams, where many games are created using it among other open-source game engines. Juan focuses on presenting Godot as a perfect choice for indie game developers, but such presentation is often manipulative. For example, here’s what Juan said:

The trend is much stronger on http://itch.io vs Unreal and Unity (again, not counting other engines [emphasis mine]), this is based on average of published games for some weeks, showing that for those who just do game development Solo, Godot is becoming a major choice..

First of all, recall Juan said that they don’t compete with Unity or Unreal. Secondly, look at his chart he presented there16:

Juan Linietsky about Godot's adoption for game jams

Looks like Godot is the new king of the gaming world… If you ignore all the other game engines! Who needs a comprehensive analysis when you can just omit competition, right Juan? Let’s celebrate selective data and half-baked conclusions! 🙃

Jokes aside, visual manipulations that completely omit some product in a chart can be described as a form of graph manipulation or distortion known as “omission” or “exclusion.” Juan intentionally removed other game engines from a chart to highlight Unity and Unreal. This created a false message that they are equivalent game engines that can compete, while downplaying other engines like GameMaker. People’s confusion confirmed this.

This isn’t showing GM2 or any other engines. [Are] they excluded on this pie chart or are all the games released truly exclusive to these 3 engines?

“Why did Juan exclude other engines?” you might ask. Juan is heavily biased due to his wishful thinking and avoids taking responsibility for his words. Regardless of Juan’s motives, when he explicitly disregards significant game engines like GameMaker, his chart still misrepresents data. From the perspective of Godot followers, there is no reason to doubt Juan. Juan’s “clarification” may go unread, and the misleading image could hold undue influence. Some may choose Godot without considering other game engines, merely because they trust Juan’s words. The impact of the cult of personality should not be underestimated.

In summary, despite appearing to value quality, the Godot leadership actually exploits the notion of quality as a marketing tool to attract more followers, users, contributors, and sponsors. In other words, it’s always easy to claim to value quality even when this may not reflect reality. Although Godot developers may claim to prioritize quality, the project’s deficient management and authoritarian governance often prioritize quantity over quality instead.

Compromise over consensus

As we have covered in Trustocracy chapter, Godot is based on pure trustocracy. If you start to question technical decisions in Godot, you’ll be labeled as someone who cannot be trusted, so they will start to ignore your pull requests, proposals etc. For your information, the pull request time cost is reaching up to three years before a change is merged in Godot17. The ambiguity of the development process and Godot’s vision contribute to the high number of proposals and pull requests. However, many of these changes are rejected by Godot leaders, leading to disappointment among contributors.

You may have heard that Godot’s development decisions are based on consensus, but this is not true. While opinions are considered, the final decision is ultimately made by the technical decision-makers, Juan and Rémi. In particular, Juan’s language reflects his authority18:

In any case, if you want to leave this proposal open I am fine, but for the time being you don’t have my consensus [emphasis added] to go forward with it.

Someone replies ironically:

Democracy… has not won. 😄 But if this is the vision of the project maintainers, I will no longer argue and support this decision.

If we assume positive intentions, Juan may not fully understand the meaning of the word “consensus” or he may believe he has the sole authority to represent it. This is reminiscent of the rhetoric used by dictators.

Again, it’s not a problem per se if BDFLs like Juan want to govern their project this way, but some projects are utmost honest in this in contrast to Godot. For example, see Bevy’s contributing documentation when they explicitly mention about the fact that the project is developed by “singular Benevolent Dictator and project lead”19:

@cart is, for now, our singular Benevolent Dictator and project lead. He makes the final decision on both design and code changes within Bevy in order to ensure a coherent vision and consistent quality of code.

You won’t see this kind of honesty in Godot, because Godot’s leadership shields itself behind community. The alleged success of Godot is built upon lies and manipulation of contributors.

I also had a chat with Juan, and he said this:

Those who became maintainers just picked an area of the engine they liked, worked on it, contributed, showed results, showed that they did not need much help, had always a flawless attitude [emphasis added], etc, showed lots of compromise [emphasis added] for the project and they did all this humbly and without asking for anything back, just because they loved doing it. They did not do this with the intention of be given responsibility. This is why, someone that also makes it clear that is seeking to be given responsibility inspires the opposite effect of gaining trust, specially if it tries to politicize things [emphasis added] going on. This makes other contributors, maintainers, etc. be wary of you and not trust you.

This further confirms that compromise is more important in Godot, especially when we take this with flawless attitude, which means unquestionable attitude in reality. This is certainly a problem, because asking questions is very important to reaching consensus. Contributors don’t ask to be given responsibilities nor ask to be trusted. Yet Godot leadership keeps fixating on trust regardless, because ability to ask questions posses a risk to Godot’s cultic status quo.

Godot leadership also labels discussions on Godot’s governance as political discussions in order to block them rather than seeing such discussions as genuine attempts at clarifying Godot’s governance model. This is also because they project their own real political agendas upon contributors, because that’s exactly what they do, as you’ve seen in chapters such as Cult Leader.

Conclusion

Even if we don’t take into account governance issues covered so far, the problem is not necessarily about Godot’s governance model, nor any other ideology which you can see in open-source projects, corporate organizations etc. The core problem is Godot’s hypocrisy and deception. If you ever get angry comments from either Juan, Rémi, or any other Godot cult leader, and they start to blame you for things you haven’t done, it’s the time you should know you’re participating in an abusive relationship.

Godot leadership treats community as a fuel. Juan seldom completes features. On the surface, they make the engine seem great to attract corporate sponsors that are oblivious to what happens inside the inner Godot cult of developers. Critical bugs remain unresolved for years. You may say it’s a nature of open-source, but other open-source communities have a sense of responsibility in contrast to Godot.

There are mostly compromises in Godot, which are all biased towards what Juan wants personally. Even if a major decision is made without Juan’s explicit expression publicly, be rest assured that such decision was made behind the doors, and executives of Juan’s decisions are Godot’s sub-leaders for the most part, such as Rémi.

Juan receives flattery and praise in Godot community on a daily basis. Cult of personalities have proven to lead to dramatic consequences in human history. Of course, Juan is not a big tyrant, he’s more like a petty tyrant, but given enough power, he could run authoritarian state or a failed democracy state, and this leads to corruption. Godot won’t be able to achieve true success because dissent opinion is not tolerated in Godot’s development community, especially opinion from those who have acquired recognition in Godot community.

We can only “applaud” how Juan masterfully deceives Godot followers, and how he spawns people similar to him around him. But from the point of view of civilized community, they in fact destroy the autonomy of the human will. These people who follow Godot could’ve spent their time and effort on healthy endeavors that match their life purpose, and not supporting endeavors of toxic leaders.

Therefore, it is essential for individuals to critically evaluate the dynamics at play and consider the potential harm that can arise from such a manipulative and authoritarian structure. Awareness and understanding are crucial in breaking free from the grips of undue influence and reclaiming autonomy.

References

1

Influence Continuum - By Freedom of Mind.

2

Story about leadership - By Juan Linietsky, Twitter.

5

QbieShay on Code of Conduct - Godot Contributors Chat, #coffee-break channel.

6

Slaveocracy and Trustocracy - By Daniel De Leon, July 15, 1910.

9

Discord Ban - Godot subreddit.

10

Common Myths and Misconceptions About Cults and Cultic Groups - By International Cultic Studies Association.

11

About Godot 4, Vulkan, GLES3 and GLES2 - By Ilaria Cislaghi.

14

Analysis of Godot Engine’s Source Code - By Sergey Vasiliev, April 30, 2015.

15

Juan Linietsky about unit tests in Godot - By Juan Linietsky, GitHub.

17

Godot Engine’s pull request time cost - Data from OSS Insight.

18

Rename AudioStreamPlayer{,2D,3D} or VideoPlayer for consistency - Comment by Juan Linietsky, Godot proposals, GitHub.

19

Bevy’s contributing guide - Bevy repository.