Défaut de conception de Visual Studio Code (2022)

• Visual Studio Code sépare le code source sous licence MIT du produit sous licence propriétaire distribué par Microsoft, si bien que des forks comme VSCodium et OpenVSCode Server entrent en conflit avec l’écosystème officiel
• Les builds officielles sont distribuées avec, dans product.json, des paramètres propres à Microsoft comme telemetry, gallery, logo ; les builds communautaires deviennent des builds « clean », mais ne peuvent pas se connecter au Visual Studio Code Marketplace
• VSCodium et OpenVSCode Server suppriment ou n’incluent pas la télémétrie des versions officielles, mais, entre la collecte de données par les extensions elles-mêmes et les restrictions d’accès au Marketplace, il leur est difficile d’offrir telle quelle l’expérience VS Code attendue par les utilisateurs
• Lorsque des extensions et serveurs de langage Microsoft, comme Pylance, la feuille de route de l’extension C# ou la licence des outils C/C++, sont liés aux produits et services officiels, des services concurrents comme Gitpod, GitLab, Datacoves, OpenBB ou Foam ont du mal à proposer légalement les mêmes fonctionnalités
• OpenVSX, le développement d’outils de langage ouverts et le soutien aux mainteneurs open source sont cités comme des alternatives, mais quand Microsoft remplace les valeurs par défaut par des outils propriétaires, la communauté et les produits concurrents doivent assumer à la fois des écarts fonctionnels, des différences de configuration et des contraintes juridiques

---

Le code source est ouvert, mais le produit est distribué différemment

• Sept ans après son lancement, Visual Studio Code s’est imposé comme l’éditeur de fait dans le développement logiciel
• Microsoft a publié le code source de Visual Studio Code sous licence MIT, mais le produit Visual Studio Code téléchargé par les utilisateurs est distribué sous une licence propriétaire distincte
• D’après les explications des mainteneurs de Visual Studio Code, le build de Microsoft clone le dépôt vscode, puis remplace product.json par une version propre à Microsoft
  • Ce fichier contient des fonctionnalités propres à Microsoft, comme la télémétrie, la galerie et le logo
  • Le build ainsi produit est distribué sous licence Microsoft
• La critique centrale du texte est que cette distinction constitue le mécanisme clé par lequel Microsoft divise la communauté open source

Les limites auxquelles se heurtent VSCodium et OpenVSCode Server

• VSCodium est une distribution desktop sous licence libre, portée par la communauté
  • Elle suit automatiquement le projet upstream sous licence MIT et génère des builds binaires
  • Elle fournit un build dont la télémétrie présente dans la version officielle a été supprimée
  • Le product.json par défaut ne configure aucun endpoint Microsoft, ce qui produit un build « clean » sans personnalisations Microsoft
• Même VSCodium, qui utilise la même base de code, ne peut pas bloquer complètement toute collecte de données
  • Les extensions peuvent collecter des données de manière indépendante, il faut donc faire attention aux extensions installées
• OpenVSCode Server est une distribution serveur sous licence libre, qui sert de base à Gitpod
  • Elle suit automatiquement le projet upstream sous licence MIT
  • La branche gp-code/main comporte quelques personnalisations par surcouche
  • Elle n’inclut pas la télémétrie de la version officielle
• Aucune des deux distributions ne peut se connecter au Microsoft Visual Studio Code Marketplace, et cette restriction entraîne une rupture de l’écosystème

Le virage de Microsoft vers les services et sa stratégie pour les outils de développement

• Microsoft a commencé à transformer sa manière de fournir des logiciels il y a environ neuf ans
  • L’entreprise est passée d’un modèle où des équipes QA dédiées testaient les builds à un développement par sprints, à des rolling releases et à une approche fondée sur les retours de télémétrie des Insider Builds
• À la même période, à la faveur de réorganisations internes, Microsoft est devenue une entreprise de services
  • Azure est devenu pendant cette période un concurrent substantiel d’AWS
• Du point de vue des consommateurs, le plus grand changement a été le déplacement de la base client depuis des produits on-premise installables vers un modèle de consommation de services fournis par Microsoft
• Dans le domaine des outils de développement aussi, les IDE qui ne reposent pas sur un abonnement sont présentés comme en recul
  • Le cas de Xcode d’Apple est mentionné comme exception, grâce à l’existence d’autres sources de revenus
