Designfehler in Visual Studio Code (2022)
(ghuntley.com)- Bei Visual Studio Code sind der MIT-lizenzierte Quellcode und das von Microsoft vertriebene Produkt unter proprietärer Lizenz getrennt, wodurch Forks wie VSCodium und OpenVSCode Server mit dem offiziellen Ökosystem kollidieren
- Offizielle Builds werden mit Microsoft-spezifischen Einstellungen wie Telemetry, Gallery und Logo in
product.jsonausgeliefert; Community-Builds sind zwar „clean“, können sich aber nicht mit dem Visual Studio Code Marketplace verbinden - VSCodium und OpenVSCode Server entfernen oder enthalten die Telemetrie der offiziellen Releases nicht, können aber wegen der Datenerfassung durch Erweiterungen selbst und wegen der Marketplace-Beschränkungen nicht ohne Weiteres die von Nutzern erwartete VS-Code-Erfahrung bieten
- Wenn Microsoft-Erweiterungen und Sprachserver wie Pylance, die C#-Erweiterungs-Roadmap oder die Lizenzierung der C/C++-Tools an offizielle Produkte und Services gebunden sind, wird es für konkurrierende Services wie Gitpod, GitLab, Datacoves, OpenBB und Foam schwierig, dieselbe Funktionalität rechtmäßig bereitzustellen
- Als Alternativen werden OpenVSX, die Entwicklung offener Sprachwerkzeuge und die Unterstützung von Open-Source-Maintainern genannt; wenn Microsoft die Standards auf proprietäre Tools umstellt, müssen Community und Konkurrenzprodukte zugleich Funktionsunterschiede, Konfigurationsunterschiede und rechtliche Einschränkungen tragen
Der Quellcode ist offen, aber das Produkt wird anders ausgeliefert
- Visual Studio Code hat sich sieben Jahre nach seiner Veröffentlichung faktisch als Standard-Editor in der Softwareentwicklung etabliert
- Microsoft hat den Quellcode von Visual Studio Code unter der MIT-Lizenz veröffentlicht, aber das Visual-Studio-Code-Produkt, das Nutzer herunterladen, wird unter einer separaten proprietären Lizenz vertrieben
- Laut der Erklärung eines Visual-Studio-Code-Maintainers klont ein Microsoft-Build zunächst das
vscode-Repository und überschreibt anschließend die Microsoft-spezifischeproduct.json- Diese Datei enthält Microsoft-spezifische Funktionen wie Telemetry, Gallery und Logo
- Der so erzeugte Build wird unter einer Microsoft-Lizenz vertrieben
- Der zentrale Vorwurf des Artikels ist, dass diese Trennung der Kernmechanismus ist, mit dem Microsoft die Open-Source-Community spaltet
Grenzen, auf die VSCodium und OpenVSCode Server stoßen
- VSCodium ist eine von der Community getragene Desktop-Distribution unter freier Lizenz
- Sie folgt automatisch dem Upstream-MIT-Projekt und erzeugt Binär-Builds
- Sie liefert Builds aus, bei denen die Telemetrie der offiziellen Releases entfernt wurde
- In der standardmäßigen
product.jsonsind keine Microsoft-Endpunkte gesetzt, wodurch ein „cleaner“ Build ohne Microsoft-Anpassungen entsteht
- Auch VSCodium kann trotz derselben Codebasis nicht jede Datenerfassung vollständig verhindern
- Erweiterungen können unabhängig Daten sammeln, daher muss man bei den installierten Erweiterungen vorsichtig sein
- OpenVSCode Server ist eine Server-Distribution unter freier Lizenz, auf der Gitpod basiert
- Sie folgt automatisch dem Upstream-MIT-Projekt
- Im Branch
gp-code/maingibt es einige Overlay-Anpassungen - Die Telemetrie der offiziellen Releases ist nicht enthalten
- Beide Distributionen können sich nicht mit dem Microsoft Visual Studio Code Marketplace verbinden, und diese Einschränkung führt zu einer Trennung des Ökosystems
Microsofts Wandel zum servicezentrierten Modell und die Strategie für Entwicklerwerkzeuge
- Microsoft begann vor etwa neun Jahren damit, seine Art der Softwarebereitstellung zu verändern
- Weg von einem Modell, bei dem ein dediziertes QA-Team Builds testete, hin zu sprintbasierter Entwicklung, Rolling Releases und einem Ansatz auf Basis von Telemetrie-Feedback aus Insider Builds
- Im selben Zeitraum wandelte sich Microsoft durch organisatorische Umstrukturierungen zu einem Service-Unternehmen
- Azure entwickelte sich in dieser Zeit zu einem ernsthaften Konkurrenten von AWS
- Aus Verbrauchersicht bestand die größte Veränderung darin, dass sich die Kundenbasis von installierten On-Premises-Produkten hin zu einem von Microsoft bereitgestellten Service-Konsummodell verschob
- Auch im Bereich der Entwicklerwerkzeuge wird die Entwicklung so dargestellt, dass nicht abonnierte IDEs seltener werden
- Ausnahmen wie Apples Xcode werden erwähnt, weil dort andere Erlösquellen bestehen
- Visual Studio Code wird kritisiert als Einstiegstor, um das Ökosystem der Entwicklerwerkzeuge in ein End-to-End-Konsum- und Servicemodell zu überführen
- GitHub Codespaces wird als White-Label-Variante bestehender Services beschrieben, die mit Visual Studio Online, Microsoft Dev Box und Microsoft Azure DevTest Labs verbunden sind
GitHub Codespaces und Microsoft DevDiv
- Microsoft übernahm GitHub im Jahr 2018 und stellte 2019 Visual Studio Online vor
- Dazu gehörte eine Komponente, mit der sich ein „codespace“ lokal hosten ließ
- Später wurden die Codespaces-Teams und verwandte Bestandteile zu GitHub verschoben
- GitHub Codespaces wird als DevDiv-Projekt beschrieben, das bei GitHub angesiedelt wurde
- An dem Tag, an dem Nat Friedman als CEO zurücktrat, wurde eine interne Mail zur organisatorischen Neustrukturierung bei Microsoft geteilt
- Julia Liuson wurde zur Präsidentin der Microsoft Developer Division befördert
- GitHub-CEO Thomas Dohmke berichtet seither an Julia Liuson
- Zur Developer Division gehören Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, Azure Developer SDK, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache und Spring Cloud
- Laut dieser Mail verzeichneten Visual Studio und Visual Studio Code seit 2014 eine mehr als 16-fache Steigerung der Nutzung
- Julia Liuson wird außerdem als die Person erwähnt, die kurz vor ihrer Beförderung eine Last-Minute-Änderung durchsetzte, die die .NET-Community spaltete
- Laut einem Zitat aus The Verge wertete eine anonyme Microsoft-interne Quelle diese Änderung als geschäftsorientierte Entscheidung
Eine Ökosystemstruktur, die als „konstruiertes Zerbrechen“ funktioniert
- Konkurrenzprodukte wie Gitpod können innerhalb des Visual-Studio-Code-Ökosystems existieren, werden aber mit dem Vorwurf konfrontiert, dass Microsoft jederzeit rechtliche Risiken schaffen kann, um den Markt aufzuteilen
- Der Open-Source-Quellcode von Visual Studio Code zieht Nutzer an, erschwert es konkurrierenden Services aber, dieselbe nahtlose Erfahrung wie offizielles Visual Studio Code oder GitHub Codespaces zu bieten
- Nicht nur Gitpod, sondern auch Unternehmen wie GitLab, Datacoves, OpenBB und Foam, die auf Basis des VS-Code-Quellcodes mit Microsoft oder GitHub konkurrieren wollen, stehen vor demselben Problem
- Als Bereiche, in denen konkurrierende Services bei Abhängigkeit von Microsoft-Tools etwas nicht ohne Weiteres rechtmäßig anbieten können, werden genannt
- Microsoft .NET C#
- der allgemeine Python-Markt und der Data-Science-Markt
- Project Jupyter und der Großteil des Data-Science-Markts
- C oder C++
- Java könnte als nächstes Ziel folgen, falls Microsofts Tools das Niveau der RedHat-Werkzeuge erreichen
- Nach dem TIOBE-Index gehören fünf dieser Sprachen und Ökosysteme zu den populärsten Bereichen; zudem habe Microsoft über TypeScript eine Kontrolle, die nahe an der siebtbeliebtesten Sprache JavaScript liege
Umstellung der Standards und das Problem proprietärer Erweiterungen
- Microsoft wird vorgeworfen, nach ausreichender Verbreitung per Erweiterungs-Update proprietäre Angebote zum Standard machen zu können
- In der Python-Community wurde der Open-Source Microsoft Python Language Server eingestellt und das proprietäre Pylance zum Standard
- Laut einem Zitat aus Visual Studio Magazine zwang Microsoft die Nutzer nicht aktiv zum Wechsel, setzte Pylance aber als neuen Standard
- Die Python-Erweiterung erreichte im VS Code Marketplace etwa 50 Millionen Downloads und wird als etwa doppelt so populär wie die nächstbeliebte Jupyter-Erweiterung beschrieben
- Auch in der .NET-Community wird die C#-Erweiterungs-Roadmap als Beispiel für einen ähnlichen Standardwechsel genannt
- Selbst wenn alternative Werkzeuge wie Open.NET entstehen, müssen Nutzer plattformspezifische Einstellungen separat verknüpfen
- Auf dem Desktop kann man
ms-dotnettools.csharpindevcontainer.jsoneintragen - In Gitpod müsste man stattdessen ein noch nicht existierendes offenes Werkzeug in
gitpod.ymleintragen, wodurch Unterschiede entstehen
- Auf dem Desktop kann man
- Innerhalb des offiziellen Microsoft-Ökosystems wird dieselbe
devcontainer.json-Konfiguration zu einer einzigen Quelle der Konfiguration, die sowohl auf dem Desktop in Visual Studio Code als auch in GitHub Codespaces unverändert funktioniert
Die durch Lizenzen entstehenden rechtlichen Beschränkungen
- Es wird gewarnt, dass Gitpod, GitLab, Datacoves, OpenBB oder Foam mit harten rechtlichen Maßnahmen durch Microsofts Rechtsabteilung rechnen müssten, wenn sie Beschränkungen umgehen und Microsoft-Erweiterungen wie
ms-dotnettools.csharpin ihren Services anbieten - Selbst wenn Nutzer konkurrierender Cloud-Entwicklungsumgebungen diese Erweiterung manuell installieren, könnte dies eine Lizenzverletzung darstellen
- Die Lizenz des Microsoft-C/C++-Add-ons erklärt, dass die Software nur zusammen mit Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server sowie nachfolgenden Microsoft-Produkten und -Services installiert und verwendet werden darf
- Durch diese Bedingung ist es für VS-Code-basierte Produkte außerhalb der offiziellen Microsoft-Distributionen schwierig, die von Nutzern erwarteten Microsoft-Sprachwerkzeuge unverändert bereitzustellen
Mögliche Reaktionen: OpenVSX und offene Sprachwerkzeuge
- Es wird kritisiert, dass die Zukunft der derzeit entstehenden Softwareentwicklungswerkzeuge in eine geschlossene Richtung geht
- Selbst wenn einige Komponenten die OSI-Definition erfüllen, muss das für den gesamten Zusammensetzungsgraphen nicht gelten
- Open Source wird ursprünglich als finanzielles Mittel beschrieben, um proprietäre On-Premises-Software in Schach zu halten und die Offenheit von Dateiformaten zu bewahren
- Gleichzeitig wird damit erklärt, warum sich mit Open Source nur schwer Geld verdienen lässt
- Vorgeschlagen wird, dass womöglich eine neue Bewegung gegen proprietäres SaaS nötig ist, die die Offenheit der Computerfreiheit absichert, oder eine Neubetrachtung der Freie-Software-Bewegung der 1970er Jahre
- Gitpods Open-Source Sustainability Fund ist eine der Reaktionen auf diese Ökosystem-Spaltung
- Über 1,5 Jahre wurden mehr als 32.000 US-Dollar an Maintainer von Sprachserver-Werkzeugen in der Open-Source-Community ausgeschüttet
- Gitpod schuf Open VSX, um das Marketplace-Problem im Open-Source-Ökosystem von Visual Studio Code teilweise zu lösen, und spendete das Projekt an die Eclipse Foundation
- Die größte künftige Aufgabe besteht darin, für alle Bereiche, in denen Microsoft die Community auf proprietäre Sprachserver umgestellt hat, offene Sprachwerkzeuge zu entwickeln
Später per Redaktion ergänzte Inhalte
- Eine Bearbeitung vom 31. August 2022 fasst zusammen, dass Microsoft VSCode entwickelte, eine proprietäre kostenlose Distribution und proprietäre kostenlose Erweiterungen anbot und anschließend die beste sprachspezifische Erfahrung an ein geschlossenes VSCode band
- Eine Bearbeitung vom 16. Dezember 2022 ergänzt, dass auch GitLabs Web IDE auf VSCode-MIT-Basis und dessen Remote-Development-Erfahrung unter demselben Problem leiden
- Eine Bearbeitung vom 13. Oktober 2023 stellt fest, dass Googles Project IDX ebenfalls auf VSCode MIT basiert und dass die Erwartung, Visual Studio Code LSP werde bei .NET und Python dort einfach so funktionieren, weder realistisch noch rechtmäßig ist
- Eine Bearbeitung vom 24. April 2025 kritisiert, Microsoft habe das VSCode-Ökosystem absichtlich beschädigt, um Konkurrenz bei KI-Coding-Assistenten wie Windsurf und Cursor zu bremsen
- Am selben Tag wird dies mit der Einführung eines konkurrierenden Microsoft-Produkts und Zugangsbeschränkungen für VS-Code-Forks bei der C/C++-Erweiterung verknüpft erwähnt
5 Kommentare
Ich überlege, auf
vimoderzedumzusteigen.Ich verwende ein Terminal mit eingestellter Opazität.
Wisst ihr zufällig, wie man bei
nvimdie Hintergrundfarbe entfernt?Wenn ich nur das herausfinde, würde ich
nvimunbedingt ausprobieren wollen ...Wenn Sie das
kitty-Terminal verwenden, sollte Transparenz angewendet werden, wenn Sie es mit derselben Hintergrundfarbe behandeln.Andernfalls könnten Sie auch ein Plugin wie dieses in Betracht ziehen..
https://github.com/xiyaowong/transparent.nvim
Vielen Dank. Ich werde es mir einmal ansehen.
Es hat geklappt. Danke. Einen schönen Tag noch.
Meinungen auf Hacker News
In gewisser Weise könnte diese Situation auch eine Chance sein. Das VSCode-Ökosystem ist in vielerlei Hinsicht ziemlich fragil.
cpptoolshat zwar beeindruckende Seiten, funktioniert aber häufig falsch und ist praktisch nicht debuggbar; bei anderen Extensions kann man kaum erwarten, dass sie wesentlich besser sind.Das größere Problem ist das sehr schwache Sicherheitsmodell: Extensions laufen nicht in einer Sandbox, und auch Clients, die auf Remote-Repositories zugreifen, sind konstruktionsbedingt sehr unsicher.
Wenn man nur Unternehmenscode betrachtet, muss man sich vielleicht weniger Sorgen machen, dass ein Repository einen angreift; bösartige Extensions sollte man aber selbstverständlich fürchten, und wir haben uns daran gewöhnt, Entwickler-Tools viel zu leicht zu vertrauen.
LLMs darf man niemals vertrauen, und es ist nicht sicher, einem LLM, das versuchen könnte, den Nutzer anzugreifen, Rechte zu geben, direkt in ein Repository zu schreiben oder in bestimmten VSCode-Kontexten JS-Code auszuführen.
In einem besseren Ökosystem hätte ein Tool wie
cpptoolskeinen Internetzugriff, also auch keine Telemetrie, und dürfte nur den Workspace lesen, eigene Cache-Dateien anlegen und die UI manipulieren.HTTPS_PROXYgesetzt ist.Auch die SSH-Extension startet für jeden Client, mit dem sich ein Nutzer verbindet, einen Serverprozess, und die Zustandserhaltung nach dem Trennen der Verbindung wirkt ebenfalls nicht konsistent.
Am Ende verbringt man viel Zeit damit, Menschen zu helfen, Probleme zu beheben, die sie sich durch die Nutzung von VSCode selbst geschaffen haben.
Es gibt keinen Mittelweg zwischen den beiden Optionen, offenen Zugriff auf alle Extensions im Marketplace zu erlauben oder alles komplett abzuriegeln und Extensions nur aus lokalen Dateien installieren zu lassen.
Letzteres macht die Pflege von VSCode erheblich aufwendiger.
compile_commands.jsonhat oder erzeugen kann — besonders mit CMake ist das vergleichsweise einfach — undclangddazu bringen kann, diese Datei zu sehen, war dieclangd-Extension für mich deutlich besser.Auch das von mir genutzte Emacs hat kaum Schutzmechanismen gegen Supply-Chain-Angriffe, und die meisten verwenden einen Community-Extension-Aggregator, der direkt aus Git-Repositories bezieht.
Allerdings gibt es den sehr kleinen Vorteil, dass Emacs-Nutzer vermutlich deutlich häufiger tatsächlich in den Quellcode der Extensions schauen, die sie beziehen.
Microsoft sagt seit Jahren, „Sicherheit ist alles und im Moment das Wichtigste“, und dann kümmern sie sich nicht einmal um eine solche Grundlage für die Nutzergruppe, bei der der Schaden etwa beim Diebstahl von SSH-Schlüsseln am größten wäre, und die zugleich die sicherheitsbewussteste Entwicklergruppe sein dürfte. Das ist seltsam.
Die Situation, in der Leute wahllos Extensions installieren und Visual Studio Code unter dem Vorwand von „Sprachunterstützung“ beliebige Extensions empfiehlt, wirkt damit deutlich schlimmer als gedacht.
Es gibt einen guten Thread zur
cpptools-Extension: https://github.com/microsoft/vscode-cpptools/discussions/126...Ich habe den Build-Prozess aus dem Quellcode nicht im Detail untersucht, aber diesem Beitrag zufolge scheint er schlicht unmöglich zu sein.
Wir werden wohl einen neuen Begriff dafür brauchen, ob eine Codebasis unter einer OSS-Lizenz steht und ob auch ihre Build-Abhängigkeiten unter OSS-Lizenzen stehen.
mainist freie Software,non-freeist unfreie Software, undcontribist freie Software, die aber von etwas außerhalb vonmainabhängt, üblicherweise unfreier Software.Den Begriff
contribselbst mag ich nicht besonders, aber diese Einteilung wirkt ziemlich sinnvoll.Viel F/OSS unter Windows und fast jede F/OSS unter macOS hat proprietäre Build-Abhängigkeiten wie MSVC, Xcode oder Apple-Frameworks und -GUI-Toolkits, kann aber trotzdem selbst F/OSS sein.
In diesem Fall geht es jedoch nicht um dieses Problem, sondern darum, dass ein Microsoft-Mitarbeiter, der wie ein Maintainer wirkt, gesagt hat: „Unsere Lizenz verbietet auch die Nutzung der Extension in alternativen VS-Code-Distributionen; sie darf nur in der offiziellen, von Microsoft erstellten Distribution verwendet werden.“
Das ist schlicht proprietäre Software.
Freiheit 0 der Definition freier Software ist die Freiheit, das Programm zu jedem gewünschten Zweck auszuführen. Wenn Drittanbieter-Distributionen von VSCode nicht dieselben Extension-Rechte wie die offizielle Distribution haben oder nicht das Recht haben, es zusammen mit kompatiblen Extensions zu verwenden, erfüllt es unabhängig von der Lizenz einzelner Codebestandteile auch Freiheit 3 nicht.
Die Aussage „Wenn es darum geht, die Language-Server-Binaries als eigenes Angebot weiterzuverteilen, verbietet das die Laufzeitlizenz“ bedeutet, dass es Kriterium 1 der Open-Source-Definition, also das Kriterium zur Weiterverbreitung, nicht erfüllt; und VSCode, das modifizierten Weiterverteilungen nicht dieselben Rechte wie dem Original einräumt, erfüllt auch Kriterium 3, das Kriterium zu abgeleiteten Werken, nicht.
VSCode und diese Extension sind beide nicht Open Source, sondern proprietäre Software, die einige Open-Source-Komponenten enthält.
Definition freier Software: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
Open-Source-Definition: https://opensource.org/osd
Wichtig ist auch, dass diese Definitionen keine allgemeinen Wörterbuchbedeutungen sind, sondern Begriffe, die innerhalb einer Bewegung mit bestimmten sozialen und technischen Zielen entstanden sind.
Dasselbe Frontend steckt auch in der Visual Studio IDE.
Als Alternative gibt es meines Wissens eine vollständig Open-Source-C++-Extension auf Basis von
clangd, aber ich kann mich irren.„Dass freie Software, die Microsoft kostenlos bereitstellt, nicht offen genug ist“, klingt selbst nach heutigen Maßstäben wie eine ziemlich seltsame Behauptung.
Früher bedeutete „kostenlose IDE“ Eclipse oder Vim mit einem Haufen Erweiterungen.
Es sieht weniger so aus, als würde Microsoft offene Alternativen behindern, sondern eher so, dass diese Alternativen schlicht schlechter sind; und wenn man Software nutzt, die von einem Unternehmen entwickelt wurde, das seine Mitarbeiter bezahlen und gleichzeitig Gewinn machen muss, gehört so etwas eben dazu.
Wer meint, selbstverständlich den Quellcode von Microsofts bester Software bekommen zu müssen, sollte sich ansehen, wie echte Open Source aussieht, die von einer unabhängigen Non-Profit-Organisation gepflegt wird.
Sie funktioniert, und vielleicht gibt es sogar einen echten Debugger, aber es ist sehr wahrscheinlich, dass man nach kurzer Zeit zurückwill.
Die Leute nehmen Software, die sie kostenlos bekommen, viel zu sehr als selbstverständlich hin. Noch vor gar nicht so langer Zeit musste man für eine IDE Hunderte bis Tausende Dollar zahlen, und wenn man ein paar Jahre später eine neue Version brauchte, zahlte man auch noch für das Upgrade.
VSIX-Erweiterungen sollten in gewissem Maße ein offener Standard sein, aber Microsoft-Erweiterungen wie Pylance verweigern aktiv den Dienst, wenn sie erkennen, dass sie in einem Nicht-Microsoft-Build von VS Code laufen.
Der Kern ist eher, dass Entwickler getäuscht werden und Microsofts Ziel darin besteht, wesentliche Teile zunehmend zu schließen.
Selbst wenn die Funktionsgleichheit erreicht ist, bleiben danach Performance-Probleme, und niemand weiß, wann diese gelöst werden.
Die Idee von Open-Source-Software ist gut, aber die beste Software bekommt man heute fast immer nur gegen Bezahlung.
Den Preis für Emacs und Vim kenne ich. Selbst wenn sie theoretisch völlig kostenlos sind, kosten sie in der Praxis Zeit, Geduld und Hingabe, und ich weiß, dass meine Entscheidung mir, der Community und der Branche zugutekommt.
Als ich früher IntelliJ nutzte, wusste ich ebenfalls genau, wie JetBrains daran verdient. Ich zahlte Lizenzgebühren und verlängerte sie jedes Jahr.
Aber was ist Microsofts Kalkül? Sie geben ein so schönes und ordentliches Werkzeug völlig „gratis“ ab – welchen Preis werde ich in Zukunft dafür zahlen?
Es ist schwer zu glauben, dass ein Riesenkonzern mit einer Marktkapitalisierung in der Größenordnung des deutschen BIP enorme Ressourcen in einen „kostenlosen“ Code-Editor steckt, nur weil er Entwickler liebt; Entwickler sollten zumindest ein wenig skeptisch sein.
Ich halte Microsoft-Software eher für einen albtraumhaften Müllhaufen.
Der Punkt des Artikels ist, dass Closed-Source-Software, die so tut, als sei sie Open Source, auch Menschen betrifft, die sie gar nicht nutzen wollen – und das wird hier übersehen.
Zum Beispiel will ich weder Azure DevOps noch GitHub Actions verwenden, aber die Organisation, für die ich arbeite, verlangt, dass das Projekt auf GitHub liegt, also werde ich dazu gezwungen.
Dadurch fühlt es sich an, als würden meine Arbeit und mein Wissen dazu benutzt, Microsofts Ausbeutung der Nutzer zu unterstützen.
Der einzige Trost ist, dass es bezahlte Arbeit ist; privat nutze ich GitHub nicht und würde es auch anderen so empfehlen.
Wenn man kein Modell dafür vorlegt, wie sich ein Jahresbudget von etwa 20 Millionen Dollar für mehr als 50 Vollzeitmitarbeiter rechtfertigen lässt, die VS Code entwickeln, klingt diese Kritik wie: „Es nervt, dass sie es uns etwas unbequemer gemacht haben, ihre Engineering-Leistung zu nehmen, bei unserem Produkt nur die Oberfläche auszutauschen und es ohne eigene Entwicklungskosten günstiger zu verkaufen und daran zu verdienen.“
Wenn sie es als Open Source veröffentlichen, gewinnen sie Vertrauen in anderen Communities, bekommen kostenlosen Code und Bug-Review sowie Erweiterungen und Support von außerhalb des Microsoft-Ökosystems, und Microsoft kann es weiterhin selbst nutzen.
Das wirkt nicht besonders kompliziert.
Historisch war das ein garantierter Weg in die Veraltung.
Auch ohne ihre Engineering-Leistung gibt es Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox und andere.
Microsofts großzügiges Decken-Geschenk interessiert mich nur, wenn keine Pocken daran hängen.
Allerdings ist es etwas komisch, das als große Überraschung darzustellen. Es war von Anfang an offensichtlich; man hat sich nur nicht darum gekümmert, weil es den Streit nicht wert schien.
Das Problem, dass Entwickler mit BSD/MIT-Lizenzen ausgebeutet werden, interessiert mich ungefähr so wenig wie die Frage, ob Microsofts Geschäftsmodell ins Wanken geraten könnte, wenn man die Telemetrie abschaltet.
Alle wussten, worauf sie sich einlassen, und entschieden sich trotzdem dafür, in der Hoffnung: „Der große Konzern-Senpai wird uns schon bemerken.“ Und er hat sie tatsächlich bemerkt – Glückwunsch.
Ich würde nichts unter einer Lizenz veröffentlichen, die schwächer ist als die AGPL, aber letztlich gibt es Dinge, die mir sehr viel wichtiger sind als Software.
Ich versuche immer noch zu verstehen, worin genau das Problem besteht.
Es klingt so, als würde Microsoft eine bessere
cpptools-/C++-Erweiterung bauen, aber viele Microsoft-Komponenten seien geschlossen, sodass man keine vollständig OSS-Version bauen könne.Und wenn Nutzer feststellen, dass sie in keiner Weboberfläche native Erweiterungen verwenden können, wird das dann zum Problem der Leute auf der Weboberflächen-Seite?
Wenn Menschen statt OSS lieber Freeware verwenden wollen, kann das enttäuschend sein, aber ich bin nicht sicher, ob es wirklich ein Problem ist.
Wenn es eine Antwort gibt, dann wohl eher, klarer zu kommunizieren, wer verantwortlich ist.
Open-Source-Anbieter sollten deutlicher machen, dass ihr Angebot Open Source ist und ein offenes Ökosystem bietet, und Entwicklern mitteilen, dass nicht alle Erweiterungen so sind und Microsofts alternative Erweiterung es nicht ist.
Wenn sich die großen Erweiterungsprojekte zusammentun, könnten sie in ihre Marketplace-Beschreibungen Hinweise aufnehmen wie:
vscode-cpptoolssteht nicht unter einer OSI-zugelassenen Lizenz, enthält viele ungeprüfte Binary Blobs, und Microsoft erlaubt keine Weiterverbreitung in nativen Open-Source-Builds oder in VSCode-Angeboten für Webdienste.Weder rechtlich noch kulturell dürfte Microsoft gern einigen OSS-Projekten den Marketplace-Zugang sperren wollen, nur weil sie ihre Lizenzbedingungen mit denen von Microsoft verglichen haben.
Auch Apple steckt gerade in Marketplace-Klagen, und Microsoft wird wohl keine Marketplace- oder weitere Kartellklage wollen.
Dann erstellt man eine weitere API mit einer einzigen öffentlichen Funktion, und diese Funktion macht lediglich einen
extern-Aufruf in dieses Library-Binary.Die zweite API stellt man unter MIT-Lizenz auf GitHub und erklärt sie zu Open Source.
Im weiteren Sinne geht es um die Frage, ob es irreführende Werbung sein sollte, so etwas Open Source zu nennen, wenn 100 % der Softwarefunktionalität in einem kompilierten Closed-Source-Binary steckt.
Anders gesagt: Wer zieht die Grenze, wenn jemand aus ausbeuterischen Gründen über die Absicht von Open Source hinausgeht?
Ich weiß nicht, ob die Funktionalität von
cpptoolszu 100 % geschlossen ist, aber tatsächlich gibt es in dem Repository, das als MIT-lizenziert ausgewiesen ist, noch drei weitere Lizenzen, denen man zustimmen muss.Man muss viel zu viel lesen, um herauszufinden, worum es eigentlich geht, und der Begriff „fragmentiertes Ökosystem“ taucht mehrfach ohne Erklärung auf.
Was Formulierungen wie „eine Venusfliegenfalle, die auf Spaltung ausgelegt ist“ überhaupt bedeuten sollen, verstehe ich nicht.
VS Code ist eine IDE, die man kostenlos von Microsoft herunterladen und verwenden kann; es ist ein Produkt, keine magische Open-Source-Plattform oder ein Ökosystem, das Microsoft nicht kontrolliert.
Alle wollen „universelle“ Entwicklerdienste bauen, aber offenbar will niemand eine IDE bauen oder finanzieren, oder es ist schlicht zu schwierig.
Das ist nicht Microsofts Schuld.
Ich will Microsoft nicht verteidigen, aber sie haben eine riesige Codebasis kostenlos bereitgestellt und darauf ein größtenteils kostenloses Produkt gebaut.
Wenn man sie forkt, hat man lediglich keinen Zugriff auf Microsofts Server; das erscheint mir fair genug.
Und Monaco ist ein überwältigend guter Editor, deshalb verwenden Frontends ihn. Früher hat man CodeMirror oder Ace eingebunden, als das die besten Optionen waren.
Hinter der Entstehung von Monaco stand wohl weniger ein riesiger Masterplan, sondern eher die Erkenntnis, dass ein eigenständiges Projekt zahllose Web-UIs ermöglichen würde.
Der Punkt, dass „die Zukunft der künftig entstehenden Softwareentwicklungswerkzeuge vollständig geschlossen ist, während die Leute das große Ganze übersehen und es okay finden, nur weil einige Komponenten die OSI-Definition erfüllen“, ist ein sehr großes Problem.
Besonders mehrere VC-finanzierte Unternehmen verwenden den Begriff Open Source viel zu locker und verändern damit Sprache, Bedeutung und sogar den Geist der Open-Source-Bewegung zum Schlechteren.
Auch YC unterstützt mehrere Unternehmen, die behaupten, Open Source zu sein, diesem Geist aber überhaupt nicht folgen.
Moralische Argumente wie Geist oder Ethik sind nicht besonders relevant.
Entscheidend ist, dass Softwarelizenzen juristische Dokumente sind und ihre Auslegung dort Bedeutung hat, wo Gerichte entscheiden.
Es scheint nicht viele Klagen im Zusammenhang mit VS Code zu geben, und Microsoft regelt diesen Bereich im Allgemeinen recht sauber.
Im rechtlichen Sinne wirkt VS Code hinreichend sicher. Es stimmt, dass einige Erweiterungen nicht unter OSS-Lizenzen stehen oder sogar komplett Closed Source sind; wenn man das nicht mag, muss man sie eben nicht nutzen.
Mehr noch: Man kann selbst Open Source erstellen und es verbessern. Open Source ist kein Recht, sondern ein Privileg, das nach Ermessen der Urheber gewährt wird, nichts, das man einfordern kann.
VS Code ist ein Closed-Source-Produkt mit vielen OSS-Komponenten, und weil es so viele davon gibt, existiert mit VS Codium auch eine vollständig OSS-Variante.
Viele dieser OSS-Komponenten werden auch in anderen Produkten verwendet, und einige sind vollständig Open Source.
Der Wert des VS-Code-Ökosystems liegt darin, dass es solche Komponenten und das Produktökosystem florieren lässt.
Niemand hat ein Anrecht darauf, VS Code kostenlos zu bekommen. Eigentlich hat niemand ein Anrecht darauf, irgendetwas kostenlos zu bekommen.
Die Alternative ist, für aufgeblähte kommerzielle IDEs zu bezahlen.
VS Code ist ordentlich, vielseitig, kostenlos und offen genug, um geforkt werden zu können.
Die Leute vergessen, dass es ein ingenieurtechnisch erstaunliches Produkt ist. Wenn man sich den Code ansieht, ist das kein Niveau, das einfach kostenlos vom Himmel fällt.
Weder Microsoft noch irgendein anderes Unternehmen schuldet irgendwem etwas kostenlos, und dieses Anspruchsdenken muss eingehegt werden.
Das Problem ist, wenn ein kostenloses Angebot faktisch so gestaltet ist, dass es einen in einen Sumpf aus rechtlicher Haftung und unbegrenzter finanzieller Verantwortung zieht.
Besonders gilt das bei einem Dienst wie VSCode, der kein einmaliger Kauf ist, sondern bei dem man über Erweiterungen und Updates dauerhaft von Microsoft abhängig bleibt – und genau so ist er tatsächlich entworfen.
Statt eine einfache Option zu schaffen, einmal sauber zu bezahlen und fertig zu sein, hat man sich dafür entschieden, den Nutzern je nach Grad ihres Widerstands langfristig einen unklaren Betrag zu entlocken.
Auch bei Open Source sage ich immer: Ich bin skeptisch, ein Framework zu übernehmen, hinter dem kein großes Geld steht.
Sich auf die Launen irgendeines genialen Ingenieurs aus dem Internet zu verlassen, ist riskant.
Microsoft wird mit VSCode Geld verdienen. Nur nicht so direkt, wie Google mit Chrome Geld verdient.
Ich finde OSS großartig, aber das ist nicht der Grund, warum ich VS Code nutze.
Ich nutze es, weil es das Problem gelöst hat, einen brauchbaren Editor zu brauchen, der kein Monster wie Eclipse ist.
In diesem Bereich gibt es auch andere Optionen wie Sublime, aber VS Code fühlte sich immer am wenigsten störend an.
Früher gab es auch das ähnliche Adobe Brackets, aber aus irgendeinem Grund war es sehr langsam und voller Bugs.
Wenn man ein OSS-Enthusiast ist, sind die Punkte des Artikels berechtigt. Am Ende ist der Quellcode aber vorhanden, und wenn man will, kann man auch seinen eigenen Marketplace betreiben.
Das kostet Zeit und Geld, aber wenn man an die Idee glaubt, sollte man investieren, statt sich auf einen Großkonzern zu verlassen.
Wenn es proprietäre Erweiterungen gibt, die man nicht haben kann, ist das schade, aber jemand könnte auch eine OSS-Version bauen.
Insgesamt stimme ich dem Artikel zu, aber ich habe keine Illusion, dass Microsoft das aus Überzeugung für Open Source tut; und im schlimmsten Fall gibt es andere Optionen, also ist es in Ordnung.