Ever higher in the stack: the “app native” paradigm and the future direction of OSS projects

The OSS world remains tightly focused on plumbing. But we will likely see the emergence of an “app native” paradigm of OSS focused on user-facing functionality.

TL;DR: I anticipate a general shift in the OSS world from “plumbing” to specific application functionality. The “cloud native” paradigm is very quickly asserting itself; it will likely be followed by an app native paradigm that will see a broad-based shift in focus and energy.

It’s almost always foolhardy to predict the future, but I still think that it’s incumbent upon us to carefully examine current trends and do the best we can to extrapolate from them and discern a rough Zeitgeist, lest we fail to adequately recognize approaching dangers and opportunities (and to adjust our practices accordingly).

Photo by Alfons Morales on Unsplash

In this post I’ll venture some educated guesses about the general direction and thrust of open-source software (OSS). I anticipate a broad-based shift from the current state of affairs — a cloud native moment strongly focused on basic software “plumbing” but tending toward a baseline plumbing consensus — toward a new paradigm: an OSS universe in which the focus of our collaborative energy shifts to ever-more specific functionality. I call this future paradigm the app native paradigm in computing.

The cloud native moment, focused on plumbing, will give way to an app native paradigm focused on specific end-user-facing capabilities.

Ecosystem consolidation, part 1: Kubernetes

It’s been said in many contexts that Kubernetes promises to be the operating system of the cloud, or the orchestrator of the cloud, or the POSIX layer of the cloud (depending on whom you ask). Given the explosive growth of the Kubernetes ecosystem in recent years, things do seem headed in that direction, especially now that Kubernetes is moving beyond containers and becoming more of an all-purpose scheduler/orchestrator (see projects like Virtual Kubelet, Knative, and Kubevirt).

Kubernetes itself may not “win” but I do suspect that something Kubernetes shaped will win and become the industry default for doing big and bold things in the cloud. Some default orchestrator for cloud workloads of all sorts will emerge (containers, functions, plain old binaries, directed acyclic graph computing topologies, etc.).

This will mark a major victory for the so-called cloud native paradigm, which I believe harbors scheduler/orchestrator consensus as an implicit teleology. Other pieces of the puzzle will follow suit (see below).

Kubernetes or something like it will provide a basic orchestration layer that will be complemented by other components.

Ecosystem consolidation, part 2 through n: the other components

With a default orchestration plane in place, other “plumbing” components will begin to complete the picture:

• A service mesh à la Envoy or Istio will become the default network control plane for the “cloud OS,” allowing for centralized control over every network packet.
• Policy mechanisms will enable arbitrarily complex enforcement of declarative policy directives. The Open Policy Agent is already providing a blueprint.
• A deterministic deployment mechanism like Terraform or perhaps something inspired by the Nix ecosystem will form the pipeline for computing artifacts of all kinds to be run on the “cloud OS.”
• An abstraction like Kubernetes Operators will provide the default interface for managing already-deployed computing artifacts
• Arbitrarily granular intelligibility into workloads will be provided by a hybrid of monitoring, observability, logging, and tracing technologies (projects like Prometheus, Jaeger, OpenTracing, Fluentd, Cortex, OpenMetrics, and OpenCensus are showing the way here).
• Tools will be developed for testing the formal correctness of complete architectures. Think “Coq for the cloud” or Diffy writ large.
• Baseline primitives will be in place to run applications at planet scale and with as much geographical specificity as necessary, with the core principles undergirding CDNs, edge computing, and projects like Spanner applied to all cross-cluster, non-local computing concerns.

All of the above components (if that’s even the right word!) will be built to interoperate as seamlessly as possible. Specifications will drive the core interfaces (think of the Open Container Initiative and the Container Network Interface as precursors). Competition and plurality will continue to exist in the “plumbing” sphere but market players will compete over implementations, not interfaces.

Network orchestration, deployment, globality, workload diversity — these and components yet unknown to us will complete the bedrock of the future.

The next stage: app-native OSS

Disclaimer: I’m not sure that I like the app native terminology at all but I’ll roll with it as a placeholder for now. Suggestions welcome!

What I mean by app-native OSS is a universe of open-source projects that

• can make bold assumptions about and take for granted broad swathes or underlying plumbing and thereby
• focus virtually all of their efforts on providing common, modular, reusable bits of end-user-facing functionality

These OSS projects would be much further up the “stack” than we’re used to seeing now.

Here are some application domains that we may see as app-native OSS efforts:

