Deciding where the Docker ecosystem will make money

The Docker forking hoopla is providing an interesting example, in realtime, of how open communities figure out monetization.

#RealTalk: Open communities are not immune to C.R.E.A.M.

One of the most important decisions an open source community makes is where and how it will make money. I always liked Eclipse’s take because they’re mega clear on this topic; the ASF plays this goofy game where they try really hard to pretend they don’t need to answer the question, which itself is an answer, resulting in only the occasional quagmire; Linux has a weird situation where RedHat figured out This One Cool Trick to circumvent the anti-commercial leanings of the GPL; MySQL has a weird dual licensing model that I still don’t fully grasp the strategic implications of; RIP Sun.

The role of standards plays another defining role when it comes to monetization. Think of Java/J(2)EE, vs .Net, vs PHP (a standard-less standard?), vs HTML and WS-*. vs, the IETF/ISOC RFC-scape that defines how the internet works. While not always, by far, standards are often used tactically to lesson the commercial value (or zero it out completely) of any given component “lower” in the stack, pushing the money “up” the stack to the software that implements, uses, or manages the standard. Think of how HMTL itself is “of no value” (and was strategically pushed that way early on), but that the entire SaaS market is something like a $37.7bn market, part of the overall $90.3bn that, arguably, uses HTMLas one of the core technologies in the stack, at the UI layer, (along with native mobile apps. now).

The dynamics of how open source, standards, and the closed source around it are defined and who “controls” them are one of the key strategic processes in infrastructure software.

The Docker ecosystem is sorting out monetization

Right now, you can see this process in action in the Docker ecosystem. Product management decisions at Docker, Inc. are forcing the community to wrestle with how ecosystem members will make money, including Docker Inc. itself.

By “ecosystem,” I mean “all the people and companies that are involved in coding up Docker and/or selling Docker-based products and services.” Actual end-users play a role, of course, but historically don’t have as much power as we’d like at this stage of an open communities formation.

End-users have to vote with their feet and, if they have one, wallets – whether wearing expensive loafers (enterprise) or cracked sandals (paying with nothing but the pride of ubiquity) – which, by definition, is hard to do until a monetization strategy is figured out, or completely lumped all together.

Looking just at the “vendors,” then, each ecosystem member is trying to define which layers of the “stack”‘will be open, and thus, free, and which layers will be closed, and thus, charged for. Intermixed with this line drawing is determining who has control over features and standards (at which level) and, as a result, the creation of viable business models around Docker.

Naturally, Docker, Inc. wants as big slice of that pie as possible. The creator of any open technology has to spend a lot of nail-biting time essentially deciding how much money and market-share it wants to give up to others, even competitors. “What’s in it for me?” other vendors in the ecosystem are asking…and Docker Inc.’s answer is usually either some strategic shoe-gazing or a pretty straight forwardly the reply “less than you’d like.”

As a side note, while I don’t follow Docker, Inc. as an analyst any more (so I’m not mega up-to-date), it seems like the company consistently puts the end-users first. They’re looking to play the Tron role in this ecosystem most valiantly. This role doesn’t, really, conflict at all with elbowing for the biggest slice of the pie.

chart_vendors-focused-on-deployment-platforms-orchestration-developer-tools-2
From The New Stack’s Docker & Container Ecosystem research

Similar to Docker Inc’s incentives to maintain as much control as possible, the “not-Docker, Inc.” members of the ecosystem want to commoditize/open the lower levels of the stack (the “core”), and leave the upper layers as the point of commoditization. This is the easiest, probably most consistently successful business model for infrastructure software: sell proprietary software that manages the “lower,” usually low cost to free, layers in the stack. From this perspective, not-Docker, Inc. members want to fence in the core Docker engine and app packaging scheme as the “atomic unit” of the Docker ecosystem. Then, the not-Docker, Inc.’s want to keep the management layer above that atomic unit for themselves to commercialize (here “orchestration,” configuration management, and the usual systems management stuff) . But, of course, Docker Inc. is all like “nope! That’s my bag o’ cash.”

As explained by one of those ecosystem vendors, who works at Red Hat:

And while I personally consider the orchestration layer the key to the container paradigm, the right approach here is to keep the orchestration separate from the core container runtime standardization. This avoids conflicts between different layers of the container runtime: we can agree on the common container package format, transport, and execution model without limiting choice between e.g. Kubernetes, Mesos, Swarm.

We saw similar dynamics – though by no means open source – in the virtualization market. VMware started with the atomic unit of the hypervisor (remember when we were obsessed with that component in the stack and people used that word a lot?), allowing the ecosystem to build out management on-top of that “lower” unit.

Then, as VMware looked to grow it’s TAM, revenue, and, thus, share price and market-cap, it expanded upward into management. At this point, VMware is a, more or less, the complete suite (or “solution” as we used to call it) of software you need for virtualization. E.g., they use phrases like “Software Defined Datacenter” rather than “virtualization,” indicative of the intended full-scope of their product strategy. (I’m no storage expert, but I think storage and maybe networking?is the last thing VMware hasn’t “won” hands down.)

“What, you don’t like money?”

Screenshot 2016-09-01 12.09.56.png
From one of Donnie’s recent presentations.

All of this is important because over the next 10-15 years, we’re talking about a lot of money. The market window for “virtualization” is open and wildcatters are sniffing on the wafting smell the money flitting through. Well, unless AWS and Azure just snatches it all up, or the likes of Google decides to zero the market.

