Google, Docker and the State of Open Source Projects – InApps Technology 2022

As OSCON 2015 was winding down in Portland, Oregon (home base of InApps Technology founder Alex Williams), Alex convened a panel comprised of co-host Donnie Berkholz (research director, development, DevOps & IT Ops at 451 Research), Adrian Cockcroft (technology fellow at Battery Ventures), and Mike Amundsen (director of API architecture, API Academy at CA Technologies), to record this episode of InApps Technology Analysts podcast.

For more episodes check out the podcast section of InApps Technology.

#55: Google, Docker and the State of Open Source Projects

Listen to all TNS podcasts on Simplecast.

This podcast is also available on YouTube.

In the last episode of the podcast, the panel discussed the newly-announced Cloud Native Computing Foundation (CNCF), in light of the several other open source foundations that already exist, and then explored the meaning of the term “cloud native.”

While debate over the definition may continue (the CNCF also supplies a definition of cloud-native application development), Alex asks this panel what are the market forces that have led to all of these open source foundations?

Donnie observes that the barrier to entry is lower for testing out new governance models now that the Linux Foundation provides foundation as a service.

“There are a lot of new foundations,” says Adrian, “but most of them are associated with some existing foundation entity. They’re not brand new, stand-alone things.” He adds, “Having it be run by Linux or Apache or something like that seems to be the right way to do it.”

Mike wonders whether foundations are now a replacement for a shared standard, and notes that foundations are not appearing in connection with the WC3 or the IDPF, for example.

Adrian explains that there are two ways to build a standards group:

“Make them easy to join and great for marketing, or, hard to join and good for building standards and products.”

“If you have too many people joining, you end up with this unwieldy thing that can’t make decisions and get stuff done, but it’s great for marketing because everyone joined it,” says Adrian.

Adrian says that owners of open source projects are being told, “We don’t like it that you’re the owner of this project. We want Kubernetes to not be a Google project. We want Docker to not be a Docker project. We want someone else to own it, so that we feel more comfortable about that.”

“That’s really why the code is being donated to the foundation,” he says. “It’s because there’s now a business barrier to further adoption of that code.”

Alex mentions that this phenomenon did not occur around APIs, and, moreover, that a lot of innovation has occurred over the last several years without the benefit of multiple foundations. Mike suggests that an enterprise having to hand off its code to a foundation in order to preserve and grow its market is a radical notion. And, both Alex and Mike note that the Open Container Initiative (OCI) leaves Docker somewhat exposed in the market.

Adrian sees it as a calculated risk. “You’re gambling that the ecosystem is going to grow faster and bigger,” he says, “rather than 100 percent control of a small ecosystem, you become a dominant player in a much bigger ecosystem.”

Foundation frenzy and ecosystem dominance notwithstanding, the advent of containers has led to enterprises and developers facing a changing universe of possible stacks. The panel dives into some of the realities that accompany these changes, one being the presence of competing scheduler providers and configurations.

“How do we move a level up the stack when this open source alternative comes into the market?” asks Donnie. “What’s next after all these schedulers? There’s going to be some kind of meta-scheduler — some smart resource manager — that just does a little bit more.”

Alex acknowledges the confusion experienced by the majority of clients occupying the middle strata of the marketplace — the ones who are between the solo front-end app developer and the giant service providers, such as AWS — and who are only trying to build an appropriate stack.

Adrian and Mike suggest that a lot of it comes down to things that have yet to happen.

“We have those southbound controlling-all-the-devices APIs,” says Adrian, “but the northbound APIs — the oxbow the applications run against — has been pretty immature, and has taken a long time to come along.”

“What’s missing is this federation — this ability to have the logical equivalent of a public cloud account — that actually is global, and then you can deploy things from a single API endpoint in all these different regions and zones.”

“We keep ignoring the application level — the large-scale distributed level,” says Mike. “I don’t think anybody is thinking really aggressively about how to automate, and speed up, and create more resiliency, on the app development side. That is still bespoke, sweaty work, full of mistakes, full of testing, and lacking automation.”

“Right now,” says Mike, “I build apps the same way I was building them twenty years ago, for the most part, and I think that’s kind of a mistake. It should be easier for me to build an app that doesn’t fall over.”

Docker is a sponsor of InApps Technology.

Feature image: “minimalism” by edward musiak is licensed under CC BY-SA 2.0.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.