Falha de projeto do Visual Studio Code (2022)
(ghuntley.com)- O Visual Studio Code separa o código-fonte sob licença MIT do produto sob licença proprietária distribuído pela Microsoft, o que coloca forks como VSCodium e OpenVSCode Server em conflito com o ecossistema oficial
- As builds oficiais são distribuídas com configurações exclusivas da Microsoft no
product.json, como telemetria, gallery e logo; as builds da comunidade se tornam builds “clean”, mas não conseguem se conectar ao Visual Studio Code Marketplace - VSCodium e OpenVSCode Server removem ou não incluem a telemetria das releases oficiais, mas, por causa da coleta de dados feita pelas extensões e das restrições de acesso ao Marketplace, é difícil oferecer exatamente a experiência do VS Code que os usuários esperam
- Quando extensões e language servers da Microsoft ficam vinculados ao produto e aos serviços oficiais, como no Pylance, no roadmap da extensão C# e no licenciamento das ferramentas de C/C++, serviços concorrentes como Gitpod, GitLab, Datacoves, OpenBB e Foam passam a ter dificuldade para oferecer legalmente os mesmos recursos
- OpenVSX, o desenvolvimento de ferramentas de linguagem abertas e o apoio a mantenedores de open source são citados como alternativas, mas quando a Microsoft muda os padrões para ferramentas proprietárias, a comunidade e os produtos concorrentes acabam assumindo ao mesmo tempo diferenças de recursos, diferenças de configuração e restrições legais
O código-fonte é aberto, mas o produto é distribuído de outra forma
- Sete anos após seu lançamento, o Visual Studio Code se consolidou como o editor padrão de fato no desenvolvimento de software
- A Microsoft publicou o código-fonte do Visual Studio Code sob licença MIT, mas o produto Visual Studio Code que o usuário baixa é distribuído sob uma licença proprietária separada
- Segundo a explicação dos mantenedores do Visual Studio Code, a build da Microsoft clona o repositório
vscodee depois sobrescreve com umproduct.jsonexclusivo da Microsoft- Esse arquivo inclui recursos exclusivos da Microsoft, como telemetria, gallery e logo
- A build criada dessa forma é distribuída sob licença da Microsoft
- A crítica central do texto é que essa distinção é o principal mecanismo pelo qual a Microsoft fragmenta a comunidade open source
Limitações enfrentadas por VSCodium e OpenVSCode Server
- VSCodium é uma distribuição desktop guiada pela comunidade e sob licença livre
- acompanha automaticamente o projeto MIT upstream e gera builds binárias
- oferece builds com a telemetria presente na release oficial removida
- o
product.jsonpadrão não aponta para endpoints da Microsoft, então é gerada uma build “clean”, sem customizações da Microsoft
- Mesmo usando a mesma base de código, o VSCodium não consegue bloquear totalmente toda coleta de dados
- extensões podem coletar dados de forma independente, então é preciso cuidado com as extensões instaladas
- OpenVSCode Server é uma distribuição de servidor sob licença livre que serve de base para o Gitpod
- acompanha automaticamente o projeto MIT upstream
- tem algumas customizações de sobreposição no branch
gp-code/main - não inclui a telemetria da release oficial
- Nenhuma das duas distribuições consegue se conectar ao Microsoft Visual Studio Code Marketplace, e essa restrição leva a uma ruptura do ecossistema
A mudança da Microsoft para um modelo centrado em serviços e sua estratégia para ferramentas de desenvolvimento
- Há cerca de 9 anos, a Microsoft começou a mudar a forma como entrega software
- saiu de um modelo em que uma equipe dedicada de QA testava as builds para um desenvolvimento baseado em sprint, rolling release e feedback de telemetria das Insider Builds
- No mesmo período, após uma reorganização interna, a Microsoft se transformou em uma empresa de serviços
- nesse intervalo, o Azure cresceu até se tornar um concorrente real da AWS
- Do ponto de vista do consumidor, a maior mudança foi a migração da base de clientes de produtos instalados on-premise para um modelo de consumo de serviços fornecidos pela Microsoft
- No campo das ferramentas de desenvolvimento, IDEs sem assinatura também passam a ser tratados como algo em retração
- casos com outra fonte de receita, como o Xcode da Apple, são citados como exceção
- O Visual Studio Code é criticado como porta de entrada para levar o ecossistema de ferramentas de desenvolvimento a um modelo de serviço consumido de ponta a ponta
- o GitHub Codespaces é descrito como um white label de serviços já existentes ligados ao Visual Studio Online, Microsoft Dev Box e Microsoft Azure DevTest Labs
GitHub Codespaces e a DevDiv da Microsoft
- A Microsoft adquiriu o GitHub em 2018 e lançou o Visual Studio Online em 2019
- ele incluía componentes para hospedar um “codespace” localmente
- depois, a equipe do Codespaces e elementos relacionados foram movidos para o GitHub
- O GitHub Codespaces é descrito como um projeto da DevDiv que passou a ficar dentro do GitHub
- No dia em que Nat Friedman deixou o cargo de CEO, foi compartilhado um e-mail de reorganização interna da Microsoft
- Julia Liuson foi promovida a presidente da Microsoft Developer Division
- o CEO do GitHub, Thomas Dohmke, passou a se reportar a Julia Liuson
- a Developer Division inclui Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, SDKs de desenvolvedor do Azure, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache, Spring Cloud e outros
- Segundo esse e-mail, Visual Studio e Visual Studio Code registraram mais de 16 vezes de crescimento em uso desde 2014
- Julia Liuson é citada como a pessoa que, antes da promoção, executou uma mudança de última hora que dividiu a comunidade .NET
- segundo citação do The Verge, uma fonte interna anônima da Microsoft viu a mudança como uma decisão orientada por negócios
Uma estrutura de ecossistema que funciona como “ruptura planejada”
- Produtos concorrentes como o Gitpod podem existir dentro do ecossistema do Visual Studio Code, mas são criticamente expostos ao fato de que a Microsoft pode, a qualquer momento, criar riscos legais e dividir o mercado
- O código-fonte open source do Visual Studio Code atrai usuários, mas dificulta que serviços concorrentes ofereçam uma experiência tão fluida quanto a do Visual Studio Code oficial ou do GitHub Codespaces
- Não só o Gitpod, mas também empresas como GitLab, Datacoves, OpenBB e Foam, que tentam competir com a Microsoft ou com o GitHub a partir do código-fonte do VS Code, enfrentam o mesmo problema
- Ao depender de ferramentas da Microsoft, passam a existir áreas que serviços concorrentes têm dificuldade de oferecer legalmente, entre elas:
- Microsoft .NET C#
- mercado Python de uso geral e de ciência de dados
- Project Jupyter e grande parte do mercado de ciência de dados
- C ou C++
- prevê-se que Java possa ser o próximo alvo se as ferramentas da Microsoft se aproximarem do nível das ferramentas da RedHat
- Segundo o índice TIOBE, 5 desses ecossistemas de linguagem estão entre os mais populares, e a Microsoft também é descrita como tendo um grau de controle próximo sobre o JavaScript, o 7º mais popular, por meio do TypeScript
Mudança dos padrões e o problema das extensões proprietárias
- A Microsoft é criticada por poder, após garantir adoção suficiente, transformar ofertas proprietárias no padrão por meio de atualizações de extensões
- Na comunidade Python, o Microsoft Python Language Server open source foi descontinuado e o Pylance passou a ser o padrão
- segundo citação da Visual Studio Magazine, a Microsoft não forçou a migração dos usuários, mas definiu o Pylance como novo padrão
- a extensão Python registrou cerca de 50 milhões de downloads no VS Code Marketplace e é citada como tendo aproximadamente o dobro da popularidade da extensão Jupyter, a seguinte mais popular
- Na comunidade .NET, um movimento semelhante é apresentado como em andamento por meio do roadmap da extensão C#
- Mesmo que ferramentas alternativas como Open.NET sejam criadas, o usuário passa a precisar conectar configurações diferentes para cada plataforma
- no desktop, é possível colocar
ms-dotnettools.csharpemdevcontainer.json - no Gitpod, seria preciso colocar em
gitpod.ymluma ferramenta aberta que ainda nem existe, gerando esse tipo de diferença
- no desktop, é possível colocar
- Dentro do ecossistema oficial da Microsoft, a mesma configuração
devcontainer.jsonvira uma fonte única de configuração que funciona igual no Visual Studio Code desktop e no GitHub Codespaces
Restrições legais criadas pelo licenciamento
- O texto alerta que, se Gitpod, GitLab, Datacoves, OpenBB, Foam e outros tentarem contornar as restrições e oferecer em seus serviços extensões da Microsoft como
ms-dotnettools.csharp, podem enfrentar uma forte reação jurídica da equipe legal da Microsoft - Mesmo que usuários de ambientes de desenvolvimento em nuvem concorrentes instalem manualmente essas extensões, isso ainda pode constituir violação de licença
- O texto da licença da extensão Microsoft C/C++ afirma que o software só pode ser instalado e usado com Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server e produtos ou serviços sucessores da Microsoft
- Por essa condição, produtos baseados em VS Code que não sejam distribuições oficiais da Microsoft têm dificuldade para oferecer exatamente as ferramentas de linguagem da Microsoft que os usuários esperam
Caminhos de resposta: OpenVSX e ferramentas de linguagem abertas
- Há a crítica de que o futuro das ferramentas de desenvolvimento de software que está sendo construído caminha para o fechamento
- mesmo que alguns componentes atendam à definição da OSI, o grafo completo de componentes pode não atender
- O open source é descrito originalmente como uma arma financeira para conter software on-premise proprietário e manter a abertura dos formatos de arquivo
- ao mesmo tempo, isso se conecta ao motivo de ser difícil ganhar dinheiro com open source
- Propõe-se que talvez seja necessário um novo movimento que garanta a abertura da liberdade computacional diante do SaaS proprietário, ou uma revisão do movimento de software livre dos anos 1970
- O Open-Source Sustainability Fund do Gitpod é apresentado como uma das respostas a essa ruptura do ecossistema
- em 1,5 ano, foram distribuídos mais de 32 mil dólares a mantenedores de ferramentas de language server da comunidade open source
- Para resolver parcialmente o problema do Marketplace no ecossistema open source do Visual Studio Code, o Gitpod criou o Open VSX e o doou à Eclipse Foundation
- O maior desafio daqui para frente é desenvolver ferramentas de linguagem abertas em cada área em que a Microsoft deslocou a comunidade para language servers proprietários
Conteúdo adicionado em edições posteriores
- A edição de 31 de agosto de 2022 resume que a Microsoft criou o VSCode, ofereceu uma distribuição gratuita proprietária e extensões gratuitas proprietárias, e depois vinculou a melhor experiência por linguagem a um VSCode fechado
- A edição de 16 de dezembro de 2022 acrescenta que a Web IDE baseada no MIT do VSCode e a experiência de desenvolvimento remoto do GitLab também sofrem do mesmo problema
- A edição de 13 de outubro de 2023 afirma que o Project IDX do Google também é baseado no MIT do VSCode, e que esperar que o LSP do Visual Studio Code funcione do mesmo jeito em .NET e Python é inviável e não é legalmente permitido
- A edição de 24 de abril de 2025 critica a Microsoft por ter quebrado intencionalmente o ecossistema do VSCode para conter concorrentes de assistentes de programação com IA, como Windsurf e Cursor
- no mesmo dia, o texto relaciona esse movimento ao lançamento de um produto concorrente da Microsoft e à restrição de acesso de forks do VS Code à extensão C/C++
5 comentários
Estou pensando em considerar usar
vimouzed.Eu uso um terminal com
opacityconfigurada,por acaso você sabe como remover a cor de fundo do
nvim?Se eu só descobrir isso, com certeza quero experimentar o
nvim...Se você usa o terminal kitty, acho que vai aplicar transparência se configurar com a mesma cor de fundo.
Ou então vale considerar um plugin como este..
https://github.com/xiyaowong/transparent.nvim
Obrigado. Vou dar uma olhada.
Conseguiu. Obrigado. Tenha um bom dia.
Opiniões do Hacker News
Em certo sentido, esta situação pode ser uma oportunidade. O ecossistema do VSCode é bastante frágil em vários aspectos
cpptoolstem pontos excelentes, mas frequentemente funciona mal e é praticamente impossível de depurar; é difícil esperar que outras extensões sejam muito melhoresO problema maior é que o modelo de segurança é muito fraco: extensões não são executadas em sandbox, e clientes que acessam repositórios remotos também são, por design, muito inseguros
Quando você só olha código da empresa, talvez se preocupe menos com a possibilidade de o repositório atacar você, mas extensões maliciosas obviamente devem preocupar, e nos acostumamos a confiar com facilidade demais em ferramentas de desenvolvimento
LLMs nunca devem ser confiados, e não é seguro dar a um LLM, que pode tentar atacar o usuário, permissão para escrever diretamente no repositório ou executar código JS em partes do contexto do VSCode
Em um ecossistema melhor, uma ferramenta equivalente ao
cpptoolsnão teria acesso à internet, portanto não teria telemetria, e só deveria poder ler o workspace, criar seus próprios arquivos de cache e manipular a UIHTTPS_PROXYfoi definidoA extensão de SSH também inicia um processo de servidor para cada cliente ao qual o usuário se conecta, e a preservação de estado após a desconexão não parece consistente
No fim, muito tempo é gasto ajudando pessoas que usam VSCode a corrigir problemas que elas mesmas criaram
Não há meio-termo entre permitir acesso aberto a todas as extensões do Marketplace ou bloquear tudo completamente e permitir a instalação de extensões apenas por arquivos locais
A segunda opção impõe uma carga considerável de manutenção do VSCode
compile_commands.json, o que é relativamente fácil especialmente com CMake, e consegue fazer oclangdenxergá-lo, a extensãoclangdfoi muito melhor para mimO Emacs que eu uso também não tem muitos mecanismos para impedir ataques à cadeia de suprimentos, e a maioria usa agregadores comunitários de extensões que puxam diretamente de repositórios Git
Ainda assim, há uma vantagem muito pequena: a proporção de usuários de Emacs que de fato olham o código-fonte das extensões que trazem provavelmente é bem maior
A Microsoft vem dizendo há anos que “segurança é tudo e é o mais importante agora”, então é estranho que não tenha cuidado nem desse básico para o grupo de usuários que sofreria o maior impacto se algo como chaves SSH fosse roubado, e que também é o grupo de desenvolvedores mais atento à segurança
A situação em que pessoas instalam extensões aleatórias e o Visual Studio Code recomenda extensões arbitrárias em nome de “suporte a linguagem” parece muito pior do que se imaginava
Há uma boa thread sobre a extensão
cpptools: https://github.com/microsoft/vscode-cpptools/discussions/126...Não investiguei a fundo o processo de build a partir do código-fonte, mas, lendo isso, parece simplesmente impossível
Parece que vamos precisar de um novo termo para expressar quando uma base de código tem licença OSS e quando suas dependências de build também têm licença OSS
mainé software livre,non-freeé software não livre, econtribé software livre que depende de algo fora demain, normalmente software não livreNão gosto muito do termo
contribem si, mas essa classificação parece bastante sensataMuito F/OSS no Windows e quase todo F/OSS no macOS têm dependências de build proprietárias, como MSVC, Xcode e frameworks/toolkits de GUI da Apple, mas ainda assim podem ser F/OSS em si
Mas este caso não é esse problema: trata-se de uma situação em que um funcionário da Microsoft que parece ser mantenedor disse que “nossa licença também proíbe usar a extensão em distribuições alternativas do VS Code; ela só pode ser usada na distribuição oficial feita pela Microsoft”
Isso é simplesmente software proprietário
A liberdade 0 da definição de software livre é a liberdade de executar o programa para qualquer finalidade; e, se uma distribuição de terceiros do VSCode não tem os mesmos direitos de extensão da distribuição oficial, nem o direito de ser usada com extensões compatíveis, então, independentemente da licença de parte do código, ela também não passa na liberdade 3
Dizer que “se você está tentando redistribuir o binário do servidor de linguagem como sua própria oferta, a licença de runtime proíbe isso” significa que ele não passa no critério 1 da definição de open source, o critério de redistribuição; e o VSCode, que não permite que distribuições modificadas tenham os mesmos direitos do original, também não passa no critério 3, o critério de obras derivadas
O VSCode e esta extensão não são open source; são software proprietário que inclui alguns componentes open source
Definição de software livre: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
Definição de open source: https://opensource.org/osd
Também é importante notar que essas definições não são significados comuns de dicionário, mas termos criados dentro do movimento com objetivos sociais e técnicos específicos
O mesmo front-end também está no Visual Studio IDE
Acredito que exista, como alternativa, uma extensão C++ totalmente open source baseada em
clangd, mas posso estar enganado“O software livre que a Microsoft dá de graça não é aberto o suficiente” soa como uma afirmação bem estranha até pelos padrões atuais
Antigamente, “IDE gratuita” significava Eclipse ou Vim cheio de extensões
Pelo que parece, a Microsoft não está impedindo alternativas abertas; elas simplesmente são piores, e isso faz parte quando se usa um software feito por uma empresa que precisa pagar funcionários e ainda dar lucro
Quem acha que tem direito de receber o código-fonte dos melhores softwares da Microsoft deveria ver como é um verdadeiro projeto open source mantido por uma organização independente sem fins lucrativos
Ele vai funcionar, talvez até tenha um depurador de verdade, mas é bem provável que, pouco depois, você queira voltar
As pessoas dão valor demais como garantido ao software que receberam de graça. Não faz tanto tempo assim que era preciso pagar centenas ou milhares de dólares por uma IDE, e, alguns anos depois, pagar também pelo upgrade se quisesse uma nova versão
Extensões VSIX deveriam ser, em alguma medida, um padrão aberto, mas extensões da Microsoft como o Pylance detectam quando estão rodando em um VS Code que não é o build da Microsoft e se recusam ativamente a funcionar
O ponto central está mais perto de dizer que os desenvolvedores estão sendo enganados e que o objetivo da Microsoft é ir fechando as partes essenciais
Mesmo depois de alcançar essa paridade, ainda restará o problema de desempenho, e ninguém sabe quando isso será resolvido
A ideia de software open source é boa, mas hoje em dia o melhor software quase sempre exige pagamento
Eu conheço o preço de usar Emacs e Vim. Mesmo que, em teoria, sejam totalmente gratuitos, na prática há um custo em tempo, paciência e dedicação, e sei que minha escolha beneficia a mim, a comunidade e o setor
Quando eu usava IntelliJ, também sabia exatamente como a JetBrains lucrava. Eu pagava a licença e renovava todo ano
Mas qual é o cálculo da Microsoft? Ela entrega uma ferramenta tão bonita e decente de forma totalmente “gratuita”; que preço vou pagar no futuro?
É difícil acreditar que uma megacorporação com valor de mercado comparável ao PIB da Alemanha gaste recursos enormes para criar um editor de código “gratuito” só porque ama desenvolvedores, e desenvolvedores deveriam ser ao menos um pouco céticos
Vejo o software da Microsoft mais como um monte de lixo de pesadelo
O ponto do texto é que, quando software de código fechado finge ser open source, isso afeta até quem não quer usá-lo, e isso está sendo ignorado
Por exemplo, eu não quero usar nem Azure DevOps nem GitHub Actions, mas a organização onde trabalho exige que o projeto seja colocado no GitHub, então sou forçado a usar
Como resultado, sinto que meu trabalho e meu conhecimento estão sendo usados para a Microsoft explorar usuários
O único consolo é que é trabalho remunerado; pessoalmente, não uso GitHub e recomendaria o mesmo a outras pessoas
Se você não apresenta um modelo para justificar o orçamento anual de cerca de 20 milhões de dólares de mais de 50 funcionários em tempo integral que fazem o VS Code, essa crítica soa como “estou irritado porque ficou um pouco inconveniente pegar o resultado de engenharia deles, trocar só a camada superficial do produto e lucrar vendendo mais barato sem custo próprio de desenvolvimento”
Ao publicá-la como open source, ela ganha a confiança de outras comunidades, recebe código e revisão de bugs gratuitos, além de extensões escritas e mantidas fora do ecossistema da Microsoft, e a própria Microsoft também pode continuar usando isso
Não parece uma questão tão complicada
Historicamente, isso foi um caminho garantido para a obsolescência
Mesmo sem os resultados de engenharia deles, existem Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox etc.
Só me interesso pelo generoso presente em forma de cobertor da Microsoft se ele não vier acompanhado de varíola
Mas é meio engraçado noticiar isso como se fosse uma grande surpresa. Era óbvio desde o começo; as pessoas só não se importaram porque não parecia valer a briga
O problema de desenvolvedores de licenças BSD/MIT serem explorados me interessa tanto quanto o problema de o modelo de negócios da Microsoft ser abalado se a telemetria for desativada
Todo mundo sabia no que estava entrando e escolheu pensando “um veterano de uma big tech vai nos reconhecer”, e de fato reconheceu, então parabéns
Eu não colocaria nada sob uma licença mais fraca que AGPL, mas, no fim das contas, há coisas com que me importo muito mais do que software
Ainda estou tentando entender qual é exatamente o problema
Parece que a Microsoft está criando extensões
cpptools/C++ melhores, mas muitos componentes da Microsoft são fechados, então não dá para compilar uma versão OSS completaE, quando o usuário percebe que não pode usar extensões nativas em nenhuma interface web, isso vira um problema do pessoal da interface web?
Se as pessoas querem usar freeware em vez de OSS, isso pode ser decepcionante, mas não sei se é realmente um problema
Se há uma resposta, parece ser deixar mais claro de quem é a responsabilidade
Empresas open source deveriam deixar mais explícito que suas ofertas são open source e fazem parte de um ecossistema aberto, e informar aos desenvolvedores que nem todas as extensões são assim, e que a extensão alternativa da Microsoft não é
Se os principais projetos de extensão se articularem, poderiam colocar nas descrições do marketplace algo como:
vscode-cpptoolsnão usa uma licença aprovada pela OSI, contém muitos blobs binários não auditados, e a Microsoft não permite redistribuição em builds nativos open source nem em ofertas de VSCode como serviço webLegal e culturalmente, a Microsoft provavelmente não vai querer bloquear o acesso ao marketplace só porque alguns projetos OSS compararam os termos de licença deles com os termos da Microsoft
A Apple também está enfrentando processos relacionados a marketplace agora, e a Microsoft não vai querer um processo sobre marketplace nem outro caso antitruste
Depois criar outra API com uma única função pública, e essa função apenas faz uma chamada
externpara o binário daquela bibliotecaPublicar essa segunda API no GitHub sob licença MIT e declará-la open source
Em termos amplos, se 100% da funcionalidade do software está dentro de um binário compilado de código fechado, a questão é se chamar isso de open source deveria ser propaganda enganosa
Em outras palavras, a questão é quem traça a linha quando alguém ultrapassa a intenção do open source por motivos exploratórios
Não sei se 100% da funcionalidade do
cpptoolsé fechada, mas, na prática, dentro do repositório que diz estar sob licença MIT, há outras três licenças com as quais é preciso concordarÉ preciso ler texto demais para descobrir qual é o ponto real, e a ideia de “ecossistema fragmentado” aparece várias vezes sem explicação
Não faço ideia do que significa uma expressão como “uma dioneia projetada para fragmentar”
O VS Code é um IDE que você pode baixar e usar gratuitamente da Microsoft; é um produto, não uma plataforma ou ecossistema open source mágico que a Microsoft não controla
Parece que todo mundo quer criar serviços de desenvolvimento “universais”, mas na prática não quer criar ou financiar um IDE, ou isso é difícil demais
Isso não é culpa da Microsoft
Não quero defender a Microsoft, mas ela disponibilizou uma base de código enorme de graça e construiu em cima dela um produto em grande parte gratuito
Se você fizer um fork, só não terá acesso aos servidores da Microsoft; isso me parece justo o suficiente
E o Monaco é um editor esmagadoramente bom, por isso os front-ends o usam. Antes, quando CodeMirror ou Ace eram as melhores opções, era isso que se instalava
Mais do que haver um grande plano mestre por trás da criação do Monaco, parece que viram a oportunidade de, ao torná-lo um projeto independente, viabilizar inúmeras UIs web
O ponto de que “o futuro das ferramentas de desenvolvimento de software que serão criadas daqui para frente está completamente fechado, mas, como alguns componentes satisfazem a definição da OSI, as pessoas perdem de vista o panorama geral e acham que está tudo bem” é um problema muito grande
Especialmente várias empresas financiadas por VC estão usando o termo open source de forma frouxa demais, e com isso estão distorcendo a linguagem, o significado e até o espírito do movimento open source
A YC também apoia várias empresas que se dizem open source, mas não seguem esse espírito de forma alguma
Moralismos sobre espírito ou ética não são tão relevantes
O importante é que licenças de software são documentos jurídicos, e o lugar onde sua interpretação importa é o tribunal
Não parece haver muitos processos relacionados ao VS Code, e a Microsoft em geral cuida bem dessa parte
Em termos jurídicos, o VS Code parece suficientemente seguro. É verdade que algumas extensões não têm licença OSS ou são totalmente fechadas, mas, se você não gosta disso, basta não usá-las
Além disso, você pode criar open source por conta própria e corrigir o problema. Open source não é um direito, é um privilégio concedido a critério do autor, não algo que se possa exigir
O VS Code é um produto de código fechado que inclui muitos componentes OSS, e há tantos desses componentes que também existe o VS Codium, totalmente OSS
Muitos desses componentes OSS também são usados em outros produtos, e alguns são completamente open source
O valor do ecossistema do VS Code está em permitir que esses componentes e o ecossistema de produtos floresçam
Ninguém tem direito a receber o VS Code de graça. Na verdade, ninguém tem direito a receber nada de graça.
A alternativa é pagar por uma IDE comercial inchada.
O VS Code é bom, genérico, gratuito e aberto o suficiente para poder ser feito um fork.
As pessoas esquecem que ele é um produto de engenharia impressionante. Se você olhar o código, não é algo que sairia de graça.
Nem a Microsoft nem qualquer outra empresa deve algo de graça a ninguém, e esse senso de direito precisa ser controlado.
O problema é quando uma oferta gratuita é, na prática, projetada para jogar você num pântano de responsabilidade legal e responsabilidade financeira sem teto.
Ainda mais em um serviço como o VSCode, que não é uma compra única e no qual você precisa continuar dependendo da Microsoft por meio de extensões e atualizações — e ele foi de fato projetado assim.
Em vez de criar uma opção fácil de pagar uma vez, de forma limpa, e encerrar o assunto, escolheram extrair, no longo prazo, um valor ambíguo conforme o nível de resistência do usuário.
Também digo sempre sobre open source: sou cético quanto a adotar frameworks que não tenham muito dinheiro por trás.
Depender dos caprichos de algum engenheiro genial aleatório da internet é arriscado.
A Microsoft vai ganhar dinheiro com o VSCode. Só não é tão direto quanto o Google ganhando dinheiro com o Chrome.
Acho OSS ótimo, mas não é por isso que uso o VS Code.
Uso porque ele resolveu o problema de eu precisar de um editor utilizável que não fosse um monstro como o Eclipse.
Há outras opções nessa área, como o Sublime, mas o VS Code sempre me pareceu o menos intrusivo.
Antes também havia o Adobe Brackets, parecido, mas por algum motivo ele era muito lento e cheio de bugs.
Se você é entusiasta de OSS, as críticas do texto são válidas. Mas, no fim, o código-fonte existe, e você também pode operar seu próprio marketplace se quiser.
Isso custa tempo e dinheiro, mas, se acredita nessa ideia, deveria investir nela em vez de depender de uma gigante.
Se houver uma extensão proprietária que você não possa ter, é uma pena, mas alguém também pode criar uma versão OSS.
No geral, concordo com o texto, mas não tenho a ilusão de que a Microsoft faz isso por convicção em open source; e tudo bem, porque no pior caso há outras opções.