Toward A Theory Of Subtractive Development (2019)
Revisiting Koji's Blueprints
This is a formal, technical memo that I wrote in November 2019 as part of our Series A fundraise. At that time, we had been building Koji for about a year. We had a small community of developers who were experimenting with the platform and building remixable games—but we knew, deep down, that the real opportunity was much bigger.
Many of the descriptions that follow—especially as they relate to implementations—are outdated by now. But I thought it would be interesting to share this here to provide some context for where Koji came from, why we built it, and where it is headed. In general, the themes that this piece explores, as well as the idea of Subtractive Development, continue to be the foundation that guides our roadmap and vision.
Be warned that this is lengthy (10k words—yikes!) and technical. If you want to get the tl;dr, just read the Introduction, Background, and Innovation sections, and then skip down to the Summary at the end.
Subscribe for more! Back to new, accessible, and shorter-form pieces next week!
-S
“If you look at a dog following the advice of his nose, he traverses a patch of land in a completely unplottable manner. And he invariably finds what he is looking for.”
- W. G. Sebald
Introduction
Software is responsible for the most rapid and transformative era of value creation in human history. For many problems (both business and creative), it is the most powerful, scalable, and effective solution available. It can upend entire industries; it can make teenagers into millionaires overnight. It is eating the world, some say.
Yet, eight years after Marc Andreesen made that statement, the cost and effort required to create software is still so high, and the knowledge required so complex and broad, that this powerful tool remains out of reach to all but a few. It is due to these constraints that relatively few software ideas are actually built and released as products. We generally understand software projects to be complex and costly processes, reserved only for the most well-researched and well-planned ideas.
We certainly don’t create software the same way we might quickly create a spreadsheet to model something; or a powerpoint to communicate a proposal; or the way a teenager might use a suite of image editing tools to create a funny meme. However, individuals are increasingly capable of using more and more complex media/tools as means of creative expression, communication, and professional advancement. Creative tasks that previously took months, teams, and budgets can now be done in a few minutes from a smartphone. We believe there is nothing that excepts software, as a whole, from this trend.
Indeed, the limiting factor in the creation of software today is not creativity. The limiting factor is engineering.
Diminishing that factor and accelerating the democratization of software development within the structures of a modern platform presents an opportunity to create and capture value on a scale orders of magnitude greater than any extant app store or software market to date.
The purpose of this document is to establish an initial context for the space by exploring why creating and publishing software today is so difficult; to use that context to propose a radical rethinking of the way in which we approach the development of interactive content in a modern world, especially one where interactivity is beginning to ramp from traditional software to new digital spaces and modes of discovery (a “post-app store” world); to identify and explore ways in which the Koji platform is already well-positioned to define and capitalize on this opportunity; and to explicate a high-level roadmap of product development over the next 12-18 months that moves in the direction of our long-term vision.
Notes
In this document, we use words like apps, software, products, and games interchangeably to refer to pieces of interactive content. We understand interactive content to be anything that changes in response to user-interaction (as opposed to passive content, like video or images). Creating interactive content requires programming and code (we also generally use the words programming, coding, and engineering interchangeably).
What that content might actually be is such a large and non-intuitive set (that is, it evolves and changes over time as it responds to new ideas and patterns) that it is futile to attempt to define it, and one risks missing the forest for the trees in attempting to do so.
By crude example, the set of interactive content includes everything from simple pieces of humor that make you laugh for a few seconds as you’re scrolling through a feed, to fully-featured dating apps where you might find your true love; games with hundreds of hours of play-value; games with five minutes of play-value; and a million other classes of applications in all different directions, with many of those classes still undiscovered.
For additional context, we can look to YouTube, and to the breadth of content that makes sense within the scope of YouTube as a platform for video.
It is unproductive to spend time attempting to define or enumerate the types of videos that make sense on YouTube, as that set includes everything from tutorials about how to change the timing belt on a car to videos of people “unboxing” new iPhones. Many of the video categories now popular on YouTube did not even exist until the platform began to mature and consumers began to better understand the creative constraints. Things like unboxing videos, or video game streaming, would never have been developed without the ease of distribution and the self-referential social context created by YouTube as a platform.
In understanding Koji and our vision, it is essential to decouple the generic object (“interactive content”) from its context (“but what kind of interactive content?”) when encountering terms like apps and games in the sections that follow.
Background
Why is creating software so difficult?
Programming is complex and abstract. It is difficult, however, to believe that it is so fundamentally complex and abstract that it can only ever be grasped by the classically trained and a scattered handful of autodidacts.
We identify two factors that outsizedly contribute to the perceived complexity of programming but are, in fact, not intrinsic to the discipline: the long-held approach of building new software additively, and the proliferation of specialized toolchains originally meant to support large organizations.
1. Software is built additively
Today, software is built in the same way houses are built: additively. If you approach a home builder and ask them to build you the exact same house as your neighbor—you simply want to paint it a different color and decorate the interior differently—they begin by laying a foundation. The house must be framed, plumbed, wired. Roofing, insulation, drywall, etc. Even if every house on the street is exactly the same, aside from paint color, the builder must start from the beginning on each lot.
Additive construction is a logical pattern for creating goods in physical space; you obviously can’t copy paste a house and repaint it. As a model for creating digital goods, however, additive construction is absurd.
Yet, this is how all software is built today. If you approach a developer and ask them to build you the exact same app as your competitor—you simply want it branded differently and with some minor modifications to its functionality—they begin with an empty project. They will spend the majority of the project’s budgeted time building and implementing “core” functionality and configuring it to meet the project’s specifications. Depending on the type of app, this includes things like authentication, user accounts, profiles, navigation menus, data storage, friend/follower graphs, physics engines, push notifications, payments, analytics, etc.
Even if the developer has created many similar apps before and can borrow bits of code from past projects or open-source libraries, they still operate within this bottom-up, additive mode of construction. Developers are required to make decisions at each level of the stack and understand how those decisions will affect the final product. Imagine the interior decorator forced to choose the gauge of wire for the electrical main, when all they actually care about is styling the living room.
2. Industry-standard technologies, tools, and patterns are optimized for specialized implementations inside large organizations
The set of knowledge required to build and deploy a scalable application using modern tools is not intended to be wielded by a single individual, or even a small team. In fact, the majority of popular frameworks, libraries, and tools were incubated inside giant organizations and built to solve the needs of those organizations, both at a software level and a human resources level.
Two examples:
A framework called React is currently one of the most popular tools for developing websites. React was created by Facebook to power the Facebook website and, later, Instagram. It is best suited to managing the state and behaviors of complex web applications, and promoting code reuse across large product suites.
A service called Kubernetes is currently one of the most popular tools for managing servers. Kubernetes was developed by Google to manage the tens of thousands of servers that power Google’s many services.
If you want to build and deploy anything beyond the most simple text-based website or novelty game, this is a representative sampling of the tools available to you. You are forced to learn specialized tools at a generic level, adopting complex enterprise technology at each level of the additive stack.
Additionally, because of the value placed on developers ultimately getting a job inside one of the big companies who use these tools, educational materials (from formal university courses to simple tutorial blogs) focus on teaching these tools and, in doing so, perpetuate a landscape where broad domain knowledge of enterprise software tools feels like a barrier to entry to software as a whole.
Innovation
Koji’s fundamental innovation is a radical rethinking of software development: inverting the additive paradigm in favor of a subtractive model.
A subtractive model of software development
Assume:
There is nothing new under the sun. Most of the things people want to build have been built before, and new ideas are almost always most effectively framed in relation to products that already exist (e.g., “Uber for dog sitting”, “Airbnb for music studios”, “Flappy Bird with guns”, “Tinder but women must send the first message”, etc.).
When looking at the composition of software as a “stack” of layered abstractions (with things like rendering engines and network management at the lowest level and styles and creative assets at the highest level), most creative input affects components “higher up” the stack. The higher a component sits in the software stack, the more it is subject to variance. As you move lower down the stack, components are increasingly mature implementations of solved engineering problems.
Unlike physical goods, digital goods (software) can be cloned, or duplicated, instantly and perfectly.
It follows:
The delta of a new product in relation to its reference product is smaller than the delta of the new product in relation to an empty codebase.
The rate of innovation via the creation of new software increases exponentially, as each derivative work adds to the set of available reference sources for future products. The delta of any new product in relation to a reference product grows smaller over time. Software begins to evolve like life: explosively, in all directions.
Market effects of adopting the subtractive model
Widespread adoption of the subtractive model creates demand for a new class of software developer. This new developer is the “gig economy” variant of developer. They are not expected to navigate the entire “stack,” nor are they required to know how to open a blank terminal and build an entire application from scratch.
Rather, this “gig developer” is focused on creating incrementally new products by driving meaningful delta (turning a cloned reference product into a new product) through discrete, tactical mutations at specific levels of the stack. This developer is more easily hired and managed by non-technical individuals and organizations, as the scope of product development is well-defined, and the set of available choices and decisions narrow.
The Koji platform allows non-technical end-users to create new products by varying components at the highest levels of the stack without the need to manipulate code. However, by facilitating collaboration between end-users and gig developers within the context of a marketplace, end-users can drive more meaningful, lower-level mutations to their products and participate in the evolution of software.
In the following section, we will explore the technical innovation and infrastructure created by Koji to support the Subtractive Model.
Koji today (November 2019)
Overview
While quantitative statistics about a codebase are far from the best way to evaluate technology (bordering on meaningless, some might argue), they may nonetheless be helpful in providing some context for understanding the in-depth technical sections that follow. Koji has been in development, formally, for 13 months. It has been available in public beta for about six of those 13 months. At the time of writing, it consists of over 125,000 lines of code across 17 different services.
In terms of beta usage and early traction, Koji users have deployed around 10,000 applications that have been used by over 2 million unique users. About 100 of those apps are apps that we have identified as being core or foundational to spawning derivative apps. You can think of these core apps as “templates.” Most of these templates are hypercasual games (see “Koji tomorrow” section to understand why we chose to place an initial focus on hypercasual games, and how we understand the evolution of other types of content on the platform), but other classes of software like utilities, business tools, and interactive ads have appeared.
For the purposes of this document, we can separate the Koji platform into three product areas:
Koji Editor, where a user creates applications,
KojiCDN, which publishes, hosts, and distributes those applications, and
Koji Network, which leverages platform-level economies of scale to “supercharge” Koji apps with things like in-app purchases/microtransactions, realtime multiplayer, single sign-on, highly-available databases, and an embedded player that lets Koji apps ride on any platform or network without the friction of installations.
Koji Editor: Creating new software
Introduction
At a general level, Koji Editor is a multi-faceted Integrated Development Environment (IDE) composed of increasingly higher order derivative abstractions of source code.
Users can choose to operate at any of these layers, depending on their goals and skills, and shift between different layers within the same project as they desire (e.g., a professional developer may only want to interact with code when building their app, and a non-technical individual may only want to use visual controls to build their app. In some cases, however, the professional developer may find it easier to manipulate some component using visual controls, or a non-technical person may brave The Matrix and dive into code to modify some value that is unavailable at the visual layer).
New projects on Koji are created by “remixing” existing apps within the Koji network of apps (or, less commonly, importing code from another source). Remixing an app creates an exact copy of the source app, along with the source app’s development environment and deployment instructions.
Layer 0: Git, files and folders
At the foundation of the Koji Editor is a Git server. Similar to services like GitHub, Koji’s Git backbone is a highly-available, distributed source code management system. It binds to native Git, which means that developers can interact with their code repositories on Koji using the same command line tools or GUIs they use to interact with GitHub.
Git is one of the most popular version control systems, and is used within organizations to track changes in source code. It is important that this lowest level abstraction of a Koji project (its core) is the same core used in modern software development. This means that, regardless of the ways in which higher order abstractions within Koji might constrain or efface underlying code, there are ultimately no constraints as to the type of software that can be created on Koji.
Today, Koji apps are modern web applications that ultimately compile to Javascript. These applications use the same underlying technologies as some of the most popular sites and games in the world, and are structured using industry-standard methodologies. If you commissioned the development of a web application from a professional developer who had never heard of Koji, the software they would deliver to you would be compatible with Koji and its code would likely look similar to many Koji apps. This is all to say: Koji apps are, simply, regular apps. We have intentionally avoided forcing structural requirements or injecting proprietary technology at this fundamental level in order to optimize for a wide breadth of applications and a diverse community of developers, methodologies, and techniques. By remaining unopinionated and “meta” in this way, the platform is future-proof and capable of evolving as software as a whole continues to evolve. The solutions and abstractions on which we have focused are generic to the development of interactive content as a whole, and you will see in later sections how we empower end users and third-party developers to extend the functionality of the platform itself in order to support and grow with new and emerging use cases.
First derivative: Live code editor and remote-hosted development environment
Koji Editor is a cloud-based IDE, meaning it runs entirely in the browser and does not require end-users to install any software, plugins, or extensions to use. This is important when empowering development across a diverse community of users, many of whom (especially in developing economies) may not have access to computers of their own. Modern software development requires the installation of tools to a computer. If the only device to which you have access is a locked-down machine in an internet cafe, or a tablet, you are simply not able to participate in the modern software development economy. By enabling full-stack application development in the browser (existing “code sandboxes” or “playgrounds” may allow users to learn/play with code, but serious, professional development will require installing software locally), Koji opens development to the Next Billion Users, as well as a younger generation in the developed world that is increasingly reliant on tablets and mobile phones, and less so on desktops and laptops.
This is possible from a technical level because the Koji editor works by provisioning a development environment and editor on a remote server and streaming that editor directly to your browser. When you open a project on Koji, Koji assigns your project to a server from a pool of available servers in our cloud. That server then pulls your project’s metadata and downloads its source code from the Koji Git server.
The server uses the instructions provided in the source code to start whatever development servers, processes, and additional resources the application needs in order to serve a live preview of itself. While this is happening, the server is side-loading the Koji editor core alongside the code. We call this core Remy, after the rat in the movie Ratatouille.
Remy is responsible for listing, opening, closing, and editing files; managing and manipulating terminals; interfacing with the project’s underlying Git repository; and many other low-level editor functions. Remy exposes a WebSocket server, and your browser connects to Remy, meaning your browser is synchronized directly to your remote editor server.
In effect, the Koji Editor you see in your browser is a functional “live stream” of the Remy instance that is running on the remote server. This means that you can connect to a reproducible, persistent environment from any device, anywhere in the world.
This also means that you can choose to allow anyone else to connect to that same session alongside you. This enables live collaboration, as we built Remy from the beginning to facilitate functional mutations to files using Operational Transformation (OT), similar to the way realtime collaboration works in Google Docs (in fact, the bulk of research and development behind OT was driven by Google and Google Docs). Through matchmaking services operated at the platform level, we can seamlessly connect users of Koji Editor with “gig developers” (as discussed previously), who can modify and extend projects in real time (longer term, more asynchronous collaboration is best solved using Git and standard Git workflows).
A development environment typically creates a hot-reloading live preview of the project’s code. Normally, this live preview is only accessible to the developer working on the code, from the machine on which the developer is editing the code. If they want to share their preview, they either need to take a screenshot or screen-recording, or they might commit their changes to the project’s git repository, and ask another developer to pull those changes to their machine and start a development environment on their machine in order to see the first developer’s work. Because the Koji editor is fully remote (we terminate HTTPS at the proxy-level, before tunneling external requests inside a remote development server), live previews are accessible simply via URL. They can be shared instantly with anyone, anywhere in the world. You can even scan a QR code and see your live preview on a phone or tablet (this, by itself, is powerful, as previewing web apps on mobile devices is incredibly difficult. When Koji proxies requests into remote development servers, it also injects debugging tools at response-time in order to capture error logs from connected devices. This kind of seamless remote debugging on mobile devices is not possible without Koji).
The remote development server is simply a full-featured Linux environment, meaning developers have access to all the standard low-level command line utilities they need in order to work effectively.
When it comes to actually editing code in this environment, Koji utilizes the current state-of-the-art code editor: a Microsoft open source project called Monaco. Monaco is the text editor that powers VS Code, the world’s fastest-growing and most popular IDE. Monaco is an industry-standard, and used by millions of developers around the world. It is fast, performant, and well-supported by the open source community. Our implementation introduces support for multiple cursors and selections in order to facilitate the realtime collaboration mentioned previously.
Second derivative: Visual customization controls (VCCs)
Shifting to the level above raw code, Koji has developed a rendering engine for an abstraction type that we call Visual Customization Controls (VCCs). VCCs are no-code interfaces for manipulating data. They might take the form of a color picker, or a 3D object posing tool, or a text editor, depending on the type of data being manipulated (these interfaces themselves are extensible by third party developers--more on that later).
The VCC Editor is dynamically generated by parsing the VCC definition files bundled inside an app’s source code. This means that Koji does not attempt to automatically read and transform a developer’s raw code into something visual. Rather, the visual abstractions available inside that codebase are defined with intention by the author of the project’s code (it is important to note that, because of remixing and Subtractive Development, additional VCCs can be defined, or even modified or removed, in later evolutions of a project).
In exploring the Koji Editor as a product built on derivatives, we hope to communicate that we do not see these visual controls as a “crutch,” or as some kind of weaker, less full-featured substitute to code. Many “low-code” or “no-code” platforms seem to adopt the mindset that coding is difficult because code itself is fundamentally scary, and that if one could create enough abstractions that a user no longer needs to see code, the problem would be solved. We do not believe this to be the correct approach. We celebrate and embrace code. It is simply that higher order visual abstractions are, oftentimes, more effective ways of manipulating a project than modifying raw code. In the same way that professional photo editors do not manipulate the raw binary data of an image inside a text editor, it is more efficient and intuitive to define a color palette for a game using swatches and color pickers than editing HEX values in a text file.
VCCs form one of the key extensibility vectors of the Koji Editor and are critical to the effectiveness of the platform and the realization of our vision for software development. Koji Editor defines a few base data types, letting users modify things like text strings, images, colors, 3D objects, and sounds. However, third-party developers can extend the types of VCCs available on the platform by creating Custom VCCs.
Custom VCCs are, themselves, Koji apps (this kind of recursive dimensionality within the context of higher derivatives—remixable Koji apps being used to create other remixable Koji apps—becomes difficult to digest intuitively, and we apologize). Custom VCCs allow for the manipulation of more complex data types, beyond the set of base types we hard-code into the platform. Early examples include tools for drawing game maps, animation tools, synthesizers, premium asset packs, etc.
Custom VCCs mean that the power and depth of the visual abstraction layer in Koji Editor is unbounded. Developers can create controls to generate and manipulate data types that can then be incorporated into apps by other developers to extend the power of their apps and dramatically increase the level of customization possible at the visual layer.
This is a unique and innovative approach, as the power of a visual abstraction layer is ultimately defined by the sum power and breadth of its component control types. Other “no-code” or “low-code” editor tools are constrained by the types of controls they choose to hard-code into the tool, which tends to lead product development in one of two directions: either the developers of the tool focus on creating meaningful abstractions to complex data types, and create a finite set of controls that is far too limited and specific to facilitate the development of broad categories of applications, or the developers of the tool create a set of abstractions optimized for the lowest common denominator of data types, and create a set of controls too abstract and generic to be valuable in any meaningful way (oftentimes, this generic approach leads to something that looks as complex as raw code, if not moreso).
Because VCCs are simply Koji apps that have identified themselves as being compatible with the VCC messaging protocol (an extension architecture that helps VCCs communicate with the larger editor in which they are embedded), VCCs themselves are remixable in the same way any other Koji app is remixable. This unique constraint presents a solution to the “no-code problem” proposed in the preceding paragraph by invalidating its presentation as a choice (“when given a choice, take both”). By enabling a marketplace of visual abstractions, each of which brings with it the potential for infinite permutations to fit varying use-cases, Koji is able to offer meaningful, specialized controls at the scale and dimensionality necessary to support any category of software.
Additionally, custom VCCs can identify themselves as conforming to data types already known to the editor. For example, if an app developer specifies a VCC as being of type “image,” the editor knows to render an image picker for the user. However, the editor is also aware of the existence of custom VCCs that have registered themselves as being able to manipulate data of type “image” (note that “image” is used here only as a readily available example for a generic type T). Because there are alternate VCCs available for this data type, a user can choose to instantly switch from the base image picker to any compatible custom VCC. These custom controls could vary wildly in what they do; the only constraint is that when all is said and done, they pass an “image” back to the Koji Editor. For example, they might let you draw an image with a paint brush, or take a picture using your camera, or let you search and purchase an image from a library of premium/branded assets—it doesn’t matter as long as the end result is an image.
Third derivative: Semantic remixing
Until this point, we have been mostly exploring the Koji Editor from within the framework of the web browser as it appears on a large format device like a laptop or tablet. This is, however, not the only framework for understanding the editor. As we move toward higher layers of abstraction and away from raw code, it makes sense to consider mobile devices and their role in the creation of software.
Some VCCs in a project are more important than others; some VCCs may change very little from remix to remix. For example, remixing and modifying a 3D shooter game might expose hundreds of VCCs. These could include everything from the name of the game and the skins of the characters available, all the way to the recoil of a specific weapon and the regeneration rate of player health. In the vast majority of cases, especially cases where someone is remixing on-the-go from a mobile device (maybe to share the game in a group chat, or on an Instagram Story, responding to a contextual event in the same way we presently use GIFs), the only VCCs they care about are the ones that modify the game enough that the person remixing can apply their unique context to the new product.
Looking to TikTok by way of example: successful TikTok remixes are not successful because the creator has repitched the underlying song, or radically changed a dance. Oftentimes, the only mutation required to make something new and valuable is a subtle facial expression, or changing the text overlayed on the video. Small adjustments at the highest levels of abstraction can create meaningfully unique products.
This insight has two applications within when looking to the third order of the Koji editor:
A user might only need to make slight modifications to an app to achieve the results they desire. By using data to understand the most commonly modified VCCs across derivative apps (and to understand VCCs whose values are commonly linked), Koji can surface the most relevant controls and create a seamless consumer experience that makes creating a new app feel as fun, easy, and creative as recording and editing a video on TikTok.
By then understanding the data types (see “type conformance” in the previous section) of those aggregate VCCs and treating them as semantic tags, Koji can identify apps with similar inputs. This mode of creation decouples VCCs from a specific underlying application, letting users set VCC values and then cycle between compatible apps (e.g., if a user provides data values for a “character,” a “weapon,” and an “opponent,” Koji can cycle through all possible apps that can be remixed using those data types and let the user discover a reference app in this manner).
This third-order editor is effectively Mad Libs for software development, which lends itself well to more spontaneous and amateur creation on mobile devices.
KojiCDN: Publishing and distributing software
Deploying an application is one of the most involved and complex steps in modern software development. From the outside, one might reasonably assume that the skills required to deploy and manage an app in production are contained within the set of skills required to write the code that powers that app. But in the same way that the skills required to grill the best burger do not necessarily overlap with the skills required to be CEO of McDonalds, even the best developers often fumble when it comes to taking an application they’ve built and tested locally and publishing it in a scalable, reliable, and cost-effective manner.
The majority of thinking involved in architecting production-ready systems (DevOps) is agnostic to the code that ultimately runs inside those systems, and the landscape of modern deployment automation tools is bimodal in a similar way to development tools: one group of tools optimizes for ease-of-use at the expense of performance and scalability, supporting only the most trivial of applications; the other group optimizes for giant enterprise deployments at the expense of usability. The vast majority of modern applications fall in the middle of this distribution (i.e., they require an architecture that is more complex than a static blog, but less complex than Netflix—a comparison which also illustrates the effective size of this underserved gap).
In deploying and managing applications, Koji again takes the approach of stacking layered abstractions. At the core, Koji deployments automate modern enterprise workflows and technologies in a way that is configurable and extensible by end users. In practice, this means that any app remixed on Koji can be deployed quickly, reliably, and securely with one click.
This is possible because deployment configuration is defined in code that is bundled inside the application, similar to how VCCs are defined. Each Koji app carries inside it the instructions required to deploy itself. Those instructions define the steps required to compile production-ready code bundles, how those code bundles should be deployed, and how they should be accessible by users of the deployed application.
New deploys are triggered by updates to a project on the Koji Git server. When a user clicks “Publish Now” in the editor, the editor creates a Git commit and pushes it to the Git server. The Git server receives the commit, verifies the commit message to see if it should trigger a new deployment, and, if so, fires a webhook to start that deployment.
Provisioning deployment servers works in a similar way to how Koji provisions and manages remote development environments. Both use Git and Docker to create environments; but, where development environments also load a persistent editor and keep the server running, deployment environments run only the commands necessary to compile production bundles of the project’s code. They export those bundles and then terminate themselves.
Koji apps are full-stack, meaning they can generate multiple bundles (frontends and backends, for example). Code bundles are deployed to one of two targets, depending on the type of content they deliver:
Static bundles (“frontends”) are deployed to cold storage in the cloud. We “warm” those static bundles into KojiCDN, so they’re cached at edge nodes around the world and ready to be delivered to users quickly. Static bundles execute all their code on a user’s device, meaning the only requirement to serve them is to deliver the files as quickly and reliably as possible.
Dynamic bundles (“backends”—code that runs on a server, connects to databases, etc., and then sends dynamic/computed data to a user. In full-stack applications, frontends request and process data from backend APIs) are containerized and deployed to Google Cloud Run. Without ephemeral containerization technology (“serverless containers”), code needs to be constantly running on a server to power dynamic web services. This requires constant monitoring, resource management, and up-front cost to keep a server running 24/7. By deploying dynamic services to “cold” containers, and intelligently starting, stopping, and scaling them based on traffic patterns, the cost and mental overhead of managing dynamic applications in production is dramatically reduced.
Once an app’s bundles are deployed to their requisite targets, Koji registers a map of services that defines where those services actually exist in Koji infrastructure. It then loads that map into KojiCDN. KojiCDN handles proxying incoming network requests to the correct service, taking a domain like `https://mygame.koji-apps.com` and fetching static resources, or a domain like `https://myapi.koji-apps.com` and making a request against that project’s dynamic bundle. A project can have many domains pointing to the same resource. These domains are generated automatically for new projects, but users can choose to create custom subdomains on Koji-controlled domains (coolgame.koji-apps.com, etc.), or point domains they own to Koji and route traffic to their project using those domains (e.g., a domain like https://gabimatch.com/ is simply a custom domain that is managed by Koji and serves a Koji project. Users of this site have no idea that it is powered by Koji under the hood).
Koji automatically manages HTTPS for all domains, a key requirement for building secure applications. When a user registers their custom domain with Koji, they do so by configuring the domain’s DNS records to point to Koji-controlled IP addresses. Once Koji verifies that it is receiving traffic from the custom domain, it begins the process to request an HTTPS certificate from a certificate authority (CA). The CA then validates that the requester (Koji) actually controls the domain by making a request to a specific path on the domain and validating that the file returned by that path matches an authorization value. To facilitate this authorization, KojiCDN creates a synthetic path on the domain to serve the challenge file. Once the certificate has been generated, Koji serves the certificate alongside the domain and securely encrypts the keys used to sign the certificate, as certificates expire and must be renewed every 60 days.
This architecture enables users to deploy complex, scalable, and highly-performant web applications with zero domain knowledge. More technical users with DevOps experience can use the tools and patterns with which they are already familiar.
Additionally, this massive reverse-proxy architecture creates a unique opportunity to extend the Koji platform in another dimension: plugins. Plugins are generic rules for injecting code into deployed apps at request time, meaning a plugin can modify a deployed app after it has been deployed. Plugins can do things like inject ad units into deployed apps, create paywalls or password restrictions before accessing apps, or configure apps to serve the extra resources and manifests required for apps to live on other platforms like Google Play Store or KaiOS Store without requiring technical intervention in the underlying product. Plugins are easily configured by users from within the Koji Editor, and plugins themselves are extensible by third-party developers.
Platform-level tooling & economies of scale
Because Koji sits at a network level common to all software that is deployed on the platform, we are able to invest in and expose technologies and services that “supercharge” Koji apps with things like in-app purchases/microtransactions, realtime multiplayer, single sign-on, highly-available databases, and an embedded player that lets Koji apps ride on any platform or network.
While these technologies are, indeed, available outside of Koji and could be implemented by a motivated developer in an app outside the Koji Network, they typically require specialized domain knowledge and come with additional, oftentimes-unintuitive details and considerations when being deployed at scale (“unknown unknowns”).
In evaluating potential technology to build out at the platform level, the deciding consideration is whether or not implementing this technology once, at massive scale, is more effective than implementing it individually, at small scale. This consideration relates to implementation at a technical level, but also extends beyond. For example, it is dramatically more effective to build a universal embedded player at the platform level, where we can leverage authority and a large content catalogue to develop relationships with social platforms (Reddit, Twitter, Snapchat, etc.) and ensure the Koji Embedded Player is treated as a first-class citizen on those platforms; than for an individual developer to attempt to create an embedded player for a single app and have it run well on other networks.
In light of this, we have made platform-level investments (at different levels of depth and fidelity) in the following product areas:
The Koji Embedded Player rides natively inside other social networks (Reddit, Snapchat, Instagram, Twitter, etc.) and delivers apps to those platforms in the same seamless way that YouTube videos are embedded in those platforms. The Koji Embedded Player also allows apps to be embedded on any website, including blogs and news sites.
KojiPay facilitates microtransactions and other in-app purchases, including tipping, from a shared wallet in units as small as $0.01USD. Platform-level infrastructure handles security, top-ups, gift codes, and payouts/settlements to app owners. Combined with the Embedded Player, this means that apps played inside social feeds can charge users of other networks through KojiPay, with Koji capturing some percentage of that value.
Koji Database is a schemaless key/value data store for reading and writing persistent data (similar to a spreadsheet). This enables use cases as simple as game leaderboards to use cases as complex as clones of Twitter, complete with user profiles, authentication, and social graphs. At this time, we have intentionally limited the possible complexity of queries against this database (because Koji apps are simply Javascript apps, they can connect to any third-party database like Firebase Postgres, MySQL, etc. if the application requires. Koji maintains a user-level password vault, letting users use VCCs to configure authentication for any remote, third-party tools that require it) in order to avoid being sucked into the complexities of overbuilding a database product. This decision will evolve over time as the platform grows.
Koji Dispatch is a highly-available service for real-time communication between users of an application. This service forms the foundation of every realtime app on the platform, from simple chat and turn-based games, to complex multiplayer 3D shooters. By solving for real-time/multiplayer at the platform level, we are able to invest significant resources into leveraging enterprise solutions in order to build a highly-scalable, geographically-sharded service capable of supporting millions of simultaneous connections.
We plan to create a shared identity and permissions layer that rides alongside apps in the network, making it easy and secure for end-users to share identity and data across applications, even when those applications are embedded in other places.
As we better understand usage through data and see where developers are pushing the limits of the platform, we will find additional product areas where innovation and investment are most effective at the platform level. For these advanced technological problems best solved at scale, Koji apps can simply be consumers of the innovations we make. This further reduces the breadth of domain and systems knowledge a developer must possess (in addition to the cost and time required) in order to create world-class, compelling, and engaging software.
Product roadmap: Koji tomorrow
This section broadly explores some potential directions in which the Koji product might evolve over the short (6 months), mid (6-18 months), and long term (18 months onward). The goal of this exploration is to define a framework that informs product development and helps to evaluate opportunities and areas of focus.
Content evolution
The Subtractive Model facilitates the evolution of software at a rate and scale heretofore unseen. By catalyzing the creation of reference apps (thus increasing the amount of available “primordial matter” from which new apps might evolve), and choosing early targets with intention, we believe it may be possible to effectively compress the time it takes for the exponential curve of evolution to reach meaningfully significant slope.
Why start with hypercasual games?
This is the reason for our initial focus on hypercasual games. Hypercasual games present the best beachhead from which to launch this revolution, both for financial/business reasons as well as social/philosophical reasons.
From a business sense, hypercasual games present real, quantifiable value to brands, businesses, and influencers. These groups currently commission the creation of hypercasual games as marketing tools for $15-150k per game, with a development lead time of 4-12 months. By reducing the cost and development time by one or more orders of magnitude, Koji gains market and mindshare penetration, early revenue, and the beginnings of a consumer network.
In terms of driving social awareness and adoption of the Subtractive Model, hypercasual games are the best examples to illustrate its power. Each hypercasual game typically relies on a single gameplay mechanic (slicing fruit, shooting zombies, matching gems, etc.). A well-executed hypercasual game template presents little to no engineering challenges; the vast majority of the stack is “solved” in terms of development. Rather, it is from the highest level of the stack that innovation and virality take place. “Re-skinning” a hypercasual game is often all it takes to provide enough context to turn a boring game into a viral hit. The mutations that create compelling variants of hypercasual games happen almost always at the top of the stack, as opposed to complex applications where mutations may need to be more fundamental in order to drive valuable derivatives. Thus, hypercasual games are ideally positioned to showcase the power of the Subtractive Model to a large audience of developers and non-technical individuals alike.
Content predictions (12 months, 5 years, 15 years)
One of the most common questions people ask after learning about Koji (so much so that we included a full page of notes at the beginning of this document in an attempt to preempt it) is usually some variant of: “What are the best games on the platform?”
The issue in asking this question is the subjectivity inherent to the word “best.” When looking at the hypercasual games that dominate the Koji platform today, it is easy to imagine that the “best” games, and the most valuable direction for the platform to evolve, would be toward higher-fidelity games with more complex mechanics and longer gameplay value. While tempting, this path fails to accurately capture the scale and dimensionality enabled by the Koji platform (missing the forest for the trees).
Based on early data, and borrowing from trends exposed by other UGC platforms/networks, we can make some general predictions about what Koji apps will look like over time. These predictions should not be taken with any seriousness, other than to understand the scope of this opportunity as we see it.
12 months
Over the next 12 months, hypercasual games will continue to dominate the Koji platform. These games will become more refined, mechanics will become more compelling. We will see many truly beautiful hypercasual games with unique art and design. We will see many turn-based multiplayer games, as well as larger-world multiplayer games (2D, 3D, puzzles, shooters, etc.). There will regularly be games that become breakout, viral hits via embedding on platforms like Reddit and Twitter (especially timely games created in response to news/trends/memes). We will see games/interactive content as a type of content regularly created by downmarket “social media managers” to accompany their other posts. Major influencers and brands will regularly share games about themselves. A culture of creating and playing “fangames” (alongside “fanart” and “fanfiction”) will begin to emerge, most likely among teens. We will see individuals and agencies start developing Koji games full-time.
Not all Koji games will move in the direction of beauty and compelling mechanics. We will see a lot of awful games. Janky, broken, weird games. Things that don’t seem like they would have any value. However, many of those games will receive millions of plays. In fact, most games published will be more toward this end of the spectrum than toward the other, more high-fidelity end. The sum plays of these shitty games might not exceed the sum of the head of the content distribution at this point, but over time, the long tail dictates that they will.
We will see templates for simpler games, things that only have a few seconds of value as interactive jokes or memes to deliver a punchline. We will see utilities and business apps develop, especially tools that help SMBs and small to midsize ecommerce. We will see a significant percentage of our catalogue of apps in languages other than English.
Five years
Five years from now, the Subtractive Model will be the dominant paradigm of software development outside of specialized cases and giant enterprise software companies. Most teenagers will know how to create an app or game, in the same way they know how to create an image-based meme or a TikTok today. Meaningful competitors to Koji will have appeared. Many people make a full-time living within the Koji economy. Many studios and agencies exist to support the Koji economy by extracting value at its edges. The exponential growth and evolution of software has hit its stride, and the effect on business, problem solving, and creative expression is profound.
15 years
In 15 years, the Subtractive Model forms the basis for creation in the digital worlds where we now spend most of our time. You can, indeed, copy paste a house and repaint it.
Guided evolution and early value detection systems
Returning to reality, let us examine a unique opportunity available to Koji due to its platform architecture. Especially in the early days of the evolution of apps/games, we are uniquely positioned to use data in order to understand trends within the platform as they develop, as well as use our dominant position to guide the hand of the market toward opportunities that we would like to explore. As more apps are published and more users consume those apps, we can monitor network-level traffic to identify a trending app and use the data surrounding that app’s graph of remixes (the app’s “evolutionary lineage” so to speak) in an attempt to isolate what about that specific app caused the trend (i.e. is it a new gameplay mechanic? Is the app relevant to a new community/fandom?). Once we have uncovered the forces driving the trend, we can amplify them using marketing spend, or, if relevant, communicate the learnings from that trend to the wider community to help the Koji community create more relevant and compelling content. As the platform moves toward maturity and scale, this trend data could become incredibly valuable.
Programming language and deploy target agnosticism
Today, it is a requirement that Koji apps are built using Javascript (or one of the many popular programming languages that ultimately compile to Javascript) and deploy to the web. Looking at the underlying architecture of Koji, however, there is no intrinsic requirement that this be the case. This is an artificial constraint we have chosen to impose at the first phase of the platform for a few reasons:
Javascript is the most popular programming language, and the modern language for which there exists the most educational resources.
The web is the most versatile and widely-available deployment target. As a platform, the web has the fewest restrictions and gatekeepers. Web applications are becoming increasingly more powerful (for many metrics, web technology is on par with native performance).
By limiting the set of applications on the platform to the most common language and the most generic deploy target, we keep the developer community focused and aligned while it is still small, delivering tools without overcompensating for a niche language or target at such an early stage of the platform.
A single language means developers can more effectively learn from one another and share relevant learnings with the larger community. Improvements to an app or game can be easily replicated across other apps and games.
Consumer creation experience
A high-priority area of focus in the near-term is in improving the “consumer-ified” creation/remixing experience, specifically for creation on mobile devices. When creating a new application becomes as easy as adding a post to an Instagram Story or remixing a TikTok, we dramatically increase the potential that any specific app template will find viral fit via the law of large numbers. Easy consumer remixing makes individual Koji apps more valuable and increases the rate of evolution within the platform as a whole. This mode of creation enables more clear communication of the power of Koji to operators of consumer networks, and has the potential to fuel and inspire deeper integrations.
Introduction of platform-level components in embedded players
As we continue to expand the set of technologies built in to Koji at the platform level (payments, identity, etc.), it is critical that those technologies be first-class citizens within the embedded player. At this stage, the embedded player is the most important discovery and delivery vector of Koji apps, allowing any Koji app to be embedded in third-party social networks.
Explorations of licensing models
First-party payments infrastructure at the platform level (KojiPay) is the most straightforward and intuitive way for Koji to participate in the value exchange facilitated by the platform. Presently, this value exchange is possible between consumers and app creators via tipping and in-app purchases. By implementing compelling transaction models at other places within the platform, such as “premium templates” or “premium VCCs,” we have the potential to incentivize more professional developers to participate in this early economy.
These payment touchpoints bring with them the ability to explore more complex transaction/licensing schemes, beyond simply “pay to use” or “pay to own.” For example, a talented developer could create a game and charge $5 for users to remix that game. Alternatively, they might create a game and allow the game to be remixed and republished for free, with the condition that they receive a cut of any revenue, or any revenue beyond a certain lower bound. This allows professional developers to hedge their bets, and, instead of attempting to create a game and find viral fit, to participate in the value created by crowdsourced remixing of their game, where hundreds of remixes provide no return, but maybe one remix is funny/engaging/compelling in just the right way and becomes the next Flappy Bird.
Gig-ification/commoditization of software developers
Building first-party infrastructure to support the coming wave of gig-economy developers will allow Koji to participate in the value exchange that occurs in that marketplace. This infrastructure includes things like vetting and testing developers, feedback and ratings, matchmaking, and payment processing.
Summary
Creation for the sake of creation is the most noble and fundamental human pursuit. We firmly believe that interactive content presents a medium for creative expression as powerful as art and music. The internet has existed for 50 years; we have barely even scratched the surface in terms of the types of content that will come to exist in this medium. We have no idea the types of things that will be created, and we cannot begin to comprehend the rates and directions in which our world will continue to evolve. Put simply, it will be profound.
We do know one thing, however, and it is that we are currently living in the Dark Ages of software development. Today, software development is highly specialized and its availability is limited to a small handful of people with classical training or deep pockets. With the exception of a few renegades (who, themselves, in maturity and success, are pulled in the direction of tradition rather than keeping alight the spirit of something new), modern software developers are something akin to the icon painters of Byzantium. Their work is beautiful. It is innovative in many ways, and it deserves to be celebrated.
We, however, are ready for the Renaissance.
As new digital platforms and spaces come to exist, and new populations (both generationally and geographically) come online for the first time, the need for content and software will only continue to increase.
If we continue to approach the development of software using current patterns, we will not be able to meet this new demand. This has obvious effect in a tremendous amount of unrealized value relative to available demand, as well as two higher order consequences:
The rate of macro-innovation will lag. Technologies like VR, AR, 5G, digital worlds, and other platforms whose real, long-term adoption (beyond the novelty of the underlying technology) depends on the availability of compelling content all raise the same time-old question: “What is the killer app?” If the development of apps remains as difficult as it is today, we risk forcing innovative technologies into hype cycles with long cooling periods from which they may never recover.
One million people connect to the internet for the first time each day. If the power to create software remains so prohibitively expensive, software creation will continue to trend toward centralization. A few large multinationals will outsizedly control and shape the connected experience for newly-connected populations. If we do not empower these communities to control their digital experience by creating and owning their own software and content, we risk setting the stage for a kind of “digital colonialism.”
We believe that the key to managing these risks and accelerating the advent of the digital Renaissance is by adopting the Subtractive Model of software development within the context of a modern, democratic creation platform. We have laid an initial foundation for this vision, but this is only the beginning.