- Visual Studio Code は MIT ライセンスのソースコードと、Microsoft が配布する プロプライエタリライセンスの製品が分離されており、VSCodium や OpenVSCode Server のようなフォークが公式エコシステムと衝突している
- 公式ビルドは
product.json に テレメトリ、gallery、logo など Microsoft 専用の設定を入れて配布され、コミュニティビルドは「clean」ビルドになるが、Visual Studio Code Marketplace には接続できない
- VSCodium と OpenVSCode Server は公式リリースのテレメトリを削除するか含めていないが、拡張機能自体のデータ収集と Marketplace へのアクセス制限により、ユーザーが期待する VS Code 体験をそのまま提供するのは難しい
- Pylance、C# 拡張機能のロードマップ、C/C++ ツールのライセンスのように、Microsoft の拡張機能と言語サーバーが公式製品・サービスに結び付けられると、Gitpod、GitLab、Datacoves、OpenBB、Foam のような競合サービスは同じ機能を合法的に提供しにくくなる
- OpenVSX とオープンな言語ツールの開発、オープンソースメンテナー支援が代替策として挙げられているが、Microsoft がデフォルトをプロプライエタリツールに変更すると、コミュニティと競合製品は機能差・設定差・法的制約を同時に背負うことになる
ソースコードは公開されているが、製品は別の形で配布される
- Visual Studio Code はリリースから7年が経った時点で、ソフトウェア開発における事実上の標準エディタとして定着した
- Microsoft は Visual Studio Code の ソースコードを MIT ライセンスで公開したが、ユーザーがダウンロードする Visual Studio Code 製品は別の プロプライエタリライセンス で配布されている
- Visual Studio Code メンテナーの説明によると、Microsoft ビルドは
vscode リポジトリをクローンした後、Microsoft 専用の product.json を上書きする
- このファイルにはテレメトリ、gallery、logo など Microsoft 専用機能が含まれる
- こうして作られたビルドは Microsoft ライセンスで配布される
- この区分こそが、Microsoft がオープンソースコミュニティを分断する中核的なメカニズムだという点が、この記事の中心的な批判である
VSCodium と OpenVSCode Server が直面する限界
- VSCodium はコミュニティ主導の自由ライセンスの デスクトップディストリビューションである
- upstream の MIT プロジェクトを自動的に追随し、バイナリビルドを生成する
- 公式リリースに含まれるテレメトリを削除したビルドを提供する
- デフォルトの
product.json には Microsoft のエンドポイントが設定されていないため、Microsoft のカスタマイズがない「clean」ビルドが生成される
- 同じコードベースを使う VSCodium でも、すべてのデータ収集を完全に防ぐことはできない
- 拡張機能は独立してデータを収集できるため、インストールする拡張機能には注意が必要である
- OpenVSCode Server は Gitpod の基盤となる自由ライセンスの サーバーディストリビューションである
- upstream の MIT プロジェクトを自動的に追随する
gp-code/main ブランチに一部のオーバーレイカスタマイズがある- 公式リリースのテレメトリは含まれていない
- どちらのディストリビューションも Microsoft Visual Studio Code Marketplace に接続できず、この制限がエコシステムの分断につながっている
Microsoft のサービス中心への転換と開発ツール戦略
- Microsoft は約9年前からソフトウェア提供のあり方を変え始めた
- 専任 QA チームがビルドをテストする方式から、スプリントベース開発、rolling release、Insider Build のテレメトリフィードバックに基づく方式へ移行した
- 同じ時期の組織再編を経て、Microsoft はサービス企業へと転換した
- Azure はこの期間に AWS の実質的な競合へと成長した
- 消費者の観点で最も大きな変化は、インストール型オンプレミス製品から、Microsoft が提供する サービス消費モデルへ顧客基盤が移行した点である
- 開発ツール領域でも、サブスクリプションではない IDE は減少する流れとして扱われている
- Apple の Xcode のように別の収益源がある場合は例外として言及されている
- Visual Studio Code は、開発ツールエコシステムをエンドツーエンドの消費型サービスモデルへ移す入口だと批判されている
- GitHub Codespaces は Visual Studio Online、Microsoft Dev Box、Microsoft Azure DevTest Labs とつながる既存サービスのホワイトラベルとして説明されている
GitHub Codespaces と Microsoft DevDiv
- Microsoft は2018年に GitHub を買収し、2019年に Visual Studio Online を公開した
- ここにはローカルで「codespace」をホストするコンポーネントが含まれていた
- その後、Codespaces チームを含む関連要素が GitHub へ移った
- GitHub Codespaces は、GitHub 所属となった DevDiv プロジェクトとして説明されている
- Nat Friedman が CEO を退任した日に、Microsoft 内部の組織再編メールが共有された
- Julia Liuson が Microsoft Developer Division のプレジデントに昇進した
- GitHub CEO の Thomas Dohmke が Julia Liuson に報告する構造になった
- Developer Division には Visual Studio、Visual Studio Code、.NET、C#、TypeScript、OpenJDK、Azure 開発者 SDK、Azure App Services、Functions、Logic Apps、API Management、Dapr、Redis Cache、Spring Cloud などが含まれる
- そのメールによると、Visual Studio と Visual Studio Code は2014年以降、16倍以上の利用増加を記録した
- Julia Liuson は昇進前、.NET コミュニティを分断した土壇場の変更を実行した人物として言及されている
- The Verge の引用によると、Microsoft 内部の匿名情報筋はこの変更をビジネス重視の判断と見ている
「設計された分断」として機能するエコシステム構造
- Gitpod のような競合製品は Visual Studio Code エコシステム内に存在できるが、Microsoft がいつでも法的リスクを作り出して市場を分割できる、という批判を受けている
- Visual Studio Code のオープンソースコードはユーザーを引き寄せる一方で、競合サービスが公式 Visual Studio Code や GitHub Codespaces のような滑らかな体験を提供しにくくしている
- Gitpod だけでなく、GitLab、Datacoves、OpenBB、Foam など、VS Code のソースコードを基盤に Microsoft や GitHub と競合しようとする企業も同じ問題を抱える
- Microsoft ツールに依存すると、競合サービスが合法的に提供しにくい領域として次が挙げられている
- Microsoft .NET C#
- Python の汎用用途およびデータサイエンス市場
- Project Jupyter とデータサイエンス市場の大部分
- C または C++
- Java は、Microsoft ツールが RedHat ツールの水準に近づけば次の対象になり得ると予想されている
- TIOBE インデックス基準で、上記の言語・エコシステムのうち5つが最も人気のある軸に含まれ、Microsoft は TypeScript を通じて、7番目に人気の JavaScript に近い支配力を持つと説明されている
デフォルト切り替えとプロプライエタリ拡張機能の問題
- Microsoft は十分な採用を確保した後、拡張機能の更新によって プロプライエタリな提供物をデフォルトにできる、という批判を受けている
- Python コミュニティでは、オープンソースの Microsoft Python Language Server が終了し、プロプライエタリな Pylance がデフォルトになった
- Visual Studio Magazine の引用によると、Microsoft はユーザーに強制移行はしていないが、Pylance を新しいデフォルトに設定した
- Python 拡張機能は VS Code Marketplace で約 5,000万ダウンロードを記録し、次に人気の Jupyter 拡張機能の約2倍とされている
- .NET コミュニティでも、C# 拡張機能のロードマップを通じて同様のデフォルト切り替えが進んでいる事例として示されている
- Open.NET のような代替ツールが作られても、ユーザーはプラットフォーム別の設定を別途つなぎ込む必要がある
- デスクトップでは
devcontainer.json に ms-dotnettools.csharp を入れられる
- Gitpod では
gitpod.yml に、まだ存在しないオープンなツールを入れなければならない、といった違いが生じる
- Microsoft 公式エコシステム内では、同じ
devcontainer.json 設定がデスクトップの Visual Studio Code と GitHub Codespaces でそのまま動作する 単一の設定ソースになる
ライセンスが生む法的制約
- Gitpod、GitLab、Datacoves、OpenBB、Foam などが制限を回避して
ms-dotnettools.csharp のような Microsoft 拡張機能をサービスで提供すれば、Microsoft 法務チームから強い法的対応を受ける可能性があると警告している
- 競合するクラウド開発環境のユーザーが当該拡張機能を手動インストールしても、ライセンス違反になり得る
- Microsoft C/C++ 拡張機能のライセンス文言は、このソフトウェアを Microsoft Visual Studio、Visual Studio for Mac、Visual Studio Code、Azure DevOps、Team Foundation Server、および後継の Microsoft 製品・サービスとともにのみインストール・使用できるとしている
- この条件により、公式 Microsoft ディストリビューションではない VS Code ベース製品は、ユーザーが期待する Microsoft の言語ツールをそのまま提供しにくい
対応の方向性：OpenVSX とオープンな言語ツール
- 現在構築されているソフトウェア開発ツールの未来は閉鎖的な方向へ進んでいる、という批判がある
- 一部のコンポーネントが OSI の定義を満たしていても、全体の構成グラフはそうではない可能性がある
- オープンソースは本来、プロプライエタリなオンプレミスソフトウェアを牽制し、ファイル形式の開放性を維持するための金融的な武器として説明されている
- 同時に、オープンソースで収益を上げるのが難しい理由とも結び付いている
- proprietary SaaS に対抗し、コンピューティングの自由における開放性を保証する新たな運動、または1970年代の自由ソフトウェア運動の再検討が必要かもしれないと提案している
- Gitpod の Open-Source Sustainability Fund は、このエコシステム分断問題への対応の一つである
- 1.5年の間に、オープンソースコミュニティの言語サーバーツールのメンテナーへ 3万2,000ドル以上が配布された
- Gitpod は Visual Studio Code オープンソースエコシステムの Marketplace 問題を一部解決するために Open VSX を作り、Eclipse Foundation に寄贈した
- 今後最大の課題は、Microsoft がプロプライエタリな言語サーバーへコミュニティを移行させた各領域で オープンな言語ツールを開発することである
その後の編集で追加された内容
- 2022年8月31日の編集では、Microsoft が VSCode を作り、プロプライエタリだが無料のディストリビューションとプロプライエタリだが無料の拡張機能を提供した後、言語ごとの最良の体験を閉じた形の VSCode に結び付けた、と要約している
- 2022年12月16日の編集では、GitLab の VSCode MIT ベースの Web IDE とリモート開発体験も同じ問題を抱えると付け加えている
- 2023年10月13日の編集では、Google の Project IDX も VSCode MIT ベースであり、.NET と Python で Visual Studio Code LSP がそのまま動作するという期待は不可能で合法的でもないとしている
- 2025年4月24日の編集では、Microsoft が Windsurf や Cursor のような AI コーディングアシスタントとの競争を抑えるために、VSCode エコシステムを意図的に壊したと批判している
- 同じ日に、Microsoft の競合製品リリースと C/C++ 拡張機能の VS Code forks へのアクセス制限を関連付けて言及している
5件のコメント
vim や zed を使う案を検討しています。
私は opacity が設定されたターミナルを使っているのですが、
nvim の背景色をなくす方法をご存じでしょうか？
これさえ分かれば、ぜひ nvim を使ってみたいのですが……
kittyターミナルをお使いなら、同じ背景色にすれば透明が適用されるはずです。
あるいは、こうしたプラグインを検討してみるのも……
https://github.com/xiyaowong/transparent.nvim
ありがとうございます。確認してみます。
成功しました。ありがとうございます。良い一日をお過ごしください。
Hacker Newsの意見
ある意味では、この状況はチャンスになり得る。VSCodeエコシステムは多くの面でかなり脆弱だ
cpptoolsは優れた点もあるが、しばしば誤動作し、事実上デバッグ不能で、他の拡張も大してましだとは期待しにくいより大きな問題はセキュリティモデルが非常に弱いことで、拡張はサンドボックス化されておらず、リモートリポジトリにアクセスするクライアントも設計上きわめて危険だ
会社のコードだけを見るなら、リポジトリ自身が攻撃してくる可能性はあまり心配しなくてよいかもしれないが、悪意ある拡張は当然心配すべきであり、開発ツールをあまりに簡単に信頼することに慣れすぎている
LLMは決して信頼すべきではなく、ユーザーを攻撃しようとするかもしれないLLMに、リポジトリへ直接書き込んだり、VSCodeの一部コンテキストでJSコードを実行したりする権限を与えるのは安全ではない
より良いエコシステムなら、
cpptoolsに相当するツールはインターネットアクセス権を持たないためテレメトリもなく、ワークスペースの読み取り・自身のキャッシュファイル作成・UI操作程度だけが可能であるべきだHTTPS_PROXYが何に設定されているのかさえ分からないことが多いSSH拡張も、ユーザーが接続するクライアントごとにサーバープロセスを立ち上げ、切断後の状態保存も一貫していないように見える
結局、VSCodeを使うことで自分たちで作った問題を直す手助けに多くの時間を費やすことになる
マーケットプレイスのすべての拡張へのオープンなアクセスを許可するか、完全にロックダウンしてローカルファイルからしか拡張をインストールできなくするか、その中間がない
後者はVSCodeの保守にかなりの負担を与える
compile_commands.jsonを持っているか生成できて、特にCMakeでは比較的簡単で、clangdにそれを見せられるなら、clangd拡張のほうが私にはずっと良かった私が使っているEmacsもサプライチェーン攻撃を防ぐ仕組みはほとんどなく、多くはGitリポジトリから直接取得するコミュニティ拡張アグリゲータを使っている
ただ、Emacsユーザーのほうが取り込む拡張のソースコードを実際に目を通す割合はずっと高そうだ、というごく小さな利点はある
Microsoftは何年ものあいだ「セキュリティがすべてであり、今もっとも重要だ」と言ってきたのに、SSHキーのようなものが盗まれたときに影響がもっとも大きいユーザー層であり、かつもっともセキュリティ意識の高い開発者層のために、そうした基本すら整えていなかったとは奇妙だ
人々が無作為に拡張をインストールし、Visual Studio Codeが「言語サポート」の名目で任意の拡張を勧める状況は、思っていたよりずっと悪く見える
cpptools拡張に関する良いスレッドがある: https://github.com/microsoft/vscode-cpptools/discussions/126...ソースからビルドする過程を深く掘り下げたわけではないが、この投稿を見るとそもそも不可能に見える
あるコードベースがOSSライセンスであり、そのビルド依存関係までOSSライセンスなのかを表す新しい用語が必要になるかもしれない
mainは自由ソフトウェア、non-freeは非自由ソフトウェア、contribは自由ソフトウェアだがmain外の、たいていは非自由のソフトウェアに依存するものだcontribという用語自体はあまり好きではないが、この分類はかなり妥当に思えるWindows上の多くのF/OSSやmacOS上のほぼすべてのF/OSSは、MSVC、Xcode、AppleのフレームワークやGUIツールキットのような独占的なビルド依存関係を持っているが、それでもそれ自体はF/OSSであり得る
しかしこの件はそういう問題ではなく、メンテナのように見えるMicrosoft社員が「我々のライセンスでは代替のVS Codeディストリビューションで拡張を使うことも禁じており、Microsoftが作成した公式ディストリビューションでのみ使える」と述べている状況だ
これは単なるプロプライエタリソフトウェアだ
自由ソフトウェアの定義における自由0は、望む目的のためにプログラムを実行する自由であり、VSCodeのサードパーティ配布版が公式配布版と同じ拡張の権利や互換拡張とともに使う権利を持てないなら、コードの一部のライセンスに関係なく自由3も満たせない
「言語サーバーバイナリを自前の配布物として再配布しようとするなら、ランタイムライセンスがそれを禁じる」というのは、オープンソース定義の条件1、すなわち再配布の基準を満たしていないという意味であり、改変再配布版に原版と同じ権利を認めないVSCodeも条件3、派生著作物の基準を満たしていない
VSCodeとこの拡張はどちらもオープンソースではなく、オープンソースの構成要素を一部含むプロプライエタリソフトウェアだ
自由ソフトウェアの定義: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
オープンソースの定義: https://opensource.org/osd
これらの定義が一般的な辞書的意味ではなく、特定の社会的・技術的目的を持って運動の内部で作られた用語である点も重要だ
同じフロントエンドがVisual Studio IDEにも入っている
代替として
clangdベースの完全オープンソースなC++拡張があると認識しているが、間違っているかもしれない「Microsoftが無料で提供する自由ソフトウェアが十分にオープンではない」というのは、今の基準で見てもかなり妙な主張に聞こえる。
昔は「無料IDE」といえば Eclipse や拡張を大量に載せた Vim を意味していた。
見たところ、Microsoft がオープンな代替を妨害しているというより、その代替が単に劣っているだけであり、従業員に給料を払いながら利益も出さなければならない企業の作ったソフトウェアを使うなら、もともとそういう面はある。
Microsoft の最高のソフトウェアのソースコードを当然受け取れると感じている人は、独立した非営利団体が維持する本物のオープンソースがどんなものか見てみればよい。
機能はするし、もしかすると本物のデバッガもあるかもしれないが、そう遠くないうちに戻りたくなる可能性が高い。
人々は無料で手に入れたソフトウェアを当然視しすぎている。少し前までは IDE に数百〜数千ドルを払う必要があり、数年後に新バージョンが必要になればアップグレード費用も払っていた。
VSIX 拡張はある程度オープンな標準であるべきだが、Pylance のような Microsoft 製拡張は、Microsoft ビルドではない VS Code 上で動作していることを検知すると、積極的に動作を拒否する。
核心は、開発者たちが欺かれており、Microsoft の目標は必須部分を閉じていくことにある、という点に近い。
機能面の同等性が終わっても、次には性能の問題が残り、それがいつ解決されるのかも分からない。
オープンソースソフトウェアという考え方は素晴らしいが、今日の最高のソフトウェアは、ほとんどの場合やはりお金を払わなければ手に入らない。
Emacs と Vim を使う代償は分かっている。理論上は完全に無料でも、実際には時間、忍耐、献身というコストがあり、自分の選択によって自分とコミュニティと業界が利益を得ることも分かっている。
以前 IntelliJ を使っていたときも、JetBrains がどう利益を得るのか正確に分かっていた。ライセンス費用を払い、毎年更新していたからだ。
だが Microsoft の計算は何なのだろう。こんなに美しく、十分に良いツールを完全に「無料」で提供して、将来私はどんな代償を払うことになるのだろうか。
ドイツの GDP に匹敵する時価総額を持つ巨大企業が、ただ開発者を愛しているというだけで莫大な資源を投じて「無料」のコードエディタを作ると信じるのは難しく、開発者は少なくとも少しは懐疑的であるべきだ。
Microsoft のソフトウェアは悪夢のようながらくたの山に近いと思う。
クローズドソースのソフトウェアがオープンソースのふりをすると、それを使いたくない人にまで影響が及ぶ、というのが記事の要点なのに、それを見落としている。
たとえば Azure DevOps なのか GitHub Actions なのかも使いたくないが、私が働く組織がプロジェクトを GitHub に載せなければならないので、強制的に使わされる。
その結果、自分の労働と知識が Microsoft によるユーザー搾取に使われているように感じる。
唯一の慰めは、これが有給の仕事だという点だけで、個人的には GitHub を使わないし、他人にもそう勧めるつもりだ。
VS Code を作っている常勤社員50人以上の年間およそ2,000万ドルの予算をどう正当化するのかというモデルを示さない限り、この批判は「彼らのエンジニアリング成果をうちの会社が持ってきて製品の表面だけ変え、自前の開発費もかけずにもっと安く売って利益を得ることを少しやりにくくしたなんて、腹が立つ」と言っているように聞こえる。
それをオープンソースとして公開すれば、他コミュニティからの信頼が得られ、無料のコードとバグチェック、Microsoft のエコシステム外での拡張作成とサポートも得られ、Microsoft 自身もそれを使い続けられる。
それほど複雑な問題には見えない。
歴史的に見て、それは陳腐化への確実な道だった。
彼らのエンジニアリング成果がなくても、Emacs、Vim、Clang、GCC、IDEA、Eclipse、Firefox などがある。
Microsoft の寛大な毛布の贈り物に興味があるのは、天然痘がおまけについてこない場合だけだ。
ただ、これを大きな驚きのように報じるのは少し滑稽だ。最初から明白で、ただ争う価値がなさそうに見えたので気にしていなかっただけだ。
BSD/MIT ライセンスの開発者が搾取される問題には、テレメトリを切れば Microsoft のビジネスモデルが揺らぐかもしれないという問題と同じくらいしか関心がない。
みんな「大企業の先輩が自分たちに目をかけてくれるはずだ」と思い、何に参加するのか分かったうえで選び、実際に目をかけてもらえたのだから、おめでたいことだ。
私は AGPL より弱いライセンスでは何も公開しないだろうが、結局のところソフトウェアよりはるかに気にかけていることが他にある。
まだ何が問題なのか把握しようとしているところ。
Microsoft がより良い
cpptools/C++ 拡張を作っているが、多くの Microsoft コンポーネントがクローズドであるため、完全な OSS 版をビルドできない、という意味に聞こえる。そして、ユーザーがどの Web インターフェースでもネイティブ拡張を使えないと分かったとき、それは Web インターフェース側の人たちの問題になる、ということなのだろうかと思う。
人々が OSS ではなく フリーウェア を使いたがるなら失望はするかもしれないが、それが本当に問題なのかは分からない。
答えがあるとすれば、誰が責任を負うべきかをもっと明確に知らせることだろう。
オープンソース企業は、自分たちの提供物がオープンソースであり開かれたエコシステムであることを、もっと明確にし、すべての拡張がそうではないこと、そして Microsoft の代替拡張はそうではないことを開発者に知らせるべきだ。
主要な拡張プロジェクトが足並みをそろえれば、マーケットプレイスの説明に、
vscode-cpptoolsは OSI 承認ライセンスではなく、未審査のバイナリ blob を多く含み、Microsoft はネイティブなオープンソースビルドや Web サービス向け VSCode の提供での再配布を許可していない、といった案内を付けられるかもしれない。法的にも文化的にも、Microsoft は、いくつかの OSS プロジェクトが自社のライセンス条件を Microsoft の条件と比較したという理由で、マーケットプレイスへのアクセスを阻止したいとは思わないはずだ。
Apple も今マーケットプレイス訴訟を抱えており、Microsoft もマーケットプレイスや別の反トラスト訴訟は望まないだろう。
その後、公開関数が 1 つだけの別の API を作り、その関数はそのライブラリバイナリに
extern呼び出しをするだけだ。2 つ目の API を GitHub に MIT ライセンスで上げて、オープンソースだと宣言する。
広く見れば、ソフトウェア機能の 100% がクローズドソースのコンパイル済みバイナリの中にあるなら、それを オープンソース と呼ぶのは虚偽広告であるべきなのか、という問題だ。
言い換えれば、誰かが搾取的な理由でオープンソースの意図を踏み越えるとき、誰が線を引くのかという問題だ。
cpptoolsの機能が 100% クローズドかどうかは分からないが、実際には MIT ライセンスとされているリポジトリの中で、同意しなければならない別のライセンスがさらに 3 つある。実際の要点が何なのかを知るのに、あまりにも多くの文章を読まなければならず、「分裂したエコシステム」という概念が説明なしに何度も出てくる。
「分裂するよう設計された ハエトリグサ」のような表現が、いったい何を意味するのか分からない。
VS Code は Microsoft が無料でダウンロードして使える IDE であって、Microsoft が管理しない魔法のようなオープンソースプラットフォームやエコシステムではなく、製品だ。
みんな「汎用」の開発者向けサービスを作りたがるが、実際には IDE を作ったり資金を出したりはしたくない、あるいは難しすぎるように見える。
それは Microsoft のせいではない。
Microsoft を擁護するつもりはないが、巨大なコードベースを無料で提供し、その上に大半が無料の製品を作った、ということだ。
フォークしても Microsoft のサーバーにアクセスできないだけで、その程度なら十分に公正ではないかと思う。
そして Monaco は圧倒的に優れたエディタなので、フロントエンドが使っているのだ。以前は CodeMirror や Ace が最善だったとき、それらを導入していた。
Monaco の誕生の背後に巨大なマスタープランがあったというより、むしろ独立プロジェクトにすれば数多くの Web UI を可能にできるという機会を見た、という方が近いように思える。
「これから作られるソフトウェア開発ツールの未来が完全に閉ざされているのに、一部のコンポーネントが OSI の定義を満たしているという理由で、人々は大きな絵を見落とし、それでよしとしている」という点が非常に大きな問題だ。
特に VC 投資を受けた多くの企業が オープンソースという用語 をあまりに緩く使っており、言葉と意味、さらにはオープンソース運動の精神まで悪い方向に変えてしまっている。
YC も、オープンソースだと主張しながら、その精神にはまったく従っていない企業をいくつも支援している。
精神や倫理といった道徳論は、それほど大きな関連性はない。
重要なのは、ソフトウェアライセンスが法的文書であり、その解釈が意味を持つのは法廷だという点だ。
VS Code 関連の訴訟は多くなさそうで、Microsoft はその部分をおおむね整理している。
法的な意味では、VS Code は十分に安全に見える。いくつかの拡張が OSS ライセンスではなかったり、完全にクローズドソースだったりするのは事実だが、それが嫌なら使わなければいい。
さらに言えば、自分でオープンソースを作って直せばよい。オープンソースは権利ではなく、作者の裁量で与えられる特権であり、要求できるものではない。
VS Code は多くの OSS コンポーネントを含むクローズドソース製品であり、そのコンポーネントが多いからこそ、完全 OSS の VS Codium も存在する。
それらの OSS コンポーネントの多くは他の製品でも使われており、一部は完全にオープンソースだ。
VS Code エコシステムの価値は、こうしたコンポーネントと製品エコシステムを繁栄させている点にある。
誰も VS Code を無料で受け取る権利はない。実際、何であれ無料で受け取る権利などない
代替案は、肥大化した商用 IDE に金を払うことだ
VS Code は十分に良く、汎用的で、無料で、フォークできる程度にはオープンでもある
人々は、これが工学的に驚くべき成果物だという点を忘れている。コードを見れば、無料で出てくるような代物ではない
Microsoft であれどんな企業であれ、誰に対しても無料で何かを提供する義務はなく、こうした権利意識は抑える必要がある
問題は、無料で提供されるものが、実質的に法的責任と上限のない金銭的責任の泥沼にはまり込むよう設計されているときだ
特に VS Code のように一回限りの購入ではなく、拡張やアップデートを通じて Microsoft に継続的に依存しなければならないサービスではなおさらで、実際そのように設計されている
一度きれいに支払って終わりにする簡単な選択肢を作らず、ユーザーの抵抗の度合いに応じて長期的に曖昧な金額を吸い上げる方を選んでいるのだ
オープンソースについてもいつも言っているが、潤沢な資金の後ろ盾がないフレームワークを採用することには懐疑的だ
どこの誰とも知れないネット上の天才エンジニアの気まぐれに依存するのは危険だ
Microsoft は VS Code で金を稼ぐだろう。Google が Chrome で稼ぐのと同じで、ただそれほど直接的ではないだけだ
OSS は素晴らしいと思うが、私が VS Code を使う理由はそこではない
Eclipse のような怪物ではない、実用になるエディタが必要だという問題を解決してくれたから使っている
この分野には Sublime のような他の選択肢もあるが、VS Code はいつも最も邪魔にならない感じだった
以前には似たような Adobe Brackets もあったが、なぜか非常に遅くてバグが多かった
OSS の熱心な支持者なら、この記事の指摘はもっともだ。だが結局ソースコードはあるし、望むなら自前のマーケットプレイスを運営することもできる
時間も金もかかるが、その考えを信じるなら巨大企業に依存せず投資すべきだ
手に入らない独占的な拡張があるなら残念だが、誰かが OSS 版を作るかもしれない
全体としてこの記事には同意するが、Microsoft がオープンソースへの信念ゆえにこうしているという幻想はなく、最悪の場合でも他の選択肢があるので問題ない