In some sense, this ought to be an opportunity. VSCode’s ecosystem is, in many respects, quite weak:
- cpptools is kind of amazing but also pretty bad. It regularly malfunctions for me. It’s essentially undebuggable. I have less experience with the other extensions, but I don’t expect that they that much better.
- The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
And that second point is a big deal. Maybe when poking at your own company’s code, you aren’t that concerned about your repo attacking you. You probably should be concerned about malicious extensions, but we’re all far too used to trusting dev tooling. (Don’t forget that MS’s extensions are just this side of malicious.)
But, with AI, you should absolutely not trust your LLM. It is entirely unsafe to give an LLM that might try to exploit you the ability to write into your repo directly or to run JS code in the context of any portion of VSCode. And it’s really quite easy to convince LLMs to engage in all manner of shenanigans.
There’s an opportunity to make a better ecosystem. In a better ecosystem, the equivalent of cpptools would not have telemetry, because the equivalent of cpptools would not have Internet access. It would have the ability to read the workspace, to create cache files for its own data, and to operate its UI, and that’s all.
VSCode also, by design, obscures what’s really going on on the development environment, so that when I help a VSCode user who gets stuck, they often don’t know what computer they’re logged into, where their files actually are in the file system, which Python interpreter they’re using, what HTTPS_PROXY is set to, and so on. The ssh extension also spins up a server process for every client a user connects, and it seems a bit inconsistent about preserving state across disconnections. All in all, I spend a lot of time helping people fix problems they’ve made for themselves by using VSCode.
Presumably, this is talking about some remote devcontainer configuration. None of that really applies to using vscode locally, at least not any more than any other editor.
> - The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
This is a big concern for our Infosec team. There is no middle ground between open access to every Extension on the marketplace or locked down and Extensions are installed via local files. The latter being a significant overhead in maintaining VSCode.
All these same things are true for emacs/vim/CLion plugins as well. You kind of either have to accept the risk cowboy style, do something in the middle (maybe only allow very well known extensions from source you trust), or live without the extensions.
Then you have other problems. Maintaining the store itself, obtaining the extensions people want, and keeping the extensions up to date adds some overhead.
Looks like it should be possible, although I have no experience doing it myself.
The clangd extension is much better for me, assuming that you have or are able to generate a compile_commands.json (at least easy in cmake) and point clangd to it.
One problem I always had with VSCode, is that it seems to fill up its autocomplete suggestions with "near-string-matches" from files all over the project. The jetbrains tools are quite strict in that regard and won't propose random string matches that don't fit semantically.
That doesn't sound right. clangd should (and does) only suggest semantically valid suggestions. It's also much faster than the CLion's own C++ engine, though that might change with CLion Nova.
CLion was what I used before and it was way clunkier than VSCode with clangd. Complicated libraries like CGAL just weren't usable for auto-complete, but were instant with clangd.
> The client, accessing remote repos, is wildly insecure, by design
Who's the best kid in the block regarding third-party extensions security?
There's really not much standing in front of a supply-chain attack for my editor of choice, emacs. Most people use a community extensions aggregator that also directly fetches from git repositories. The only slim advantage we have is that I'm sure a much higher % of emacs users would actually look into the source code of the extensions they pull.
If you want to be cautious, I have somewhat higher confidence in the versions of Emacs packages published on the Debian repositories[1] than the ones on ELPA/MELPA.
The downside is that not every package is packaged for Debian, and the versions are a bit stale.
This is quite surprising to me if true. Microsoft has for years touted "Security is everything and the single most important thing right now", yet something that basic is not taken care of for the most security minded audience, and for the audience with probably the biggest impact in case ssh-keys and alike gets stolen?
People randomly installing extensions (and Visual Studio Code suggesting random extensions by "language support") starts to look a lot worse than I thought. Guess I'm lucky I never jumped aboard the Visual Studio Code train...
Extensions often rely on third-party binaries (such as Language Servers, kubectl, ssh or even git itself), internet access (SAAS providers, pulling data or definitions, ...) and on your filesystem (SSH Config, Kubernetes config, Config folder in your home, ...). Sandboxing these extensions is not easy unless everything is configured within VSCode which is rarely the case.
As far as I know, extensions are not sandboxed either on Emacs, (Neo)vim, Jetbrains IDEs.
Extensions (in Emacs lingo we call them 'packages') are not sandboxed by design. Because unlike VSCode, you are allowed to override any, just about any part of a package's code. You can, for example, grab a command introduced in a third-party or a built-in package and override only specific parts of it without having to rewrite the entire thing.
Of course, in many cases that can make your entire setup brittle - i.e., what happens when the package author decides to change some functionality that you carefully and tightly integrated into your system? At the same time, there's enormous, unmatched flexibility for making your own rules of the game - there's nothing that comes even close. You can change a function to do things that it was never initially designed for. For example, if there's a command that lets you perform GitHub search and open results in the browser, you can advise that command to change the behavior and instead of opening the results in the browser, send that data to an LLM and display it in a text buffer. You wouldn't have to rewrite the entire command; you would only have to override a specific part of it. In Vim, you'd have to rewrite the entire function. In VSCode, you'd likely have to make a separate extension. In Emacs, you wouldn't even have to save the damn thing into a file - you can write it in a scratch buffer and immediately try it out.
Would still be nice to have the option to opt into, for example, running as a WASM isolate - given the option of a robust sandbox, some plugins will find it desirable to migrate and gain the secure badge or however isolated plugins are marked for user identification.
But There are plugins where it’s going to be too much of an uphill battle to move to that model though. I still think on balance having sandboxed plugins, however they’re implemented, would be pretty nice.
And happily VS Code runs in the browser (vscode.dev, github.dev) if you do choose to make that security/performance trade off at some point for some reason. And with sync you can have all your UI extensions and keybindings ported over under the covers.
Sure, I’ve even made a handful of those myself. I contrast them with workspace extensions that run on a (possibly remote) host with full access to subprocesses/etc.
VSCode could shove the entire extension, third party binaries included, into a sandbox, Docker-style. And “give this extension Internet access” could be an option when you install it, with the default being “no”, and a bit warning if you want to override that default.
For all that the Docker ecosystem is somewhat of a mess, it seems more than adequate for this use case.
I am still waiting for many Windows extension scenarios that only support in-proc COM written in C++ to finally support out-proc COM with .NET, regarding how the whole security story is going on.
Yes, their C++ LSP isn't really good and I've heard C# isn't good either - but that's because they want to sell Visual Studio too. But especially "Remote SSH" and "Dev Containers" are so called game changers. And their Typescript and Python extensions are actually good.
C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) itself - this is what the base C# extension[1] uses. Both of these are licensed under MIT.
The closed-source part is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].
[2]: https://github.com/muhammadsammy/free-vscode-csharp (please consider giving it a star, it's the only actively maintained alternative and other tools end up relying on it downstream to support debugging - VSCodium as well as Emacs and Neovim with VSC extension bridges)
Lately they've begun embedding the same C# analysis stuff they have in VS into VSCode if you pay for the license. I haven't used it in anger (long since left for Rider), but it has come in handy when troubleshooting people's VS issues at work from my Mac. The test explorer now blows up in exactly the same way in VS and VSCode :)
the internet archive isn't going to last much longer, maybe five or ten years
as brewster says: 'governments burn libraries'
there's a reason that the first backup of the internet archive is at alexandria and that the first time brewster started the internet archive it was a for-profit company called 'alexa'
in a few tiny comments it demonstrates precisely the problem the larger ecosystem is facing and will almost certainly get much much worse sooner than we think.
VSCode is not open-source, and neither is this extension.
Much F/OSS on Windows and virtually all F/OSS on macOS has proprietary build dependencies (e.g., MSVC on Windows, Xcode and various Apple frameworks and GUI toolkits on macOS), but is still itself F/OSS. It's true that such software doesn't promote or embody software freedom to the same extent as free software written for free platforms and built with free toolchains and dependencies.
But this case isn't about that. Reread the comment of maintainer (presumably an MS employee) at the end:
> I'm sorry to let you know that our license also prohibits using our extension in alternate distributions of VS Code - only the official one produced by Microsoft may be used. So even if we did produce a RISC-V version, you wouldn't be licensed to use it with Code Server.
That's just proprietary, software plain and simple.
Recall freedom 0 of the free software definition:
> The freedom to run the program as you wish, for any purpose (freedom 0).
In the way that third-party distributions of VSCode do not come with the same rights to extend the software or use it in combination with compatible extensions as the first-party distribution does, VSCode also fails the test of freedom 3, regardless of the license of much of the code:
> The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
It's not that your modified copies must give your users the same rights to inspect and modify the code as you had (that's copyleft) but that you are unable to give them such rights. MS does this not entirely through the licensing of VSCode but also through the licensing of certain extensions, but the actual outcome is the same.
It's not a different story for the term open-source. This:
> May we ask why you'd like to do this? If you're planning to redistribute the language server binaries as your own custom offering, please note that our runtime license prohibits that.
means that the extension fails condition 1 (the redistribution criterion) of the open-source definition. And VSCode not allowing modified redistributions the same rights as the original fails condition 3 (the derived works criterion).
Neither VSCode nor this extension is open-source. They're both just proprietary software with some open-source components.
Note that these are not definitions in the ordinary lexographical sense. They are terms that were created with explicit social and technical purposes in mind, by and for organized movements. This isn't an argument from the dictionary but a reminder of the purposes of these concepts.
Partly true, partly false. VS Code is FOSS (MIT license). The VS Code binary that Microsoft distributes is freeware (proprietary license).
> and neither is this extension
Correct.
> That's just proprietary, software plain and simple.
Indeed, the Pylance extension is proprietary software.
> In the way that third-party distributions of VSCode do not come with the same rights to extend the software or use it in combination with compatible extensions
False. Third party distributions of VSCode can absolutely use compatible extensions. The license of certain proprietary extensions does not allow you to use them with third party distributions of VSCode.
> It's not that your modified copies must give your users the same rights to inspect and modify the code as you had (that's copyleft) but that you are unable to give them such rights. MS does this not entirely through the licensing of VSCode but also through the licensing of certain extensions
The VSCode license prevents you from reverse engineering, modifying it, and you agree to send some telemetry to Microsoft. You're correct that the MS distribution is not FOSS. It's the same with Chrome (the code base) and Chrome (the browser binaries that Google distributes).
> Neither VSCode nor this extension is open-source.
Again, to be clear: VSCode (the binary) is not OSS, but the source code used to build VSCode (the binary) *is* OSS.
Pylance (the extension) is straight up proprietary software.
> Note that these are not definitions in the ordinary lexographical sense. They are terms that were created with explicit social and technical purposes in mind, by and for organized movements. This isn't an argument from the dictionary but a reminder of the purposes of these concepts.
The MIT license represents a different view on the social and technical goals of open source software. It's much simpler than the GPLs and only has one obligation for the user/redistributors: display a copyright notice. It's not as copyleft as the GPLs.
Building the open source repo gets you something which isn't VSCode. It doesn't install a lot of VSCode extensions, therefore you shouldn't call it VSCode and shouldn't say VSCode is FOSS.
This is very well put. If the open source repo was named "VSCodium" it would communicate better what is going on. (Chrome / Chromium.)
Edit: to be clear, I think Microsoft should offer VSCodium themselves and state clearly that they take that, bundle it with other stuff, and are calling that blob VSCode.
Yes. I was a bit sloppy in using 'VSCode' to refer only to the thing distributed at code.visualstudio.com but also treating derivative works of what Microsoft calls 'Code - OSS' in their GitHub repo as defective (more limited) derivatives of 'VSCode'.
> The MIT license represents a different view on the social and technical goals of open source software. It's much simpler than the GPLs and only has one obligation for the user/redistributors: display a copyright notice. It's not as copyleft as the GPLs.
The MIT license is a tool used for a range of purposes, not an expression of values. It doesn't 'represent a view' about how software should be developed or distributed in the same way that documents like, e.g., the FSF's account of the four fundamental software freedoms, the OSI's Open-Source Definition, or the Debian Free Software Guidelines do. It sits at a different layer. Moreover, all of those documents incontestably include MIT-licensed software among the licenses that embody their values-- none of those organizations or movements they participate in exclude permissively licensed software.
That some source code is distributed under the terms of the MIT license only tells us a little bit about the way and extent to which it is or isn't aligned with the values and touted benefits of either the free software movement or the open-source movement. There are individuals (and organizations, if you count the contributor bases of large, relatively organized software projects) who are interested in software freedom and/or open-source development but averse to copyleft, but permissive licenses don't themselves exclusively support only one set of values and goals or constitute a statement of allegiance to other doctrines (and neither do copyleft licenses).
And that's part of what makes statements of values and ideas that go beyond licenses per se, like the ones I cited but also books like Free Software, Free Society and The Cathedral and the Bazaar, and the many shorter online documents one can find at FSF.org, EFF.org, sfconservancy.org, or even the OSI's policy advocacy work valuable: they transmit the things that copyright licenses cannot. They are reminders that adopting software and software development practices means making choices about entering into concrete relations of power, dependency, collaboration, and competition. The F/OSS licenses are instruments in service of meaningful choices about those things. And that's exactly the way that my recourse to things like the Open-Source Definition and the FSF's article What is Free Software was not to make a merely verbal dispute, arguing about what words mean, but a move to ground this discussion in the range of first-order values for which F/OSS licenses are instruments. That's something equally relevant and equally worth doing whether the licenses in question are maximally permissive (like the technically-not-a-license of donating a codebase to the public domain), strong copyleft licenses like AGPLv3, or something else like LGPL or MPL.
clangd is fully open source. You can build it yourself from llvm sources.
It works fine with emacs LSP support. I never used the proprietary extension so I can't compare the functionality, stability nor speed.
"The free software Microsoft is giving away isn't open enough" has to be one of the weirdest modern takes. I remember when "free IDE" meant "Eclipse" or "vim with a billion extensions".
From what I can tell, Microsoft isn't even sabotaging open alternatives, they're just Not As Good. That sucks, but that's just how it works when you're using software made by a company that likes to pay its staff and still make a profit.
I welcome everyone who feels entitled to the source code of Microsoft's very best software to see what true open source, maintained by an independent non-profit organisation looks like. You'll get an IDE that's functional, maybe even features a real debugger, but you'll probably wish you could go back not long after.
People are taking software given to them free of charge for granted. It's not that long ago that you had to buy IDEs for hundreds or thousands of dollars and you had to buy the upgrade if you wanted the next version a couple of years later.
> From what I can tell, Microsoft isn't even sabotaging open alternatives
I think they are. VSIX extensions are supposed to be some sort of open standard, but some Microsoft extensions like Pylance actively refuse to work if they detect running in something other than Microsoft's build of VS Code.
Microsoft's extensions don't work, but that's Microsoft's choice. Whatever open source alternative for Pylance exists (if any) will work just fine.
If they messed with VSCode to sabotage OpenPylance or whatever the situation would be different, but in this case people are just looking a gift horse in the mouth.
Pylance is Pyright (open source) plus custom Small Language Models and other proprietary sauce.
Pylance isn't sabotaging Pyright, because it is built on top of it. You can find alternative extensions that are "just" Pyright. (They have a fraction of the users because the SLM-based magic of Pylance is a nicer experience if you can "afford" it [based on your principles].)
Pyright is maybe sabotaging competitive projects MyPy and Ruff by being "knighted" as a part of Pylance, but that's not generally how open source competition is seen to exist. There also doesn't currently seem to be competition for the proprietary bits of Pylance outside of the LLM space. That's maybe catching up quickly, but Microsoft's more dedicated SLM models might still be leaders in the space, and Microsoft wanting to keep models proprietary while they are competitive shouldn't be a surprise.
Encourage you to look at the bigger picture. What happens when there’s an official extension by a 3rd party vendor SDK that defines a dependency on the proprietary language server/extension.
It’ll work fine for “Visual Studio Code” but all these OSS forks (inc recent venture capital funding for AI ones) gets wrecked.
It turns into a game of having to iterate through the graph and trying to convince official SDKs to change their product direction.
>"The free software Microsoft is giving away isn't open enough"
This is not a quote from the article and isn't what the article is saying. It's effectively suggestig that devs are being duped and MS goals are closing essential parts down.
Exactly. Look at the Ashai Linux project. They are doing tremendous work, but getting basic feature parity with a now 3 year old laptop is still ongoing work.
Then once feature parity is done, performance problems are next, if they ever get addressed and completed.
I love the idea for open source software, but the very best software in todays world is always something you have to pay for.
So my problem with MSFT's big plan is that I simply don't know it.
I do know the price I'm paying for using Emacs and Vim. Even though (in theory) they are completely free, in reality there's a price there. Vim and Emacs require time, patience, and dedication, just like any other tools. I know who gains from my choice - myself, the community, and the industry.
I knew exactly how JetBrains profited from my choice of using IntelliJ in the past - I paid for the license and renewed it every year.
But what's MSFT's scheme here? They're giving me this beautiful, nice tool completely for "free"? What price will I have to pay for that choice in the future?
I'm sorry, but I think every dev should remain at least a bit skeptical, do you truly believe that Microsoft, a colossal corporation with a market capitalization comparable to the GDP of Germany, spends an enormous amount of resources to build "a free" code editor, because... I dunno, they love you or something?
We are in uncharted territory. This major corporation has a "big plan" that relies on making their product offerings "open source" while simultaneously surrounding it with a minefield such that the "open source" aspect is camouflage/subterfuge.
"Subterfuge Source" has a nice ring to it, and abbreviated "SS" really drives the point home as well.
They realized by pushing typescript they can drive companies away from java, then when those companies will realize typescript sucks they'll be redirected to c#
Microsoft's software is absolute nightmare pile of trash.
> People are taking software given to them free of charge for granted.
Whooosh: this is the point made by the author of the article zooming over your head. The point is that closed-source software that pretends to be open-source will affect even those who don't need or want to use it.
For example, I don't want to use Azure DevOps (Github Actions) or w/e it's called. It's absolute garbage. Abysmal design, abysmal implementation. But, I'm forced into it because the org I work for has an obligation to put their projects in GitHub. And, against my will, my work and my knowledge is used by Microsoft to abuse their users.
My only consolation is that I do this as a paid job, and I, personally, will not use Github, and will advise everyone I can to do the same. But this is too little. I want to be a good person, and to do my job in such a way that it's valuable to people who requested it. I feel really bad that, instead, I'm indirectly peddling the pile of garbage made by Microsoft to astronomically enrich the few people standing at the top of the company.
Your rant about being forced to use a software your company decided for has nothing to do with the topic at hand, the person you responded to said that VSCode is Microsoft’s very best software. That’s definitely defensible, right now vscode is the most advanced open source editor that ever existed. It came from nowhere in an insanely crowded space and became the de facto standard on every system because it is so good for so many use cases.
> most advanced open source editor that ever existed.
I feel like you are either paid to write this, or are trying to be funny... By what metric is this editor the "most advanced"? It doesn't hold a candle to Either Vim or Emacs. It doesn't even play in the same league. It's just crude simplistic nothing-going-on-for-it garbage... I'm writing this as someone who has to support a lot of VSCode users, and I do know the program better than an average VSCode user. But I would never switch to using it. There's not a single compelling reason for someone who knows how to use either Emacs or Vim to even consider this possibility.
> insanely crowded space
There are only two decent code editors: Vim and Emacs. They've been in this "crowded" space for a very long time without any real competition. Anything else is just so much worse it doesn't even merit a passing mention. VSCode is in the same group with MSVS / Eclipse / IDEA / NetBeens etc. editors that simply don't seem to know what it means to be a good code editor.
In a sense, it's very similar to how you might want to buy something from Ali Express (or even Amazon more recently). You find yourself looking through dozens of pages of variations of the same low-quality version of the product manufactured cheaply in some impoverished country. And you simply won't find the real thing there, and may get an impression that cheap junk is all there is. This is, essentially, what happens if you use MSVS / Eclipse / IDEA and Co. You just grow to believe that there's only garbage, and there's a tight competition between different flavors of garbage.
Thanks for the condescending tone but I’ve been using vim then emacs half a decade each before trying, then switching to vscode as my main editor.
I’ve written my fair share of elisp, org mode files, and vim script. Vscode is better and easier to learn, and has way better support for almost every languages.
Sure I had to accept supbar alternatives to org-mode and magit. In exchange I get a way faster experience (emacs is ridiculously slow in comparison) and quasi-IDE features
> Vscode is better and easier to learn, and has way better support for almost every languages.
You missed everything you could possibly miss in your quest to master any coding editor. VSCode doesn't have support for any language. At least, not in the sense Emacs or Eclipse do, for example. VSCode model is to rely on language servers, which are programs external to VSCode. You can use them in Emacs too, for example.
To contrast this, Eclipse, for example, has, built into the editor, a ton of Java-related parsing and handling. It even has a built-in Java compiler.
So, to say that VSCode supports language X better than Emacs (or any other editor capable of running language server) is just plain ignorance.
As for easier to learn: so what? -- It's even easier to learn to tie your shoelaces. It doesn't mean there's anything good (or bad) about the editor. It's completely irrelevant...
> emacs is ridiculously slow in comparison
Slow to do what? Using Emacs I'll be running circles around you using VSCode and taking a dozen coffee breaks a day watching you struggle to do basic text editing. VSCode isn't made for good programmers, it's not optimized for fast work. Watching people write code in VSCode is like being a professional dancer and seeing geriatric rehab for stroke patients trying to learn to dance as a way of getting their life back. Except, in the later case, the effort is commendable, and you want to do everything you can to help the poor elderly people, while in the former, you just feel disgust and disdain for the laziness and lack of motivation or insight.
Without proposing a model for how the 50+ full time employees who create VS Code justify their collective ~20MM annual budget, this sounds a lot like: “Ugh, they made it mildly inconvenient for my company to benefit from all their engineering work but swap out the product surface and reap the profits by undercutting their product via not needing to fund the engineering ourselves. How lame.”
>Microsoft builds their own IDE for internal use in many other departments
>Budget is acceptable to have a flexible modern tool for their own uses
>Open source it to gain respect within other communities as well as get free code/bug checking and additional extensions written/supported even outside of MS ecosystem, that MS can still use
that's not my problem. my problem is making sure i don't make my own job skills dependent on microsoft's continued goodwill, because historically that has been a guaranteed path to obsolescence. i don't need their engineering work. i have emacs, vim, clang, gcc, idea, eclipse, firefox, and so on
i'm only interested in microsoft's generous gift of blankets if they come without smallpox
Naturally you also generously support emacs, vim, clang, gcc, idea, eclipse, firefox, and so on for them making your livehood possible, selling your skills.
no; i provide some support for some of them, but the nature of software is that it is infinitely replicable, so in general the efforts of a few suffice to satisfy the needs of many
mostly what i offer 'in return' is more free software, which is also how, for example, the vim and gcc teams support each other, for the most part
i'm surprised to see your comment because i thought you were old enough to know this already
I am old enough to see too many devs abandon open source because it doesn't pay the bills, contrary to the old promises of everyone singing happy songs around the fireplace on a comunity farm kind of ideas.
And also to remember Public Domain and the various flavours of Shareware and Demos, which is what Open Core/Dual Licensing are nowadays, by another name.
sure, plenty of people have always abandoned open source for that reason. running a free software business isn't easy. fortunately, the nature of open source is that it doesn't depend on any one person or group, so it keeps working when people abandon it. it's worth noting that over the last 30 years this has worked so well that almost all software of consequence is open-source now, which is why we aren't having this discussion on msn in blackbird or on compuserve
i agree that open-core is little more than shareware. dual-licensing is a different model, one pioneered by peter deutsch in the early 90s
this is ground we explored extensively on the fsb mailing list in the late 90s. if you're interested in my current thinking on the relationship between markets and open-source knowledge sharing, i've just written a somewhat longer note at https://news.ycombinator.com/item?id=41696527
yes, and we are going to see a lot more of that, unfortunately. heartbleed was another somewhat similar case, and though the debian openssl hole was probably accidental, nobody will ever be able to prove that conclusively
Most of us are old enough to have seen too many devs abandon iOS and Android for being head-up-ass terrible solutions.
I don't know what solution you're promoting because Free Software still works. The professional for-profit software industry is in the toilet right now - Open Source is destroying it in a certain for-profit purview.
>because historically that has been a guaranteed path to obsolescence
Has it? If there's one good thing about Microsoft, it's that basically anything, even from the stone age, is still supported. You can fire up some executable from the 1990s on Windows and it works and you can probably just be a .net dev for the next 50 years if you want to. If there's one company in this industry that takes long term support and backwards compatibility seriously it's Microsoft
> takes long term support and backwards compatibility seriously it's Microsoft
Silverlight, Internet Explorer, Windows Phone, Microsoft Edge (Legacy), Windows Media Center, Microsoft Expression, Hotmail, MSN Messenger, Zune, Kinect, Cortana (on mobile devices), Groove Music, Windows Mobile, FrontPage, ActiveX, Visual Basic 6, Windows XP, Windows 7, Skype for Business (being replaced by Teams), Office Picture Manager, DCOM, Winforms (considered legacy), .NET Remoting (superseded by WCF), WCF itself now considered largely obsolete, Classic ASP.NET (Web Forms), etc.
While Microsoft does offer LTS for core products, they also regularly obsolete technologies, often driven by market changes or strategic shifts. Their rate of obsolescence is comparable to other major tech companies.
You're talking about the most broadest of broad experiences here, what about all the proprietary dev products that have been sunset which usually was design to keep in said developer in the walled garden?
while I like your point in general you might be wrong on MFC part at least a bit.
Last time I checked one can still choose optional MFC component of desktop development in vs installer and it will let you build old code with latest toolchain and do maintenance. Not that it makes any sense in 2024 but its still there.
ps. I've been hitting F5 every working day in vs for entire career and have no plans to switch to anything else =)
> A guitar doesn't make the musician, and the hammer doesn't make the carpenter.
A good guitar player or a good carpenter sure as shit know a good tool from a bad tool. Good tools are force multipliers and can can make somebody much better than without the tool.
Plus bad tools can actively keep people away from learning new things. A shitty soldering iron can absolutely convince somebody they suck at soldering. Sure a pro can make use of a shitty soldering iron but they won’t do it willingly and their output will be subpar. Same with cooking and bad knives. Same with anything.
The argument that “tools don’t make somebody good” is pretty silly. They absolutely do.
> The argument that “tools don’t make somebody good” is pretty silly. They absolutely do.
I disagree, but only because I'd rephrase what you're saying as "good tools are force multipliers for skilled people". You can give a beginner musician the most expensive guitar rig, and they'll still sound like a beginner.
I also never said what you're arguing against. The GP was essentially complaining that using vscode would hamstring their career because their skill would be in something Microsoft could take away. What I was trying to say is the reason programmers get paid isn't because they're good at using their IDE, it's because they're good at programming. I believe the GP's concern is misplaced.
Consider: Do you go to a restaurant because their chef uses expensive high-end knives, or because they have good food?
i wrote one of those comments specifically in response to your comment, in order to correct your misreading of mine, so you really have no excuse whatsoever for not having read it
much of what you learn programming in an ide is how to program, but some of it is how to use the ide, and it's common for programmers to keep using the same ide for decades as a result
i still have some keybindings in emacs from when i used visual c++ last millennium, and i'm probably using emacs in significant part because i started using lugaru epsilon in about 01989. since then i've also used vi, vim, idea, eclipse, nedit, and the f83 editor, but i keep ending up back in emacs sort of by default. and i think my level of flexibility on this count is far above average
Famous guitarists mostly only play specific expensive brands because they are endorsed by them. Any professional musician can make the cheapest of instruments sound really good. Maybe a note is missed here or there and the sound is not as good as it could be but it will still be way way better than an average player.
Here is Satriani playing on a terribly setup guitar [1] His only comment at the end? Oh, that was a little painful.
There's nothing wrong with having a favorite. That's not the same as only being able to use that specific brand. A good guitarist can play any good instrument well, just as a good developer should be able to write good software in an IDE that isn't their preferred one. The favorite tool just makes them a bit better; it isn't required to do the job.
> Is that why famous guitarists play only on specific expensive brands...
But that isn't true. Lots of famous guitarists play, and love, the cheap guitar they had before they made it big. Yeah they own lots of expensive guitars (because they like collecting guitars and are rich enough to do it). But they don't only play those.
Although it is an interesting thought experiment, to a certain degree, I don't think it's right to compare musical instruments and IDEs.
IDEs are usually far more complex due to their vast feature sets and constant evolution. If guitars evolved and increased in complexity at the same rate as IDEs, we would've seen something absurd like James Hetfield wielding a 150-string monster guitar.
IDEs have become incredibly complex tools with features that go far beyond the original concept of text editing, while guitars have remained relatively consistent in their core design and function over decades.
We don't have to keep practicing typing "the quick brown fox jumped over the lazy dog" over and over again to master an IDE, while you have to play same tunes again and again to become a virtuoso. Experienced musicians often have a broader, more adaptable skill set and can change instruments, while IDE users might be more "locked in" to their preferred environment for various reasons.
I agree with your sentiment though - good programmers are good not because they've mastered their tools - they chose to master their tools because they are good programmers.
almost all pianos have more strings than that; the bottom octave or so have two strings each and the rest of the keys have three strings each, for a total of somewhere around 250 strings. pipe organs are routinely significantly more complex than that. but a lot of the elaboration in musical instruments doesn't take the form of increasing the number of parts; instead we have things like special varnishes, holes cut in particular shapes, special alloys for strings, tweaked electronic circuit designs, tweaked magnetic pickup designs, etc. i'm not sure it would be easier for a random person to learn how to make a stratocaster-competitive electric guitar than it would be for them to learn how to write an emacs-competitive ide
Okay, yeah, I see where you're going with this. I guess, you can compare IDEs and musical instruments, in many aspects, there's more overlap in two areas.
For famous guitar players: they play guitars that pay them (endorsements). They basically don't need to buy anything because guitar brands will offer them customized instruments. It has nothing to do with how much these guitar cost.
Your skills as a developer are never dependent on the tools, APIs or platforms you use. You can always abstract over that. But yes, effectively using your skills will always be somewhat dependent on some company's goodwill. If a product, platform or feature you use goes away, you need to switch. That doesn't only happen for development IDEs. It's a process of learning that happens (or should happen) continuously in any line of work, and especially in software development.
As a developer you should already be used to having to switch stuff to something else. Going from DX12 to Vulcan, from x86 to RISC-V, from Linux to FreeBSD, from XCode to EMACS, from Perl to Python, from Angular to Flask, whatever.
inevitably some of your learning efforts are sunk into the tools, apis, and platforms you use. those can compound over time, making you more effective for the rest of your life, or simply be a pleasant memory. spending time on tools, apis, and platforms that are not dependent on some company's goodwill is helpful here; none of vulkan, x86, risc-v, linux, freebsd, emacs, perl, python, angular, or flask is dependent on any single company
(x86? yes, without amd, x86 would have died around 02000 like most other 80s architectures did, killed by intel's itanic blunder.)
in the 90s i invested time learning a lot of different tools and platforms. most of them are no longer useful to me because they were dependent on some company or other: vax, vax/vms, informix, netapp, mfc, sunos 4, purify, clearcase, pv-wave idl, erdas imagine, khoros cantata, irix, windows nt 3.51, cde. but, for the most part, those that were open standards (or, better still, free software) remain useful to me to this day: diff and patch, shellutils (now coreutils), tcp/ip, perl, netbsd, emacs, python, html, css, the i386 architecture, bash, vim, c, c++, sql, gcc, gdb, samba, ssh, postscript, tcl, tk, etc.
admittedly x.25, smtp, ftp, perl, tcl, twm, and fvwm are not as useful these days, and visual c++ and win32 are still somewhat useful. so it's not 100% black and white. but the longevity difference is extremely striking
You also have vscode. What you don’t have is the various proprietary extensions msft makes to vscode, just as you don’t have every proprietary extension anyone has ever made to those listed platforms.
> You also have vscode. What you don’t have is the various proprietary extensions msft makes…
i’m not trying to be confrontational i promise, but i mean, yeah, youre just repeating what we’re discussing…
microsoft bangs its drums chanting “please like us again, look at how open source we are. we’re not the same abusive company we used to be… we’ve changed, really.”
to many of us, the extension ecosystem is the biggest thing separating code from other IDEs in the first place.
this is just more abusive tactics from a company with very very long history of abuse, only this time they try to hide it behind empty “open source community, look how much we love you” rhetoric.
i’ve always recommended to organizations to run fast and far from ms products. basically “if you’re looking at a long timescale, you want agility, you want to be able to easily pivot in various other directions. if you use MS, you never know where they’re going to lock you down. run fast and far from them.” and this is just another example of why.
i think the commenter above nailed it perfectly with, “they keep telling us we should be grateful for microsoft blankets infected with the smallpox.”
Software engineers have to be the most melodramatic lot in existence. Microsoft: you can use this product for your development work freely, but we have licensing in place that prevents redistribution that cuts out our core product offering because let’s be real here this is really expensive to develop and both us and our employees have bills to pay just like anyone else.
Internet personalities: the closest thing I might compare this to is the deliberate proliferation of smallpox and the resulting deaths of hundreds of thousands of native americans. (a story which, ironically, turns out to be almost entirely fabricated to spread FUD about the us government… https://allthatsinteresting.com/smallpox-blankets)
> let’s be real here this is really expensive to develop and both us and our employees have bills to pay just like anyone else
Couldn't put it better. FOSS advocates want everything for free and source code released every time, all the time. Who's paying the bills? The rent? The mortgage?
To be precise, the system sucks, but we have to work within it, and that means profit-driven companies which pay employees liveable salaries so said employees can buy the food and shelter they need to experience a decent life.
I'll bet that 95% of FOSS developers either contribute as part their full-time job, or already have full-time jobs with the salary and flexibility that allows them to also contribute to FOSS projects in their free time. Not everyone has this luxury.
i don't care. if you don't want to write free software, that's fine with me. but don't piss on my shoes and tell me it's raining, and don't offer me a gift and then demand payment
> but don't piss on my shoes and tell me it's raining, and don't tell me it's a gift and then demand payment
Who's doing this? VS Code is free; Pylance is free, cppdbg is free, the C# suite is free. However the licences are clear; these extensions are closed source.
VS Code's core editor functionality (Monaco, LSP, DAP, etc) is fully open, and has been regularly repurposed and re-branded by several other companies. I sincerely don't see the problem. If someone else wants to write their own extensions, they are free to; these extensions are Microsoft's IP and hence Microsoft is free to do what it wants with its IP.
The disingenuity is what you are condoning. The repo is superficially organized to appear open-source but is actually a minefield.
Github will sometimes say "found other licenses"; the best Github can do is to "report" on the state of a repository; it's up to the community to decide on stricter tolerances for declaring something to be open-source, because as we see here, even a major corporation is willing to engage in subterfuge/exploitation.
Saying something is "open source" provides material benefit: it creates attention, it attracts users, it creates community. Shouldn't a project be fully in-the-spirit of open source to benefit?
There's plenty of case law around the word "free"; it's just too early for the phrase "open source" to have settled case law.
(assuming you haven’t somehow looked at a block of legal text, disregarded the opening paragraph, and assumed the rest of it somehow is to be interpreted in isolation?)
> Internet personalities: the closest thing I might compare this to is the deliberate proliferation of smallpox and the resulting deaths of hundreds of thousands of native americans. (a story which, ironically, turns out to be almost entirely fabricated to spread FUD about the us government
Hmm? I mean maybe some people believe this, but I have never heard of anyone thinking the epidemic that affected hundreds of thousands of Natives was caused by blankets. The Natives I know are well aware that it was a specific event and most Smallpox infections were caused by general contact with Europeans.
In fact, the commenter doesn't even do this, they just referenced the siege and then YOU conflated it with hundreds of thousands of deaths. Officials did intentionally infect Natives and the article confirms that, so I don't think merely referencing that fact is spreading a myth?
I didn't read the article but I could absolutely see MS doing something shady to promote their AI racket: beginning next year, VSCode Basic edition will remain free, but to use Premium AI Cloud additions will cost just $6/month for a basic plan. (Then shoehorn intellisense and a bunch of other features that used to work fine into the "AI" paywall, because it's 2024 and words don't mean anything anymore).
Or more likely, "the free version will now contain ads and mandatory telemetry, pay to upgrade to premium for a more streamlined experience". Just like the Mafia, create the problem then sell your their solution.
Their business model being bad is not my concern. They're not a broke kid whose bad decisions I'm exploiting.
Edit: OTOH reporting on this as if it's a grand surprise is a bit funny. Like come on, this was obvious from the start. I just didn't care, it didn't feel like a fight worth fighting. And I care about BSD/MIT license devs being exploited about as much as MS' business model potentially falling apart because I turn off telemetry: folks knew what they're going into, and did it anyway because "sempai corpo will notice us." Well, it did, congratulations.
As for me, I don't care. I ain't posting anything on anything lighter than AGPL, ever, but I'm a small bean and ultimately there's stuff I care about way more than software.
Their business model is fine, and telemetry has nothing to do with it. The telemetry aspect of the article is a red herring the author introduced seemingly to elicit more popular support on their website and others like it. The core issue has nothing to to with telemetry and everything to do with licensing and intellectual property.
It sounds like MS is making a better cpptools/C++ extension mouse trap and it's impossible to build a fully OSS version because many of the MS components are closed? And when a user discovers he/she can't use their native extensions from any web interface, this is a problem for the web interface guys? I have to ask -- if people want to use this freeware instead of OSS software, it might be disappointing, but is that really a problem?
If there is an answer, it would seem to be more information about who is to blame. Perhaps open source vendors should be more clear that their offerings are also open source and open ecosystem? Perhaps that would tip off devs that not every extension is, that is -- the MS alternative extension is not.
One could even be more forceful:
"Certain alternatives, like vscode-cpptools, are NOT licensed under an OSI approved license. vscode-cpptools contains many unexamined binary blob components. Developers of blah blah blah C++ extension strongly believe in an open ecosystem for VSCode extensions, but MS has also refused to allow redistribution of vscode-cpptools, if used by native open source builds or by those offering VSCode via web services. Developers of blah blah blah believe, whether the code is closed or open source, ALL VSCode extensions should be freely redistributable for the good of the broader VSCode extension ecosystem."
If major extension projects are aligned, they could simply add a notice like above to their description on their marketplace page? Trust me, legally, culturally, MS really, really doesn't want to deny access to its marketplace, because a few OSS projects wanted to offer a comparison of their license terms to those of MS.
Apple is currently dealing with a marketplace lawsuit. MS doesn't want a marketplace or another antitrust suit.
Here's a simple example: you write an API consisting of one public function. You compile the API into a binary with a closed source license.
You then create another API with one public function. This function is an extern call into the library binary.
You publish the second API into Github with an MIT license and proclaim your API is open-source.
The broad theme is: if 100% of the functionality of the software is inside a closed-source compiled binary, should it be false advertisement to say it is "open source." Or in other words, who draws the line when someone oversteps the intent of "open-source" for exploitative reasons.
I don't know if cpptools' functionality is 100% closed; in reality there are three other licenses you must agree-to within a repository that is supposedly MIT licensed.
> The broad theme is: if 100% of the functionality of the software is inside a closed-source compiled binary, should it be false advertisement to say it is "open source."
I get it. I disagree that it's false advertising, though I do agree it could be scummy. For instance, if MS created a combination package, licensed that package as MIT, whereas the important bits were proprietary.
Maybe any conflation of licenses have since been scrubbed from the marketplace, but from what I see on their license pages right now, I'm not sure MS's behavior rises to scummy. The Python package makes pretty clear it includes pylance, and pylance makes clear it's not MIT licensed.
> I don't know if cpptools' functionality is 100% closed; in reality there are three other licenses you must agree-to within a repository that is supposedly MIT licensed.
It should be well known by now vscode-cpptools and vscode-python are partially closed, which is good enough as closed, which is good enough as BSL, etc. If it's not clear, then that's a failure of the open source community and alternatives to make it clear. The license links seem pretty clear to me. Perhaps it would be better if the situation were made even clearer, like a badge for OSI licensed packages, but it's not yours or my store.
My God's honest feeling is transparency and building better stuff is really the only remedy. You either believe in the FOSS development model or you don't. You either have a strong open source language community or you don't. If the C++ or Python OSS people can't muster an alternative, it's not MS's fault for building a better mouse trap which only works with MS products.
There is this overwhelming desire in FOSS communities to works the refs, or even FUD wrong-thinking projects, instead of saying: "They have a development model and so do we. We believe ours is better." Python, in particular, has so much interesting language server stuff going on in Rust (see Ruff and pylyzer). Re: C++, clangd is apparently very good too. It stinks for the ecosystem that MS has acted this way, but I think one just needs to very clear about whose fault it is when something breaks, or when someone can't use an MS extension, because it's obviously MS's fault.
It takes a LOT of reading to find out what the actual point is here, and the concept of a “fractured” “ecosystem” is brought up a dozen times without being explained. A “venus fly trap that is designed to fracture”? What in the heck.
VS Code is an IDE you can download and use for free from Microsoft. It’s not some magical open-source platform/ecosystem thing that anyone can use for anything, which Microsoft has no control over. It’s a product.
It seems like everyone wants to make “universal” developer _services_, but no one wants to build or fund an IDE, or it’s just too hard or something. That’s not Microsoft’s fault.
Not going to defend Microsoft but they provided a massive codebase for free and yeah they have built a product on top, that is mostly free. If you fork you just don't have access to MS servers. Not fair enough?
Also Monaco is the best editor by a thousand miles, front-ends are just using this editor because it's the best. We used to install CodeMirror or Ace when they were the best options.
I'm not sure there was a massive master plan behind the creation of Monaco, on the contrary, they saw an opportunity to make it a standalone project that unlocked countless of web UI.
> The future of software development tooling that is being built is closed as fuck, and people seem to be okay with it because select components meet the OSI definition while missing the bigger picture.
This is such a huge problem and something that I have regularly commented on on Hacker News itself how the open source term is being applied so loosely especially by a bunch of VC funded companies who are further perpetrating this horrible horrible change in language and meaning and the ethos behind the open source movement.
YC itself is funding a bunch of these companies who claim to be open source but do not follow the ethos at all.
The problem is not companies doing this but users and developers not caring or sharing your concerns. All this moralism about ethos and such is just not that relevant.
What matters is that software licenses are legal text documents. The only place where the interpretation of those texts matters is in a court room. I don't think there are a lot of court cases involving VS Code. MS tends to have their house in order on that front.
So, VS Code seems safe enough in the legal sense. Yes, it has some extensions that are not licensed as OSS or that are simply closed source. So what? If that bothers you, don't use those. Or better, fix it by creating some open source. Open source is not a right, it's a privilege that is granted to you at the discretion of the creators of that software. Not something that you can demand from them.
VS Code is a closed source product that includes lots of OSS components. So much that there's VS Codium a well, which is fully OSS. A lot of those OSS components are used in other products as well. And some of those things are fully open source. The value of the VS code ecosystem is that it enables this ecosystem of components and products to thrive.
True, slap a price on it. I'm sure people here get enough utility out of VSCode to pay for it.
The problem is when the free offering is actually designed to ensnare you in a tarpit of legal liability and uncapped financial liability. Especially with a service like VSCode where it's not a single purchase and you rely on Microsoft indefinitely (through extensions and updates). But it's designed that way. There's no other option. They chose to not make it simple to avoid a single clean payment, and extract longer term money of ambiguous amount based on user resistance.
I paid for jetbrains stuff for many years because it was worth it. And compared to eclipses features et it was leagues above.
That's worth money.
Like I always say about open source. I'm skeptical about adapting frameworks without big money behind them... Because relying on the whims of random internet amazing engineer is a risk.
MS will make money on vscode. Just like Google makes money on Chrome. Just not directly.
A marvel of engineering, really? In find using bloated browser tech and napkin-designed language to build a barely functional IDE as "impressive" as building a mile-long pedestrian bridge using Popsicle sticks and chewing gum.
To be fair, a (stable, used by many for many years) mile-long pedestrian bridge constructed out of popsicle sticks and chewing gum would be a fairly impressive feat.
I'll take browser tech + JS based IDE over a streamlined ASM based one that updates at a glacial pace any day. Which is why there aren't really any other great options, traditional IDEs can't keep up. Even MS' own original visual studio product - there's no point to it anymore.
What is the nature up these updates you're speaking of? The core of the IDE is the editor and a plugin system. Editors are pretty much a solved problem, some people still swear by 40 year old vi and that doesn't seem to make them less employable. Drawing to a GUI instead of a console isn't much of a challenge nowadays either. Whatever updates are required will be for the plugins, and that's not technology specific; Delphi (25+ years ago!), Eclipse and IntelliJ all have that. Visual Studio or XCode painting themselves in a corner by being so rigid is no excuse for using the mushiest language to control the most abstracted platform to design a new IDE.
I think OSS is great, but it's not why I use VS Code. I use it because it solved my problem of having a capable editor that is not a monstrosity (e.g. Eclipse etc). There are others in this space, I guess most famously Sublime, but VS Code always felt the least in the way. There was Adobe Brackets before it that was similar, but somehow very slow and buggy.
The article makes valid points, if you are an OSS enthusiast. But at the end of the day, you always have the source code and you can always run your marketplace. This costs time and money, but if you believe in the idea you have to invest something and not depend on a mega corporation. If there are proprietary extensions that you can't have that sucks, but again someone can build an OSS one.
But overall I agree with the article, I just have no illusions they are doing anything out of belief in open source, and I'm fine with it because worst case I have other options.
When reading the article, I remembered the joke about a radiologist looking at the patient's CT and going: "Ooooh, this is good! And this is so good! Just perfect!" while the patient is in the room. The patient: "But, doctor, I don't feel good at all!" To which the radiologist answers: "It's soooo good none of these are my problems!"
I don't use VSCode and never will. It's just an awful editor, regardless of who's peddling it. None of the things that are important to me are controlled or somehow touched by Microsoft.
But, I'm undecided about what's the right thing to do here: if I dislike both Microsoft and VSCode being, essentially, a closed-source product sprinkled with open-source, do I side with people who want this piece of junk and fight to make it truly open-source or wait to see it inevitably die a fiery death?
I think DoomEmacs is worth a recommendation as an add on to what you’re saying. As it’s basically “slow” nvim with all batteries included + Org mode.
It’s was a very easy switch for me from VScode at least, and while I called it “slow” that is because nvim is ridiculously fast. DoomEmacs performance is still great, for the most part.
yeah I agree I think most devs that has used one of these distributions would be hard pressed to go back to vscode if they care about their IDE/text editor being open source - not to mention it can be a lot of fun extending them in ways that are personal to your workflow. Complaining about a massive corporate entity being self serving is kind of missing the hills for the trees.
The clearest way to understand it is that VS Code is open core software.
There's actually a lot in that core, especially when you compare it to other open core products (ex. Gitlab). Enough that you can fork it and have a viable MVP for your own IDE (as Cursor, Gitpod, and many others have done)
But you shouldn't ever be under the impression that you fork will be identical to VS Code.
Frankly I think developers have benefited a lot from this. There's actually a strong foundation for others to innovate on their own IDEs without sinking years into basic R&D, and it's much better than the alternative era when ~all the user-friendly IDEs were proprietary.
IntelliJ has been open source (or open core if you like) for many years now, I think even pre-dating VS Code. So the idea that it's the first or only IDE that works this way is wrong.
Everybody can do that themselves, if the original maintainers don't want to (which is a security problem ;):
If you are not the author, we suggest you first reach out to the author with an issue in their GitHub repo to request that they publish their extension to open-vsx.org. We've drafted a template with suggested content for the issue.
Encourage you to look at the bigger picture. What happens when there’s an official extension by a 3rd party vendor SDK that defines a dependency on the proprietary language server/extension.
It’ll work fine for “Visual Studio Code” but all these OSS forks (inc recent venture capital funding for AI ones) gets wrecked.
It turns into a game of having to iterate through the graph and trying to convince official SDKs to change their product direction.
I'm going to get downvoted, but no one is making you use VSCode or Chrome/Chromium. I came across a post here that was like "I use Chromium, I ethically can not use Chrome." Firefox is right there, if you want an to support a different browser.
Zed exists, it's new but it's already a very good IDE. I tested it with Unity and the C# support is fantastic.
20 years ago the notion Microsoft would develop dev tools for Mac and desktop Linux would be absurd. Now you're mad you can't just fork VS Code, sprinkle some tweaks on it and create a business around that ?
> Zed exists, it's new but it's already a very good IDE.
An IDE needs at least a working Debugger (or, to be more precise, a graphical interface to debugger(s)).
And Zed has exactly the same problems VS Code has, minus actually contributing LSP and DAP (Debug Adapter Protocol) to "the editor community". So, Zed is actually worse in that regard.
> An IDE needs at least a working Debugger (or, to be more precise, a graphical interface to debugger(s)).
For me that should read at _last_ (or not at all).
While almost any IDE I ever used had a debugger (starting woth Borland Turbo C++) the number of times I used one I can count on both hands. And even then, a CLI to the debugger is just fine.
Like with any feature an IDE may offer, there are people for which that very one is essential.
Fair enough; but don't assume your non-negotiable X is the same for every other user of an IDE. It is not.
I'm sorry, but what _is_ the difference between an editor and an IDE for _you_?
Btw. I'm not saying that having an integrated debugger is a sufficient condition for an editor to be an IDE (VS Code isn't, Sublime Text isn't, other editors with DAP support aren't).
> but don't assume your non-negotiable X is the same for every other user of an IDE. It is not.
But _you_ not needing a debugger in an IDE is a reason something is an IDE without one, I see. Btw. I'm (normally) not using IDEs.
Wikipedia[1] says an "IDE normally consists of at least a source-code editor, build automation tools, and a debugger". Not that is says "normally", not "definitely".
And in the next paragraph the "definition" encompassing a continuum of features and not a definite set is further clarified.
My point was that "X is missing" => "this is not an IDE" is not true for this reason.
> I'm sorry, but what _is_ the difference between an editor and an IDE for _you_?
For me an IDE "knows" about other files I have open and their relationship with the one I'm editing (usually a "project") and it _i_ntegrates external tools/programs.
An editor does not. It just lets me edit a file. Maybe it has syntax highlighting or folding but everything it offers is based on that file. A good example is SciTE which was my go-to for years.
In an editor you can't right click on some type in the current file and choose "Go to definition" if that definition is another file.
Of course there is a continuum. For example, running an external command is something many editors offer. And if your file is of a certain type they may even guess what the (build) command may be.
When you have non-local (=outside the file you're editing) functionality and some integration with external tools I'd wager you're using an IDE of some sort.
Then you can argue if that IDE ticks enough of those boxes defining your needs, fair enough. But you can't say something isn't an IDE because it is not an IDE for you. ;)
P.S. non-negotiables for me are mostly around that VCS integration. But I acknowledge that other people may not have this need (are fine using the command line for this only). But that only means I would not use an IDE that lacks those; I would not therefore say it isn't an IDE.
> For me an IDE "knows" about other files I have open and their relationship with the one I'm editing (usually a "project") and it _i_ntegrates external tools/programs.
With that definition any usable editor and vim-likes ;) is an IDE. I can live with that (that Zed is an editor comparable to them) too.
A few weeks ago I switched to Cursor. Everything seems to work unchanged -- all my extensions, the marketplace etc. That seems to contradict various things in this article, for example the claim that certain programming languages couldn't have the standard extension support in forks.
I think the level of alarmism is way overblown especially from the author’s perspective coming from Gitpod.
There’s so much focus on how Microsoft has this huge advantage with VSCode and GitHub Codespaces as a cohesive product.
But I think that this entire cloud coding workstation space is rather niche in itself.
I think the average user of VSCode, VSCodium, or whatever other fork has full flexibility to not use Microsoft’s preferred extensions and solutions and customize their environment.
All this stuff about fracturing an ecosystem basically amounts to picking default extensions and I just don’t know if this is one of those “abuse of market power” things yet.
I mean, sure, it can be said that it’s bad how Microsoft is so large that it can single-handedly steer the course of a lot of development trends.
At the same time, I don’t think VSCode being such a good product was something that came out of Microsoft’s dominance. They had a lot of luck with that one, they had the right idea, people, and management at the right time. Microsoft makes plenty of software where their big company big dollar investment hasn’t made them a market leader and they have a laundry list of failures and technologies that are trending downward to show for it.
I would agree with another comment on this thread: it really does seem like a bunch of complaining from some cloud workspace competitors who want to get a free IDE for themselves that works perfectly.
But you can sell Vscode if you want? Fork it like VSCodium and sell vsmoneycode. You can't sell all the addons, but this is a business model heaps of people use (open product, closed modules/addons)
>But you can sell Vscode if you want? -> yes you technically can but in practice it's almost impossible to be competitive, since for several major languages the best extension isn't open source. Author called it a "fracture".
Kdenlive isn’t better than DaVinci Resolve/Adobe Premiere/Final Cut Pro.
Heck, a whole lot of I know consider IntelliJ a whole lot better than VSCode.
Open source isn’t really guaranteed to compete with proprietary software and often doesn’t.
The author calls that fracture, but to me an open source product with extensions will logically have both proprietary paid extensions and open source extensions, just like there are vendors who sell closed-source software for Linux.
If I sell my proprietary application for Linux and I only distribute it for Ubuntu, that doesn’t make Linux “not really open source.”
In my opinion that is normal and expected and isn’t cause for alarm.
No, it isn't true for most software. Firefox and Chrome are better than MSIE or Spyglass Mosaic. TCP/IP is better than CompuServe, AOL, and X.25. Apache and nginx are better than IIS. Perl, Python, and JS are better than PowerBuilder and Visual Basic. GCC is better than Borland C++ and various Unix-vendor C compilers. Even today, GCC is an enormously better C compiler than Visual Studio's, although at least Visual Studio does have a competitive C++ compiler in it. Arduino is better, for most purposes, than various proprietary embedded-vendor IDEs, which themselves mostly use GCC. Linux is better than Unicos, Solaris, and Symbian, though iOS and Microsoft Windows are still competitive.
Open-source software has pretty comprehensively replaced proprietary software throughout the computing stack over the last 30 years mostly by being vastly better. Proprietary software is holding onto footholds in a few places, most of which you listed.
The general strategy for preventing the situation where "an open source product with extensions will logically have both proprietary paid extensions and open source extensions" is copyleft licenses such as the GNU GPL.
Fundamentally, this mindset and flaw in the definition is why open source can't prevail. Because open source is absolutely committed to being unsustainable.
You miss the point. "Open source is not a business model" but also the OSI has made it increasingly clear it doesn't want it to even be possible to make a business model on top of open source software.
That means companies will be, regardless of the desire otherwise, forced into proprietary models, and proprietary development will continue to be the most effective way to put food on the table.
Open source will forever be a niche volunteer thing plus some predatory abuse by monopolies because the OSI is not interested in open source being the default way to make software.
>the OSI has made it increasingly clear it doesn't want it to even be possible to make a business model on top of open source
The OSI's definition of open source was worked out in the 1990s and has changed almost not at all. That stability in the meaning of "open source" (or "OSI-approved", if you want to be precise) is a good thing. If you want to experiment with software licenses that (like open source) don't lock the user in or that (like open source) allow forking, but that are better than open source at allowing the maintainer to earn money, then please do -- just don't call your experiment open source. Coin another term.
It is not some awful tragedy that those who want to experiment with software licenses cannot use the reputation of the "open source" label to market their offerings.
Parenthetically, "nice volunteer thing" is not an accurate description of AOSP, Chromium, Firefox and most Linux desktop software.
All exploitative projects entirely funded and mostly operated by a monopoly found violating the law or awaiting judgment for such in almost every single first world jurisdiction.
Also neither AOSP nor Chromium are used in the real world in practice, over 99.99% of users use proprietary forks.
In other words, thank you for supporting my statement entirely.
>Also neither AOSP nor Chromium are used in the real world in practice, over 99.99% of users use proprietary forks.
I didn't think it needed spelling out, but OK: GrapheneOS would not exist if AOSP didn't have an open-source license. Electron, Microsoft Edge and Brave browser wouldn't exist if Chromium hadn't been released on open-source terms.
Surely it is not your claim that because Google has done bad things, nothing that Google has ever done has ever been positive?
Going back to your previous comment, where you write, "the OSI is not interested in open source being the default way to make software."
Do you actually believe that if the OSI had been smarter or more ethical or had listened to your advice (sent back in time perhaps) then open source might have become the default way to make software?
I consider it obvious that that was never a possibility.
OK, my previous comment was clumsy (and I concede that most of the software on the machine I'm using to write this is open source). What I meant to do with my previous comment was point out that my interlocutor seems to believe that the situation in software is just terrible, which implies that if things had gone different, it could be a lot better. But I'm not able to imagine a realistic evolution in which software ends up in a much better place than the current status quo.
it's been much worse in the past, so we know it can be much worse. probably at the time it was hard to imagine the evolution to where we are now, so maybe it can get much better too. certainly i had no idea 30 years ago where we'd be now
OK, then let's focus on the fact that my interlocutor seems to believe he can see how to make it much better than it is now, which is very different from its being possible, but none of us in this conversation can see how to do it with any confidence.
i think it's reasonable for him to try different things to try to make it better, but i share your lack of confidence in his proposed course of action, particularly since he seems to have such a hazy understanding of what has been tried already ;)
> GrapheneOS would not exist if AOSP didn't have an open-source license
First, Graphene OS is used by... less than 0.01% of Android users, so again, thank you for confirming my point. Furthermore, GrapheneOS is harmful for the ecosystem. Similar to VSCode, proprietary services are essentially gated out from alternatives to the default proprietary Android. And the big problem with Graphene and other AOSP forks, is they waste developer effort while protecting monopolies. Every developer-hour wasted on Graphene is a developer-hour not spent on a truly open mobile OS, and that's sad.
> Electron
We could live without it. Nobody needs a whole browser to ship a single page app. But also...
> Microsoft Edge and Brave browser wouldn't exist
So remember that whole part where I said 99.99% of use is the proprietary forks? Edge is, of course, completely proprietary. (Brave is just a cryptocurrency grift, will focus on Edge here.) Microsoft is a monopoly in several respects still, and Edge adds several anti-features like ads on the start page and shopping "features" which collect your shopping behavior. Furthermore, the switch to Chromium for Edge makes the Internet ecosystem worse. Because one of the largest independent web rendering engines disappeared overnight... further contributing to Google's monopoly stranglehold over the web ecosystem, and it's ability to essentially force standards bodies to comply with it's choices or become irrelevant.
> if the OSI had been smarter or more ethical
I think time travel conjecture is sort of pointless, obviously there are dozens of conditions on when good licenses got approved, what projects adopted them, etc. But if SSPL was approved, as the viral copyleft license it is, less open alternatives would evaporate overnight. Without the risk Amazon would lift your product, wrap it in a proprietary platform, and simultaneously undercut you on cost, I think at least for SaaS, there'd be very little reason for a business to launch without providing their code on fair terms.
All that being said, the discourse around the OSI and open source is toxic enough and compromised enough, I think shifting to new terms is ideal anyways. I saw https://fair.io/ "fair source" recently, which seems quite reasonable, though I'd love to also see an expression of it more focused around labor and sustainability in addition to just business case. Developers deserve to get paid for their work, and I feel the primary goal of open source at this point is to cultivate free labor for the tech monopolies backing the OSI.
the osi was founded by people who built their businesses on open-source software, with whom i talked about it in detail at the time. despite entrenched resistance from, among others, proprietary software vendors and the iranian government, open source became the default way to make software about ten years ago. in large part that's because it's much better at limiting predatory abuse from monopolies than proprietary software is, so large users commonly choose open-source software even when proprietary alternatives look better on paper
i think you're missing not only the point but actually reality as a whole
> But I think that this entire cloud coding workstation space is rather niche in itself.
It's common / popular in certain enterprise circles, for "security" and audit reasons. No admin or most permissions on your computer. You get a specific VM with "controls". Anything required might be installed on request.
A locked down cloud hosted IDE might just be 1000% easier.
Yup, same argument as Youtube. Also people suck at boycotting, if they don't like VSC don't use it...if they don't like ads on YT as a viewer then don't watch it. If they don't like ads on YT/lack of payment for content they make as a creator...don't use it! "There's no alternative" make one, or release content elsewhere (the path that Nebula, etc went down).
If you try to make a business building on top of it it’s a risk you are taking. Whether vscode was partially oss or fully closed seems like an inconsequential detail.
The headline of this is a bit counterintuitive: many people, when they see the word "fracture," might imagine an ecosystem in which different offerings can coexist. Someone not reading the full article might even think this implies that VS Code might even "break apart" into many open-source forks, which would be a good thing.
But the word "fracture" is very much meant in a different context here, in that Microsoft does not allow its proprietary extensions to VS Code to be used legally by any third-party fork, and thus can leverage the unique and unstandardized behavior of e.g. its closed-source Pylance Python language server to ensure that no fork can replicate the experience (glitches-as-features and all) that practically all users of VS Code will expect, thus giving forks a Sisyphean challenge to overcome.
https://visualstudiomagazine.com/articles/2021/11/05/vscode-... is linked in the OP and discusses the surprise the community felt when VS Code transitioned to Pylance. I'd venture to say that most users of VS Code have no idea how much of their Python editing experience is run by closed-source logic.
On one hand, it's a bit frustrating that many people, myself included, switched to VS Code from other IDEs because "if the community sees a problem, the community has the tools to fix it and will do so." But that ceases to be true when the bulk of the IDE's power comes from closed-source language servers that Microsoft could feature-freeze (or deallocate resources from them) at any time, and still have ~years before any community language server could begin to replicate all the edge-case behaviors of their closed-source extensions and gain notoriety as a better alternative to Microsoft's defaults.
Is this a bad status quo, though? Microsoft's invested incredible resources in a stellar user experience to date, and might not have done so if it didn't have this strategy in play - a strategy that ensures that no fork will ever be able to capture developer mindshare, and that ensures that the larger Microsoft ecosystem of services will never be disadvantaged or de-promoted by such a fork. As long as leadership desires to continue making this advantage larger and larger, and have Microsoft developers dogfood their own IDE, and thus continue to invest in their language servers, most users will benefit. And sure, some of us will need to keep typing "# type: ignore" into our codebases to work around a Pylance bug that nobody can see the code to submit a PR to fix... but we gain so much in return for that inflexibility. I'm more interested in how my IDE helps me to make my own visions into reality, than in the purity of whether it can truly be called "open source."
> the bulk of the IDE's power comes from closed-source language servers
Not sure that's so very true for most langs / stacks other than Python. Go LSP & vscode extension is Go-owned, C++ you have clang LSP+ext and can really skip MS' offering(s) there. TypeScript LSP+ext is most likely OSS (dunno) or else MS-owned anyway; dotnet same. Niche langs own their LSP+exts anyway. The builtin HTML / CSS stuff is bare-bones IIRC, if there aren't richer OSS alternatives out there yet there sooner-or-later will be. Python, I wouldn't know, but let's face it, if a lang is a big FOSS project it can and will mobilize their own owned and ever-more-excellent LSP + ext if and when necessary / desirable — and if it's niche and small-scale, MS won't anyway, proprietary or not.
In light of this post, and ignoring Sublime Text as I’ve tried it and don’t like it, what commercial IDEs are worth looking at for a generalist like me who bounces between C, Python, Terraform, YAML, Markdown, and more? I’m on Linux.
I was just looking at their products. Looks like IDEA is aimed at Java developers, but I assume that doesn’t prevent it being used for other languages?
Specifically you should look at the JetBrains All Products Pack. That's what I have and I've used Pycharm, CLion, Datagrip and Rider extensively. I love being able to switch languages without having to learn a new interface, keyboard shortcuts, etc. You get a nice JetBrains Toolbox app to manage all your IDEs.
Agreed. The price between just IDEA and the all products pack is not terribly different and I enjoy using IDEA and Datagrip. I've also played with a few other of their IDEs and it's nice to not have to learn anything new. That said, I do 99% of my work in IDEA since it can do pretty much everything.
My only major complaint about JetBrains is that they make me switch programs when switching languages. I have a license for CLion and PyCharm Pro, and while they're both great, the fact that I cannot 'import' all the features from one into the other is quite infuriating.
That's what I do. I can program my Go, Python, Java, and JavaScript projects all within IDEA Ultimate by just installing the extension from the marketplace. The only exceptions are C/C++ and Rust that 'require' a different IDE or paid extension and don't work in IDEA Ultimate for whatever reason.
> The source code has been released by Microsoft under the open-source MIT license, but the product available for download (Visual Studio Code) is licensed under this proprietary license.
I used to consider releasing software under the MIT license to be more generous since there are no conditions other than attribution. However by now I can see that releasing under a copyleft is actually more generous than a permissive license since the copyleft conditions also binds the author of the software to continue releasing their code under an open-source license. Turns out Richard Stallman was right after all.
The author of software (or generally the copyright holder) is not bound by the terms of their own license, so they can publish the same software and/or later versions under different licenses however they see fit.
This applies equally if their own license is MIT or if it's GPL/copyleft.
(From that point of view, Microsoft would be able to release VSCode as GPL while also shipping binaries under a proprietary license, if they wanted to.)
Things get more complicated when they aren't really the authors because they have merged contributions from other authors, e.g. pull requests. Then what happens depends on the license used by the other authors for their contributions. Sometimes the contribution's license is implied, or legally unclear. To avoid problems, some diligent organisations require contributors to sign or confirm something to make it clearer, before they accept contributions to be merged.
In understand that, but if people license their work under an MIT license then there is nothing impeding whoever manages the repository to slap a new license on the code even if people already contributed to it.
> To avoid problems, some diligent organisations require contributors to sign or confirm something to make it clearer, before they accept contributions to be merged.
That's a very generous way of saying they're having people sign away their rights under a copy-left license.
Do you guys think Microsoft is pissed that Cursor exists? Do you think there are internal execs raging about the decision to open source VS Code because of it?
I can give you one data point. There is no way in hell my company would let us use cursor. Generative AI is viewed with a lot of skepticism, and we spent a long time testing out copilot before approving it for all developers to use. We use copilot because microsoft is so trusted and we use many microsoft products
They're probably asking themselves how Meta/Facebook is able to misappropriate "Open Source" to mean something completely different, and how they can do so themselves now while still showing "Microsoft <3 Open Source" ads.
People when a piece of software is source-available but not strictly OSS: outrage
People when Microsoft pulls this trick (core repo OSS, most useful things around it are full of DRM and legal traps): silence
The hypocrisy is really astounding and in a way, MS has managed to pacify even the strongest FOSS advocates by offering something which looks like OSS but it actually isn't. This is on par with claiming that a repo is GPL but the build API keys are not. (Yes, this also happened elsewhere, and not even in a corporate project at all!)
The Open Source Definition is hilariously unfit for purpose in 2024 because it allows shenanigans like this.
The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension.
This is very clearly malicious.
"Source-available but not strictly OSS" is, in most cases, not really giving anything of value to the community. You are not free to use it in building your own solutions. At best, it allows easier collaboration with customers.
Open core absolutely is open source. There's a clear and valuable open source core that others can build on to build their own products.
This isn't just hypothetical. As far as I know, no source-available license allows you to actually use it to build your own product. While VS Code has many other products built on the core (including products that lawyers have reviewed closely for compliance).
A program that allows me to freely use and modify it as long as I’m not a multi-billion-dollar corporation is much more useful to me than a program which allows anyone to use and modify a part of it.
> Open core absolutely is open source. There's a clear and valuable open source core that others can build on to build their own products.
Depending on where the line is drawn. How functional the "core" in a real life scenario is. Often companies use some "enterprise security" features as closed thing, like saml/oauth/... where one could argue those should be default state of things these days.
For example, if the copyright holder applies a security fix to an old version that had "expired" and is now open source, will that cause old version to revert to source-available? Does any security fix, even the simplest one, require clean room reverse engineering on part of the community? Unless these questions are answered clearly by the copyright holder, BUSL/FSL are not really usable as open source even after the expiration date.
> For example, if the copyright holder applies a security fix to an old version that had "expired" and is now open source, will that cause old version to revert to source-available?
Yeah, it’s tricky. By default, I think it does go back to source-available, but I would trust the vendor to explicitly release the fix as open source instead. Of course, it should be addressed in future versions of such licenses, and in the meanwhile vendors should promise to not hold security updates out.
It’s not something exclusive to delayed licenses though: vendor of a permissively licensed software can make a security fix under a proprietary license. They don’t do this because it would be a dick move and the community will fork the software, but this is a possibility.
The funny thing is that I’ll never understand why it’s not open source and why its license prohibits its use in VSCodium. Pylance is good, but not that good. Certainly not on a level of PyCharm. What incentive do they have to keep it secret except being evil?
VSCode is build to sell Azure and other Microsoft services, which they won’t if you use VSCodium. To a lot of people this will probably be less obvious than it is to anyone working in a Microsoft heavy enterprise organisation. The VSCode extensions integrate incredibly well with the Microsoft infrastructure you already have when you’re tied into Azure and the Microsoft AI services. It also ties in rather well with both Azure DevOps and GitHub, which are other services you’re then likely to purchase.
I don’t mean this as a negative thing as such. It’s just Microsoft being better at selling products to enterprise organisations than anyone else. One of the reasons Azure has grown from around 10% to 25% of the global market share during the previous past 5-10 years while AWS has actually lost its position is simply sales. When AWS first entered Europe they were a lot like Google Cloud, in that even if you were a municipality you would end up in an automated support loop. Then Azure came along and sold the same Microsoft support as they’ve always done, which is basically the best IT business partner you can have as an enterprise organisation, and naturally they won. It’s not like Amazon didn’t notice, a few months after Azure really rolled out we suddenly had an AWS account manager and direct phone support. But by then the ship had sort of sailed because of how Microsoft simply offers great value. Teams is another good example, it was a worse communications platform than what we had at the time, but it was “free” because it was attached to every user license we had, including the cheap educational ones. Almost nobody in non-tech enterprise will spend money on something they get for free, even if the free product takes years to become as good.
VSCode is the same. We pay for co-pilot and we pay for a lot of the Azure integrations, because why wouldn’t we? In the giant IT budget heading to Microsoft they are tiny costs which are in the “services” category in the excel sheet that heads for the budget. It is tiny, but when you consider just how many EU enterprise organisations buy these services it’ll amount to millions and for some services billions of revenue for Microsoft.
A good way to think of the “new” Microsoft strategy is similar to how cartoons are used to sell toys. You can watch Lego Dreamzzz for free on YouTube because Lego knows it means a lot of people are going to buy their Dreamzzz sets. It’s the same thing with VSCode. On top of that, they’re winning the familiarity game. When you hire a new developer, they’ll want to use what they know, which for many people is VSCode.
Agree with your post, but this gist still doesn´t make much sense to me:
> VSCode is build to sell Azure and other Microsoft services, which they won’t if you use VSCodium
If corporate has bought into MS, they will use Azure services anyway. So for MS it would not matter if vscodium also integrates well with Azure or has a good .net core debugger, their customers will still bring the whole IT budget to them.
Because you are spot on. Corporate buys the whole MS store, only walk the road that MS marketing has blessed and it happily walks into the Azure trap. They outsource IT strategy and planning to MS anyway, and MS names it "Azure".
I’m agree, but my organisation is an example of one which would be in the atlassian ecosystem if it wasn’t for the MS integrations. Which would honestly also be there from the Azure CLI but I’m the only one who uses that and no decision maker likes it. I’m not advocating for it since I personally dislike the atlassian ecosystem (shhhhh).
>What incentive do they have to keep it secret except being evil?
Money. Which is OK. Developers need salaries. They need to justify the department budget to bean counters and sales internally. The company you work for is most likely not a charity too.
If you want to strictly use free software (as I do), VsCodium is great for everything I need.
You can't use Gitpod, Theia IDE, etc with Pylance. Or GitHub Copilot. Or Live Share or numerous other VSCode extensions.
The idea is people start a project in VS Code, need to scale up to a reproducible dev environment for multiple users, and follow ads in VSCode to GitHub Codespaces, which charges by the hour for VMs. Now you're locked into that, you're locked into GitHub as well, and they can cross sell you GitHub Actions, GitHub Advanced Security &etc.
Therefore, Pyright is almost the minimum needed to add type checking to your CI process.
Edit: to clarify, not only is Codespaces advertised in VS Code, it also uses private APIs so no competitor can publish an extension which replicates this functionality on the VSCode marketplace.
Like I wrote here [0], corporate has an azure subscription. All the companies code repositories already live there, including build automation. A capable vscodium isn´t going to eat into Azure baseline.
I don´t think MS is after solo hobby devs. For startups they have other incentives to lure them into their ecosystem, like free Azure credits.
And that is why open source projects on github are free too. Because the paying organizations depend on the free software ecosystem, build by volunteers in their free time. MS wants control [1] about that nonetheless, because not having that is a risk to their baseline
1. That is not necessarily harming libre software per se, but keep in mind that MS is only interested into OSS as long as their commercial customers depend on it.
They make money with VsCode (by forced, or at least hard to disable, telemetry, ads [1], and probably many other subtle things. Plenty of ways to monetize developer eyeballs). Pylance is just a vehicle to encourage people to use proprietary VsCode instead of open forks like VsCodium.
> The funny thing is that I’ll never understand why it’s not open source and why its license prohibits its use in VSCodium.
And also the fact that Pyright, the underlying library that powers Pylance, is open source. Microsoft even has a mostly workable demo extension built from it, which is fully open source, published in their marketplace, and receives regular updates.
Source Available is fine by me so long as it isn't being misrepresented as Open Source in an attempt to sponge off of the goodwill generated by Open Source communities. So I'm not feeling the "outrage".
And I spent a good portion of my open source advocacy activities on license compliance at the ASF, helping projects to ensure that even with all the bundled dependencies the aggregate licensing of the distributed artifacts complied with the terms of the Apache License Version 2.0. So I'm not feeling that "silence" either.
What I'm feeling is "hypocrisy" being projected onto a straw man by someone who's got an axe to grind with OSI and the Open Source Definition.
I concede the last part, it is slightly a soapbox from my part about the OSI. However, it's not really a strawman because these issues are very much linked together. The definition itself is very strict yet not comprehensive - false positives and false negatives are both common.
The sentiment that "VSCode is OSI-compliant so it's morally okay to support it" is very common, and it's substantially derived from the OSI definition. I do not think that it's an irrelevant issue or that it would be misrepresenting the definition.
Is it really free (as in freedom) software when it contains DRM? Is it really open source when critical extensions are unusable if you build the software for yourself? It might meet the definition strictly by the words but in my view, this is not much better than TiVo-isation (when the license is adhered to but the user can't effectively use a modified version) or other shady practices.
No moral qualms here. There are large pieces of it that are useful without VS Code (for example, the Monaco editor and the language server protocol). Not to mention al the use people get out of it for free. It seems like the good well outweighs the bad.
Oh, I definitely agree. While I don't use the editor (mainly because I prefer full IDEs and not glorified text editors personally) I agree that holistically, the existence of VSC is a net positive to the programming community. My argument comes from a moral perspective - even though the good outweighs the bad, the bad parts are really scummy and need more awareness.
Like, my perspective is not utilitarian, it comes from a deontological point of view. I see people and companies get regularly flamed (or even harassed/intimidated) for much smaller things such as the crime of creating their non-OSI-compliant licenses and various related things. In contrast to that, the VS Code ecosystem is much more proprietary, grants much less practical freedoms and operates from a way less clean moral background than any of these projects. Yet, many people are willing to excuse this because Microsoft has figured out a way to implement vendor lock-in without breaching any of the four freedoms in techicality. To me, this is way worse than someone saying "no we won't let you use our software for anything"...
> crime of creating their non-OSI-compliant licenses
Just don't call it "Open Source" and you won't get nearly as many complaints.
The big problem arises when somebody tries to leech off of the goodwill built up by Open Source communities and give their Source Available proprietary offering some FOSS-juice. (Most often VC-backed companies who have failed to understand that "Open Source is not a business model").
Well, this thread is getting off-topic real fast but okay, I'll reply :)
This argument would make sense from a strictly logical perspective if these were all the facts but the problem is that the expression "open source" wayyyy predates the OSI. It's been used in the 80s and the 90s on Usenet and in various places, and it simply meant software which was distributed in source code form. (as opposed to binary form) These pieces of software didn't even have a license file attached to them which was implicitly understood as public domain, or "do whatever the fuck you want to do with it".
The OSI simply appropriated the term to a narrower, stricter meaning which grants certain freedoms to the user and takes certain freedoms away from the creator. (Such as the freedom to change your mind in licensing! You can't practically change your mind since these are all non-revocable grants)
Furthermore, I don't really agree with the "leeching off the goodwill of OSS" framing. From a practical perspective as a user, having the source code available is way closer to OSI-licensed software than proprietary, closed-source software. You can view the code of the program, you can usually share your modifications with others (which is technically disallowed but the developers are very unlikely to care as long as you don't resell it), you can fix bugs in it, you can change functionality you don't like.
A less-commonly talked about side effect is that if the source is available, the developers are less incentivised to provide user-hostile features, simply because they know that the users can patch it out relatively easily. There's many cases of rugpulls and forced functionality changes in software nowadays and almost all of it is possible because the user can't simply change the code to change the unwanted behaviour but must put up with it instead.
Naturally, this is a huge advantage compared to closed-source software. And if a company is willing to share its source code with its users, this should be lauded and encouraged! Obviously, the developers want some benefit from sharing the code, and one of the huge benefits is goodwill by customers. If the developers are not incentivised - but more commonly, harassed and mocked - to share their source but disallow competitors to steal it, in most cases, they will simply not share the code at all, leaving you, as a user, with way less freedom in practical terms.
Both you and the company can't really do anything with paper freedoms - you can't really use paper freedoms and the company can't survive if their licensing permits others to profit off their work while discouraging them of doing so. In this view, having more practical freedoms should be encouraged because it helps both the user in having more usable and more modifiable software, and helps the developers not to go bankrupt when Amazon decides to commoditise their offering or something.
EDIT: I conflated "developer" with "company" when writing this post. My apologies. Of course, everything above also applies to natural people who develop software too, not just corporations. I made this mistake because of the subject matter (Microsoft), sorry.
I don't believe the term "open source" was used much before a certain meeting in 1998 [1] when it was suggested as an alternative to "free software." Some people say it predates that meeting, but I haven't seen clear evidence. Do you have examples where it was used?
On the other hand, people were using licenses that are now called "open source" licenses well before that, so the practice certainly precedes the term. Also, the OSI definitions were derived from the Debian Free Software guidelines.
This applies to the situation where the users are programmers. And I am a programmer. But I have never and probably never will modify any open-source applications I may be using. Too much work. Some library-code perhaps but not a full application (like VSCode).
Too easy to cause more errors rather than fixing them, creating a dependency to my own modifications. When it becomes time to upgrade to the next version of such OS software I will need to merge my modifications to the official app or library, and there is no guarantee that my modification would be compatible with the latest version of the said software. If it is not compatible that means either more work for me, or that I can't upgrade.
You specific having the time/resources is not the point. The point is that for users with the resources, they have the freedom to do this (either themselves or by hiring someone).
"I don't have the resources to exercise my freedoms" might be a problem for you, but it's not a problem caused by the freedom or the mechanic granting it.
Right, freedoms are great. But my point is such a freedom is not very valuable to anybody else than programmers, or rich people and companies who can afford to hire them.
And even for programmers like me it is not very valuable, especially if we're talking about sw-applications like VSC as opposed to library code.
The nice thing about society is that it allows people to come together and pool their resources, in order to achieve an expensive thing that no individual might be able to reasonably afford.
I get that nice things that you want are sometimes expensive, but that's just life, isn't it? The world doesn't owe you a cheap-and-easy-to-hack-on piece of software.
Of course the topic of spirit-vs-letter of Open Source is worth discussing. (I've personally meditated quite a lot on "open governance" vs. "open source", which is tangential but related).
But I think your portrayal of FOSS advocates at large as unconcerned about the spirit vs. letter of open source compliance is wildly inaccurate. If anything FOSS communities discuss such topics obsessively. (How many bits have been spilled onto the internet about TiVo-isation?)
Thank you for your insight, I really appreciate it!
>If anything FOSS communities discuss such topics obsessively.
I don't see this the same way. Whenever topics like these come up, "quoting the OSI definition word-by-word" is a fairly a common moral argument. (See every Mongo/SSPL or ElasticSearch thread on this site and you'll see)
While there is definitely discussion of this, you are entirely right, there's a substantial proportion of people (I'm not claiming that it's necessarily the majority or anything - but influential enough to derail or block things) who do not take the spirit of the Free Software movement into account at all. At a glance, many arguments against these licenses don't come from a viewpoint that these licenses violate the spirit of Free Software - they just mechanically quote the OSI freedoms without any critical evaluation or moral reasoning.
pxc's analysis is great and morally I definitely agree with it. I don't think that most people agree with it though - which legitimises the VSCode "open-source" approach.
> MS has managed to pacify even the strongest FOSS advocates
I'm not sure that's the case. I think the strongest FOSS advocates gave up on Microsoft decades ago, and just don't engage with anything they put out. If MS release source-available stuff, strong FOSS advocates don't peep because they've not even looked at it. Why bother - it's Microsoft. If someone else does it, well, the FOSS advocates still had some hope that what they didn't wouldn't be terrible, so there's space for those hopes to be dashed.
> If you enjoy a rabbithole, look at how much DRM there is in Pylance
So just don't use it? The linked discussion points to Basedpyright https://github.com/detachhead/basedpyright/ as the best free alternative right now (with some additional features around Python optional typechecking that aren't even in Pylance itself).
What are the benefits of running Jupyter from VS Code rather than on its own? Isn't Jupyter the sort of thing that can only be made more fragile and complicated by IDE integration?
Absolutely, this is not just a random tangential comment! With a bit of searching, any time criticism of VSCode comes up, it's shrugged off with "it's OSS!". Even from people who use Linux, a substantial proportion of programmers bring out the OSS card to deflect criticism of these exploitative practices.
I'd like to kindly point out that the real issue here is that it claims to be open source, while the most important parts are not. We are not entitled to demand that entities make their software open source, but accusations of deception don't fall under the scope of entitlement.
I don't think it's deceptive to have an MIT-licensed core editor (which is distributed by MS under a custom license) and proprietary extensions.
Like many OSS enthusiasts, I did some initial research on VSCode/VSCodium and decided to install the latter (similar to Chrome/Chromium).
As I kept using it I discovered that some MS extensions would refuse to run on VSCodium without workarounds.
At that point I was fully aware of the license situation and still decided to switch to VSCode for convenience.
My point is that most software developers are capable of understanding how VSCode and its "useful extensions" are licensed; it's not a new concept. And from there, each individual can choose what tools they use according to their preferences.
There is no claim anywhere that the entire product is open source. This is made up hyperbol.
On the vscode landing page they say. "built on open source" with a link to where you can clearly read the license. The ONLY thing that is important is the licence. This clarifies that parts of the product are not open source. At this point you can either use the product or not use the product. But as YOU didn't build it or pay for it you have no place to complain. This is the same sense of entitlement that causes people to harass open source maintainers to fix a bug or implement some feature. People want everything for free and are outraged when they find that the world is not so. Yes it is convenient to go to the package manager and find just what you were looking for without having to do any work or commit any contribution but this is a privilege and not a right. It's amazing that any open source exists at all and where it exists we should say thankyou and where it doesn't either button up and pay or build it yourself.
Vast majority of software we use are based on open-source. I'd argue that stating "built on open source" is sort of paltering.
> But as YOU didn't build it or pay for it you have no place to complain.
I disagree with this point. You're conflating legitimate criticism or discussion about the model (which many have differing opinions on) with the harassment of open-source maintainers - something I strongly oppose as well. Could it be that past negative experiences have made you overly defensive? If so, I understand, but I believe it's a bit misplaced in this context.
The slogan is true and useful to know. If I don't know anything about VScode and I land on the page and I see that it's built on open source I would find that interesting. If I was a reasonable person the first thing I would do is then read further and find out more about the project. I would find that most of the code is released under MIT and that the release build from microsoft has other proprietary modules attached. I could then delve deeper and make a rational decision as to whether this tool is suitable for my project or business.
The first thing I would NOT do is get on hacker news and bitch about how the project is being deceptive and evil. That is just lazy and entitled thinking.
You're right, it's a subjective matter. While your point is valid, I'd also add that the tool's widespread popularity is largely due to the high-quality extensions, many of which are not open source.
You make it sound like poor and good hearted Microsoft is being abused by evil ungrateful kids.
It’s time this crappy company gives something back for decades of evil that they’ve brought on OSS community.
Convenience and comfort are freedom's enemy. What is going wrong with the traditional editors and programming tools that (assumably) younger devs are going for those full-blown IDEs? Has the complexity of development with back/front/ops exploded so much that older editors are lagging behind modern needs?
As OSS old-timer, I gave VS Code a try, but it was too noisy and distracting, slow, and didn't allow enough control over what was being installed and when. To each their own of course, but I didn't see any particular reason why VS Code is much better or deserves to be more popular than other editors, and if any functionality is missing from other editors – especially those that are incorporating tree-sitter – then maybe we can just improve those alternatives?
Talking about modern editors, I like where Zed is headed, but that project also has some non-OSS components or aspirations if I remember right.
The editor is open-source. If you want DRM trap to be open-source, create them yourself. VSCode is a text editor at its core, and you're free to use it as you see fit.
The blog read like the author is crying that Microsoft is not giving away extension for Gitpod to make money
Back during the early 2000s, when OpenOffice threatened to eat Microsoft's lunch, they created the new .docx/.pptx/.xlsx Office Open XML file formats and got ISO to standardize them as ISO 29500-1.
The standard isn't detailed enough to create your own Office implementation. Not even Microsoft Office implements it correctly. Microsoft only created the standard so they could claim they were as open as OpenOffice, to prevent OpenOffice from becoming the standard, to make sure third parties would continue building upon Microsoft Office, and to ensure third party implementations would always be slightly worse.
As leaked emails later showed, even Microsoft employees used the Embrace Extend Extinguish term to describe this project.
I'm not sure why you think the VSCode situation is so different.
Microsoft pretended Office was open so third parties would continue building an ecosystem around Office. But no matter how "open" Office was, you had to get MS Office to get the best experience, so no one could really compete.
Microsoft pretends VSCode is open so third parties continue building an ecosystem around VSCode. But no matter how "open" VSCode is, you have to get real VSCode to get the best experience, no one else can really compete.
Do you understand it now? It was never about the files themselves, but always about add-ins, extensions and an entire ecosystem.
>Microsoft pretends VSCode is open so third parties continue building an ecosystem around VSCode.
That's not the case here. Gitpod wants extensions for free to monetize them.
The text editor is free and open-source, and they utilize it for their UI, as shown in the tweet posted in the blog. Someone observed that many tools employ the VSCode UI.
The VSCode Marketplace is Microsoft's proprietary platform for VSCode extensions, separate from the open-source code.
However, anyone can create their own marketplace for open-source VSCode extensions.
The EEE (Embrace, Extend, Extinguish) tactics you described don't apply to VSCode.
EEE typically involves Microsoft embracing a standard and then killing it. there's no standard to embrace. When we have thousands of text editors out there, each with their own extension ecosystems.
Same, I wonder if the people complaining have experience with vscodium (to know the difference). Everything I want works with vscodium and I never had any problems with it. The only thing I know doesn't work are dev containers, but I never personally wanted to use them.
"most useful things around it are full of DRM and legal traps" is a HUGE overstatement. Vscodium is great and have everything anyone can want (except, maybe, devcontainers)
MS is a bit weird. After realizing that most competent developers had left the MS ecosystem, they went for a Zeitenwende. But they did only for 90%.
I wonder to what extent this halfheartedness should be ascribed to the MS org chart or to reasoning like "we should prevent a competent competitor to run away with our tools".
In the mean time, there is a capable replacement named Theia [0] with none of the strings attached. We as a whole would do best to move to that one. [1]
To be honest, Theia (the last beta I tried some months ago) is everything people always complain about Electron apps: slow as molasses - way worse than e.g. Atom (or Pulse) (which VS Code actually isn't).
> The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension. This is very clearly malicious.
Huh? There's been lots of outrage about this. Repeatedly.
However, the problem is that nobody with any resource is willing to step up and replace the Microsoft closed source plugins. And developers aren't willing to put themselves out to use non-encumbered extensions.
It's basically a big "Put Up or Shut Up" from Microsoft, and nobody is willing to "put up" so we wind up with "shut up".
>The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension. This is very clearly malicious.
Huh? If anything, MS prevents people from shooting themselves in the foot and illegally installing a piece of software against the license terms.
You can use vscodium for free, it's great, you literally don't have access to a few MS extensions (with open alternatives, which you can support financially if you care).
Yes, PyLance has a pretty strict license and makes it very clear it cannot be used in forks (and that's not really surprising and pretty standard I'd even say for a corporation such as Microsoft, it's like the current licenses saying this is open source but cannot be used by competitors, what's really surprising for me is that forks are choosing to ignore this):
> INSTALLATION AND USE RIGHTS. a) General. You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”) to develop and test your applications. b) Third Party Components. The software may include third party components with separate legal notices or governed by other agreements, as may be described in the ThirdPartyNotices file(s) accompanying the software.
One thing I don't understand is how forks (I'm actually talking about Cursor which is one I'm actually evaluatinng) are getting away with scrapping all extensions from the VSCode marketplace... I even e-mailed them but had no official position on that. Maybe they have some separate contract with Microsoft -- they do have OpenAI backing, so, maybe they have some bridge there, does anyone know? Or maybe Microsoft is just waiting to see how they themselves can profit for it and so is taking no legal action at this point?
-- disclaimer: I'm on the author of PyDev and I do have my own Python extension that I publish to VSCode and OpenVSX (https://marketplace.visualstudio.com/items?itemName=fabioz.v...)... it's completely Open Source in Eclipse, but for VSCode it's currently commercial. I discovered that's a nice way to have less people requesting support, even though 99% of it is still Open Source ;)
Its close in spirit to DRM: they enforce that if you are using their projects, it is under their legal terms.
Many of their VS Code extensions[0] have license terms which /prohibit/ them from being used in editors that are not Microsoft's VS Code editor, and Microsoft can issue cease-and-desist for violations of this, as well as 'open source forks of VS Code' using their marketplace services.
Microsoft also has a pattern they follow where they publish repositories on GitHub to proclaim they are open source, while actually distributing proprietary binary blobs in them that are fundamental core parts of functionality to the codebase[2][3][4]
Isn't it worse than that? They're not just unsupported, I thought it was against their EULA to use the MS extensions with anything but the official VSCode.
It doesn't matter to the average person using it for personal projects but it's a liability to businesses. It wouldn't matter most of the time but this is Microsoft we're talking about.
Meh, for me personally I don't care about EULAs, as you say.
And for business, they will use the official VS Code anyway. My own employer is up to their armpits in Satya's ass. Over the last 8 years the MS sales goons have managed to get us to throw out every third party solution they had an option for. We even have to use Edge now.
It's really important to realize that some 70% of the OSI's funding comes from proprietary services houses (Amazon, Microsoft, and Google mostly and then like... Comcast and IBM), and so nobody at the OSI legitimately cares about openness. The reason SSPL is not OSI approved is because Amazon pays an entire OSI staff salary a year and the SSPL costs Amazon money.
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
I've read the arguments, but those arguments apply equally to the AGPL, which would not be approved by the OSI today. SSPL has no field of use restrictions, it simply has restrictions that require viral open sourcing.
And there's nothing slanderous about pointing out that, yeah, Amazon pays out a significant portion of the OSI's entire operating budget. (edit: Actually FWIW, Amazon is apparently not currently on the Sponsors page... maybe they didn't renew this year. But they used to be at the top.)
You can also use SSPL code to develop nuclear weapons and murder drones, as long as you publish the code! Additionally, you can also use SSPL code in a business offering that code as a service... as long as you publish all of the code for that service!
Oh. I've read more about SSPL and I actually like it. I don't see how it's not open source. I guess OSI, Red Hat and Debian know better than me, I'll have to check their reasoning. Though you are right that I don't see how it's fundamentally different from AGPL.
Thanks for correcting me!
>Specifically, this is discriminatory against users of the software that use proprietary software within their stack,
The difference between the AGPL and the SSPL is that while both relate to software which the end user interacts with over a network, the AGPL places no restrictions on what the software is used for, while the SSPL encumbers commercial SAAS.
This is a field of use restriction, and it is indeed the point of the SSPL! But field of use restrictions are disallowed under OSI's Open Source Definition — because it's critically important that Open Source software must be usable for any purpose to avoid uncertainty and exclusion, as explained elsethread [1].
You can't just keep claiming there's a field of use restriction when there isn't. It merely conveys a requirement for open sourcing dependencies required for operating services, an entirely noble copyleft behavior.
Any business which isn't exploiting open source in order to benefit proprietary source won't even be phased by this. It's simply a requirement to open source your stuff, which the OSI would support if supporting open source was actually their mission.
OK, I believe I understand the distinction you're making here.
I had to fight my way through your aspersions about the motivations of the people who take part in OSI license discussions, some of whom I am personally acquainted with. I consider the notion that they are driven by allegiance to Amazon and the like risible, although you don't have to take my word for it (and shouldn't, it's an argument from [negligible] authority).
The idea is that a "field-of-use restriction" should deny a license grant based on field-of-use, as opposed to granting a right to users to obtain source code based on field-of-use. This seems like a technicality when the obvious effect is to cripple commercial competition which some see as illegitimate and advantage certain other parties — something completely at odds with the idea that Open Source software needs to be available for any use, deeply cherished by myself and many other FOSS advocates.
For what it's worth, while I generally support, develop, and use open source software, I think "freedom 0" is somewhat problematic. Beyond the fact that I feel us doing labor to support the common good should not inherently require it be usable for corporate greed (I think a noncommercial license shouldn't be treated as a sin by the open source crowd), I think there's a sort of Paradox of Tolerance issue if you allow proprietary developers to compete directly with open source developers using their own code.
If we aren't able to say "hey, this is for open source use only", companies unburdened by ethics will always have a market advantage over ethical open source companies, and that in the long term will ensure open source doesn't win.
ladies and gentlemen, this is a perfect example of the word-by-word interpretation I was talking about in another subthread:) The SSPL is a perfectly sensible license, the only thing it does wrong is to stop SaaS exploitation of software. As the GP said, the OSI is mostly funded by hyperscalers, it's in their vested interests to keep the status quo.
Field-of-use restrictions are certainly a useful tool in fighting open source exploitation, and the blanket disallowal of them just plays into the hands of Amazon and whatnot, allowing them to massively profit off everyone else's work.
Also, note that the OSI doesn't even follow their own definition by the letter! I quote,
Section 13 is very obviously intended to be a restriction against the field of endeavor of offering the software as a service, and thus not in compliance with OSD #6. I don't see how you can change this while maintaining the intent of your license, which is indeed to specifically encumber vendors other than MongoDB who engage in that field of endeavor.
So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field! The conflict of interest is blatantly obvious here...
> So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field!
Stopping hyperscalers is restricting usage in a field.
The primary reason that field-of-use restrictions are part of the OSD is to avoid excluding anyone from the community, and also to avoid fights about whether anyone belongs. Historically, military uses were often excluded in certain licenses — but just what constituted military use could be very hard to determine and potentially could result in endless litigation. Dual-use technology, anyone?
The same reasoning applies to hyperscaling. If you allow any restrictions on field of use in "Open Source", then a fundamental guarantee that countless users of OSS have been counting on goes up in smoke. Before, it was software that anyone could use for any purpose. But now, everyone has to wonder, "am I actually allowed to use this Open Source Software"?
I firmly agree with these arguments, and I'm glad that the OSI continues to be intellectually and morally consistent in applying them — despite your asserting that they must be corrupt to do so.
> People when a piece of software is source-available but not strictly OSS: outrage
Also people who in some contexts could be infinitely more productive with their favorite editor by not being forced to work with an IDE. One thing is developing for the desktop where having a form editor becomes handy, therefore KDevelop or Lazarus make sense, but why in the world should one be forced to use that behemoth for a small set of .c or any other language files where a well thought makefile can rule them all? Do I have to install and configure vscode for a short source that would run on a microcontroller? Really?
I see more and more projects requiring vscode, and that is not good if they don't actually need it (YMMV of course): turning a set of sources and their makefile in a IDE project isn't hard, doing the opposite is often a nightmare.
Say what you want about microsoft, but it protects its developers by making sure they get paid, and it also does so for third party developers who target Microsoft.
I'd rather get paid than build towards an ideal bunny world of free as in free beer software.
There's a bait and switch. For users free software is about not having a cost associated, Wikipedia, Wordpress, Google and Youtube, Whatsapp, ChatGpt, they all compete in the same category of software that doesn't have a cost.
Now for developers, they are recruited to build software under the guise of freedom, while their users care not about the men who die for the cause, and only appreciate the free stuff.
The argument that you can still get paid developing free software is obtuse. Source code is a very valuable tool to protect intellectual property (which is a recognized legal asset despite what stallman would like to be the case). If you sacrificie your source code advantage by making it public (which is a requisite for free software, put down your "Free software isn't open source" paragraph gun), then you give away most of your capacity to make money out of your skill. Furthermore, open source development and closed source development are two very different skillsets, so you kind of get locked in to a worse paid form of software (with the exception of the top 0.01% of developers who might net evangelizing positions at actual proprietary companies like Guido Van)
But you can totally charge for free (as in free speech) software. While you're required to provide the source code to those who pay you to use the software, you don't have to provide it to those who haven't paid. You could also charge for each update and only provide the versions that the user has paid for.
Also what do you have to say to the open-source projects that take a "dual licensing" approach, like how Google profits from creating their own proprietary browser Chrome that has more features than the open-source Chromium? Isn't it practical for companies to freely provide an open-source version with fewer features and sell a better, proprietary version? I havnen't done any of this, but to me it sounds like there's plenty of ways to make money developing open-source software.
"While you're required to provide the source code to those who pay you to use the software, you don't have to provide it to those who haven't paid."
The issue is that you give away your source code to your clients and competitors, who can then save money by not paying you.
If you don't give them source code, whether by distributing binaries or access to a server which holds the code, you can recoup the investment by ensuring clients only get the benefit of your software when they pay.
It's a similar dilemma in the pharma industry, yes you can free the patents and publish the synthesis method, but who is gonna pay the researchers?
Finally Chrome is more of a byproduct of google's efforts to scrape the internet, turns out that in order to figure out what a website is showing a user you need to pretty much develop a full fledged browser. The goal of google was never to develop a browser.
"Also what do you have to say to the open-source projects that take a "dual licensing" approach, like how Google profits from creating their own proprietary browser Chrome that has more features than the open-source Chromium?"
Critically, Google doesn't sell or charge for Chrome access.
Their monetization model is making software free (as in beer) in exchange for advertising. Again, that funky word free.
Regarding imitating that model, you and me are not google, and will more likely fail than not if we were to pursue that model.
As a whole section of tech sector that builds a lot of useful tools and products exclusively on Microsoft stack? I understand that Windows Server, MS SQL Server and ASP .Net folks are less represented in the HN crowd, but pretending that most of them regret their tech stack decisions is absurd.
Paul Maritz also explained to Intel representatives that Microsoft’s response to the browser threat was to “embrace, extend, extinguish”; in other words, Microsoft planned to “embrace” existing Internet standards, “extend” them in incompatible ways, and thereby “extinguish” competitors.
Haven't yet seen a reason to use VSCode and can't anticipate I will
As an editor it's a pain in the ass, as an ecosystem it feels like a fucken freemium mobile game for how polluted and nickel-and-dimey extensions are, and worst of all it's owned by microsoft so while this article is informative on the specifics, I knew from the jump there was some legal fuckery involved because there literally always is
I can't be a total purist and never use a tool that's connected to a large tech company's ecosystem, but where at all possible one should, and this is only becoming more true
This is giving MS a lot of credit for having a long term plan.
Isn't it just that all companies want to extend/embrace/control.
This has happened with a lot of Open Source products recently.
Didn't this just happen with Redis this year.?
"The mission of the Microsoft Developer Division is to earn the trust and love of developers across all languages and platforms and make them successful as they build the applications of the future."
Maybe the simpler explanation is that they want to make a good product? Which will mean it spreads out, and they do need some amount of control, thus the 'official' build.
Of course, they are also shady. I lived through the Explorer lawsuit days. But even then, I think they stumbled into it, they didn't have much of a plan beyond control.
All companies want to extend and control.
OSS was supposed to be a counter to this.
But seems like without some kind of 'pay' model where developers can actually 'live' and contribute, it eventually falls apart. There are just not as many people willing to spend nights and weekends developing and especially SUPPORTING OSS for free. So any OSS tools that are good and widespread, and don't have some support like research funding, get co-opted.
Maybe a non-profit company is the best way. But we've seen how that turns out if it actually takes off, like OpenAI.
Coding in notepad or nano has been a great investment of my time.
I don't need to learn any of these tools or read about any drama, I just type letters into the screen and use my keyboard to move my pointer. That's it, if I need anything more complex to handle my codestring, I write code.
But I have never needed to run a search and replace of a variable, both notepad and nano can do that. If I need anything more complex I do it manually. Anyone that does some exercise or has had a physical job knows that doing something 26 times in a row is basic stuff of any worthwile endeavor.
>Anyone that ... has had a physical job knows that doing something 26 times in a row is basic stuff of any worthwile endeavor.
I have. There were an awful lot of electric tools doing things that used to require manual work. And they were used even the old guys who were fighting against their broken bodies to work for long enough be able to retire.
Yeah, early in my career I got by with gedit on Ubuntu but before too long a 700,000+ line PHP project with deep, deep inheritance trees showed up and I very much embraced an IDE.
It's not a download, it's a blessing.
It's not corrupting, it's purifying.
It's syntax highlighting for your strained eyes and block commenting for your sore fingers.
It's peace.
Take care.
I love your extreme position. I don't believe it could work for any of the projects I work on, and even if it would it would be a huge time sink and it would hold me back a lot.
But I dream about a simpler world where I could just open nano on a dusted terminal in a basement, grab my printed copy of a OS manual, and code away.
- cpptools is kind of amazing but also pretty bad. It regularly malfunctions for me. It’s essentially undebuggable. I have less experience with the other extensions, but I don’t expect that they that much better.
- The VSCode security story is very, very weak. Extensions are not sandboxed. The client, accessing remote repos, is wildly insecure, by design.
And that second point is a big deal. Maybe when poking at your own company’s code, you aren’t that concerned about your repo attacking you. You probably should be concerned about malicious extensions, but we’re all far too used to trusting dev tooling. (Don’t forget that MS’s extensions are just this side of malicious.)
But, with AI, you should absolutely not trust your LLM. It is entirely unsafe to give an LLM that might try to exploit you the ability to write into your repo directly or to run JS code in the context of any portion of VSCode. And it’s really quite easy to convince LLMs to engage in all manner of shenanigans.
There’s an opportunity to make a better ecosystem. In a better ecosystem, the equivalent of cpptools would not have telemetry, because the equivalent of cpptools would not have Internet access. It would have the ability to read the workspace, to create cache files for its own data, and to operate its UI, and that’s all.