From 2005 to 2006, for consulting reasons, I spent all my free time thinking about game engines, how to evaluate them, and trying to understand how to evaluate open source contributions in
relation to commercial games engines.
In the summer of 2007, I put together this presentation as a high level overview of my general thoughts from that process.
Looking back on this lecture, I still think it gets at a lot of really core issues in game engine technology and processes.
The tl;dr version runs something like this: game engines are full, essentially, of cross-cutting concerns. You need graphics, sound, input, physics, and so on.
But for efficiency and ease of content creation, you also need special case support for terrain, characters, building complex, vegetation, and lots of other domains,
and those special cases often need to touch many, many subsystems. But you also need support for tons of special features (save/load, database persistence, networking,
multi-threading support, console hardware support, script language support, etc) that cannot be isolated; they have to touch many, many systems deeply too. Commercial
games engines are massively integrated, so they can balance these concerns. Open Source tends to work best when massive, wide spread modularity can be harnessed, and
so they run afoul of many of these system-wide concerns. Hence the slow uptake of Open Source in game engines.