4 ms·

Time to add GitLab to the list of companies playing in MSFT's sandbox. Whilst VSCode (MIT) is OSS the ecosystem is not open-source and is designed in a way that

Time to add GitLab to the list of companies playing in MSFT's sandbox. Whilst VSCode (MIT) is OSS the ecosystem is not open-source and is designed in a way that makes your product a walking, talking, advertisement for GitHub Codespaces. See https://ghuntley.com/fracture https://ghuntley.com/fracture

rcarr 4y ago
I find this a weird decision too. Why would you choose a product made by your director competitor to be a core part of your product? I suppose it’s semi-common with big companies (Apple using Samsung produced iPhone parts comes to mind) but it’s still a bit strange. I feel like JetBrains or Sublime or someone need to get a real competitor going because I don’t like the way VSCode is coming to dominate the web editor space without any real competition. Give it 5 years though and I think we’ll have a rust based editor that will dominate everything else due to high performance.
- ranguna 4y ago
  Because vscode is really good. Vscode (or vscodium) is open source. You could say the same about the brave browser, it uses chromium under the hood, which is a open source browser engine maintained by Google, a direct competitor of brave. Not only is chromium part of brave's core business, it is what its core business runs on. So I don't really see an issue with using vscode OSS in gitlab.
  - ghuntley 4y ago
    Ensure you read https://ghuntley.com/fracture https://ghuntley.com/fracture. If any point of that is wrong then happy to amend but it is what it is. In a couple years time there will be no Microsoft maintained LSPs that non MSFT companies can use. Microsoft are keeping them for themselves. As is their right. So if all these companies come in thinking they can compete with MSFT the answer really is, no they cannot, not without substational amounts of investment and maybe a collab between these companies to recreate all the LSPs that Microsoft is locking down. I would love to see some form of collab…
    - ranguna 4y ago
      So you are saying vscodium's problem is extensions. I'm sorry, you are gonna have a bad time with pretty much all major text editors, including vim. The biggest issue I've seen was with the python language server, but even that can be replaced with an OSS equivalent. I have copilot installed in vscodium. Remote ssh to vscode works, vscode containers work. Everything is working.
      - ghuntley 4y ago
        That configuration however is illegal and in breach of licensing agreements.
        ranguna 4y ago
        What's illegal now?
- dnsmichi 4y ago
  GitLab team member here, thanks for your feedback. This blog post about the future of the Web IDE [0] provides insights on the evaluation and plans, published in May 2022. The remote development direction page [1] dives into all plans, challenges, etc. and also links engineering and product resources (issues, epics) to subscribe to. I'd suggest commenting on the epic with thoughts and ideas [2] - thanks! [0] https://about.gitlab.com/blog/2022/05/23/the-future-of-the-gitlab-web-ide/ https://about.gitlab.com/blog/2022/05/23/the-future-of-the-g... [1] https://about.gitlab.com/direction/create/editor/remote_development/ https://about.gitlab.com/direction/create/editor/remote_deve... [2] https://gitlab.com/groups/gitlab-org/-/epics/7419 https://gitlab.com/groups/gitlab-org/-/epics/7419
- survirtual 4y ago
  VSCode was my to-go for years but I had to force alternatives due to the increasingly bad practices I’ve seen by Microsoft. So I switched to vim. It has a large learning curve for me & the habits I have, and a lot or it requires work, but I have liked the change a lot — especially for remoting and working directly on other systems. It isn’t as convenient or easy, but the freedom is important. Anyway, with regards to Rust, I was using https://github.com/helix-editor/helix https://github.com/helix-editor/helix for a bit as an editor. I ran into an issue with keymapping that was pretty basic but still an involved feature and so I set it down, but it is still very functional. A few years and it will be solid. And I agree with you, new offerings will come from Rust that will outcompete.
dnsmichi 4y ago
GitLab team member here. Thanks for your feedback. You can learn more about the Remote Development direction in [0], follow iterations in [1] and read about the steps to integrated the client-only VS Code as new Web IDE into the GitLab DevSecOps platform [2]. I'd encourage you to try the Web IDE Beta next week on Dec 19, and add thoughts, ideas and feedback into this issue [3]. Thanks! [0] https://about.gitlab.com/direction/create/editor/remote_development/#whats-next--why https://about.gitlab.com/direction/create/editor/remote_deve... [1] https://gitlab.com/groups/gitlab-org/-/epics/7419 https://gitlab.com/groups/gitlab-org/-/epics/7419 [2] https://gitlab.com/groups/gitlab-org/-/epics/7683 https://gitlab.com/groups/gitlab-org/-/epics/7683 [3] https://gitlab.com/gitlab-org/gitlab/-/issues/385787 https://gitlab.com/gitlab-org/gitlab/-/issues/385787
- ghuntley 4y ago
  Hi Michi. It’s a though one but appreciate you replying. Something to discuss over beers next time we see each other if you want to. I’ve studied above many times over.