• Visual Studio Code est critiqué comme étant la porte d’entrée vers un basculement de l’écosystème des outils de développement vers un modèle de services consommables de bout en bout
  • GitHub Codespaces est décrit comme une marque blanche de services existants liés à Visual Studio Online, Microsoft Dev Box et Microsoft Azure DevTest Labs

GitHub Codespaces et Microsoft DevDiv

• Microsoft a acquis GitHub en 2018 et a présenté Visual Studio Online en 2019
  • Celui-ci incluait un composant permettant d’héberger un « codespace » localement
  • Par la suite, les éléments associés, dont l’équipe Codespaces, ont été transférés vers GitHub
• GitHub Codespaces est décrit comme un projet DevDiv passé sous l’égide de GitHub
• Le jour où Nat Friedman a quitté son poste de CEO, un e-mail de réorganisation interne de Microsoft a été partagé
  • Julia Liuson a été promue présidente de Microsoft Developer Division
  • Le CEO de GitHub, Thomas Dohmke, s’est retrouvé dans une structure où il rend compte à Julia Liuson
  • La Developer Division comprend Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, les SDK développeurs Azure, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache, Spring Cloud, etc.
• Selon cet e-mail, l’utilisation de Visual Studio et de Visual Studio Code a été multipliée par plus de 16 depuis 2014
• Julia Liuson est mentionnée comme la personne qui, avant sa promotion, a exécuté un changement de dernière minute ayant divisé la communauté .NET
  • Selon une citation de The Verge, une source anonyme interne à Microsoft a vu ce changement comme une décision dictée par le business

Une structure d’écosystème qui fonctionne comme une « rupture conçue »

• Les produits concurrents comme Gitpod peuvent exister dans l’écosystème Visual Studio Code, mais il leur est reproché d’être exposés au fait que Microsoft peut à tout moment créer un risque juridique et segmenter le marché
• Le code source open source de Visual Studio Code attire les utilisateurs, mais il rend difficile pour les services concurrents de fournir une expérience fluide comparable à celle de Visual Studio Code officiel ou de GitHub Codespaces
• Outre Gitpod, des entreprises comme GitLab, Datacoves, OpenBB ou Foam, qui cherchent à concurrencer Microsoft ou GitHub en s’appuyant sur le code source de VS Code, rencontrent le même problème
• Si l’on dépend des outils Microsoft, les domaines suivants sont cités comme difficiles à proposer légalement par des services concurrents
  • Microsoft .NET C#
  • Le marché Python généraliste et data science
  • Project Jupyter et la majeure partie du marché de la data science
  • C ou C++
  • Java est présenté comme une possible prochaine cible si les outils Microsoft se rapprochent du niveau des outils RedHat
• D’après l’indice TIOBE, cinq des langages et écosystèmes ci-dessus figurent parmi les axes les plus populaires, et Microsoft est décrit comme disposant, via TypeScript, d’un contrôle proche de celui exercé sur JavaScript, le septième langage le plus populaire

Changement des valeurs par défaut et problème des extensions propriétaires

• Microsoft est critiqué pour sa capacité à faire d’une offre propriétaire le choix par défaut via une mise à jour d’extension, une fois l’adoption suffisante acquise
• Dans la communauté Python, le Microsoft Python Language Server open source a été abandonné et Pylance, propriétaire, est devenu le choix par défaut
  • Selon une citation de Visual Studio Magazine, Microsoft n’a pas forcé les utilisateurs à migrer, mais a défini Pylance comme nouvelle valeur par défaut
  • L’extension Python est créditée d’environ 50 millions de téléchargements sur le VS Code Marketplace, soit environ deux fois plus que l’extension Jupyter, citée comme la deuxième plus populaire
• Dans la communauté .NET, la feuille de route de l’extension C# est présentée comme un cas où un changement similaire des valeurs par défaut est en cours
• Même si des outils alternatifs comme Open.NET sont créés, les utilisateurs doivent relier séparément les configurations propres à chaque plateforme
  • Sur desktop, il est possible d’ajouter ms-dotnettools.csharp dans devcontainer.json
  • Sur Gitpod, il faudrait ajouter dans gitpod.yml un outil ouvert qui n’existe pas encore, ce qui crée ce type d’écart
• Dans l’écosystème officiel de Microsoft, la même configuration devcontainer.json devient une source unique de configuration qui fonctionne telle quelle dans Visual Studio Code desktop et GitHub Codespaces

Les contraintes juridiques créées par les licences

