Defecto de diseño de Visual Studio Code (2022)
(ghuntley.com)- Visual Studio Code separa el código fuente con licencia MIT del producto con licencia privativa que distribuye Microsoft, lo que hace que forks como VSCodium y OpenVSCode Server choquen con el ecosistema oficial
- El build oficial se distribuye con configuraciones exclusivas de Microsoft en
product.json, como telemetría, gallery y logo, mientras que los builds de la comunidad quedan como builds “clean”, pero no pueden conectarse a Visual Studio Code Marketplace - VSCodium y OpenVSCode Server eliminan o no incluyen la telemetría del release oficial, pero por la recolección de datos de las propias extensiones y las restricciones de acceso al Marketplace, les resulta difícil ofrecer exactamente la experiencia de VS Code que los usuarios esperan
- Si las extensiones y los language servers de Microsoft quedan atados a productos y servicios oficiales, como ocurre con Pylance, la hoja de ruta de la extensión de C# o la licencia de las herramientas de C/C++, servicios competidores como Gitpod, GitLab, Datacoves, OpenBB y Foam tienen dificultades para ofrecer legalmente la misma funcionalidad
- Se mencionan como alternativas OpenVSX, el desarrollo de herramientas de lenguaje abiertas y el apoyo a mantenedores de open source, pero cuando Microsoft cambia los valores predeterminados hacia herramientas privativas, la comunidad y los productos competidores terminan cargando al mismo tiempo con diferencias funcionales, diferencias de configuración y restricciones legales
El código fuente está abierto, pero el producto se distribuye de otra forma
- Siete años después de su lanzamiento, Visual Studio Code ya se consolidó como el editor estándar de facto en el desarrollo de software
- Microsoft publicó el código fuente de Visual Studio Code bajo licencia MIT, pero el producto Visual Studio Code que descargan los usuarios se distribuye bajo una licencia privativa aparte
- Según la explicación de los mantenedores de Visual Studio Code, el build de Microsoft clona el repositorio
vscodey luego sobrescribe con unproduct.jsonexclusivo de Microsoft- Ese archivo incluye funciones exclusivas de Microsoft como telemetría, gallery y logo
- El build creado de esa manera se distribuye bajo la licencia de Microsoft
- La crítica central del texto es que esta separación es el mecanismo clave con el que Microsoft divide a la comunidad open source
Límites que enfrentan VSCodium y OpenVSCode Server
- VSCodium es una distribución de escritorio con licencia libre impulsada por la comunidad
- Sigue automáticamente el proyecto upstream bajo MIT y genera builds binarios
- Ofrece builds con la telemetría del release oficial eliminada
- Como el
product.jsonpredeterminado no tiene configurados endpoints de Microsoft, se genera un build “clean” sin personalizaciones de Microsoft
- Aun usando la misma base de código, VSCodium no puede bloquear por completo toda recolección de datos
- Las extensiones pueden recopilar datos por su cuenta, así que hay que tener cuidado con las extensiones instaladas
- OpenVSCode Server es una distribución de servidor con licencia libre que sirve de base para Gitpod
- Sigue automáticamente el proyecto upstream bajo MIT
- Tiene algunas personalizaciones superpuestas en la rama
gp-code/main - No incluye la telemetría del release oficial
- Ninguna de las dos distribuciones puede conectarse a Microsoft Visual Studio Code Marketplace, y esa restricción termina fragmentando el ecosistema
El giro de Microsoft hacia los servicios y su estrategia de herramientas de desarrollo
- Microsoft comenzó a cambiar su forma de entregar software hace unos nueve años
- Pasó de un modelo con un equipo de QA dedicado que probaba los builds a un modelo basado en sprints, rolling release y retroalimentación de telemetría de Insider Build
- En ese mismo periodo, tras una reorganización interna, Microsoft se convirtió en una empresa orientada a servicios
- Durante ese tiempo, Azure creció hasta convertirse en un competidor real de AWS
- Desde la perspectiva del consumidor, el mayor cambio fue el traslado de la base de clientes desde productos instalables on-premise hacia un modelo de consumo de servicios ofrecidos por Microsoft
- En el ámbito de las herramientas de desarrollo, también se presenta como una tendencia la reducción de IDE no basados en suscripción
- Se menciona como excepción el caso de Apple con Xcode, por tener otras fuentes de ingresos
- Visual Studio Code recibe la crítica de funcionar como puerta de entrada para mover el ecosistema de herramientas de desarrollo hacia un modelo de servicios de consumo end-to-end
- GitHub Codespaces se describe como una etiqueta blanca de servicios previos conectados con Visual Studio Online, Microsoft Dev Box y Microsoft Azure DevTest Labs
GitHub Codespaces y Microsoft DevDiv
- Microsoft adquirió GitHub en 2018 y lanzó Visual Studio Online en 2019
- Esto incluía componentes para alojar un “codespace” localmente
- Después, los elementos relacionados, incluido el equipo de Codespaces, pasaron a GitHub
- GitHub Codespaces se describe como un proyecto de DevDiv que terminó dentro de GitHub
- El día en que Nat Friedman dejó el cargo de CEO se compartió un correo interno sobre reorganización en Microsoft
- Julia Liuson fue ascendida a presidenta de Microsoft Developer Division
- El CEO de GitHub, Thomas Dohmke, pasó a reportarle a Julia Liuson
- Developer Division incluye Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, Azure Developer SDK, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache y Spring Cloud
- Según ese correo, Visual Studio y Visual Studio Code registraron un aumento de uso de más de 16 veces desde 2014
- Se menciona a Julia Liuson como la persona que, antes de su ascenso, ejecutó un cambio de último momento que dividió a la comunidad de .NET
- Según una cita de The Verge, una fuente interna anónima de Microsoft consideró ese cambio una decisión guiada por intereses de negocio
Una estructura de ecosistema que funciona como “fractura diseñada”
- Se critica que productos competidores como Gitpod pueden existir dentro del ecosistema de Visual Studio Code, pero Microsoft conserva la capacidad de crear riesgos legales en cualquier momento para dividir el mercado
- El código open source de Visual Studio Code atrae usuarios, pero dificulta que servicios rivales ofrezcan una experiencia tan fluida como la de Visual Studio Code oficial o GitHub Codespaces
- No solo Gitpod: también compañías como GitLab, Datacoves, OpenBB y Foam, que buscan competir con Microsoft o GitHub sobre la base del código fuente de VS Code, enfrentan el mismo problema
- Al depender de herramientas de Microsoft, se mencionan las siguientes áreas como difíciles de ofrecer legalmente para servicios rivales
- Microsoft .NET C#
- El mercado general de Python y el de ciencia de datos
- Project Jupyter y gran parte del mercado de ciencia de datos
- C o C++
- Se anticipa que Java podría ser el siguiente objetivo si las herramientas de Microsoft se acercan al nivel de las de RedHat
- Según el índice TIOBE, cinco de esos lenguajes y ecosistemas están entre los más populares, y se dice que Microsoft también tiene un control cercano sobre JavaScript, el séptimo más popular, a través de TypeScript
El cambio de valores predeterminados y el problema de las extensiones privativas
- Se critica que, una vez logrado suficiente nivel de adopción, Microsoft puede convertir sus ofertas privativas en la opción predeterminada mediante actualizaciones de extensiones
- En la comunidad de Python, el open source Microsoft Python Language Server fue descontinuado y Pylance, que es privativo, pasó a ser el valor predeterminado
- Según una cita de Visual Studio Magazine, Microsoft no forzó a los usuarios a cambiar, pero sí estableció Pylance como nueva opción predeterminada
- La extensión de Python registró cerca de 50 millones de descargas en VS Code Marketplace, y se la menciona como casi el doble de la siguiente extensión más popular, Jupyter
- En la comunidad de .NET también se presenta un caso similar en marcha a través de la hoja de ruta de la extensión de C#
- Aunque se creen herramientas alternativas como Open.NET, los usuarios deben enlazar configuraciones distintas según la plataforma
- En escritorio, se puede poner
ms-dotnettools.csharpendevcontainer.json - En Gitpod, habría que poner en
gitpod.ymluna herramienta abierta que todavía no existe, generando esa diferencia
- En escritorio, se puede poner
- Dentro del ecosistema oficial de Microsoft, el mismo archivo
devcontainer.jsonfunciona como una fuente única de configuración tanto en Visual Studio Code de escritorio como en GitHub Codespaces
Las restricciones legales creadas por la licencia
- Se advierte que si Gitpod, GitLab, Datacoves, OpenBB o Foam intentan esquivar la restricción y ofrecer en sus servicios extensiones de Microsoft como
ms-dotnettools.csharp, podrían enfrentar una respuesta legal fuerte del equipo jurídico de Microsoft - Incluso si un usuario de un entorno de desarrollo en la nube competidor instala manualmente esa extensión, podría seguir existiendo una violación de licencia
- La licencia de la extensión de Microsoft para C/C++ indica que el software solo puede instalarse y usarse junto con Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server y productos o servicios posteriores de Microsoft
- Por esta condición, a los productos basados en VS Code que no sean distribuciones oficiales de Microsoft les resulta difícil ofrecer las herramientas de lenguaje de Microsoft tal como las esperan los usuarios
Respuesta posible: OpenVSX y herramientas de lenguaje abiertas
- Surge la crítica de que el futuro de las herramientas de desarrollo de software que hoy se están construyendo avanza hacia un modelo cerrado
- Aunque algunos componentes cumplan con la definición de la OSI, el grafo completo de componentes podría no hacerlo
- Se describe al open source como un arma financiera que originalmente servía para contrapesar el software on-premise privativo y mantener abiertos los formatos de archivo
- Al mismo tiempo, eso se conecta con por qué es difícil ganar dinero con open source
- Se propone que podría hacer falta un nuevo movimiento que garantice la apertura de la libertad informática frente al SaaS privativo, o una revisión del movimiento de software libre de los años 70
- El Open-Source Sustainability Fund de Gitpod se presenta como una de las respuestas a esta fractura del ecosistema
- En un periodo de 1.5 años, se distribuyeron más de 32 mil dólares a mantenedores de herramientas de language servers en la comunidad open source
- Gitpod creó Open VSX para resolver parcialmente el problema del Marketplace dentro del ecosistema open source de Visual Studio Code, y luego lo donó a la Eclipse Foundation
- El mayor reto hacia adelante es desarrollar herramientas de lenguaje abiertas en cada área donde Microsoft haya movido a la comunidad hacia language servers privativos
Contenido agregado en ediciones posteriores
- La edición del 31 de agosto de 2022 resume que Microsoft creó VSCode, ofreció una distribución gratuita privativa y extensiones gratuitas privativas, y luego ató la mejor experiencia por lenguaje a un VSCode cerrado
- La edición del 16 de diciembre de 2022 agrega que el Web IDE basado en VSCode MIT de GitLab y su experiencia de desarrollo remoto sufren el mismo problema
- La edición del 13 de octubre de 2023 indica que Project IDX de Google también está basado en VSCode MIT, y que esperar que el LSP de Visual Studio Code funcione igual en .NET y Python no es posible ni legal
- La edición del 24 de abril de 2025 critica que Microsoft rompió deliberadamente el ecosistema de VSCode para frenar a competidores de asistentes de programación con IA como Windsurf y Cursor
- Ese mismo día también vincula el lanzamiento de un producto competidor de Microsoft con la restricción de acceso de forks de VS Code a la extensión de C/C++
5 comentarios
Estoy considerando usar vim o zed.
Uso una terminal con la opacidad configurada,
¿de casualidad saben cómo quitar el color de fondo de nvim?
Si encuentro solo eso, de verdad quiero probar nvim...
Si usas la terminal kitty, si lo configuras con el mismo color de fondo probablemente se aplicará la transparencia.
Si no, también podrías considerar un plugin como este..
https://github.com/xiyaowong/transparent.nvim
Gracias. Lo revisaré.
Tuvo éxito. Gracias. Que tengas un buen día.
Opiniones de Hacker News
En cierto sentido, esta situación podría ser una oportunidad. El ecosistema de VSCode es bastante frágil en varios aspectos.
cpptoolstiene cosas impresionantes, pero falla con frecuencia y en la práctica es imposible de depurar; es difícil esperar que otras extensiones sean mucho mejores.El problema más grande es que el modelo de seguridad es muy débil: las extensiones no están en sandbox, y los clientes que acceden a repositorios remotos también son, por diseño, muy inseguros.
Cuando solo ves código de la empresa, puedes preocuparte menos por la posibilidad de que un repositorio te ataque, pero por supuesto sí hay que preocuparse por extensiones maliciosas, y nos hemos acostumbrado a confiar con demasiada facilidad en las herramientas de desarrollo.
Nunca se debe confiar en los LLM, y no es seguro darle a un LLM —que podría intentar atacar al usuario— permisos para escribir directamente en el repositorio o ejecutar código JS en ciertos contextos de VSCode.
En un ecosistema mejor, una herramienta equivalente a
cpptoolsno tendría acceso a internet, por lo que tampoco habría telemetría, y solo debería poder leer el área de trabajo, crear sus propios archivos de caché y manipular la UI.HTTPS_PROXY.La extensión de SSH también levanta un proceso de servidor por cada cliente desde el que se conecta el usuario, y la conservación del estado tras desconectarse no parece ser consistente.
Al final, uno termina dedicando mucho tiempo a ayudar a arreglar problemas que ellos mismos crearon al usar VSCode.
No hay un punto intermedio entre permitir acceso abierto a todas las extensiones del Marketplace o bloquearlo por completo e instalar extensiones solo desde archivos locales.
Esto último supone una carga considerable para el mantenimiento de VSCode.
compile_commands.json, especialmente con CMake, donde es relativamente fácil, y puedes hacer queclangdlo vea, la extensión declangdme ha funcionado mucho mejor.Emacs, que uso, tampoco tiene muchos mecanismos para impedir ataques a la cadena de suministro, y la mayoría usa agregadores de extensiones de la comunidad que traen cosas directamente desde repositorios Git.
Aun así, hay una pequeñísima ventaja: creo que una proporción mucho mayor de usuarios de Emacs realmente mira el código fuente de las extensiones que instala.
Microsoft lleva años diciendo que “la seguridad lo es todo y ahora es lo más importante”, así que resulta extraño que no haya cubierto ni siquiera algo tan básico para el grupo de usuarios para quienes el impacto de que se roben cosas como claves SSH es mayor, y que además debería ser el más consciente de la seguridad: los desarrolladores.
La situación en la que la gente instala extensiones al azar y Visual Studio Code recomienda extensiones arbitrarias bajo el pretexto de “soporte de lenguaje” parece mucho peor de lo que pensaba.
Hay un buen hilo sobre la extensión
cpptools: https://github.com/microsoft/vscode-cpptools/discussions/126...No profundicé en el proceso de compilar desde el código fuente, pero leyendo esto parece directamente imposible.
Parece que hará falta un nuevo término para expresar si una base de código tiene licencia OSS y si sus dependencias de compilación también tienen licencia OSS.
maines software libre,non-freees software no libre ycontribes software libre que depende de algo fuera demain, normalmente software no libre.No me gusta mucho el término
contriben sí, pero esta clasificación parece bastante razonable.Mucho F/OSS en Windows y casi todo el F/OSS en macOS tienen dependencias de compilación propietarias como MSVC, Xcode y frameworks o toolkits GUI de Apple, pero aun así pueden ser F/OSS por sí mismos.
Pero este no es ese problema: aquí un empleado de Microsoft que parece ser mantenedor dijo que “nuestra licencia también prohíbe usar la extensión en distribuciones alternativas de VS Code, y solo puede usarse en la distribución oficial hecha por Microsoft”.
Eso es simplemente software propietario.
La libertad 0 de la definición de software libre es la libertad de ejecutar el programa con cualquier propósito; y si una distribución de terceros de VSCode no tiene los mismos derechos sobre extensiones que la distribución oficial, ni el derecho a usarse con extensiones compatibles, entonces tampoco pasa la libertad 3, independientemente de la licencia de parte del código.
Decir que “si lo que se intenta es redistribuir el binario del servidor de lenguaje como una oferta propia, la licencia de runtime lo prohíbe” significa que no cumple con el criterio 1 de la definición de open source, el de redistribución; y VSCode, al no permitir que las distribuciones modificadas tengan los mismos derechos que la original, tampoco cumple el criterio 3, el de obras derivadas.
VSCode y esta extensión no son open source; son software propietario que incluye algunos componentes open source.
Definición de software libre: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
Definición de open source: https://opensource.org/osd
También es importante que estas definiciones no son significados generales de diccionario, sino términos creados dentro de un movimiento con fines sociales y técnicos específicos.
El mismo front-end también está incluido en el IDE de Visual Studio.
Tengo entendido que existe una extensión de C++ completamente open source basada en
clangdcomo alternativa, aunque podría estar equivocado.“Que el software libre que Microsoft regala no sea lo suficientemente abierto” suena como una afirmación bastante extraña incluso con los estándares actuales.
Antes, un “IDE gratuito” significaba Eclipse o Vim con un montón de extensiones.
Visto así, más que Microsoft obstaculizando alternativas abiertas, parece simplemente que esas alternativas no son tan buenas; y cuando usas software creado por una empresa que tiene que pagar sueldos a sus empleados y además generar ganancias, eso viene con el paquete.
Quienes sienten que deberían recibir por derecho propio el código fuente del mejor software de Microsoft pueden ver cómo se ve el verdadero open source mantenido por una organización independiente sin fines de lucro.
Funcionará, y quizás hasta tenga un depurador de verdad, pero es muy probable que al poco tiempo quieran volver.
La gente da demasiado por sentado el software que recibió gratis. No hace tanto había que pagar cientos o miles de dólares por un IDE, y si unos años después necesitabas una versión nueva, también pagabas la actualización.
Las extensiones VSIX deberían ser, en cierta medida, un estándar abierto, pero extensiones de Microsoft como Pylance se niegan activamente a funcionar si detectan que se están ejecutando en un VS Code que no es la compilación de Microsoft.
El punto central se acerca más a que los desarrolladores están siendo engañados y a que el objetivo de Microsoft es ir cerrando las partes esenciales.
Incluso cuando terminen con la paridad funcional, después quedarán los problemas de rendimiento, y nadie sabe cuándo se resolverán.
La idea del software open source es buena, pero hoy en día el mejor software casi siempre se obtiene pagando.
Sé cuál es el costo de usar Emacs y Vim. Aunque en teoría sean completamente gratuitos, en la práctica tienen costos de tiempo, paciencia y dedicación, y sé que mi elección nos beneficia a mí, a la comunidad y a la industria.
Cuando usaba IntelliJ antes, también sabía exactamente cómo se beneficiaba JetBrains: pagaba una licencia y la renovaba cada año.
Pero ¿cuál es el cálculo de Microsoft? Me dan esta herramienta hermosa y decente totalmente “gratis”; ¿qué precio voy a pagar en el futuro?
Es difícil creer que una megacorporación con una capitalización de mercado comparable al PIB de Alemania invierta enormes recursos en crear un editor de código “gratuito” solo porque ama a los desarrolladores, y los desarrolladores deberían ser al menos un poco escépticos.
Considero que el software de Microsoft es más bien una pila de basura de pesadilla.
El punto del artículo es que cuando el software de código cerrado finge ser open source, también afecta a quienes no quieren usarlo, y eso se te está escapando.
Por ejemplo, no quiero usar ni Azure DevOps ni GitHub Actions, pero la organización donde trabajo tiene que subir proyectos a GitHub, así que termino obligado a usarlos.
Como resultado, siento que mi trabajo y mi conocimiento se usan para que Microsoft explote a los usuarios.
El único consuelo es que es trabajo remunerado; personalmente no uso GitHub y recomendaría a otros hacer lo mismo.
Si no se propone un modelo para justificar un presupuesto anual de unos 20 millones de dólares para más de 50 empleados de tiempo completo que crean VS Code, esta crítica suena como: “me molesta que hayan hecho un poco incómodo que nuestra empresa tome sus logros de ingeniería, solo cambie la superficie del producto y lo venda más barato para obtener ganancias sin costos propios de desarrollo”.
Si lo publica como open source, gana la confianza de otras comunidades, obtiene código gratis, revisión de bugs y también la creación y soporte de extensiones fuera del ecosistema de Microsoft, mientras Microsoft puede seguir usándolo.
No parece un problema tan complicado.
Históricamente, eso fue un camino garantizado hacia la obsolescencia.
Incluso sin sus logros de ingeniería, existen Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox, etc.
El generoso regalo de una manta por parte de Microsoft solo me interesa si no viene con viruela incluida.
Pero es un poco gracioso que se informe sobre esto como si fuera una gran sorpresa. Era obvio desde el principio; simplemente no me importó porque no parecía valer la pena pelear por eso.
El problema de que los desarrolladores con licencias BSD/MIT sean explotados me interesa tan poco como el problema de que desactivar la telemetría pueda tambalear el modelo de negocio de Microsoft.
Todos eligieron esto sabiendo en qué se metían, pensando “algún superior de una gran empresa nos reconocerá”, y como efectivamente los reconoció, felicidades.
Yo no subiría nada con una licencia más débil que AGPL, pero al final hay cosas que me importan muchísimo más que el software.
Todavía estoy tratando de entender cuál es el problema
Suena como que Microsoft está creando mejores extensiones de
cpptools/C++, pero muchos componentes de Microsoft están cerrados, así que no se puede crear una versión OSS completaY me pregunto si, cuando los usuarios se dan cuenta de que no pueden usar extensiones nativas en ninguna interfaz web, eso se convierte en un problema de la gente de las interfaces web
Si la gente quiere usar freeware en vez de OSS, puede ser decepcionante, pero no sé si realmente sea un problema
Si hay una respuesta, probablemente sea comunicar con más claridad quién debería hacerse responsable
Los proveedores de código abierto deberían dejar más claro que lo que ofrecen es de código abierto y forma parte de un ecosistema abierto, e informar a los desarrolladores que no todas las extensiones lo son, y que las extensiones alternativas de Microsoft no lo son
Si los principales proyectos de extensiones se ponen de acuerdo, podrían agregar en la descripción del marketplace un aviso de que
vscode-cpptoolsno tiene una licencia aprobada por la OSI, contiene muchos blobs binarios no revisados y Microsoft no permite su redistribución en builds nativas de código abierto ni en servicios web que ofrecen VSCodeNi legal ni culturalmente Microsoft querría bloquear el acceso al marketplace solo porque algunos proyectos OSS compararon sus condiciones de licencia con las de Microsoft
Apple también está enfrentando ahora demandas por su marketplace, y Microsoft no querrá una demanda por su marketplace ni otra demanda antimonopolio
Luego crear otra API con una sola función pública, y que esa función solo haga una llamada
externa ese binario de la bibliotecaSubir la segunda API a GitHub con licencia MIT y declararla de código abierto
En términos generales, si el 100% de la funcionalidad del software está dentro de un binario compilado de código cerrado, la cuestión es si llamarlo código abierto debería considerarse publicidad engañosa
En otras palabras, es una cuestión de quién traza la línea cuando alguien va más allá de la intención del código abierto por motivos explotadores
No sé si la funcionalidad de
cpptoolsestá cerrada al 100%, pero en la práctica, dentro de un repositorio que dice tener licencia MIT hay otras tres licencias que hay que aceptarHay que leer demasiado para descubrir cuál es el punto real, y la idea de un “ecosistema fragmentado” aparece varias veces sin explicación
No tengo idea de qué se supone que significa una expresión como “una trampa para moscas diseñada para fragmentar”
VS Code es un IDE que se puede descargar y usar gratis desde Microsoft; no es una plataforma ni un ecosistema mágico de código abierto que Microsoft no controla, es un producto
Parece que todos quieren crear servicios “universales” para desarrolladores, pero en realidad no quieren crear ni financiar un IDE, o les resulta demasiado difícil
Eso no es culpa de Microsoft
No intento defender a Microsoft, pero puso a disposición gratis una base de código enorme y construyó encima un producto mayormente gratuito
Si haces un fork, lo único es que no tienes acceso a los servidores de Microsoft; eso me parece bastante justo
Y Monaco es un editor abrumadoramente bueno, por eso lo usan los frontends. Antes instalaban CodeMirror o Ace cuando eso era lo mejor
Más que haber un gran plan maestro detrás de la creación de Monaco, parece que vieron la oportunidad de que, al convertirlo en un proyecto independiente, se habilitaran montones de interfaces web
Es un problema muy grande que “el futuro de las herramientas de desarrollo de software que se crearán en adelante esté completamente cerrado, pero como algunos componentes cumplen la definición de la OSI, la gente no vea el panorama completo y lo considere aceptable”
En especial, varias empresas financiadas por VC usan el término código abierto de forma demasiado laxa, y con eso están deteriorando el lenguaje, el significado e incluso el espíritu del movimiento de código abierto
YC también está apoyando a varias empresas que dicen ser de código abierto, pero que no siguen en absoluto ese espíritu
Los argumentos morales sobre espíritu o ética no son tan relevantes
Lo importante es que las licencias de software son documentos legales, y donde su interpretación tiene significado es en los tribunales
No parece haber muchas demandas relacionadas con VS Code, y Microsoft suele tener esa parte bastante ordenada
En términos legales, VS Code parece lo suficientemente seguro. Es cierto que algunas extensiones no tienen licencia OSS o son directamente de código cerrado, pero si no te gusta, no las uses
Más aún, puedes crear código abierto tú mismo y arreglarlo. El código abierto no es un derecho, sino un privilegio que se concede a discreción del creador, no algo que se pueda exigir
VS Code es un producto de código cerrado que incluye muchos componentes OSS, y tiene tantos de esos componentes que también existe VS Codium, que es completamente OSS
Muchos de esos componentes OSS se usan también en otros productos, y algunos son totalmente de código abierto
El valor del ecosistema de VS Code está en que permite que prosperen estos componentes y el ecosistema de productos
Nadie tiene derecho a recibir VS Code gratis. De hecho, nadie tiene derecho a recibir nada gratis
La alternativa es pagar por un IDE comercial inflado
VS Code está bien, es de uso general, gratis y lo bastante abierto como para poder hacerle un fork
La gente olvida que esto es un producto de ingeniería sorprendente. Si miras el código, no es algo que salga gratis
Ni Microsoft ni ninguna otra empresa le debe algo gratis a nadie, y esa sensación de tener derecho a todo necesita controlarse
El problema es cuando una oferta gratuita en realidad está diseñada para meterte en un pantano de responsabilidad legal y responsabilidad monetaria sin límite
Más aún en un servicio como VSCode, que no es una compra única sino que te hace depender continuamente de Microsoft mediante extensiones y actualizaciones; de hecho, está diseñado así
En vez de crear una opción sencilla de pagar una vez de forma clara y terminar, eligieron extraer a largo plazo una cantidad ambigua según el nivel de resistencia del usuario
También lo digo siempre sobre el código abierto: soy escéptico a la hora de adoptar frameworks que no tengan mucho dinero detrás
Depender de los caprichos de algún ingeniero genio al azar de internet es riesgoso
Microsoft va a ganar dinero con VSCode. Solo que no de forma tan directa como Google gana dinero con Chrome
Creo que el OSS es excelente, pero esa no es la razón por la que uso VS Code
Lo uso porque resolvió el problema de necesitar un editor usable que no fuera un monstruo como Eclipse
En este espacio hay otras opciones como Sublime, pero VS Code siempre me pareció el menos intrusivo
Antes también existía algo similar, Adobe Brackets, pero por alguna razón era muy lento y tenía muchos bugs
Si eres entusiasta del OSS, las críticas del artículo son válidas. Pero al final el código fuente está ahí y, si quieres, también puedes operar tu propio marketplace
Requiere tiempo y dinero, pero si crees en esa idea, deberías invertir en ella en vez de depender de una megacorporación
Si hay extensiones propietarias que no puedes tener, es una lástima, pero alguien podría crear versiones OSS
En general estoy de acuerdo con el artículo, pero no me hago ilusiones de que Microsoft haga esto por convicción en el código abierto y, en el peor de los casos, hay otras opciones, así que está bien