Hacker News Reader

Comment by benjaminwootton | Hacker News Reader

Has there ever been a bigger missed opportunity in business than Docker managed to preside over? They could have created a huge business, but the product and go to market strategy has been awful.

In my opinion, selling a PaaS was fundamentally the wrong call when they could have licensed an enterprise version of the engine and taken a commission on every server in existence. This is more a Microsoft or RHEL type business rather than a second rate Pivotal or OpenShift, which in themselves are being mullered by EKS/AKS in enterprise.

The whole pitch towards legacy apps was also short termist distraction when investment dollars are all going to cloud native solutions. Legacy apps are a big business case but getting companies to invest in their legacy estate is still a tough ask. This angle should have been secondary to competing where they are naturally strong.

View on HN

I agree it was a missed opportunity, but:

1) Is there another company that benefited from that missed opportunity? No. K8S is free and it "makes money" in the sense that it's a great on-ramp for GCP, and therefore GCP is happy to subsidize it.

2) It's never too easy to be the "first" company to break into a new technology or opportunity. Look at Altavista, and how it lost to Google in just a few years, despite when Google started Altavista was already a huge company.

3) I am not sure that your proposed solution would have worked, at least in terms of making Docker successful. It is the obvious alternative, but hard to be certain that its outcome would have been a better one for Docker (the company).

There are dozens of companies providing kubernetes with various levels of management, and there are also many companies selling addons. It's a huge market, and Docker captured almost none of it.

Considering Docker literally developed the underlying technology, and a lot of the complexity and capabilities of Kubernetes come from its design, they had a tremendous advantage that was squandered.

Google clearly had a huge advantage too since they have been using containers for years. But Docker certainly was in a good place.

Exactly a good model is puppet labs. They have a enterprise version and a go to consultancy They seem to be surviving. I hope in this age of the cloud

From memory docker and some of its engineers and managers where at logger heads with redhat and google see rocket, systemd containers, podman and k8s This forced docker to commoditise it’s tech or docker was slowly boiled into commoditised component

Signed arm chair warrior

> Exactly a good model is puppet labs. They have a enterprise version and a go to consultancy They seem to be surviving. I hope in this age of the cloud

Their CEO stepped down three years ago:

https://www.oregonlive.com/silicon-forest/2016/09/luke_kanie...

The new CEO has ONE expertise, which is winding down bankrupt tech companies:

http://thedronegirl.com/2018/09/14/airware-closing/

> It's a huge market, and Docker captured almost none of it.

Is it though? Aside from cloud vendors (Azure/AWS/GCP) who's the "huge market"?

The cloud market is pretty darn huge, why are you dismissing it? Aside from the public cloud vendors, containers are very much a thing in the private cloud space too (OpenShift, Pivotal, etc).

Huge? Don't think so, not now. Name me one of these companies with more than $100M revenues per year. None. It's still a tiny market.

FYI: AltaVista lost to Inktomi, which then ceded to Google.

> Has there ever been a bigger missed opportunity in business than Docker managed to preside over?

Sun Microsystems

Do you want to elaborate?

Java.

https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ from 2002 talks about it a bit:

> Sun is the loose cannon of the computer industry. Unable to see past their raging fear and loathing of Microsoft, they adopt strategies based on anger rather than self-interest. Sun’s two strategies are (a) make software a commodity by promoting and developing free software (Star Office, Linux, Apache, Gnome, etc), and (b) make hardware a commodity by promoting Java, with its bytecode architecture and [write-once-run-anywhere]. OK, Sun, pop quiz: when the music stops, where are you going to sit down?

Sun had all sorts of good tech, worth paying for, and couldn't figure out how to make people pay for it.

>Sun had all sorts of good tech, worth paying for, and couldn't figure out how to make people pay for it.

