I assume a huge part of why GitHub is okay with this is that VS Code / Codespaces and Azure are both products from the same company. :)
I do think there's a serious autonomy question here, and I think companies do actually care a lot about maintaining their autonomy from other companies, and in many cases the incentives align a lot. The whole stack here seems like something that you can run internally / self-host:
- Codespaces are specially-configured containers. All the standard infrastructure for running containers (Docker, Kubernetes, etc.) is FOSS and is quite reasonable to run internally. It's not even like OpenStack where it's a knockoff product of what the major cloud vendors run: it's literally what the cloud vendors run.
- Shallow clones, pre-built running containers, etc. are all deployment practices, not products.
- You can ssh into a codespace.
The big problem here in my eyes is that it's reliant on VS Code, whose remoting stuff is not FOSS (and, having tried it at my own workplace pointing it at our self-hosted Kubernetes, it's been a pain to get it to work well with our authentication setup, proxies, etc. without access to the code and we have a number of open bugs filed). I think the challenge is for a free-software IDE to adopt the VS Code model of the IDE running locally but executing code (including running the LSP backend) remotely.
And, in a sense, Emacs already supports this just fine with TRAMP. It's just that the experience of using Emacs and the experience of using any modern IDE (VS Code, any of the JetBrains IDEs, whatever) are very different... and none of them are FOSS.
If you have a FOSS IDE, I think you can get this whole setup working well in a way where you have autonomy over the setup and where you can understand the details just fine. And even if you're using VS Code, you can set all of this up in a way where you're not contacting any external services.
Do you have more details on this? I thought VC Code just uses the language server protocol for remote editing, which supposed to be an open standard. What stops say neovim adding full LSP support?
LSP is definitely an open standard and you can make that work just fine. What I mean is that the components of VS Code itself that do remote execution are not open source, so if it's VS Code that you're running, you're a bit at MS's mercy for how you make it work (my current issue is that it downloads a VS Code remote agent into the container, and that download doesn't work right inside our corporate network, and there's no way to modify that).
If you're not running VS Code, then this isn't relevant to you and I'd imagine you can get a good experience via Neovim using LSP + netrw.
I do think there's a serious autonomy question here, and I think companies do actually care a lot about maintaining their autonomy from other companies, and in many cases the incentives align a lot. The whole stack here seems like something that you can run internally / self-host:
- Codespaces are specially-configured containers. All the standard infrastructure for running containers (Docker, Kubernetes, etc.) is FOSS and is quite reasonable to run internally. It's not even like OpenStack where it's a knockoff product of what the major cloud vendors run: it's literally what the cloud vendors run.
- Shallow clones, pre-built running containers, etc. are all deployment practices, not products.
- You can ssh into a codespace.
The big problem here in my eyes is that it's reliant on VS Code, whose remoting stuff is not FOSS (and, having tried it at my own workplace pointing it at our self-hosted Kubernetes, it's been a pain to get it to work well with our authentication setup, proxies, etc. without access to the code and we have a number of open bugs filed). I think the challenge is for a free-software IDE to adopt the VS Code model of the IDE running locally but executing code (including running the LSP backend) remotely.
And, in a sense, Emacs already supports this just fine with TRAMP. It's just that the experience of using Emacs and the experience of using any modern IDE (VS Code, any of the JetBrains IDEs, whatever) are very different... and none of them are FOSS.
If you have a FOSS IDE, I think you can get this whole setup working well in a way where you have autonomy over the setup and where you can understand the details just fine. And even if you're using VS Code, you can set all of this up in a way where you're not contacting any external services.