• Le texte avertit que si Gitpod, GitLab, Datacoves, OpenBB, Foam, etc. contournent les restrictions et proposent dans leurs services des extensions Microsoft comme ms-dotnettools.csharp, ils pourraient faire face à une réaction juridique ferme de l’équipe légale de Microsoft
• Même l’installation manuelle de cette extension par des utilisateurs d’environnements de développement cloud concurrents pourrait constituer une violation de licence
• Le texte de licence de l’extension Microsoft C/C++ indique que le logiciel ne peut être installé et utilisé qu’avec Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server et les produits et services Microsoft qui leur succèdent
• À cause de cette condition, les produits basés sur VS Code qui ne sont pas des distributions officielles de Microsoft ont du mal à proposer tels quels les outils de langage Microsoft attendus par les utilisateurs

Pistes de réponse : OpenVSX et outils de langage ouverts

• Une critique affirme que l’avenir des outils de développement logiciel en cours de construction se dirige vers un modèle fermé
  • Même si certains composants satisfont à la définition de l’OSI, l’ensemble du graphe de configuration peut ne pas y satisfaire
• L’open source est décrit comme ayant été, à l’origine, une arme financière pour contenir les logiciels on-premise propriétaires et préserver l’ouverture des formats de fichiers
  • Cela est aussi lié aux raisons pour lesquelles il est difficile de gagner de l’argent avec l’open source
• Le texte suggère qu’il pourrait être nécessaire de lancer un nouveau mouvement garantissant l’ouverture de la liberté informatique face au SaaS propriétaire, ou de réexaminer le mouvement du logiciel libre des années 1970
• L’Open-Source Sustainability Fund de Gitpod est l’une des réponses à ce problème de rupture de l’écosystème
  • En 1,5 an, plus de 32 000 dollars ont été distribués à des mainteneurs d’outils de serveurs de langage de la communauté open source
• Gitpod a créé Open VSX et l’a donné à la Fondation Eclipse afin de résoudre en partie le problème du Marketplace dans l’écosystème open source de Visual Studio Code
• Le plus grand défi à venir consiste à développer des outils de langage ouverts dans chaque domaine où Microsoft a déplacé la communauté vers des serveurs de langage propriétaires

Ajouts effectués lors de modifications ultérieures

• La modification du 31 août 2022 résume la situation ainsi : Microsoft a créé VSCode, proposé une distribution gratuite propriétaire et des extensions gratuites propriétaires, puis lié la meilleure expérience par langage à VSCode sous forme fermée
• La modification du 16 décembre 2022 ajoute que le Web IDE de GitLab basé sur VSCode MIT et son expérience de développement distant rencontrent le même problème
• La modification du 13 octobre 2023 indique que Project IDX de Google est lui aussi basé sur VSCode MIT, et qu’il est impossible, et non légal, de s’attendre à ce que les LSP Visual Studio Code fonctionnent tels quels pour .NET et Python
• La modification du 24 avril 2025 critique Microsoft pour avoir intentionnellement fracturé l’écosystème VSCode afin de freiner la concurrence d’assistants de codage IA comme Windsurf et Cursor
  • Elle mentionne le même jour un lien entre le lancement d’un produit concurrent de Microsoft et la restriction de l’accès des forks de VS Code à l’extension C/C++

[unsure4000]

J’envisage d’essayer d’utiliser vim ou zed.

J’utilise un terminal avec une opacité définie,
savez-vous par hasard comment supprimer la couleur de fond de nvim ?
Si je trouve juste ça, j’ai vraiment envie d’essayer nvim...

[siscof]

Si vous utilisez le terminal kitty, en le configurant avec la même couleur d’arrière-plan, la transparence devrait s’appliquer.
Sinon, vous pouvez aussi envisager un plugin comme celui-ci..

https://github.com/xiyaowong/transparent.nvim

[unsure4000]

Merci. Je vais examiner cela.

[unsure4000]

C'est réussi. Merci. Passez une excellente journée.

[GN⁺]

Avis de Hacker News

