Is Open Source the Solution to Games or Software?

Here are detailed notes from the transcript:

Detailed Notes from Podcast Transcript

Main Topics Discussed:

1. Software Bloat and Performance Degradation: The widespread issue of software becoming increasingly slow and resource-intensive, particularly in game development engines like Unity, and the resulting user/developer apathy.
2. The Efficacy of Open Source as a Solution: An exploration of whether open-source software, exemplified by Godot and LLVM, genuinely offers a viable alternative to commercial, bloated software, questioning its quality and performance trajectory.
3. Iterated Performance Decay: The compounding negative effect of minor performance losses in software updates over time, leading to significant slowdowns.
4. Hardware Evolution vs. Software Demands: The historical and current relationship between hardware advancements (especially CPUs) and software's increasing demands, and whether hardware manufacturers still benefit from bloated software.

Key Points and Arguments:

• Ubiquitous Bloat and Developer Acceptance:
  • The Unity game engine is perceived as significantly bloated, causing developers to habitually disengage (e.g., scroll social media for 20 seconds) while waiting for compilation or play-mode entry.
  • This bloat has become "the norm," akin to accepting "the US government having bloat," leading to a lack of awareness or care about alternatives among users and developers.
• Skepticism Towards Open Source as a Panacea:
  • The speaker (the one being interviewed) expresses doubt that open source like Godot is the solution to bloat, stating, "It hasn't been yet."
  • General Open Source Quality: Many open-source programs are "super buggy," despite the "open source thesis" that "all these eyes on the code" should lead to higher quality and speed. Only a few are well-engineered and maintained.
  • Lack of Direct Experience (Godot): The speaker cannot comment on Godot specifically due to lack of personal use.
• The Insidious Nature of Performance Regression (LLVM Example):
  • The open-source compiler engine LLVM, widely used, consistently becomes "between 15 and 40% slower" with each new version update for the same workload.
  • This is an "exponential" problem, comparable to negative compound interest, where small, iterated slowdowns accumulate dramatically over time.
  • Developers often rationalize minor slowdowns (e.g., "only 8% slower" with new features) as "worth it," failing to recognize the long-term, compounding negative impact on overall software performance. "Nobody takes this seriously."
• Changing Dynamics of Hardware Incentives:
  • Past Incentive: In the past, hardware manufacturers (CPU makers) did have an incentive for software to be bad, pushing consumers to upgrade.
  • Current State: This dynamic may no longer be in play, especially for CPUs, as single-core CPU speeds (Intel, AMD, Apple, Qualcomm) have largely plateaued or are leveling out.
  • A "radically new CPU technology" would be needed to reintroduce that dynamic.
• Historical Contrast in Hardware Speed:
  • In the 1990s, desktop computers (e.g., 486 CPUs) advanced so rapidly that game development companies would buy two new computers a year because each upgrade could make development 30% faster in six months.
  • Today, hardware upgrades are far less impactful for speed; the speaker's personal desktop from 2019 (with only a GPU swap) remained perfectly "fine" for years.

Important Facts or Data Mentioned:

• The Witness Boot Time: Approximately 7 seconds on Steam release.
• Unity Bloat Example: Waiting 20 seconds (e.g., scrolling Instagram) after clicking play or making code changes.
• LLVM Performance Degradation: Updates result in a 15% to 40% slowdown for the same workload.
• Developer Rationalization: "Only 8% slower" for new features.
• Speaker's Personal PC: Desktop computer purchased in 2019, used for programming and gaming, with only a GPU swap, indicating current hardware longevity.
• 1990s Hardware Pace: Buying two new computers a year, with a 30% speed increase every six months (e.g., 486 CPU era).

Conclusions or Recommendations:

• Conclusion on Open Source: While some open-source projects are well-maintained, the general quality is often "super buggy," and the "eyes on the code" thesis doesn't consistently translate to better quality or speed. It has not yet proven to be the solution to bloat.
• Conclusion on Performance Degradation: The incremental acceptance of minor performance slowdowns in software updates leads to an exponential, unsustainable decline in overall speed, a problem "nobody takes seriously."
• Conclusion on Hardware Incentives: The past incentive for hardware manufacturers to benefit from bloated software has diminished significantly due to the plateauing of CPU single-core performance.
• Overall Observation: The software industry is suffering from a "sickness" of continually accepting and building upon increasingly bloated and slow foundations, seemingly without a clear understanding of or a strong will to pursue alternatives.