I feel that you're conflating few concepts, hackability, "open source", single point of failure architectures.

Yes, VSC is less hackable than emacs, but I don't think it's necessarily the same thing. VSC (and others like it) are going for a more streamlined "App Store" experience, while emacs is going for a more DIY/hackable style editor. You can always fetching the VSIX file and sideload it is if the "store" is down though.

Yes, VSC is less "open source" than emacs. if "open sourceness" is a score out of 10 or something. Pretty sure RMS would argue linux is less "open source" than emacs too.

Not sure why this is futile for the VSCodium devs. They are taking a dependency on a service for installing extensions. The solutions is more readonly mirrors for the official OpenVSX endpoint.

If your main archlinux mirror is down, you don't cry about the centralized state of our life. You use a different mirror. You throw in 5 or 10 in case one or two are down. I understand why a company like Microsoft might want a more centralized service to distribute the extensions. But for an open source clone? is Microsoft also expected to create the mirror clone?

My point about VSC is that brands itself as "open source" when Microsoft clearly intends for it to have a proprietary, tightly controlled ecosystem. It's not just RMS-unapproved, it's practically a lie. You can use it as a FOSS editor, but only if you are willing to accept a vastly subpar experience. Oh, and they've started cracking down on people using their proprietary VSC plugins in derived editors, too.

I expected it to be a little less convenient to leave Microsoft's beaten path. I did not expect it to be a massive waste of time. This is what I meant by futile. Not only is it apparently very brittle, it's missing large swaths of VSC's ecosystem. Hell, I don't even know if the extension I wanted is available on OpenVSX because it's still down!

If Microsoft hadn't openwashed their product, I wouldn't care nearly as much.

Besides, Emacs still provides a streamlined system for managing packages on top of being hackable. It even makes installing and upgrading packages straight from a Git repo easy. Sometimes you can have your cake and eat it too.

> Yes, VSC is less "open source" than emacs. if "open sourceness" is a score out of 10 or something.

VS Code is not Open Source, period. What exists in the “Visual Studio Code - Open Source” repo that is MIT licensed but cannot be used to build VS Code. Once-upon-a-time it was just branding, telemetry, and a license to use the Microsoft Extension Marketplace. Now, however, there are proprietary, closed-source extensions and additions that are only available in the proprietary-licensed VS Code.

> You can always fetching the VSIX file and sideload it is if the "store" is down though.

No, you cannot do so legally (in the context of using Vscodium or similar), as it is a violation of [the VS Code Marketplace ToS][1]: “You may not import, install, or use Offerings published by Microsoft or GitHub, or Microsoft affiliates in any products or services except for the In-Scope Products and Services.”

[1]: https://cdn.vsassets.io/v/M253_20250303.9/_content/Microsoft...

> is Microsoft also expected to create the mirror clone?

Allowing open source VS Code (ie. VS Code you compiled from Microsoft’s repo) to access extensions would be enough. Nobody is asking Microsoft for more than basic access. It’s does not even require a code changes, just a policy change.

Even Google allows Chrome forks to access the Chrome Store.

> Pretty sure RMS would argue linux is less "open source" than emacs too.

The word you're looking for is 'free'. Free as in freedom and free software. The open source philosophy focuses on the openness of the code base and the associated advantages. Free software philosophy highlights the freedom that the software gives its user on their devices. Opening the source code is just a means to that end for the free software philosophy. Most open source software are also free software. But a few software like VSC and Chrome manages to be open while holding back the freedom from its users. Stallman and others tried to highlight this difference, but were largely neglected. The large scale ignorance of this distinction is what led to spread of travesties like the Chrome browser.

I completely agree with GP on this matter. I use centralized repos for Emacs like ELPA and MELPA like a metadata source. The actual packages are downloaded directly from their git repos. All these happen transparently and failure is practically non-existent, even in the absence of mirrors. In contrast with such convenience, the only way to fully utilize VSC extensions market is to use MS's proprietary build of VSC. If you tried installing some essential extensions (like remote editing and editor sharing) on a fork or an open source build of VSC, it would 'conveniently' tell you that it doesn't work on an alternate build and instead give you the link to download the proprietary build. Some of these functionality don't even need an extension on Emacs (eg: tramp). What are the justifications for such restrictions? They alone know. But I'm sure that they aren't technical. You're probably too busy to worry about the politics behind it, whenever you find yourself in such a situation. It's quiet manipulative in my opinion. And all these were before MS started banning VSC forks from their marketplace.

It's even worse. VSCode used to be more open source originally, back when it was enthusiastically adopted. And then, gradually, official extensions started replacing parts with closed blobs with onerous licensing terms. C# and Python extensions have both suffered from this. Although the C++ one was never fully open, if I remember correctly.

I was gonna write this. Package management with distributed mirrors for both speed + redundancy are a solved problem in the Linux world. Ship trusted signing keys and even the shadiest mirror becomes verifiable.