How does Coder’s code-server differ from GitPod’s OpenVSCode Server?

This is a great question, and quite a few people have wanted to know after GitPod’s recent announcement. At their core, both projects extend Microsoft’s open-source VS Code. However, the GitPod team describes their project as attempting to apply a minimal set of changes, as per their readme:

VS Code has traditionally been a desktop IDE built with web technologies. A few years back, people started patching it in order to run it in a remote context and to make it accessible through web browsers. These efforts have been complex and error prone, because many changes had to be made across the large code base of VS Code.

Luckily, in 2019 the VS Code team started to refactor its architecture to support a browser-based working mode. While this architecture has been adopted by Gitpod and GitHub, the important bits have not been open-sourced, until now. As a result, many people in the community still use the old, hard to maintain and error-prone approach.

At Gitpod, we've been asked a lot about how we do it. So we thought we might as well share the minimal set of changes needed so people can rely on the latest version of VS Code, have a straightforward upgrade path and low maintenance effort.

Personally, I find their recounting of the project’s history to be a bit misleading. I suppose it’s accurate to say that Gitpod first started with a fork of Microsoft’s repo, while we initially went with a submodule approach. Or that they’re going for a "minimal" set of changes, which I believe is technically true if we're comparing line counts across our respective projects.

But what I find especially...interesting, is how their phrasing promotes "OpenVSCode Server" as if they're thought-leaders in this situation, and that they’ve decided to graciously share their approach over the "old, hard to maintain and error-prone."

Gitpod’s messaging has changed over the past week as well, first by linking their readme to an issue I wrote regarding a refactor of code-server, albeit in a misleading light. That link has since been removed. One might think that by reading Gitpod’s announcement first, they were actually the team who guided both us and the greater open-source community, toward a better architecture.

But...if you happened to catch that our refactor began well before Gitpod’s announcement, you might get the impression that they’re trying to reframe these events to Gitpod’s apocryphal advantage. Personally, I was frustrated to see their project launch under what I believe is attempt to redirect the public discourse as code-server being old, hard to maintain and error-prone. Ironic given the fact that I was busy this week with a major refactor to our server implementation, but I suppose anything worth anything is worth fighting for...

Lastly, I was also surprised at their project name, "OpenVSCode Server", which in my opinion, not only draws comparison to Microsoft’s trademark, but also adds confusion to our existing project. Ultimately, code-server is MIT licensed and everyone’s free to copy with attribution. And while I can’t say for certain, there are parts of Gitpod’s project that look similar enough to give me déjà vu, even beyond the commonalities of two projects targeting an API and linter defined by Microsoft upstream. Honestly, I wouldn’t mind our projects aligning so much if I didn’t get such a strange territorial vibe from their team, but I hope that this is all just a small part of a larger misunderstanding.

I suppose all I’m looking for is an upfront acknowledgment of the great work put in by both myself, the engineers at Coder, and all you wonderful people.

Anyway...that’s a lot of words to still not answer the question, "What’s the difference between these projects?"

Well, this is our approach to building code-server:

• Add the server functionality not included in Microsoft’s open-source offerings in such a way that it conforms to their project guidelines, making it easier for us to keep up with version changes.
• Retain a high degree of understanding in upstream’s architectural designs so that we can build features faster and with fewer issues.
• Implement extra features the community frequently asks for, such as TLS via Coder Link, and an open-source replacement for Settings Sync.
• Eventually, offer our changes back upstream as pull requests, minimizing the differences between our fork and mainstream releases.

Thank you all again for reading my very long reply. I think this is about as close to the right answer I can give for now, but if this doesn’t suffice, I hope the upcoming releases of code-server will say enough.

~Teffen