• D’une certaine manière, cette situation pourrait aussi être une occasion. L’écosystème VSCode est assez fragile à bien des égards.
  cpptools a des aspects remarquables, mais il dysfonctionne souvent, est pratiquement impossible à déboguer, et il est difficile d’espérer beaucoup mieux des autres extensions.
  Le problème plus large est que le modèle de sécurité est très faible : les extensions ne sont pas sandboxées, et les clients qui accèdent à des dépôts distants sont eux aussi, par conception, très peu sûrs.
  Quand on ne consulte que le code de son entreprise, on peut moins se soucier de la possibilité qu’un dépôt vous attaque, mais il faut évidemment s’inquiéter des extensions malveillantes, et nous avons pris l’habitude de faire trop facilement confiance aux outils de développement.
  Il ne faut jamais faire confiance à un LLM, et il n’est pas sûr de donner à un LLM, qui pourrait tenter d’attaquer l’utilisateur, le droit d’écrire directement dans un dépôt ou d’exécuter du code JS dans certains contextes de VSCode.
  Dans un meilleur écosystème, un outil équivalent à cpptools n’aurait pas d’accès à Internet, donc pas de télémétrie, et ne pourrait guère que lire l’espace de travail, créer ses propres fichiers de cache et manipuler l’UI.

  • Par conception, VSCode masque l’état réel de l’environnement de développement ; quand on aide des utilisateurs bloqués, ils ne savent souvent pas sur quelle machine ils sont connectés, où se trouvent les fichiers dans le système de fichiers, quel interpréteur Python ils utilisent, ni même à quoi HTTPS_PROXY est défini.
    L’extension SSH lance aussi un processus serveur pour chaque client auquel l’utilisateur se connecte, et la préservation de l’état après déconnexion ne semble pas cohérente.
    Au final, on passe beaucoup de temps à aider les gens à corriger des problèmes qu’ils se sont créés eux-mêmes en utilisant VSCode.
  • Le modèle de sécurité de VSCode est aussi une grande source d’inquiétude pour notre équipe de sécurité informatique.
    Il n’y a pas d’entre-deux entre autoriser un accès ouvert à toutes les extensions de la marketplace, ou tout verrouiller complètement et n’installer les extensions qu’à partir de fichiers locaux.
    Cette dernière option alourdit considérablement la maintenance de VSCode.
  • Si vous avez ou pouvez générer un compile_commands.json, ce qui est relativement facile surtout avec CMake, et que vous pouvez faire en sorte que clangd le voie, l’extension clangd a été bien meilleure pour moi.
  • Si les clients qui accèdent à des dépôts distants sont extrêmement peu sûrs par conception, je me demande quel est le meilleur éditeur en matière de sécurité des extensions tierces.
    Même l’Emacs que j’utilise n’a pas grand-chose pour empêcher les attaques de chaîne d’approvisionnement, et la plupart des gens utilisent des agrégateurs d’extensions communautaires qui récupèrent directement depuis des dépôts Git.
    Le tout petit avantage, toutefois, est que les utilisateurs d’Emacs sont probablement bien plus nombreux à réellement lire le code source des extensions qu’ils importent.
  • Si c’est vrai que les extensions ne sont pas sandboxées, c’est assez surprenant.
    Microsoft répète depuis des années que « la sécurité est tout, et c’est ce qui compte le plus aujourd’hui » ; il est donc étrange qu’ils n’aient même pas assuré ce minimum pour la catégorie d’utilisateurs la plus sensible à la sécurité, et celle pour laquelle l’impact d’un vol, par exemple de clés SSH, serait le plus élevé.
    Avec des gens qui installent des extensions au hasard et Visual Studio Code qui recommande des extensions arbitraires au nom de la « prise en charge du langage », la situation paraît bien pire qu’on ne l’imagine.