rcarr 4y ago

I find this a weird decision too. Why would you choose a product made by your director competitor to be a core part of your product? I suppose it’s semi-common with big companies (Apple using Samsung produced iPhone parts comes to mind) but it’s still a bit strange. I feel like JetBrains or Sublime or someone need to get a real competitor going because I don’t like the way VSCode is coming to dominate the web editor space without any real competition. Give it 5 years though and I think we’ll have a rust based editor that will dominate everything else due to high performance.

ranguna 4y ago
Because vscode is really good. Vscode (or vscodium) is open source. You could say the same about the brave browser, it uses chromium under the hood, which is a open source browser engine maintained by Google, a direct competitor of brave. Not only is chromium part of brave's core business, it is what its core business runs on. So I don't really see an issue with using vscode OSS in gitlab.
- ghuntley 4y ago
  Ensure you read https://ghuntley.com/fracture https://ghuntley.com/fracture. If any point of that is wrong then happy to amend but it is what it is. In a couple years time there will be no Microsoft maintained LSPs that non MSFT companies can use. Microsoft are keeping them for themselves. As is their right. So if all these companies come in thinking they can compete with MSFT the answer really is, no they cannot, not without substational amounts of investment and maybe a collab between these companies to recreate all the LSPs that Microsoft is locking down. I would love to see some form of collab…
  - ranguna 4y ago
    So you are saying vscodium's problem is extensions. I'm sorry, you are gonna have a bad time with pretty much all major text editors, including vim. The biggest issue I've seen was with the python language server, but even that can be replaced with an OSS equivalent. I have copilot installed in vscodium. Remote ssh to vscode works, vscode containers work. Everything is working.
    - ghuntley 4y ago
      That configuration however is illegal and in breach of licensing agreements.
      - ranguna 4y ago
        What's illegal now?
dnsmichi 4y ago
GitLab team member here, thanks for your feedback. This blog post about the future of the Web IDE [0] provides insights on the evaluation and plans, published in May 2022. The remote development direction page [1] dives into all plans, challenges, etc. and also links engineering and product resources (issues, epics) to subscribe to. I'd suggest commenting on the epic with thoughts and ideas [2] - thanks! [0] https://about.gitlab.com/blog/2022/05/23/the-future-of-the-gitlab-web-ide/ https://about.gitlab.com/blog/2022/05/23/the-future-of-the-g... [1] https://about.gitlab.com/direction/create/editor/remote_development/ https://about.gitlab.com/direction/create/editor/remote_deve... [2] https://gitlab.com/groups/gitlab-org/-/epics/7419 https://gitlab.com/groups/gitlab-org/-/epics/7419
survirtual 4y ago
VSCode was my to-go for years but I had to force alternatives due to the increasingly bad practices I’ve seen by Microsoft. So I switched to vim. It has a large learning curve for me & the habits I have, and a lot or it requires work, but I have liked the change a lot — especially for remoting and working directly on other systems. It isn’t as convenient or easy, but the freedom is important. Anyway, with regards to Rust, I was using https://github.com/helix-editor/helix https://github.com/helix-editor/helix for a bit as an editor. I ran into an issue with keymapping that was pretty basic but still an involved feature and so I set it down, but it is still very functional. A few years and it will be solid. And I agree with you, new offerings will come from Rust that will outcompete.

dnsmichi 4y ago

GitLab team member here. Thanks for your feedback. You can learn more about the Remote Development direction in [0], follow iterations in [1] and read about the steps to integrated the client-only VS Code as new Web IDE into the GitLab DevSecOps platform [2]. I'd encourage you to try the Web IDE Beta next week on Dec 19, and add thoughts, ideas and feedback into this issue [3]. Thanks! [0] https://about.gitlab.com/direction/create/editor/remote_development/#whats-next--why https://about.gitlab.com/direction/create/editor/remote_deve... [1] https://gitlab.com/groups/gitlab-org/-/epics/7419 https://gitlab.com/groups/gitlab-org/-/epics/7419 [2] https://gitlab.com/groups/gitlab-org/-/epics/7683 https://gitlab.com/groups/gitlab-org/-/epics/7683 [3] https://gitlab.com/gitlab-org/gitlab/-/issues/385787 https://gitlab.com/gitlab-org/gitlab/-/issues/385787

ghuntley 4y ago
Hi Michi. It’s a though one but appreciate you replying. Something to discuss over beers next time we see each other if you want to. I’ve studied above many times over.