Nouvelles
Miguel de Icaza mène le tollé à propos de l’outil C# à source fermée VS Code
Le co-fondateur de Xamarin et ancien cadre de Microsoft, Miguel de Icaza, a fustigé la société – ainsi que de nombreuses autres – pour avoir introduit une fonctionnalité à source fermée dans un nouveau schéma pour l’extension C # officielle pour Visual Studio Code, qualifiant cette décision “d’abus inacceptable de Puissance.”
Cet outil C # est optimisé par OmniSharp, mais Microsoft introduit une nouvelle extension basée sur le protocole LSP (Language Server Protocol), utilisé entre un éditeur / IDE et un serveur de langage pour fournir des fonctionnalités spécifiques au langage telles que la saisie semi-automatique, aller à la définition, trouver toutes les références et ainsi de suite.
“Alors que nous nous dirigeons vers un avenir plus dynamique pour l’expérience C # dans VS Code, nous avons l’intention de changer l’extension pour communiquer entièrement à l’aide de LSP et prévoyons de mettre à jour le composant OmniSharp existant pour communiquer de cette manière également”, a déclaré Tim Heuer de Microsoft dans Une annonce du 15 juin dans le référentiel VS Code/OmniSharp GitHub. “L’utilisation de LSP nous permettra d’apporter de nouvelles fonctionnalités innovantes à l’extension C# pour VS Code. Cela inclut la mise à disposition de fonctionnalités avancées et, dans certains cas, d’expériences à source fermée, telles qu’IntelliCode. Nous prévoyons de créer un nouvel ‘Hôte d’outils LSP ‘” ‘ composant (pas un nom officiel 😊), qui intègre à la fois des composants open-source, comme Roslyn et Razor, avec des composants à source fermée, offrant un éventail plus large de capacités d’outillage.”
Cela a provoqué un tollé parmi les développeurs qui soutiennent l’open source, menés par certains commentaires mordants sur Twitter de de Icaza, qui a quitté Microsoft en mars après avoir rejoint l’entreprise en 2016 lors de l’acquisition de Xamarin. En plus d’avoir cofondé cette société, il est bien connu pour ses efforts de pionnier dans de grands projets populaires tels que GNOME, Ximian et Mono.
Sa première réaction sur Twitter se lit comme suit : “Vraiment décevant que Microsoft renverse un projet open source actif en enfonçant une extension propriétaire pour continuer à verrouiller .NET. Un abus de pouvoir inacceptable de la part des administrateurs de la plate-forme et une trahison de la communauté. ” Les commentaires de suivi dans un échange avec d’autres développeurs comprenaient :
- Après la débâcle de l’année dernière, j’ai rédigé un article pour répondre à la question “Que devrions-nous faire au lieu de nous tirer une balle dans le pied?” – maintenant on le sait, il s’est envolé comme un ballon de plomb.
- Ils ont fait la même chose pour MonoDevelop, hard fork dans VSMac entièrement fermé
- Vous ne communiquez pas clairement les décisions négatives, vous devez les cacher derrière un tas d’autres choses, c’est ce que fait la publication
D’autres développeurs ont pesé avec des commentaires similaires sur la publication Twitter et sur la publication originale de Heuer (95 commentaires et de plus en plus au fur et à mesure de sa saisie), qui a vu des commentaires comme :
- Embrassez, étendez et éteignez.
- Bien que “C# in VS Code” soit apprécié, la nouvelle implémentation LSP n’étant pas open source est une décision étrange. J’espère que Microsoft le reconsidérera. S’il s’agit d’IntelliCode, ils peuvent rendre le serveur LSP extensible et open source, avec certains composants optionnels à source fermée comme IntelliCode. GitHub Copilot vit comme une extension distincte et fonctionne partout, peut-être qu’une méthode similaire peut également être utilisée pour IntelliCode dans VS Code ? Quoi qu’il en soit, à cause de Copilot, je ne pense pas qu’IntelliCode soit si important dans VS Code
- Je fais écho au sentiment que le fait d’être officiellement proche de la source est une désactivation. C’est formidable que C # pour VS Code reçoive plus d’amour, mais c’était aussi une omission étrange dans le passé. Heureux de voir que cela commence à être corrigé, mais je ne peux pas m’empêcher de sentir qu’une autre erreur est commise. IntelliCode peut être une extension distincte comme copilot, open source ce que vous pouvez.
- C’est triste et à courte vue lorsque Microsoft essaie de gagner du pouvoir à court terme (ou de récolter des bénéfices sur la part de marché existante) en prenant des décisions hostiles aux utilisateurs. Cela ressemble à un autre exemple d’étreinte/d’extension/d’extinction. C’est prévisible maintenant, mais je n’en suis pas content !
- Pouvez-vous expliquer pourquoi ce nouvel hôte d’outils sera à code source fermé ? Cela semble contradictoire avec l’esprit de VS Code. MS a gagné une tonne de bonne volonté de la part des développeurs en construisant de l’open source, il serait dommage que cela change et que les vieilles habitudes reviennent.
- Microsoft peut-il partager la raison d’être de la création de la source fermée “LSP Tools Host” susmentionnée ? Je pense que l’absence de justification rend toute la question plus ouverte aux interprétations erronées. Ce genre de tapis avec des projets open source n’est pas du tout le bienvenu. J’espère que vous réglerez ce problème avant qu’il ne se transforme en une autre crise des relations publiques.
Heuer a peut-être tenté de prévenir une telle crise de relations publiques avec un commentaire de suivi à son annonce :
METTRE À JOUR:
Merci pour les commentaires passionnés. J’aimerais clarifier certaines choses énoncées dans les commentaires que nous n’avons pas clarifiées.Les implémentations LSP pour Razor et C# resteront open-source (Roslyn et Razor) comme elles le sont aujourd’hui. L’extension VS Code C# (ms-dotnettools.csharp) elle-même restera également open-source. Ce qui est open source aujourd’hui le reste et en développement OSS actif. Cela garantit que d’autres personnes en dehors de VS Code qui utilisent LSP continuent d’avoir accès à C#.
Ce nouveau composant hôte est le pont entre les fonctionnalités open source et fermées, nous permettant de fournir les deux en même temps.
Après être devenu Microsoft Distinguished Engineer (après ce qu’il a décrit comme « le plus long entretien d’embauche de ma carrière »), de Icaza est devenu un ardent défenseur des initiatives open source de l’entreprise, qui marquent un revirement radical par rapport à il y a des décennies, alors qu’il était largement considéré comme un intimidateur monolithique et propriétaire de l’industrie dans les outils de développement et d’autres domaines, gagnant une réputation de secret de source fermée au milieu de ces caractérisations “embrasser, étendre et éteindre”.
Lorsqu’il a quitté Microsoft en mars, il a déclaré qu’il n’allait pas changer de travail tout de suite, mais qu’il prévoyait plutôt de passer du temps avec sa famille avant de choisir sa prochaine direction, ce qui impliquera probablement une expérience de démarrage.
À en juger par son commentaire sur “la débâcle de l’année dernière” et la rédaction d’un article sur l’entreprise évitant de se tirer une balle dans le pied, il avait clairement des désaccords avec la direction, mais il n’a pas précisé à quelle situation il faisait référence exactement. Son co-fondateur de Xamarin, Nat Friedman, a quitté son poste de PDG de GitHub, propriété de Microsoft, en novembre dernier.
Par coïncidence, un Codes dépoussiérés article de l’année dernière intitulé « Pouvons-nous faire confiance à Microsoft avec l’Open Source ? a déclaré: “Faites-vous confiance à Microsoft avec l’Open Source ou faites-vous réellement confiance à des personnes comme Jon Galloway, Scott Hanselman, Scott Hunter, Guido van Rossum, David Fowler, Damian Edwards, Miguel de Icaza et une poignée d’autres champions OSS qui ont poussé le message OSS en interne de bas en haut ? Et si ces personnes quittaient .NET ? Microsoft continuera-t-il à bien jouer avec la communauté ? »
Le temps nous le dira.
.