Visualizing Dependencies

Aug. 7, 2022 [technology] [proprietary] [gaming]

To better visualize how middleware can lock projects to specific platforms, one can generally create a flowchart of supported targets. A very prominent example being 3D rendering APIs and the battle that has been playing out to capture developer share. When looking at the following graph, ask yourself which starting point (red nodes) is going to offer the widest interoperability.

Any developer building their project atop DirectX or any DirectX reliant tools is effectively placing their software on a ball and chain to Window$. Even if the source code is available, the project would largely need to be rewritten or substantially modified in order to port it properly to other platforms. That is one of the goals of vendors who artificially restrict their APIs to certain platforms. I’ve seen it occur on a number of occasions, especially following Steam’s expansion into GNU/Linux, where a game developer pledges to support Mac and Linuxes but ultimately burns out trying to support builds on different APIs and ends up scrapping the effort. It is this developer tax which makes the exclusionary strategy so effective for monopolizing platforms.

And note how CrApple has completely avoided compatibility with open and industry standardized Khronos APIs Vulkan and OpenGL. They liked what Macrosuck did with their DirectX strategy so much that they decided to replicate it when they devised the Metal API. MoltenVK bridges this gap but it was made through no effort of CrApple. Gotta make sure those 3D programs don’t get freely built for your competitors… OpenGL techincally still works on Mac OS and iOS but it has been left to rot intentionally to keep development away from this interoperable solution.