• Il existe un bon fil au sujet de l’extension cpptools : https://github.com/microsoft/vscode-cpptools/discussions/126...
  Je n’ai pas creusé en profondeur le processus de compilation depuis les sources, mais à lire ce billet, cela semble tout simplement impossible.
  Il va peut-être falloir un nouveau terme pour exprimer qu’une base de code est sous licence OSS, et que ses dépendances de build le sont aussi.

  • C’est vraiment grave. Si Microsoft enterre ce fil plus tard, les gens du futur se demanderont de quoi nous parlions.
  • Debian divise sa distribution en trois composants : main correspond aux logiciels libres, non-free aux logiciels non libres, et contrib aux logiciels libres qui dépendent d’éléments hors de main, généralement non libres.
    Je n’aime pas particulièrement le terme contrib lui-même, mais cette classification me semble assez pertinente.
  • Ces quelques petits commentaires suffisent déjà à montrer précisément le problème auquel l’écosystème plus large est confronté, et il risque fort d’empirer beaucoup plus vite qu’on ne le pense.
  • VSCode n’est pas open source, et cette extension ne l’est pas non plus.
    Beaucoup de F/OSS sous Windows et presque tous les F/OSS sous macOS ont des dépendances de build propriétaires comme MSVC, Xcode, les frameworks Apple ou les toolkits GUI, mais ils peuvent tout de même être eux-mêmes F/OSS.
    Mais ici, le problème n’est pas celui-là : un employé de Microsoft qui semble être mainteneur a déclaré que « notre licence interdit aussi d’utiliser l’extension dans des distributions alternatives de VS Code ; elle ne peut être utilisée que dans la distribution officielle produite par Microsoft ».
    C’est tout simplement un logiciel propriétaire.
    La liberté 0 de la définition du logiciel libre est la liberté d’exécuter le programme pour l’usage de son choix ; et si une distribution tierce de VSCode n’a pas les mêmes droits sur les extensions que la distribution officielle, ni le droit d’être utilisée avec des extensions compatibles, alors, quelle que soit la licence d’une partie du code, elle ne satisfait pas non plus à la liberté 3.
    Dire que « si vous essayez de redistribuer le binaire du serveur de langage dans votre propre offre, la licence d’exécution l’interdit » signifie que cela ne satisfait pas au critère 1 de la définition de l’open source, celui de la redistribution ; et VSCode, qui n’autorise pas les distributions modifiées à disposer des mêmes droits que l’original, ne satisfait pas non plus au critère 3, celui des travaux dérivés.
    VSCode et cette extension ne sont donc pas open source : ce sont des logiciels propriétaires qui incluent certains composants open source.
    Définition du logiciel libre : https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
    Définition de l’open source : https://opensource.org/osd
    Il est aussi important de rappeler que ces définitions ne relèvent pas du sens courant du dictionnaire : ce sont des termes élaborés au sein d’un mouvement, avec des objectifs sociaux et techniques précis.
  • Si je comprends bien, cette extension utilise un frontend C++ propriétaire sous licence commerciale auprès d’EDG.
    Le même frontend est aussi intégré à l’IDE Visual Studio.
    À ma connaissance, il existe comme alternative une extension C++ entièrement open source basée sur clangd, mais je peux me tromper.

• Dire que « le logiciel libre que Microsoft fournit gratuitement n’est pas assez ouvert » sonne comme une affirmation assez étrange, même selon les critères actuels
  À l’époque, un « IDE gratuit » voulait dire Eclipse ou Vim avec une tonne d’extensions
  À première vue, Microsoft ne bloque pas les alternatives ouvertes ; c’est plutôt que ces alternatives sont simplement moins bonnes, et c’est le genre de chose qui arrive quand on utilise un logiciel conçu par une entreprise qui doit payer ses employés tout en dégageant des bénéfices
  Les personnes qui estiment avoir naturellement droit au code source des meilleurs logiciels de Microsoft devraient regarder à quoi ressemble un vrai projet open source maintenu par une organisation indépendante à but non lucratif
  Il fonctionnera, et aura peut-être même un vrai débogueur, mais il y a de fortes chances qu’elles aient envie de revenir en arrière assez vite
  Les gens tiennent beaucoup trop pour acquis les logiciels qu’ils reçoivent gratuitement. Il n’y a pas si longtemps, il fallait payer des centaines voire des milliers de dollars pour un IDE, puis payer aussi la mise à niveau si l’on avait besoin d’une nouvelle version quelques années plus tard

  • Il est difficile de dire que Microsoft ne bloque pas les alternatives ouvertes
    Les extensions VSIX devraient être, dans une certaine mesure, un standard ouvert, mais des extensions Microsoft comme Pylance refusent activement de fonctionner lorsqu’elles détectent qu’elles tournent dans un VS Code qui n’est pas le build de Microsoft
  • « Le logiciel libre que Microsoft fournit gratuitement n’est pas assez ouvert » n’est ni une citation de l’article ni sa thèse
    L’idée centrale est plutôt que les développeurs se font avoir, et que l’objectif de Microsoft est de fermer progressivement les parties essentielles
  • Le projet Asahi Linux est similaire. Il accomplit un travail énorme, mais il est encore en train d’atteindre la parité fonctionnelle de base avec un ordinateur portable vieux de trois ans
    Même une fois cette parité atteinte, il restera ensuite les problèmes de performances, et on ne sait pas quand ils seront résolus
    L’idée du logiciel open source est séduisante, mais aujourd’hui les meilleurs logiciels s’obtiennent presque toujours en payant
  • Mon problème, c’est que je ne connais pas le grand plan de Microsoft
    Je connais le prix à payer pour utiliser Emacs et Vim. Même s’ils sont théoriquement entièrement gratuits, ils coûtent en pratique du temps, de la patience et de l’engagement, et je sais que mon choix profite à moi-même, à la communauté et au secteur
    Quand j’utilisais IntelliJ autrefois, je savais aussi exactement comment JetBrains gagnait de l’argent. Je payais une licence et la renouvelais chaque année
    Mais quel est le calcul de Microsoft ? Ils fournissent un outil aussi beau et correct entièrement « gratuit » ; quel prix devrai-je payer à l’avenir ?
    Il est difficile de croire qu’une méga-entreprise dont la capitalisation boursière équivaut au PIB de l’Allemagne consacre d’énormes ressources à un éditeur de code « gratuit » simplement par amour des développeurs ; ceux-ci devraient au moins faire preuve d’un peu de scepticisme
  • L’expression « les meilleurs logiciels de Microsoft » ressemble à une plaisanterie
    À mes yeux, les logiciels Microsoft ressemblent plutôt à un tas d’ordures cauchemardesque
    Le point de l’article est qu’un logiciel propriétaire qui se fait passer pour de l’open source affecte même les personnes qui ne veulent pas l’utiliser, et cela t’échappe
    Par exemple, je ne veux pas non plus utiliser Azure DevOps ou GitHub Actions, je ne sais même plus lequel, mais l’organisation où je travaille m’impose de le faire parce que le projet doit être hébergé sur GitHub
    Résultat, j’ai l’impression que mon travail et mes connaissances servent à Microsoft pour exploiter les utilisateurs
    La seule consolation, c’est que c’est du travail rémunéré ; à titre personnel, je n’utilise pas GitHub et je recommanderai aux autres d’en faire autant