We used to debate the VMware to Docker Inc. comparison and competitive angle a lot. There was some odious reaction to the idea that Docker Inc. was all about slipping in a taking over VMware’s C.R.E.A.M. At one point, that was plausible from a criss-cross applesauce state of the market, but now it’s pretty clear that, at least from an i-banker spreadsheet’s perspective, VMware’s TAM is the number your doinking around with.

Figuring out that TAM and market size gives you a model for any given ecosystem member’s potential take over the next 10 years. That’s a tricky exercise, though, because the technology stack and market are being re-defined. You’ve got the core virtualization and container technology, then the management layer, and depending on if you’re one of the mega-tech vendors that does software and hardware, you’ve got actual server, storage, and networking revenue that’s dragged by new spend on “containers,” and then you’ve got the bogie of whatever the “PaaS-that-we-shall-not-call-PaaS” market becomes (disclaimer: that’s the one I work in, care a great deal about, am heavily incentivized to see win, and am rooting for – roll in the bias droids!).

I skipped figuring out the market size last year when I tried to round-up the Docker market. Needless to say, I’d describe it as “fucking-big-so-stop-asking-questions-and-ride-the-God-damn-rocket.”

Looking at it from a “that giant sucking sound” perspective, most all of the members in the Docker ecosystem will be in a zero-sum position if Docker Inc moves, and wins, the upper management layers. Hence, you see them fighting tooth-and-nail to make sure Docker Inc is, from their perspective, kept in their place.

[DrunkAndRetired.com Podcast] Episode 110 – I got a retarded Leopard

Halloween Party

In this episode we talk about a whole passel of things, most interesting of which are:

Finally, go check out DFoF!

(This episode edited by Coté.)

[DrunkAndRetired.com Podcast] Episode 24 – Small Businesses, Agile planning & Estimation, and Happy Endings

In this episode, we talk about the paper-work behind starting a small business, getting better at planning and estimation in software development, and have some choice comments on the XP take on the theory of user stories (be sure to listen past the Liquid Labs promo for that).

(This episode edited by Charles.)

Tags: , , , , , .

[DrunkAndRetired.com Podcast] The IUV Triplet, The Hati Point, and Empirical Project Managemen

In this episode, we talk about Cockburn’s “Are Iterations
Hazardous to Your Project?”
article, Agile-think re: scaling
projects from 5-50 people, and figuring out what we want from the
architecture.

Also, starting with this episode, I’m trying out listing all links to stuff we talk about on del.icio.us with the tag d&r_23, as in “Links for DrunkAndRetired.com Podcast Episode 23.”. My thinking is that for each episode, I’ll create a new tag, e.g., for episode 24, d&r_24.

Also, see the post about the for_d&r tag.

(This episode edited by Coté.)

Tags: , , , .

[DrunkAndRetired.com Podcast] Episode 22 – Teamwork & Software Development Tribes

In this episode we talk about the need to build team work and trust among all the people and tribes involved in developing and delivering software.

I had a busy week this week, what with my inlaws planning on coming here (they ended up not coming), so this episode is a couple days late. So sorry!

(This episode edited by Coté.)

[DrunkAndRetired.com Podcast] Episode 11 – Large Teams, Shitting the Field, Perfectionist Coders

A team of 100+ developers will generally develop a system so complicated it could only have been developed by a team of 100+ developers. —Darren Hobbs

In this episode, we talk with Darren Hobbs about working with a large (100+) pool of programmers on a project. And, of course, there’s some poop-jokes: gotta have that.

Thanks go out again to Zane for letting us host the MP3s on the Liquid Labs servers.

(This episode edited by Coté.)

[DrunkAndRetired.com Podcast] Episode 10 – Re: Learning from Open Source

This week, we’re givin’ you two episodes! In the second one, we talk with Matt Ray and get some feedback and corrections about last week’s show, Learning from Open Source. Charles also confesses how much he likes Mozilla Suite.

Special guest stars: Super JP and Chip.

(This episode edited by Coté.)

[DrunkAndRetired.com Podcast] Episode 08 – Learning from Open Source

In this episode, we spend some time figuring out how commercial software could benefit from applying open source software development process(es) (as we understand them) to commercial software development. Along the way, of course, we try to figure out why such software doesn’t already do it that way, and what might prevent them from changing.

[DrunkAndRetired.com Podcast] Episode 02: The Life Agile, Part 2

(Click here to download/listen to the podcast.)

There’s (above) the second episode for the old podcast. It’s the rest of Charles and I talking about Agile, software stuff, all girded by his time at ThoughtWorks. I think there’s some more StarControl sounds too…and dog barking.

You know you’ve been hittin’ reload on this page just waiting for this second episode!

[DrunkAndRetired.com Podcast] Episode 01: The Life Agile, Part 1

(Click Here to Download the Podcast)

I’ve finally put together the first Drunk and Retired podcast. This is part one of some back porch-chattin’ with my good friend, Charles Lowell about his time at ThoughtWorks, agile thinking, Star Control, and a few other things. It’s about 1/2 an hour, and you know you’ll love it!

Update: also, of course, the RSS feed contains an enclosure for this episode. So, you can just add the URL http://feeds.feedburner.com/cote to iPodder, or whatever podcast aggregator you use.