The end of Docker? The reasons behind developers changing their runtimes

# The Issue with Docker in the Current Landscape: ## 1. Changes in Docker Desktop Licensing and Cost: Docker’s choice to position Docker Desktop behind a paid membership for bigger organizations was among the most obvious turning points. While people and small projects could keep using it freely, companies discovered they had to pay for something once free—and not always any better than the new choices. This action not only infuriated me but also let developers examine their reliance on Docker more closely. Open-source proponents and cost-conscious teams began wondering whether Docker’s worth warranted the additional outlay. ## 2. Performance Issues, particularly with Windows and macOS: Docker runs rather well on Linux. Docker Desktop has long been a hassle for macOS and Windows users, though. Particularly during heavy builds or multiple container orchestration, it emulates Linux containers using virtual machines, resulting in slow performance, excessive CPU consumption, and battery drain. Conversely, new solutions like Lima used under the hood by Finch offer more effective virtualization customized for developers, hence improving performance without the complexity and bloat of Docker Desktop. ## 3. Security Risk: Root Daemon Problem Docker’s dependency on a root-running daemon is among the architectural choices it most faces criticism for. This central service controls containers and calls for higher privileges, therefore augmenting the possible attack surface in manufacturing settings. Although Docker has evolved over time with features like user namespaces and rootless mode, security-conscious organizations typically want alternatives created from the bottom up with security in mind—like Podman, which operates totally without a daemon and can function as a non-root user. … ## 5. Vendor Lock-In Fear Developers are finally cautious about delving too deeply into Docker’s private tools. Though generally embraced, even the Dockerfile syntax is not controlled by an open standard like the OCI image and runtime requirements. Especially when open standards promise more flexibility and long-term stability, developers prefer to avoid being limited to a single toolchain.