• Si l’on ne propose pas de modèle expliquant comment justifier un budget annuel d’environ 20 millions de dollars pour les plus de 50 salariés à temps plein qui développent VS Code, cette critique ressemble à : « ça m’agace qu’ils aient rendu un peu moins confortable le fait de prendre leurs réalisations d’ingénierie, de changer juste l’apparence du produit dans notre entreprise, puis de le vendre moins cher sans coûts de développement propres pour en tirer profit »

  • Il est compréhensible que Microsoft développe son propre IDE pour l’usage interne de plusieurs divisions et consacre un budget à un outil moderne et flexible
    En le publiant en open source, l’entreprise gagne la confiance d’autres communautés, obtient du code gratuit, des vérifications de bugs ainsi que la création et le support d’extensions en dehors de l’écosystème Microsoft, tout en pouvant continuer à l’utiliser elle-même
    Cela ne me paraît pas si compliqué
  • Ce n’est pas mon problème. Mon problème est de ne pas rendre mes compétences professionnelles dépendantes de la bienveillance continue de Microsoft
    Historiquement, c’était une voie garantie vers l’obsolescence
    Même sans leurs réalisations d’ingénierie, il existe Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox, etc.
    Le généreux cadeau de couverture de Microsoft ne m’intéresse que s’il n’est pas accompagné de la variole
  • Que leur modèle économique soit mauvais n’est pas mon souci. Ce ne sont pas de pauvres enfants exploités pour de mauvaises décisions
    En revanche, présenter cela comme une grande surprise est un peu risible. C’était évident dès le départ ; simplement, cela ne semblait pas valoir la peine de se battre, donc on n’y a pas prêté attention
    Le problème de l’exploitation des développeurs sous licences BSD/MIT m’intéresse à peu près autant que celui de savoir si la désactivation de la télémétrie pourrait ébranler le modèle économique de Microsoft
    Tout le monde savait dans quoi il s’engageait et l’a choisi en pensant : « le grand frère de la grande entreprise va nous remarquer », et comme il l’a effectivement fait, félicitations
    Pour ma part, je ne publierais rien sous une licence plus faible que l’AGPL, mais au fond il y a des choses qui me préoccupent bien plus que le logiciel

