HN Debrief

EVE Online's Carbon engine is now open source: Fenris Creations explains why

  • Open Source
  • Gaming
  • Infrastructure
  • Developer Tools

The story is about CCP and Fenris Creations putting parts of EVE Online’s Carbon engine on GitHub as open source. Carbon is the in-house technology base behind EVE and related projects, and the obvious question was whether this means outsiders can actually build on it or whether CCP mostly published reusable subsystems. The answer, from people digging through the repo, is that this is not a complete “ship your own EVE” release. It looks like a set of separated components, with some EVE-specific logic still visible, but without the full game or the server-side machinery people expected.

Treat this as a useful code drop, not a turnkey MMO stack. If you care about old, battle-tested engine architecture, rendering, and large-world tradeoffs, the repository is worth studying, but do not assume it contains the hard parts that made EVE EVE.

Discussion mood

Curious and mostly positive, with a dose of disappointment. People were pleased to see a major commercial game codebase opened up, but many quickly concluded that the release is partial and misses the parts that would make it a complete reusable engine or a path to running your own EVE-like server.

Key insights

  1. 01

    Time dilation was the real scaling strategy

    EVE’s signature large battles worked by slowing the simulation, not by making massive fights feel smooth. A single star system runs on one server node, and once player counts spike into the thousands the game throttles to a fraction of real time so commands stay fair and the node does not fall over. That makes the famous battles historically important, but from a player seat they become a slideshow where most people just follow orders and wait.

    If you study Carbon for “massive scale” lessons, look for graceful degradation and operational tradeoffs, not magic throughput. For your own systems, decide early whether you will preserve responsiveness, correctness, or fairness under overload, because EVE picked one and lived with the UX cost.

      Attribution:
    • cbm-vic-20 #1
    • colkassad #1
    • singron #1
  2. 02

    The repo looks more like components than an engine product

    People inspecting the GitHub drop came away saying the release is fragmented. It exposes reusable pieces and some domain logic, but lacks the glue and major subsystems that would make it feel like a coherent engine someone else could pick up and ship with. That gap matters because the announcement sounds bigger than the practical reuse case.

    Budget evaluation time before betting on this codebase. It may be excellent reference material or a source of isolated modules, but it is not the kind of release you should assume has clean build paths, complete tooling, or production-ready integration points.

      Attribution:
    • adrian17 #1
    • lyu07282 #1
    • nottorp #1
  3. 03

    Carbon also captures a stack transition in progress

    A useful technical angle is that EVE’s older architecture leaned on Stackless Python, which was notable for lightweight tasklets and unusual execution model choices. Commenters pointed to newer posts suggesting CCP has been moving away from that world, with Frontier upgrading to Python 3 while mainline EVE may not have fully followed yet. That makes the open-sourced code a snapshot of an engine family in transition, not a clean modern stack.

    Read this codebase as a historical and architectural artifact as much as a current foundation. If you borrow ideas, separate durable concepts from implementation choices tied to aging runtimes and migration baggage.

      Attribution:
    • ManBeardPc #1
    • zipy124 #1 #2
  4. 04

    EVE was designed as an MMO first

    The most useful design framing was that EVE never really optimized for realistic space simulation. It optimized for a single persistent, unsharded universe. Many odd choices flow from that, including static-feeling solar systems, fast travel abstractions, and mechanics built to spread players across a huge map while still letting economics and warfare remain globally connected.

    When you evaluate engine or game architecture, trace features back to the product constraint that drove them. Carbon’s choices make more sense if your goal is one shared world with heavy social coordination, and much less sense if your goal is a hard-science sim or a modern modular engine.

      Attribution:
    • trashb #1
    • dantillberg #1
  5. 05

    EVE’s moat was not likely in the code

    One strong point was that even a fuller source release might not damage EVE much, because the hard part was never just implementation. The enduring value came from player politics, institutions, logistics, and years of accumulated world history. That makes the missing pieces feel less like protection of unbeatable algorithms and more like normal caution around shipping internal systems.

    Do not confuse source availability with competitive vulnerability. In products with strong network effects and emergent behavior, opening code can expose internals without giving rivals the thing users actually stay for.

      Attribution:
    • 0xffff2 #1
    • adrian17 #1

Against the grain

  1. 01

    Open source may also be AI data seeding

    A skeptical read is that releasing the code could double as a way to get large language models familiar with an otherwise private codebase. If model providers ingest it, and outsiders spend tokens generating patches and questions against it, the company gets better AI leverage on its own stack at low cost. That is speculative, but it fits the timing and incentives people now look for in big code drops.

    When companies open source mature internal code, watch for secondary motives beyond community goodwill. If you maintain proprietary systems, consider whether selective publication changes how useful coding models become for your team and for outsiders.

      Attribution:
    • torginus #1
    • y1n0 #1
  2. 02

    The repo attracted scam traffic immediately

    Almost as soon as the GitHub repo appeared, fake issue comments were reportedly pushing a supposed graphics fix as a zip or executable. Commenters linked it to the broader GitHub malware pattern where attackers post convincing bug reports and “fixes” to get developers to run binaries. The point is not just that scams exist. It is that fresh, high-attention repos are now attack surfaces on day one.

    Lock down issue templates, moderation, and contributor guidance as part of any launch plan for a public repo. Tell engineers and community members never to run attached binaries from issue comments, especially in newly popular projects.

      Attribution:
    • edelbitter #1 #2
    • jerf #1
    • int0x29 #1

In plain english

MMO ↩
Massively multiplayer online game, a game designed for large numbers of players to share the same online world.
renderer ↩
The part of a game engine responsible for drawing graphics to the screen.
server node ↩
A single server machine or process that runs a portion of an online service or game world.
single-shard ↩
A design where all players exist in one shared game world instead of being split across separate servers or copies.
Stackless Python ↩
A modified Python implementation designed for lightweight concurrency using small schedulable units called tasklets.
tasklets ↩
Very lightweight units of execution in Stackless Python, similar to tiny user-space threads.
time dilation ↩
In EVE Online, a system that deliberately slows the game simulation during heavy load so the server can keep up.
unsharded ↩
Not split into separate parallel worlds or server copies, so everyone shares the same persistent environment.

Reference links

Source code and repository

Tech stack and migration background

Security references

EVE history and culture

Related games and mechanics

Videos and explainers

  • Lotus Improv video
    Recommended during a side discussion about spreadsheet interfaces and why 'spreadsheet games' often still push players to external tools.