So, why did I leave Gitpod? It's hard to pick a particular singular reason but that internal all-company letter which was sent weeks after a wonderful, yet extravagant offsite, really spooked me; like I have been homeless before and I'm sure as shit ain't going back there...
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 it internally, but 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 the experience of customers comes first and so that all employees serve the customer...
There is little point expending energy on awareness to bring in 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 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 literally 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.
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 back 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 is 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 for 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".
the Gitpod workflow will soon be replicated
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 really shine.
Thanks for reading btw.