• J’essaie encore de comprendre où est le problème
  On dirait que cela signifie que Microsoft développe de meilleures extensions cpptools/C++, mais que beaucoup de composants Microsoft sont fermés, si bien qu’on ne peut pas en construire une version entièrement OSS
  Et si les utilisateurs découvrent qu’ils ne peuvent utiliser d’extensions natives dans aucune interface web, est-ce que cela devient le problème des gens côté interface web ?
  Si les gens veulent utiliser du freeware plutôt que de l’OSS, c’est peut-être décevant, mais je ne suis pas sûr que ce soit vraiment un problème
  S’il y a une réponse, ce serait sans doute de mieux indiquer qui est responsable de quoi
  Les acteurs open source devraient expliquer plus clairement que leur offre est open source et constitue un écosystème ouvert, et informer les développeurs que toutes les extensions ne le sont pas, et que l’extension de remplacement de Microsoft ne l’est pas non plus
  Si les grands projets d’extensions se mettaient d’accord, ils pourraient ajouter dans la description du marketplace un avertissement du genre : vscode-cpptools n’est pas sous une licence approuvée par l’OSI, contient de nombreux blobs binaires non audités, et Microsoft n’autorise pas sa redistribution dans des builds open source natifs ni dans des offres VS Code destinées à des services web
  Juridiquement comme culturellement, Microsoft ne voudra sans doute pas bloquer l’accès au marketplace à quelques projets OSS simplement parce qu’ils comparent leurs conditions de licence avec celles de Microsoft
  Apple traverse déjà en ce moment des procès liés à son marketplace, et Microsoft ne voudra probablement pas d’un procès sur son marketplace ni d’une nouvelle affaire antitrust

  • Pour prendre un exemple simple, créez une API composée d’une seule fonction publique, puis compilez cette API en binaire sous licence closed source
    Créez ensuite une autre API, elle aussi composée d’une seule fonction publique, dont la fonction ne fait qu’appeler ce binaire de bibliothèque via extern
    Publiez cette seconde API sur GitHub sous licence MIT et déclarez-la open source
    À grands traits, si 100 % des fonctionnalités du logiciel se trouvent dans un binaire compilé closed source, la question est de savoir si l’appeler open source devrait relever de la publicité mensongère
    Autrement dit, la question est de savoir qui trace la limite quand quelqu’un dépasse l’intention de l’open source pour des raisons abusives
    Je ne sais pas si 100 % des fonctionnalités de cpptools sont fermées, mais en pratique, dans le dépôt indiqué comme étant sous licence MIT, il y a trois autres licences auxquelles il faut accepter d’adhérer

• Il faut lire beaucoup trop de texte pour comprendre quel est réellement le point central, et la notion d’« écosystème fragmenté » revient plusieurs fois sans explication
  Des expressions comme « une dionée attrape-mouche conçue pour fragmenter » — qu’est-ce que c’est censé vouloir dire, au juste ?
  VS Code est un IDE téléchargeable gratuitement chez Microsoft, pas une plateforme ou un écosystème open source magique que Microsoft ne contrôlerait pas ; c’est un produit
  Tout le monde semble vouloir créer des services de développement « universels », mais sans vraiment vouloir créer ou financer un IDE, ou bien c’est tout simplement trop difficile
  Ce n’est pas la faute de Microsoft

• Je ne cherche pas à défendre Microsoft, mais ils ont fourni gratuitement une énorme base de code et ont construit dessus un produit en grande partie gratuit
  Si vous forkez, vous perdez seulement l’accès aux serveurs de Microsoft ; ça me semble assez équitable
  Et Monaco est un éditeur nettement supérieur, c’est pour cela que les frontends l’utilisent. Avant, quand CodeMirror ou Ace étaient ce qu’il y avait de mieux, on les installait
  Plutôt qu’un immense plan directeur derrière la création de Monaco, on dirait surtout qu’ils ont vu l’opportunité qu’un projet indépendant rende possibles d’innombrables interfaces web

• Le fait que « l’avenir des outils de développement logiciel à venir soit entièrement fermé, mais que les gens passent à côté de la vision d’ensemble et trouvent cela acceptable parce que certains composants satisfont à la définition de l’OSI » est un très gros problème
  En particulier, plusieurs entreprises financées par du VC emploient le terme open source de façon beaucoup trop lâche, ce qui déforme le langage, le sens et même l’esprit du mouvement open source
  YC soutient aussi plusieurs entreprises qui se disent open source tout en n’en respectant absolument pas l’esprit

  • Le problème tient moins au fait que les entreprises agissent ainsi qu’au fait que les utilisateurs et les développeurs ne s’en soucient pas vraiment, ou ne partagent pas ces inquiétudes
    Les discours moraux sur l’esprit ou l’éthique ne sont pas très pertinents
    Ce qui compte, c’est qu’une licence logicielle est un document juridique, et que l’endroit où son interprétation a du sens, c’est le tribunal
    Il ne semble pas y avoir beaucoup de procès autour de VS Code, et Microsoft a tendance à mettre de l’ordre sur ce terrain
    Au sens juridique, VS Code paraît suffisamment sûr. Il est vrai que certaines extensions ne sont pas sous licence OSS, ou sont même complètement closed source, mais si cela ne vous plaît pas, il suffit de ne pas les utiliser
    Mieux encore, vous pouvez créer vous-même une version open source et corriger le problème. L’open source n’est pas un droit, mais un privilège accordé à la discrétion des créateurs, pas quelque chose que l’on peut exiger
    VS Code est un produit closed source contenant de nombreux composants OSS, et ces composants sont assez nombreux pour qu’il existe aussi VS Codium, entièrement OSS
    Beaucoup de ces composants OSS sont également utilisés dans d’autres produits, et certains sont totalement open source
    La valeur de l’écosystème VS Code tient au fait qu’il permet à ces composants et à cet écosystème de produits de prospérer