Sun had excellent engineers but no adults in the room focused on selling the tech or making money. They got drunk off the dotbomb cash influx. They saw that they needed to open source Solaris to properly compete with Linux (and arguably they weren't too late) - but they didn't actually have a plan to make MONEY off that. You can't both give away all your software while simultaneously trying to switch to x86 hardware at the time when x86 had already become a race to the bottom...

The E10K -- the former Cray Business Systems Division purchased from SGI for a pittance -- made $1.2B in its first year as a product, and probably still stands as one of the most profitable acquisitions in the history of the industry. (And was due entirely to the adults in the room.) Yes, Sun was badly disrupted by x86 -- but not being able to adapt to economic disruption is really not the same as not being able to "figure out how to make people pay for it." (Indeed, those most fixated on immediate revenue are those for whom economic disruption is most difficult to counter.)

To be clear: Sun lost a microprocessor war first and foremost. In my opinion, Sun needed to respond to x86 by being even more iconoclastic than the company had the stomach for at the time: by buying AMD ca. 2004 and fighting the Intel cross-patent poison pill in court. So in the end, Sun's problem was arguably too many adults in the room, not too few...

The "Innovator's Dilemma" basically. Sun threw gasoline on the fire by giving everything away, but it would have happened anyway.

Buying AMD would have been great.

There's always more to the (inside) story. Meaning I have no idea what's going, so should stay humble if I can't keep my mouth shut.

James Gosling's shared one theory for the downfall of Sun: radioactive packaging of the hot new UltraSparc-II chips cost the company billions.

http://nighthacks.com/jag/blog/336/index.html

I so wish Sun had survived. Jini, JavaSpaces, JXTA, grid computing... I recently had to do some AWS Lambda work (serverless & nodejs) and wanted to kill myself.

Thank you for sharing your views, theories. It's actually therapeutic.

For the curious:

> It was deeply random. It's very randomness suggested that maybe it was a physics problem: maybe it was alpha particles or cosmic rays. Maybe it was machines close to nuclear power plants. One site experiencing problems was near Fermilab. We actually mapped out failures geographically to see if they correlated to such particle sources. Nope. In desperation, a bright hardware engineer decided to measure the radioactivity of the systems themselves. Bingo! Particles! But from where? Much detailed scanning and it turned out that the packaging of the cache ram chips we were using was noticeably radioactive.

There are a few details Gosling left out: Sun trusted those chips enough to omit parity or ECC that would have smoked out the problem early, Sun reversed whatever growing trust it had been earning in enterprise space by blaming the customer and for some time making them sign NDAs to work on the problem, and Sun had engineered their sales so that they only did direct for enterprise sized purchases.

They had really good x86 hardware at a time when the post-dot.com crash wave of companies was getting started, but the sales channels were what you could charge on a credit card on their site, and VARs and the like which usually wouldn't sell to startups. Dell got a great deal of that business because they actually wanted to sell, and by the time these companies' hardware fleets got big enough for enterprise sized orders they'd long mastered how to run Dell or whatever systems to provide a reliable service.

James only has a fraction of the story there. Yes, the alpha emitter (it was radioactive boron) that had contaminated our supplier's SRAM was a serious contributing factor to the (dreaded, infamous, triggering) e-cache parity error on UltraSPARC-II that itself was a major drag on the business. No, it wasn't the only factor (there were many, sadly -- the e-cache parity error represented multiple failures at nearly every level of the system) and no, the e-cache parity error didn't alone change the fundamentals of the business -- but it definitely didn't help!

Xerox PARC!

Sun made $200 billion of revenue over 28 years. Yes, Sun missed opportunities -- but (as someone who worked at Sun during the internet boom) Sun definitely took advantage of plenty of them. Or are you making the case that Sun's technological output was so substantial that the $200 billion over the nearly three decades represents a "bigger missed opportunity in business than Docker"?

In 1999 I wanted to buy a Sun SPARCstation 5 (I worked with those). Was fabulous how that machine never blocked, was super-stable, and fast. At that time I had a linux PC box (red hat) at home, with IDE and PATA (if I remember correctly) it was really difficult for the hardware to perform.

Yeah, anything was better than ISA and IDE. But a PC with PCI and SCSI was much closer to SPARC/Alpha/MIPS/etc. performance at 1/Nth the price.

The were good machines, but they were stupidly expensive a that time. The same with SGI. I remember being quoted $18,000 for equivalent amount of memory I had just put in a linux box of my own for about $300. Sure, it wasn't really apples to apples ... but still. Intel based machines were eating their lunch for good reason.

They should have targeted a premium around what Apple charges for their hardware, not the absurd multiple they were charging.

Both sun and sgi had business models built around premium margins and couldn’t adapt the the mammals underfoot. This phenomenon is one of the things that The Innovator’s Dilemma got right.

Apple’s in a slightly different position in that they bank a more profit sun/sgi ever did and are pretty aggressive on COGS so if/when they lose their exalted position they will have a lot more room to maneuver. This is how Microsoft managed to survive its sag (decline is too strong anword) towards irrelevance and recover.

IBM was in the same situation as Microsoft but though Gerstner managed to right the ship, his successors were not able to re-ignite growth (to mix metaphors)

It always felt to me like Sun had great ideas and vision but was too early or idealistic. Seems like they would have missed at least $200 billion in revenue with follow through. Sun Grid is the AWS that never was. Chromebooks are the new Sun Rays.

I would argue that Sun's innovative output was a much larger missed opportunity than anything Docker has developed (then again, hindsight is 20-20). Yes, Docker has a lot of hype and has "brought containers to the masses" but I would argue it's nowhere near as revolutionary as ZFS/Zones/DTrace/etc. If I had been born 10-15 years earlier, I would've hoped to work for Sun. I've never wished to work for Docker.

As someone who maintains the container runtime underlying Docker (and contributes all over the stack), in my view there is a lot more innovative "core" engineering happening in the LXC/LXD camp than in the Docker camp. There are far more kernel patches coming out of LXC (and more kernel maintainers developing LXC) than have come out of Docker. And let's not forget, LXC came first to modern Linux containers. There is a lot of work going into Docker, but I guess I put more of an emphasis on OS engineering to determine who more innovative engineering on systems tools.

(Yes, there is Kubernetes but that's not a Docker project. If anything, Swarm emphasises my point. LXD has clustering too and they support real live migration between cluster nodes -- though CRIU has historically been a bit hairy.)

The tragedy of Sun is that they missed the opportunity to smite System V.

No offense to all the great people working at Docker over the years-- but after they came to see us right after they raised their series B, it immediately occurred to me that they had hired _all_ of the wrong people. I don't recall having had that visceral of a reaction like that with any other company. I think from the beginning they didn't really have a plan and it really showed IMO.

Missed opportunity or a contribution to where we are now?

I don’t reckon any of them failed, they succeeded in an unexpected way.

don't make me cry

> they could have licensed an enterprise version of the engine and taken a commission on every server in existence

Sounds like a great way to kill docker completely

Again I refer you to RHEL who have an open source version and an enterprise subscription. The Docker Engine taking a similar route rather than building another PaaS and bumping heads with Kubernetes seems an altogether more differentiated and defensible business model.

Again I refer you to RHEL who have an open source version and an enterprise subscription.

But the enterprise version is the open source version. Red Hat just didn't provide the binaries, now they even provide the binaries (since they acquired CentOS). Since White Box Linux, CentOS, and Scientific were started (which was pretty quickly after they launched enterprise Linux), they have been selling per-machine support and 'blame us when it does not work' licenses.

A similar approach may have worked, but it is not a given. Red Hat and SUSE arrived on the market when there we no big open source support companies. Once containerization turned out to be a good idea, the other open source companies could quickly adopt and provide support contracts for the same tech (which they have done).

Red Hat and CentOS don't have any official relationship. It's CoreOS you're referring to. RHEL's binaries may be available for some SW, but license-wise cannot be used for production workloads unless explicitly stated.

CentOS can be used for whatever you wish, but that's not a RH binary of course.

Totally official relationships: https://community.redhat.com/centos-faq/

So, it depends a lot what you consider an 'official relationship'. You cannot pay and be supported on CentOS. If you talk to Red Hat and you say 'we have CentOS running', the first thing they'll talk to you about is how do you migrate to RHEL, because no officially-supported products from RH run on CentOS.

That said, it is in RH's best interest to have a free version of RHEL that customers can try out and migrate their workloads to, precisely because it's easy to migrate them to RHEL. So yes, in that sense, there's some relationship.

You're correct though that there's a lot more relationship than I previously thought. Thanks for the link! I'll update my knowledge :).

> Sounds like a great way to kill docker completely

For a good open source ecosystem, a commission isn't like rent, it is more like taxes.

There's a balance point where paying someone else to debug and ship fixes for your problems approximates Adam Smith's pin factory.

The value part of an enterprise open source system is in turning around fixes fast and debugging on behalf of a customer.

>> taken a commission on every server in existence

As someone who's worked with Rob before, he gets it that you can't really squeeze money out by force.

However, there'll be enough people who pay you to air-drop committers on inexplicable problems & otherwise mostly pay them well to do what they already like doing - ship open source to the community.

They tried that when I worked for an $enterprise. But refused to support any RedHat-based images running on their engine. They also refused to license any of their products separately, seeming desperate to get a tax on any server on which Docker ran.

Neither of these went down well. RedHat had that market sewn up, and swatted Docker away like an irritating fly.

> But refused to support any RedHat-based images running on their engine.

You seem to have gotten that mixed. It was RedHat that refused to support anything (including their RHEL based images) on the docker platform unless it was run on the Red Hat's franken docker. It was RedHat that chose to not play fair, not Docker.

I was going to say much the same thing. The only reason Docker got so popular outside of Enterprise is because there were no cost barriers - and the reason it became popular inside of Enterprise is because it had become so popular outside of it.

I'm sure Docker did miss an opportunity to reap profits, but I really don't think there's as easy answer as to how they might have done that.

> Has there ever been a bigger missed opportunity in business than Docker managed to preside over? They could have created a huge business, but the product and go to market strategy has been awful.

The stories I could tell.. needless to say, looking back at the wasted opportunity is truly depressing.

We like those kinds of stories around here...

Like the time when Kubernetes, prior to it being announced, could have been a joint collaboration between Docker and Google.

I am amazed at how Docker bricked on Docker Swarm so hard.

I assert to this day that the only conclusion to choosing Docker Swarm is to rewrite a worse version of Kubernetes.

This developer, Gerhard Lazu, states otherwise regarding Kubernetes as he describes the infrastructure that he built for changelog.com based on Docker Swarm rather than K8s: https://changelog.com/podcast/254

Especially given we used to have Meetups at the office every Thursday night, where at least 1 new Orchestration project was launched/demoed every week.

The initial project the team worked on was called Beam. After about 6 months and no progress to show, the conversations referenced above happened and this is the result..

Kubernetes launched at the first DockerCon[1], early 2014. Swarm was launched[2] in beta in Dec 2014.

So, roughly 1 year late to market, 6 months after initial K8 launch.

1: https://www.youtube.com/watch?v=YrxnVKZeqK8

2: https://blog.docker.com/2014/12/announcing-docker-machine-sw...

I still rather like some of the output beam (libchan), just that GRPC came along and it's all history now.

But yes agreed this was all completely frustrating at the time, and completely depressing now.

That might have been great for Docker the company, but I wonder how it would have been for Docker the technology. Maybe Kubernetes would have ended up being less open.

I don't know much about it beyond my own perception, but I think of the cloud vendors are doing as much as possible to seem neutral / safe while usurping business logic at every turn. Things like an API gateway that's specific to a cloud provider seem like nothing more than super risky vendor lock-in to me. Another example is all the serverless rage with tech like Lambda@Edge and the equivalents. Who's realistically going to move that type of stuff between providers once they hit a certain scale?

However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible.

> However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible.

That's great to hear as it means it has served its initial intended purpose.

We take it for granted now, but the mere concept of doing this so easily in 2014 was really exciting stuff, especially when the workflow of build->publish to N cloud services is measured in minutes/seconds not hours/days.

Wasn’t Kubernetes introduced at Dockercon, and entirely built around Docker from day one? Seems like a pretty close collaboration to me.

What kind of collaboration could have taken place beyond that?

The two-ish years of Docker Swarm trying to fight with k8s and the weird tensions around Docker as the runtime in k8s probably wouldn't have happened if Docker had decided to join forces rather than actively compete.

Anyone familiar with how the swarm and k8s politics played out would know it was not a collaboration at all.

I agree that Docker took too long to embrace Kubernetes once it was obvious it had more momentum than all other orchestration projects combined. But nickstinemates suggests that Docker could have and should have “collaborated” much sooner than that, even before Kubernetes had launched. I wonder what that means in practice. What exactly should Docker have done, that they didn’t? And how would it have changed the outcome?

Docker could have never created Swarm and Compose at all. In hindsight if they went all-in on k8s from the beginning then they might now be the leader in enterprise k8s instead of Red Hat and IBM would be buying them. But this wasn't clear at all in 2014-2015.

Compose existed before k8s, and was created by a small company that Docker acquihired.

Personally, I like Docker Compose and Swarm, at the very least for non-production workloads - they're just so much lighter and simpler than k8s.

I actually would have liked to see Docker not give up on Swarm so readily. There's absolutely room for a something simpler than k8s.

Hindsight is 20/20. I recall looking at k8s and swarm closely circa 2014-2015. K8s wasn't very good. The networking worked best in the Google cloud .. not your usual datacenter. I recall concluding Swarm was the better tech. If history was any guide, k8s would lose steam. The borg connection .. I duno how much actual code went in there.

Kubernetes was evolved from Borg, which long predates docker, so no, it wasn't built around it. I have to wonder just how much Google knew they were going to squash docker from the time of that announcement, or if there's an even longer play going on here.

You may find this comment on a previous thread an interesting counterpoint: https://news.ycombinator.com/item?id=17580793

Though, as a counter-counter point, a blog post from Kubernetes itself states that it's got a direct lineage https://kubernetes.io/blog/2015/04/borg-predecessor-to-kuber...

My guess is that the truth is in the middle :)

That is a common belief, and a regular Google PR talking point, but it’s incorrect. Kubernetes is only vaguely inspired by Borg, and was created by different people, using different technology, endeavoring to solve a different problem.

In fact you could say Kubernetes was evolved from Docker, much more than it was evolved from Borg.

This is definitely true, but as you say orchestration frameworks were a dime a dozen at the time, and Kubernetes, when launched at Dockercon, was barely that.

Of course we actively chose to not collaborate on it, even after it matured a bit and had a good community.

You once told me that if we (the company) don't succeed it will absolutely be our own fault.

So many avenues to (huge) success, shutdown hard by the wrong attitudes towards the rest of the market.

Well, we did what we could and hopefully learned a bit in the process

I never understood how it was even possible for a relatively small sliver of the dev stack to command a $1b valuation.

Yep, this is it. Great technology, but it's not _the_ technology for developers, as the past years have clearly shown.

what else is used in production commonly?

"Production" is a very broad set of environments, many of which containers are completely irrelevant for. For some developers, the answer to your question is "ClickOnce" because they're building a Windows Forms application that is critical to their business.

I think folks miss this point all too often. Docker is like an engine. Every vehicle needs an engine but there are a shit ton of engine options.

Ultimately the valuable bit is the vehicle or what you do with it, not the engine.

Folks get too focused on the deeply primitive tools and miss the larger picture.

I can pinky promise you that the majority of the larger picture that is up to date / building net new stuff uses Docker, which is why I was looking for alternatives that are popular (because I'm not aware of any and I don't think ClickOnce has any significant market share...)

Duct tape, mostly.

In #devops is turtle all way down but at bottom is perl script. - @devops_borat

... via http://github.com/globalcitizen/taoup

> Has there ever been a bigger missed opportunity in business than Docker managed to preside over?

Digital had VMS, and lost slowly in the marketplace until they lost Dave Cutler to Microsoft, then VMS started collapsing. Cutler showed what he could achieve with decent backing and a company not wedded to selling expensive proprietary hardware.

Digital had the Alpha processor.

Digital had the StrongARM processor, the fastest commodity ARM chip on the market, and sold it to Intel because what future did ARM have anyway?

Digital had AltaVista.

There's plenty more, but those are some highlights.

Xerox and the personal computer at the level of what became engineering workstations. The book Fumbling the Future: How Xerox Invented, Then Ignored, the First Personal Computer covers this fairly well as I remember.

I agree it's a mess. We have docker swarm, docker compose, "regular" docker, the Moby fiasco. I'm just waiting for Enterprise Docker Faces to surface at this point.

Kubernetes isn't that great but it's less of a disaster than the current docker ecosystem.

I'm convinced another player will come in taking the best of both and give us something reasonable to work with. Maybe in 5 years or so...

Istio looks promising. The missing piece has always been convenient inter-container communication. I think something with mesh and gRPC baked into the core for strong service contracts would blow everyone else away.

Biggest? Nah. Like so many tech companies, Docker didn't have a business plan. Or,well they did have one, which they mishandled, based around container orchestration. But, then along came Kubernetes and that was that.

> The whole pitch towards legacy apps was also short termist distraction when investment dollars are all going to cloud native solutions. Legacy apps are a big business case but getting companies to invest in their legacy estate is still a tough ask.

Don't even get me started. Leadership wanted Docker to sell "MTA" (Migrate Traditional Apps) and Docker probably spent a few million to the middleware folks sitting in a room developing "archetypes" instead of TCO to position with the customer as output of the time and money containerizing those apps would save. Instead the push from sales leadership was "sell them on the value". What value? We couldn't prove we were providing any unless we did the containerization. And in the case where we could get services to handle a few freebies they were always the easy ones that didn't truly show anything. It was and is a horrible miss. I'm not sure if that's what they're still focused on but it didn't resonate with customers or prospects.

Right before I left Docker was moving into positioning Docker Enterprise for Desktop. They had ridiculously high limits on seat sales and we're going to charge ridiculous premiums per seat. Clearly nobody in leadership realized that the UI provided to bootstrap some simple framework wasn't worth that. But nope... So many wasted resources on products that add no value.

The core of docker is just cgroups, and, well, they didn't develop it, that is in the Linux kernel and GPL.

What exactly would an enterprise version offer that would make someone pay a per-server licensing cost?

> What exactly would an enterprise version offer that would make someone pay a per-server licensing cost?

Orchestration. Compose/Swarm, which Google gave away for free as k8s (In the interest of completeness, I'll add Hashicorp's Nomad will also orchestrate containers as well as binaries). The idea of Docker monetizing died with that action by Google (and to a lesser extent, Hashicorp, although Nomad does have an enterprise version which corps are paying for and using). Google needed something to slow down AWS adoption, and Docker was collateral damage. The rest of necessary tooling for container management (build, pull, push, local dev management, registries) is fairly trivial [1].

Now anyone can run Kubernetes (or Nomad), either self-hosted or with a hosted provider, which is great for the industry but not so good for Docker.

[1] https://github.com/p8952/bocker (Docker implemented in around 100 lines of bash)

As opposed to K8 implemented in around 100 million lines of whatever.

Security features, support, integration with a Docker Data Centre type management console and other complementary tools.

Exactly the same model as Redhat RHEL, who incidentally are the only profitable open source company ever.

Hortonworks was profitable before Cloudera acquisition. Rob Bearden was CEO of Hortonworks before coming to Docker as well.

There are a bunch of profitable open source companies (SUSE, nginx, Joyent, etc) -- Red Hat just happens to be largest.

Nothing. Without any secret sauce, an open source clone of an "enterprise" Docker would have been built virtually overnight.

Docker does have an "enterprise" version (called Docker EE). I'm surprised so few people have heard of it.

Probably because there are so few reasons to use it.

A much better alternative is Rancher. 100% open source.

Given Docker's a packaging format (effectively) a packaging and distribution story that's at least on a par with Debian or Red Hat would be valuable. Instead of rediscovering packing and distribution from scratch and delivering complete sacks of shit like "30% of images on dockerhub have serious security vulnerabilities" or "whoops leaked our user credentials".

The problem is that Docker engine alone is not much of a project, you need something higher level to control which containers run on which machines.

That wasn't a likely outcome; containers are too critical to platforms like Kubernetes for those platforms to allow them to be locked up by a company with an enterprise subscription. Also they aren't hard enough for that to work; there's lots of experts out there around namespaces that would write an alternative container runtime before getting locked in that way.

The elephant in the room for Docker is that there's not an effective way to monetise it - Docker Hub subscriptions clearly aren't going to cut it for a company with lots of investment and hundreds of employees.

In retrospect they should have partenered with a company like digitalocean to create a docker cloud platform.

My job was to create these opportunities and they were there - internal politics prohibited them from getting done.

Prior to all of the Docker as a Service endpoints getting launched, there was an internal pitch for a Docker as a Service program aimed at all of the cloud vendors as part of a Docker ubiquity/available everywhere strategy.

The push back internally was that we should create these integrations and sell them to the cloud vendors. That was never going to work, but, about 3 years past the mark we started talking publicly about 'Docker Editions.' A little late to the party by then..

Docker never had a viable business model, this was obvious to everyone in the space since day 1.

I disagree. From the inside, there were a few obvious business models.

The reality was bifurcation of effort and lack of alignment.

From the outside, there weren’t. App Store model with Docker Hub was never going anywhere without an entrenched platform, which you couldn’t possibly build because you didn’t have the talent (no offense at all here, the market was and is insane) and even if you had, there was too much competition from other players. Licensing wasn’t feasible, not enough value-add, and too many viable alternatives waiting in the wings for you to overplay that hand. And any secondary market that showed promise was already swarming with other companies “integrating” with Docker and making their own value props. What alternatives were there? I never saw one.

DigitalOcean.

Reply on news.ycombinator.com