Last month,  Microsoft declared that “dev containers have become broadly useful for scenarios beyond VS Code” and introduced an open source development containers specification which formalizes a configuration file called devcontainers.json and the capabilities it supports.

Remote development is a hot area in developer tools. Microsoft’s GitHub has Codespaces. Jetbrains has an IDE backend that runs remotely allowing developers to code locally while compiling and debugging on the remote machine. Gitpod, a pioneer of this approach, integrates with GitHub, Gitlab and with Jetbrains Gateway, and spins up developer environments in remote containers.

The appeal of remote development is not only the ability to work from any machine, but also having  predictable, reproducible and disposable development environments, rather than the traditional developer PC with all sorts of tools and dependencies installed.

A key part of this process is defining the target environment, which in most cases is based on one or possibly several containers. The starting point is the container image but there is also a requirement to configure the container with mount points, environment variables, startup tasks, port forwarding, and other customizations.

Visual Studio Code used devcontainers.json for this, developed for the remote containers extension first released in 2019 and now also used in Codespaces.

At the same time as Microsoft introduced the open source development containers spec, it also released a CLI (command line interface) as a reference implementation. With the CLI installed, and a devcontainers.json configured, a developer can start up a development environment on the local PC equally as easily as on Codespaces, hooked to the same GitHub repository.

But is the Microsoft-sponsored Development Containers specification just for Microsoft or something that will get wide adoption? Gitpod has its own YAML-based equivalent, .gipod.yml, but users have found the differences a source of friction, causing Gitpod co-founder Sven Efftinge to work on support for devcontainer.json, even before Microsoft’s recent announcement.

“Given VS Code’s and GitHub’s dominance in the developer world, VS Code’s devcontainer.json format is going to become a quasi-standard eventually. Supporting it will allow us to lower the entry barrier for teams who already use it so they can easily spin up their dev environments in Gitpod,” Efftinge said last year.

Users like the idea, with one even finding lack of interoperability a blocker, saying “after running into this issue I ended up losing interest in Gitpod and not pursuing it further. Never ended up getting .gitpod.yml working.”

Another remarked that it would “be nice if there was some open governed group maintaining standards like these for devtools.”

Docker was cooler on the idea, with a spokesperson telling us it was “all Microsoft” and pointing us  towards its Compose specification, though also emphasising that it does collaborate. Docker has its own support for Dev Environments in Docker Desktop but this is currently for local use only. Dev Environments do use VS Code though, and devcontainer.json is not an alternative to Compose but can work with it.

Microsoft told DevClass that its goal is to “allow anyone in any tool to configure a consistent environment with dev containers, including tools beyond VS Code or Microsoft,” and emphasising that “we did not envision this spec as a VS Code-only concept.”

The company also mentioned the importance of the spec for continuous integration and testing as well as development, and that “having an agreed upon structure of this dev-specific data is good for everyone.”

That said, contributors to the spec seem to be all-Microsoft and the only “supporting tools” currently listed are VS Code and the new CLI so it cannot yet be described as a cross-industry project. Another point of interest is that the specification includes a proposal to add “features,” which define capabilities to be added to a container, and inevitably there will be debate about what belongs in the base container image and what it would be better to add later.

The notion of a common specification is an attractive one though, giving developers freedom to use different tools as well as developing locally or remotely.