Hacker News Reader

Comment by studmuffin650 | Hacker News Reader

Interested to see if they can successfully pivot to full SaaS. It seems like with the recent AWS announcement of CodeCatalyst and Github CodeSpaces (both of which are free with an additional easy to use paid model), Gitpod has been backed into a corner. I hope they do well, but the odds are stacked against them as the enterprise selling machines that are Amazon and Microsoft are incredibly difficult to fight as a startup. With Gitlab also apparently working on their version of CodeSpaces, it seems like maybe the best position for Gitpod is an acquisition (possibly by Atlassian).

View on HN

> It seems like with the recent AWS announcement of CodeCatalyst

I took Code Catalyst for a spin the other day and it is terrible.

https://twitter.com/GeoffreyHuntley/status/15997732931288637...

> It seems like maybe the best position for Gitpod is an acquisition (possibly by Atlassian)

I agree. I used to work there and think they need to slash circa 40 employees to shrink down to more sustainable burn rate numbers - https://ghuntley.com/tea

> but the odds are stacked against them

In more ways then one https://ghuntley.com/fracture documents Microsoft's strategy with Visual Studio Code which means 6 out of 10 top programming languages integrations only work on GitHub Codepaces. If you want .NET, C++, C, Python or Jupyter then the LSP integrations cannot be legally used on Gitpod.

GitHub Codespaces got one thing right - they chose IaaS as the brick of compute meaning they can do GPUs and run Kubernetes clusters. On Gitpod, you can't because Gitpod chose Kubernetes as the compute abstraction. Gitpod needs to ditch Kubernetes...

https://github.com/gitpod-io/gitpod/issues/4889 and https://github.com/gitpod-io/gitpod/issues/10650

How is Coder going to compete against GH/MSFT?

Hmm. We find that GH/MSFT customers come to us (especially Microsoft Azure DevOps customers which have been abandoned) and GH is categorically providing non-answers of "we are investigating offering on-prem" but they have done that for a long time now - ie. a classic sales tactic to keep MSFT aligned people hopeful vs saying no.

Microsoft has been retiring on-prem products as a business strategy for over 12 years now. Why would GitHub be the snowflake exception? Somewhere, in some CVP's mind GitHub ES is already EOL (look at GitHub.com/enterprise they are already muddling the meaning of "enterprise")

If you look at /.codespaces/bin or /workspaces/.codespaces/shared on GitHub Codespaces you'll understand how tightly coupled GitHub Codespaces is to Microsoft Azure thus on-prem isn't going to happen. The likely path they could do it would be like JetBrains Spaces does it "configure in our IAM/ARM key and we will provision Azure/AWS virtual machines" via GitHub Enterprise Server.

$ ghuntley /workspaces/.codespaces/shared $ grep sku * environment-variables.json: "skuName": "Standard_F2s_v2",

If you want further information check out https://coder.com/blog/github-codespaces-coder-and-enterpris...

MS have a VS code server which is in private preview now. it's very much like a self-hosted Codespace if you squint and write a tiny bit of automation around it.

license forbids using it to host a service for others, but you can host it for yourself.

> the LSP integrations cannot be legally used on Gitpod.

Can the user install them? How complicated these are? Is there some awareness about this in OSS communities? If yes, is there some kind of consensus? (Is it something like: okay, then each programming language project needs to provide its LSP, like Rust has rust-analyzer, Scala has Metals, etc..?)

> Can the user install them?

Doing so is not legal. Here's the standard boiler plate license for the LSPs

> You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services to develop and test your applications

https://marketplace.visualstudio.com/items/ms-vscode.cpptool...

The key here is VSCode (MIT) is NOT Microsoft Visual Studio (the product) and only the product can use the LSP's, tools such as GitHub Copilot or the Visual Studio Marketplace Ecosystem.

> Is there some awareness about this in OSS communities?

Yup

https://github.com/search?q=repo%3AVSCodium%2Fvscodium+pylan...

https://github.com/VSCodium/vscodium/issues/1020#issue-11802...

> is there some kind of consensus? (Is it something like: okay, then each programming language project needs to provide its LSP, like Rust has rust-analyzer, Scala has Metals, etc..?)

The consensus is that programming languages need to author their own LSP integrations and not allow Microsoft to build it. It's why rust-analyzer, go, metals are self-developed by their communities.

Again https://ghuntley.com/fracture recaps the problems w/VScode and how Microsoft is building a GitHub 365 vision through VSCode.

The actual repo seems MIT though https://github.com/microsoft/vscode-cpptools/blob/main/LICEN... ... what is missing from this?

CEO of Gitpod here - we just announced a $25m Series A last month (https://www.gitpod.io/blog/future-of-software-cdes), so not looking to get acquired anytime soon ¯\_(ツ)_/¯

On the market landscape: the whole market around CDEs (https://www.gitpod.io/cde) is in its infancy. Our largest competition is local development. We believe that unlike for other creative workflows the convenience threshold for development in the cloud has not (yet) been crossed. We are moving away from self hosted to execute faster on what we always wanted: from history-dependent cobbled local development environments to consistently reproducible, instant, ephemeral Cloud Development Environments (CDEs). You can think of CDEs (https://www.gitpod.io/cde) as our product north star.