The Unity Lesson: How Developers Can Avoid Technology Lock-In
While I have mentioned the Unity platform in previous posts because it provides a solid solution for making UI-based apps that target most devices, it is nevertheless designed squarely for the games industry. However, the recent news and ongoing saga has hit the mainstream media because of the reaction of the games development community. Outside of the large studios that use Unreal or their own engines to produce “AAA” games, Unity is very popular with independent developers and smaller teams. The platform is popular in universities, which leads to many students having their first development experiences in C#. Unity is also a popular platform for mobile development, which may give Apple a problem.
The Unity Rug-Pull
The sad saga started off with a declared change in the monetization for the platform, from a standard license agreement to a so-called “Runtime Fee” charged for every install after a game crosses certain thresholds. This type of radical change certainly never appeared on the company’s roadmap and represented a retroactive change to the Terms Of Service (TOS). Many development teams voiced their concerns on social media about how this was a serious breach of trust.
Monetizing based on installs has no working examples in the industry and for good reason. Unity offered no explanation on how exactly they would collect these statistics, and what privacy and security lines this might cross. It was pointed out that if a developer offered a published game to a successful charity bundle, the number of installs could quickly bankrupt them. There was also the possibility of malicious re-installs that could clearly be problematic.
$0.20 — The fee per install for small developers (Unity Personal subscribers) whose games brought in $200,000 in the past year and have 200,000 lifetime installs to date.
It was clear that Unity had never seriously discussed its potential change details with any actual developers, and responded with unconvincing workarounds and PR crafted non-apologies. As I write this, the backtracking is still stumbling on like a soap opera during a writers strike. For many developers, the overall picture is that Unity is no longer a trustworthy partner, and without an immediate apology and cancellation of the runtime fee, that will remain the case.
There is still a small level of immaturity within the games industry with respect to recognizing bad faith, probably because of the industry’s hobbyist roots, which leads people to assume everyone is there for the love of it. So now small teams are scrambling to leave Unity, even midway through projects.
Have an Agnostic View of Your Technology
This post is about holding an agnostic view of the technology you use; the shenanigans with Unity are just another reason to do so. Aside from recent events, Unity is a typical Software as a Service (SaaS) provider. There is no particular reason to believe another similar SaaS company elsewhere may not try to implement a similar model.
Changing the engine technology while the plane is in flight is not always easy to do. It is likely to alarm passengers. Within the software industry, the key to being ready for change is separating a product’s intentions from its internals as early as possible. This means that both inside and outside the company, anyone can describe the product or system with a rich model showing customer problems, solutions and processes, that never couple themselves with any particular technology stack.
Because no one knows when a vital pipeline component or supplier might become uneconomic, or purchased by an erratic owner, eternal vigilance is required. This can catch smaller companies out, those that don’t have the manpower to continually review all of their agreements and contracts.
These ideas seem obvious to start with, but as attention drifts, things start to fray at the edges. You hear “It’s stored in S3”, when it should just be “stored in the cloud”. Or “Everything is in git”, as opposed to “Everything is in source control”. Or “We have backup databases”, as opposed to backup data sources. This might seem like a recipe for vagueness, but it is essential to respect the boundaries between things you control and things you don’t. It might seem cool when a CTO name checks every cool technology that their system uses, but that just ties the hands of developers. It doesn’t take long before a business can become too tightly coupled to one technology — this is why, for example, the database provider Oracle became so successful.
Boundaries Are Important
Boundaries between products and outside components become important. You can see this today when products use Large Language Models (LLM), but you wonder if this is now an AI product or a product that can use AI? Does the fortunes of the product rise and fall with the abilities of the LLM? Can the product use another supplier, or is the training data now captured by the original LLM?
This boundary confusion can also happen when one product is available within the ecosystem of another. We saw this when Apple was unhappy about Epic Games wanting to use their own payment system while within the Apple App Store.
When the product model is well-defined and not tightly enmeshed with other components and platforms, experienced developers can work properly. They know when to use off-the-shelf open source software, when to use bespoke SaaS offerings, and when to write that special sauce library internally.
Define Your Product Properly
If the product’s design is properly articulated in terms that don’t specify the technology, then you can trust the developers to select (or reject) the right mix of components. There is a creative tension between getting the most out of a component, without having to change how the calling product operates in order to exploit the advantages.
So to avoid the pain of Unity developers who are now having to learn a new platform from scratch, and may have to rewrite lots of code, keep your physical and mental models separate. Even if the workload of change remains high, you will at least have an explicable job that you can describe and estimate effectively to others.
