'There is no way we can keep coding local': GitPod's cloud development platform released into sunlight of open source

The Reg chats with co-founder Sven Efftinge

Interview GitPod, a platform that enables developers to create cloud-hosted development environments and to code in a web browser, has published its source on GitHub.

The GitPod service uses containers running in a Kubernetes cluster, providing an ephemeral development environment, with developers generally coding in a web browser using Eclipse Theia, similar to Visual Studio Code (VS Code) and compatible with its language server protocol – the key to driving intelligent IDE features like syntax highlighting and auto-complete – as well as most of its extensions.

You don't have 'works on my machine' situations; everything is reproducible. You can also snapshot yourself, share a link on StackOverflow, and everyone can recreate that situation

Theia cannot use the VS Code extension marketplace for licensing reasons, but can use an open alternative called Open VSX.

GitPod co-founder and CEO Sven Efftinge is a Theia project lead, but he played down the IDE's importance. "We are not opinionated about the IDE, not at all," he told The Register. "We are currently using Theia but we are going to open that up and allow other IDEs as well."

The essence of GitPod, rather, is the ability to define a development environment as code and have it start up automatically when a developer is working on it.

"At GitPod you put a YAML file into your repository, you version it, alongside your CI [Continuous Integration] information, that points to a Docker file where you list all the tools and also what scripts should be executed," Efftinge told us.

"The GitPod server will watch your repository and then when someone pushes code, it goes through all the automation and takes a snapshot of the environment at the end. That prepared snapshot is sitting there waiting for developers to start coding.

"You don't have 'works on my machine' situations; everything is reproducible. You can also snapshot yourself, share a link on StackOverflow, and everyone can recreate that situation."

This approach is also, according to Efftinge, distinct from what GitHub and Microsoft are doing with Codespaces, despite some similarities. CodeSpaces is still not generally available, Efftinge observed, and with GitPod "everything is prebuilt automatically so I can have ephemeral dev environment, but with Codespaces it's the same as I have locally because I reuse the dev environment."

The GitPod source, a Kubernetes application with around a dozen microservices, is now on GitHub here. Why has it been published as open source? Efftinge said that for him, open source is the norm. "GitPod is really my personal first non-open-source project. We figure this is holding back adoption.

"Community members ask questions about the source code or say, 'Can I provide an integration for this and that, I would like to try this and that.' Putting everything open source puts us all in the same room.

"People can try integrations, build on their own, contribute back. Also if they figure they have bugs, try to fix them themselves rather than waiting for us."

What is the licensing model?

"We are going for a core model very similar to GitLab or Mattermost, where we will make all the source code available and most of the functionality is under the AGPL licence. Then there is some code that is enterprise licence."

The intention, said Efftinge, is that "things that are more important to companies and enterprises and managers rather than developers, analytics, security things" will be under the enterprise licence.

"The developer stuff, we want to have that in the open source part," he said.

GitPod can either be consumed as a hosted service, or can be licensed and self-hosted. It will in principle run on most Kubernetes distributions, but there is some affinity with Google Cloud Platform (GCP). "GitPod.io runs on Google cloud and we also suggest that GitPod self-hosted runs well on GCP," said Efftinge. "You can also install it on other Kubernetes; one caveat is we need containerd running. Currently OpenShift doesn't work, for instance. But most Kubernetes distributions just work. We will also have Terraform scripts for AWS. Long term we will add more platforms, and hopefully the community will help us."

Theia running in front of a GitPod cloud development environment

According to Efftinge, cloud coding and cloud native development are a natural fit. In the old model, developers set up their own PC with everything needed to build and debug locally, and while this works well for desktop or monolithic applications, it becomes more difficult when applications formed of multiple microservices. "You don't want to run that directly in your dev environment," Efftinge told us. "You want to have a preview application that you apply automatically as part of your continuous integration pipeline, and then you start a dev environment with GitPod that automatically runs next to that and allows you to change and debug the individual components.

"We have been developing GitPod in GitPod for almost two years now. It's a Kubernetes application, we do exactly that. Nobody needs to set up something like Minikube [a single node Kubernetes cluster in a VM] locally."

Are you local?

JetBrains, which markets a popular range of IDEs written in Java, does not have a cloud IDE and told us a couple of months ago: "It's not easy to create a good technical solution, to have an IDE in the cloud. Developers still prefer to use desktop."

"I think they have to say that," said Efftinge. "There is no way we can keep coding local. The drawbacks of that, like having everything on this one big machine, there's just no way this is going to survive the landscape of code native applications."

He referred us to “a really bad shitstorm on their issue tracker”, presumably this thread on the JetBrains IDEA issue tracker, where customers complained that VS Code is far ahead for remote development. "This feature is absolutely critical to both my productivity and to avoid mental fatigue and burnout when dealing with latency. If VS Code feature completeness encapsulates the subset of IntelliJ features that I frequently use, I will likely not switch back," said one.

Dmitri Jemerov, a lead developer at JetBrains, said: "We have several initiatives in place to provide a great experience for fully remote development. Unfortunately, at this time we're unable to share any specifics or time frames, as getting the best possible experience requires massive-scale architectural changes to our codebase, but we've been working on this for quite some time already and we believe that we will have a solution that will go above and beyond what VS Code delivers today."

That was back in May, but lends support to Efftinge's view. When it is done, "we are happy to integrate," he said. ®