So, why did I leave Gitpod? It's hard to pick a particular singular reason but that internal all-company cost-cutting letter which was sent weeks after a wonderful, yet extravagant offsite, really spooked me; I guess it would be easy for leadership to paint me as disgruntled, but the reality is that as a holder of common stock in the company I'm constructively concerned about strategy, leadership, burn-rate in this economic climate and the following...
The admin panel after two years is still public on the internet
When I first joined the company, I became very uneasy that the administration interface at https://gitpod.io/admin is public on the internet and raised the problem internally. However, almost two years later all employees still have access to download customers' source code and environment variables via personal GitHub accounts.
Back in March 2021, there was a security incident where access to the administration panel was deployed in production - wide-open-by-default - without authentication, and it was never disclosed to customers. With a cumulative total of $36 million raised in venture capital, and after this incident occurred, you would think Gitpod would have hired a single security engineer by now...
Customers come last
I could write an entire blog post on this, but something structurally needs to change within Gitpod so that customers' experience comes first and that all employees serve the customer...
There is little point in expending energy on awareness to bring people into the funnel when the bottom is haemorrhaging due to product quality and service availability issues.
Preaching DevX but not shipping it
An incredible amount of energy is expended on preaching to others that companies should care about "Developer Experience" but little effort in my time was expended on actually shipping developer experience features internally.
At last count, 11 employees of Gitpod are full-time doing software development building Gitpod with Gitpod from the JAPAC region with 300ms pings to clusters in either Europe or North America. Fun question:
"how do those employees feel when they see talk about the importance of DevX but see no action on the #1 that hinders their personal DevX productivity?"
Spamming OSS projects as a growth strategy under OKR
If you look at the careers page for the replacement role of myself, you’ll see a term.
Gitpodification means spamming popular open source repositories with pull requests designed as billboards that advertise the virtues of Gitpod under OKR where employees are micromanaged in retrospect as to why a maintainer didn’t accept/merge the
Open in Gitpod in the readme of the project.
All evidence that this activity has been occurring is public. I tried, again and again, to educate leadership that spamming open-source as a growth strategy is a super bad idea. Gitpod has tried Gitpodification once before, and when feedback from the open-source community that this activity was harming the brand was relayed back to my 1-up my concerns were dismissed and told to "just do it anyway using your personal GitHub account".
Microsoft is strategically evicting Gitpod
Microsoft is back doing anti-competitive things again but this time in the Visual Studio Code ecosystem. Microsoft has fractured their developer ecosystem in a way that makes anyone who uses VSCode in their service offering effectively an advertisement for two similar Microsoft services (GitHub Codespaces and the soon-to-be re-launched Visual Studio Codespaces) that don't have the purposefully designed developer experience paper-cuts that companies that consume the MIT source code will experience.
I can't say that I blame Microsoft's approach here - salaries of engineers who specialise in language tooling are expensive, and by my napkin math, it will at least take circa $9mill/year in additional salaries for Gitpod to be able to compete against [GitHub|Visual Studio] Codespaces. As detailed in the blog post below, there will soon be no Microsoft-maintained language servers (what people refer to as "VSCode") in the future that Gitpod will be able to use legally...
Competing against Microsoft is never fun. The way Microsoft enforces their competitive advantage is by making something the default. Paul Stovell, Founder and CEO of Octopus Deploy witnessed this first-hand in 2016.
Overnight it became the default. We were exhibiting at Build 2016 at the time much of this was announced, and I remember people coming to our booth asking "so why should we use you over the Microsoft thing?". The "Microsoft thing" was announced only 5 minutes prior!
Reproducible developer environments are a movement and not a unique feature of any one particular product
Reproducible developer environments are indeed a sleeper technology that’s going to ramp up for a decade in usage until, one day, everyone will be “behind the times” if they’re not already using them, but I think the industry is heading in a different direction to the techniques used (ie.
.gitpod.yml) and advocated by Gitpod.
The problem with
workspace-images is that customers do not get security updates unless a Gitpod employee remembers to update this magical line in each one of the Docker chunks.
The problem with
.gitpod.yml is that it dictates a particular way to achieve reproducible developer environments that are locked into a singular vendor vs the competing
devcontainer.json open-standard which Microsoft is shipping as the default product experience in Visual Studio Code and GitHub (and soon Visual Studio) Codespaces.
If there's one thing I've learned in my 40 years around this sun is that whatever Microsoft ships as the default is the thing that will win.
However, I think both approaches are missing the bigger picture that the industry is looking past Docker and towards tools such as Nix (or Guix) as they provide reproducible developer environments whilst also providing tooling that enables complete ownership of ones software supply chain (via source/binary substitution) and the generation of software bill of materials.
It's no secret that I'm a fan of nix, the build tooling stole my heart four years ago after a research detour into academia and after 19 years brewing in academia, nix is going mainstream...
In this economic climate, I don't think any product should dictate reproducible developer environments (or tooling such as nix) before value can be derived as doing so introduces way too much product adoption friction.
The key to winning the valuable enterprise market is to integrate in with how enterprises currently work, minimise the amount of people/process change required and thus de-risk the political costs for a products internal advocate.
Requiring people to add
.gitpod.yml in each one of their git repositories is way too much of an ask. I was quite vocal about this topic internally during my time at 'pod because open-source maintainers kept pushing back at the prospect of "adding another yml".
Gitpod's innovation has ground to a halt
When I first heard of Gitpod (circa 3-years ago) and they later asked me to join them I was excited about three features: prebuilds, workflow and ephemeral workspaces.
Gitpod was 1st to market with the concept of pre-building a developer environment, but in this small window of time, GitHub has since re-implemented the concept in a better way via GitHub Actions, the
devcontainer.json open-standard and through advertising/educating their customers about the feature in the GitHub user interface.
the Gitpod workflow
Typically creating a workspace is done by prefixing any GitHub URL with
https://gitpod.io#https://github.com/gitpod-io/gitpod. However, GitHub has since implemented and popularised the convention of converting GitHub URLs from "dot com" to "dot dev".
Thus to open
https://github.com/gitpod-io/gitpod in [GitHub|Visual Studio] Codespaces it's as simple as either pressing "." on your keyboard or converting the URL to
Alternatively, one can just click on the giant green create codespace button in the GitHub user interface by default.
Whereas Gitpod requires people to know about their browser extension to achieve the same functionality.
One of the key differences between Gitpod and [GitHub|Visual Studio] Codespaces is the workflow that Gitpod prescribes of one workspace per branch but ...
In three years Gitpod hasn't shipped new innovations. Yes, there was that JetBrains partnership announcement, but feedback so far from customers has not been great.
This sector moves fast; GitHub has already cloned many of the key value propositions of Gitpod. Newer competitors such as Okteto have sprung up and are piggybacking off Gitpod's marketing spend to promote Okteto's product - which to be clear - is a competitor of Gitpod...
Kubernetes is the wrong abstraction layer
A development environment on Gitpod happens within a Kubernetes pod. It's pretty neat, but upon reflection, I think Kubernetes is the wrong abstraction layer for Gitpod for the following reasons:
- A product designed around Kubernetes constrains an offering to software developers who use containers. In this economic climate, enterprise companies want a singular tool that works for all software development scenarios - including windows desktop development, macOS mobile development and data science (ie access to beefy GPUs).
- Kubernetes is complex. Enterprises do not have significant experience with Kubernetes and thus selling/supporting Gitpod as an on-prem product is going to be a painful and expensive cultural transformation that I don't want to be part of.
- I think containers are not a secure enough environment isolation technique for a remote code execution as a service business aka running untrusted public workloads. Gitpod does some really cool things with Linux namespacing, but it isn't enough (security-wise), and it comes at a price (product-wise / see below)
- For almost two years it has not been possible to run Kubernetes natively on Gitpod due to the above. One of the key motivators for customers moving a development environment away from a local laptop and into the cloud is to be able to run cloud-native workflows and applications. And on Gitpod, you can't.
and that's about it. In all, I don't regret working at 'pod, and it is a company that is full of really nice people, but there are structural, strategic and leadership issues that need resolving before the product/company will shine. Overall it saddens me that the company has switched into value extraction mode over innovation and hasn't kept up with the competition.
Thanks for reading btw.