• Personne n’a le droit d’obtenir VS Code gratuitement. En fait, personne n’a le droit d’obtenir quoi que ce soit gratuitement
  L’alternative, c’est de payer pour un IDE commercial devenu obèse
  VS Code est correct, généraliste, gratuit, et suffisamment ouvert pour pouvoir être forké
  Les gens oublient que c’est un produit d’ingénierie remarquable. Quand on regarde le code, ce n’est pas du niveau de quelque chose qui sort gratuitement
  Ni Microsoft ni aucune autre entreprise ne doit quoi que ce soit gratuitement à qui que ce soit, et ce sentiment de droit acquis doit être maîtrisé

  • Exact, autant mettre une étiquette de prix dessus. Les gens ici tirent aussi assez de valeur de VSCode pour accepter de payer
    Le problème, c’est quand une offre gratuite est conçue, dans les faits, pour vous entraîner dans un marécage de responsabilité juridique et financière sans plafond
    C’est d’autant plus vrai pour un service comme VSCode, qui n’est pas un achat ponctuel et qui vous rend durablement dépendant de Microsoft via les extensions et les mises à jour ; en pratique, il est conçu ainsi
    Au lieu de proposer une option simple où l’on paie une fois proprement et c’est fini, ils ont choisi d’extraire sur le long terme des montants flous, en fonction du niveau de résistance des utilisateurs
  • Les produits JetBrains ont de la valeur, donc j’ai payé pendant plusieurs années. Comparés aux fonctionnalités d’Eclipse, ils étaient très en avance, et cela valait le coup de payer
    Je le dis aussi toujours à propos de l’open source : je suis sceptique quant à l’adoption de frameworks derrière lesquels il n’y a pas beaucoup d’argent
    Il est risqué de dépendre des caprices d’un ingénieur génial quelconque sur Internet
    Microsoft gagnera de l’argent avec VSCode. Ce n’est simplement pas aussi direct que la façon dont Google gagne de l’argent avec Chrome
  • Est-ce vraiment remarquable sur le plan de l’ingénierie ? Créer un IDE à peine fonctionnel avec une technologie de navigateur obèse et un langage qui semble conçu sur un coin de table, je trouve cela aussi « impressionnant » que de construire une passerelle piétonne d’un mile avec des bâtonnets de glace et du chewing-gum

• Je pense que l’OSS est formidable, mais ce n’est pas pour cela que j’utilise VS Code
  Je l’utilise parce qu’il a résolu le problème consistant à avoir besoin d’un éditeur utilisable, qui ne soit pas un monstre comme Eclipse
  Il existe d’autres options dans ce domaine, comme Sublime, mais VS Code m’a toujours semblé le moins gênant
  Il y avait auparavant Adobe Brackets, un produit similaire, mais pour une raison ou une autre il était très lent et plein de bugs
  Si vous êtes un fervent défenseur de l’OSS, les critiques de l’article sont pertinentes. Mais au final, le code source existe, et vous pouvez aussi exploiter votre propre marketplace si vous le souhaitez
  Cela demande du temps et de l’argent, mais si vous croyez à cette idée, il faut investir au lieu de dépendre d’une grande entreprise
  S’il existe des extensions propriétaires que vous ne pouvez pas avoir, c’est dommage, mais quelqu’un pourrait aussi en créer une version OSS
  Dans l’ensemble, je suis d’accord avec l’article, mais je ne me fais aucune illusion sur le fait que Microsoft ferait cela par conviction envers l’open source, et dans le pire des cas il existe d’autres options, donc ça me va