• Notes: There are a bajillion note applications, some of which are really great. I consider myself an Evernote power user and I’m warming to Dropbox Paper. But these applications are very similar. Their core functionality could be boiled down to a handful of interrelated data types and some kind of extension mechanism for adding bells and whistles to notes or notebooks.
• Calendars: Yep, people are still building calendar apps from scratch. In the 21st century, everyone should have a calendar app that they know and love. But as in other domains, the competition lies in who’s already there, not in the underlying technology, which is about as solved a problem as you’ll find.
• Task tracking and project management: Basecamp, Pivotal Tracker, JIRA. Love them or hate them, they’re often required at work, and maybe they help us overcome our personal organization failings. How different are they, though? This market feels tapped out and tired. Let’s build on what we know and start collaborating here.
• Chat: Slack, Facebook Messenger, Snapchat. We all use these, sometimes whether we want to or not. The core value of chat platforms, however, lies in who is already there. The core functionality, such as multi-tenant message queuing, is ripe for app-native open-source collaboration.
• Device rental: Bird, Lime, Ofo. Apps for briefly renting things and relinquishing them for the next user; scan a code, charge your card, click “STOP,” done. Lots of room for OSS collaboration here; efforts currently stymied by inability to make plumbing assumptions.
• Multimedia content presentation: YouTube, Netflix, DailyMotion. Serving static content plus search abstractions over that content plus commenting capabilities (and hopefully plus abuse and spam filters built in). There’s probably more “special sauce” in this domain than in some of the others but it’s quickly disappearing.
• Many, many others. Open up your phone and look at all of your apps. How many of them are doing truly magical, unprecedented things? And how many are there because your friends are there or due to a first-mover advantage? Anything in the latter category will be delicious fodder for app-native OSS; anything in the former category could eventually succumb to the same forces.

These sorts of capabilities could perhaps be packaged as bundles of highly configurable services, likely some mixture of containers, functions, and batch jobs. The applications of the app-native paradigm will be able to sew and splice them together with aplomb.

And remember, app-native applications will be globally distributed by default and have all of the capabilities mentioned in the list in the previous “plumbing” section. If chat, notes, task tracking, and the like are basically modules or libraries, then the app-native applications of the future will probably blow our minds the way that FourSquare did in 2010.

The OSS projects of the app-native era will be focused on application-specific functionality that we now see needlessly reproduced and reinvented over and over again.

The app-native tool ecosystem

A move in the direction of app-native OSS would inevitably lead to a profusion of new tools focused on a new set of concerns. I can venture some guesses on what tools we could expect:

• Data relationships would become a primary locus of activity. Most OSS activity around data is still in “plumbing” land, e.g. SQL and NoSQL databases, message queues, streaming data platforms. App-native projects would instead be focused on application-specific data type constellations and the tooling around them. In recent years we’ve seen an intensified focus on type safety and validation in programming languages, schema definition languages à la GraphQL and Protocol Buffers, and client libraries. This trend will certainly continue.
• Integrations would continue to be a major source of OSS activity, but app-native integrations will be between feature-rich app-native components rather than between “pipes.” Today: let’s a MySQL connector for Kafka. Tomorrow: let’s build an OSS chat platform that seamlessly interoperates with any OSS calendar system built in accordance with a collaborative OSS calendar app specification.
• Extension mechanisms would be deeply woven into app-native OSS platforms. Project collaborators would make careful decisions about the boundary line between core data types and extension-driven domains. An OSS task tracking platform, for example, may have built-in concepts of users, tasks, task statuses, and boards, but also enable application engineers to add, for example, a wide range of task-specific features via an extension interface that’s both well understood and a project of cross-project, specification-driven collaboration. Can you think of any two OSS projects that use the same extension mechanism? I honestly can’t.

New projects, new tools. The app-native tool ecosystem will be heavily focused on data engineering with an eye to user experience.

App-native OSS and the future of value creation

Prior to the “app native” stage of OSS, there will continue to be tons of new user-facing value created from continuously reinventing the app “wheels” listed above (notes, calendars, project management, chat, etc.). The emergence of app-native projects—projects that can safely assume the presence of a “cloud OS,” a networking control plane, etc.—will facilitate the building of newer and more complex wheels instead.

App-native development will not kill proprietary software and it won’t make everything collaborative in the OSS mold. The same kind of burn-and-churn competition we see in the industry will continue apace. What we will see, however, is a shift in the locus of OSS work and vision away from nuts and bolts and toward end users.

In the app-native paradigm, making money on software will involve intelligently utilizing app-native capabilities developed in the open, plus some application-specific “special sauce” on top. Some wheels will continue to be reinvented but they’ll be different wheels.

I, for one, am excited to see it all slowly take shape.