This is in France, where text messages were free (unlimited with your subscription) long ago before we had internet on our smartphone.
Thus people use text message a lot and did use WhatsApp only to contact people outside from France
Seems great. The pricing distrubs me. 75$/month this really nothing for big organization with 1000+ employee.
Also, all your testimonials seems fake. People are unfindable and no company is cited. Why do you do this ? This creates trust issues from the beginning
I don't think it says "Software not open-source is bad".
But more something like "It is marketed as open source but it is not".
Developers should be aware that VSCode is not as open source as it claims it is. In my circles, developers could swear VSCode is fully open source without even knowing VSCodium.
If people were more aware about this, they might think twice before using VSCode for everything and getting lock-in (just like the article says)
>But more something like "It is marketed as open source but it is not".
Developers should be aware that VSCode is not as open source as it claims it is.
Honest question...
Is SQLite also deceiving people about its "open source credentials" because the Encryption Extension is proprietary and costs $2000?[1]
... because as far as I can tell, most conversations do refer to SQLite as "open source" without always bringing up the encryption extension as a disclaimer in every online discussion. SQLite's creator, Richard Hipp, has a company selling a commercial license for the encryption add-on but it doesn't seem to tarnish the "open source" perception of SQLite.
I think it's often easy to unknowingly use or rely on a proprietary extension, such as in Visual Studio or even a particular browser's features.
When an extension requires you to get out your credit card then this isn't possible. If it costs $2000 you can assume it's proprietary.
So I think the issue for VScode is more nuanced: proprietary extensions are not clearly marked or separated from the open source feature set.
Another good example to consider is whether people feel deceived by various Linux distributions who bundle one-click or automated install of proprietary blobs.
Someone can correct me, but the last time I installed the remote extension pack I’m almost certain that a notification popped up that said “By using this extension, you agree to the license terms...” which is unique to the Microsoft closed source extensions.
The main way SQLite is used around the world is as a library component of a larger application. The main way people use VS code is through the proprietarized official build that uses the official EULA.
Also, lots of people seem to value the proprietary extensions a lot more than people value the encryption extension of SQLite.
>The main way people use VS code is through the proprietarized official build that uses the official EULA
The blog author complained about "Live Share" as one example. As far as I can tell, "Live Share" is not in the builds one downloads from Microsoft's "Visual Studio Code" website: https://code.visualstudio.com/download
I'm willing to be convinced that it's a marketing deception and "open source" should be removed but so far, I haven't seen any precedent from other hybrid open/closed source projects justifying that.
> Can someone explain how the situations are not analogous?
The difference is that typical usage of SQLite is co-located with an application, such that you don't need encryption, and it doesn't market itself as a great database to stand up on a far-away server.
VSCode is marketing these extensions with the core product, as features thereof. They seem to be much closer to critical, core functionality. I think that they are functionally similar situations, except that nobody uses/cares-about that SQLite extension.
Microsoft is also marketing as if VS Code is open source. One claim or the other is fine, but the combination is deceptive. There are many closed-source components which are part of VS Code, if indirectly.
I've been using VS Code since day one, and I have zero interest in Remote or LiveShare. I can definitely see how they'd be useful in certain environments, but they just have no use to me.
Not that they are critical or core, but that they are, in the words of the original author, "the best parts of VScode." All the core and critical features of VScode exist in every other editor. LiveShare and Remote are, as far as I and the author can tell, not replicated by any other editor, and are therefore (subjectively) the "best parts". Whether or not you know anyone who uses the features is irrelevant.
The person I was replying to used the words "critical" and "core".
As to best (admittedly subjective) if they are so good I'd think that one of the 100s of devs I know depend on them.
The only close one was Remote - which other editors do too - When I showed that remote drops code to the far end machine we determined that to be too risky - and went back to sshfs.
Also, if those extension are so "best" why hasn't a replica been created? Or why didn't any other editor have them? It might be those extension are not so compelling.
Also, my previous favorite editor (jEdit) had remote features back in like 2003 - maybe earlier.
I don't agree with the word choice of the parent, but I think the argument stands if you replace "critical" and "core" with "best". That's why I chose to re-reference the original article.
I'm curious if you've used the live share features personally, and if you have if you've found value in them. I suspect many devs do not like collaborative programming in general, and so may never use them or like them if they have. As someone who thoroughly enjoys collaborative programming, I can tell you that these features are extremely compelling. It's way easier to tell your designer friend to boot up VScode and click on a link to your live app running locally than almost any other solution I've found. It also makes pair programming extremely easy.
I used to use vim and now emacs for everything. I've also used JetBrains products for years. The only reason I ever boot up VScode is for those features. You just can't replicate the experience in any other editor as easily. Every other feature of VScode I've found a similar or better solution in every other editor. I'd be interested to hear any other feature of VScode that you think is as compelling, without parallel in any other editor. I suspect there are few/none.
I love pair programming. I teach loads of juniors, that's how I know so many devs (that and hiring/recruiting).
So, the features of LiveShare I found are better handled with external tools. But that is mostly because I don't want anyone to become to dependent on one tool. How can I LiveShare between emacs and Sublime? WebRTC screenshare+A/V works a treat, across editors and systems.
I don't find VSCode, or it's extension super compelling. But it is very nice.
I think the feature I like the best, built in, is that debugger - that's easier/smoother than Atom, or jEdit or any others that I've used in the last 20 years. It's like what was available in Visual Studio 6 (c1999).
If Microsoft wrote a proprietary extension to emacs that was so compelling many would consider it to be the "best" feature, I think devs would complain. Emacs is way more FOSS than VScode claims to be, so that would be an even worse affront to the philosophy of the editor and community. Maybe you're right about the JetBrains products, but to my knowledge they don't market themselves as open-source to the extent that VScode does.
Just going by "feel" without rigorously analyzing why it feels this way, my personal answer to your question is that the sqlite encryption extensions feel very much like LiveShare and not so much like Remote. Remote feels to me like a major part of the product that MS advocates without differentiation. LiveShare feels like a neat add-on that's a nifty alternative to several other similar things.
Similarly, the encryption extension has many alternatives and I've never heard Dr. Hipp advocate using it. This thread is the first I've heard of it, and I've heard of alternatives before. Where I knew coming in about Remote and LiveShare based on promotions from Microsoft.
That's just an explanation of how it "feels" to one reader, not any kind of careful analysis or sweeping statement.
> Developers should be aware that VSCode is not as open source as it claims it is.
VS Code is as open source as it claims to be.
> If people were more aware about this, they might think twice before using VSCode for everything and getting lock-in
Are there many software developers who are not aware that most open-source software can run proprietary extensions?
I personally don't use any of Microsoft's services. Therefore, the entire claim that "the best parts of VS Code are proprietary" is completely false for me.
I know full well about VSCodium, but choose not to use it. For all intents and purposes, VSCode is open source - the source code it freely avaibale on github under an MIT license. AFAIK only the installer and some extensions are not open source - that plainly doesn't mean VSCode itself isn't open source.
VSCode is a fantastic tool, and I'd prefer to use it directly from Microsoft. I am aware that there is telemetry, and as someone conscious of privacy concerns I've looked at what telemetry is sent - I'm satisfied it's anonymised sufficiently and benign enough not to affect my privacy. If the VSCode team really find this data useful, then I'm happy to provide it and help improve VSCode.
I do however think that telemetry in VSCode should be opt-in rather than opt-out.
The big surprise for me is that the extension repository isn't (legally) accessible by any open source distributions of VSCode. It's not technically part of VSCode, but it's a big piece of functionality that I would have expected to be available.
This divisive "us and them" stance is unnecessary, and doesn't help anyone.
OSS and free software matters to me - so I use VSCode, which is OSS. Whether extensions are OSS or not is immaterial (the same extensions you can use with VSCodium!).
the compiled version of chrome is not Free Software or Open Source. only a version from sources only is. you can't build chrome from those sources, only chromium.
now it is possible that VSCode is different in that regard. but if that were the case then VSCodium would not need to exist. so i guess that it is not possible to build a full version of VSCode from those sources either. i'd love to be wrong on that though
these extensions are a key part of my workflow so imo vscode in effect is proprietary as i would not find value in it without these. this appears to be an opinion that is shared with other devs here. it seems you simply handwaving that opinion away as immaterial is more divisive than someone asserting that if you appreciate OSS you should use OSS.
The gripe in the article is about extensions not also being MIT licensed - an argument precisely nobody would be making if it wasn't Microsoft; as someone else here pointed out, you could make the same argument about SQLite, but nobody would.
It’s important to note which code is MIT licensed, and which isn’t, as others have mentioned around components of the extension functionality itself.
I’m not making the specific claims you are arguing against, and I don’t disagree with what you say, in any case. Just as in SQL, and in this case, these licenses matter. A feature matrix clarifying features and licenses would be mice. Also, it would be nice to have a fully FOSS mode for VS Code in its settings or config. It is a distinction with a difference.
Yes this is exactly the risk: developers become dependent on the VSCode extension ecosystem, while thinking they are safely using only FOSS tools.
This is the kind of double-speak which lets MS have the best of both worlds. From a marketing/developer relations perspective, developers think they are using open-source tools. But in actuality, developers are investing in workflows where MS is a critical link in the chain.
I really don't understand this, when I use a library in my codebase I make sure I understand the licencing implications of using said library. When I add an extension to my IDE, I make sure I understand the licencing implications. If I add and extension to my IDE, I have modified my IDE beyond the base IDE, I should very well know the implications of doing so. It is no big secret that these two extensions are not FOSS tools. Some people care, some people don't but if a developer is blindly adding stuff to their IDE without knowing the ramifications, I would certainly question their judgment and I would certainly question their judgment if they are under the assumption that every extension out there is FOSS.
> When I add an extension to my IDE, I make sure I understand the licencing implications.
The UX decisions of VSCode go against this kind of careful consideration of licencing implications. If I open a code file and VSCode has a suggested extension for the file type, I will see an animated popup in the bottom of the screen, with a button to install. The simplest way to get rid of this popup is to simply install the extension. There's also no link on the popup to read up on the licensing terms. Everything about this interaction design wants you to just mindlessly install the extensions VSCode suggests to you, and I would wager this is what a lot of users end up doing.
Also if you look at the VSCode homepage[0], very close to the top of the page you get these marketing claims:
> Free. Built on open source. Runs everywhere.
You might be very capable of understanding the details here, but I think a new CS student who's maybe just heard of open source and knows a little bit about it could be forgiven for conflating these claims with the idea that VSCode is FOSS.
I guess it is just me, but I have never clicked on that pop-up. I always go to the extension tab and add extensions there, where the second link at the top, has a direct link to the licence of said extension. I always go to the extensions tab because it provides documentation about the extension, which I want to read before I add it to my IDE.
Even that page doesn’t tell you the license. It just has a link to “license”, and given that VS Code is marketed as open source software, and there’s often even a GitHub link (for issues), it’d be pretty easy that the “license” linked to was GPL or MIT or something.
Many times, how developers / (manager that think it is a great idea) design an application and how users, use an application do not intersect. I personally would not install an extension to my IDE without at least skimming the docs, checking the licence to see if I am going to have to subscribe or pay later, and checking reviews to ensure that it's a legit extension. I am certain, that there is a contingent of people that do, but as for developers, I would expect them to be a power users that knows better than to just click a yeah, sure install that button.
Honestly, if that where the only way to install extensions on VS Code it would probably be a deal breaker for me. I never install something because the application tells me I should. Especially in an ecosystem where anyone can provide a package. To me it would be akin to blindly adding an Node module, python module, jar or any other third party provided dependency to the custom software I am writing without first vetting it. I mean the licence for an extension, could very well state, that any software produce form the use of this extension, entitles the author of the extension a 10% royalty from said resulting software. That is a very real and valid licence, game engines, codecs, encoders use it all the time.
Other Microsoft OSS ventures makes me wonder if they haven't resurrected that policy too (e.g. the crippling slowness of azure mysql and azure postgres as compared to SQL server).
Can you give some examples? I haven’t seen Google close source something lately, except for Go’s package hosting server (which makes me inclined to believe you, I just haven’t heard of other instances).
User lock-in is how Microsoft has traditionally extinguished competition.
Microsoft Office is an early example. I know zero people that switched to it because they liked its functionality or user interface. They switched because nothing else could open Office documents correctly. Eventually, everyone I knew switched to it (and many happily switched away decades later, once “as-a-service” competition cropped up, solving the compatibility problem).
If this discussion were about anything other than text editors, I would take it much more seriously. But text editor popularity cycles every 5 years or so, and the main reason is simply that we get bored and want to try something new.
When we "invested" in VSCode over the past few years, we discarded all of our previous investments in Sublime workflows.
When we invested in Sublime back in the early-2010's, we discarded our previous investments in TextMate or Notepad++.
When we invested in TextMate or Notepad++ in the mid-2000's, we discarded our previous investments in UltaEdit or God knows what.
When we invested in UltraEdit or God known what back around the turn of the century, we discarded our previous investments in Vi or Emacs or Nano or whatever we were using from the shell in our 1990's computer science classes.
All of this has happened before, and all of this will happen again. We'll be bored with VSCode by mid-decade... and when we migrate to the next thing, it will take us a matter of days.
Agreed that many developers do this. I'm very averse to relearning all my tooling every couple of years, though, so I tend to treat FOSS very seriously because my investment will last decades. This makes me a bit of an outlier, but it's the reason I invested in building skills in GNU tools, Linux, and Emacs in the 90s, and continue to use those tools every day. For people like me, VSCode is not a great choice, for all the reasons you suggest. For most, I agree that the stakes aren't quite as high, simply because folks are switching tools from time to time for other reasons anyway.
> "From a marketing/developer relations perspective, developers think they are using open-source tools. But in actuality, developers are investing in workflows where MS is a critical link in the chain."
There's plenty of open core software that's the same, like Gitlab. I don't see any big outcry over open core in general so presumably very few people care.
> "it could have something to do with the fact that microsoft has a history of bad behavior and abuse of their market dominance, perhaps?"
Can you provide a plausible scenario for abuse is likely to happen with VSCode? Does VSCode even have any kind of market dominance? As others have pointed out, the open parts of VSCode could probably survive on their own as a community supported project, minus the proprietary plug-ins.
From what I can tell from the official VS Code site by Microsoft they no where say that it is a fully open source piece of software. Infact they say "Free. Built on Open Source. Runs Everywhere" So they are saying it is "Built on Open Source" which means something completely different to me.
"Built on Open Source" is in the same vein as putting "Made from natural ingredients" on a cereal box. It's meant to make the product sound better for you than it actually is.
While IntelliJ is not completely open source, the community edition definitely is(not free in the gpl sense but OSS). But they are careful in marketing it that way.
Given the fact that you have to download both extensions separately and intentionally from the VS Code binary. I would say that VS Code does indeed meet the technical definition and spirit of open source. I don't know a major open source IDE that does not have closed source and/or paid extensions that you can purchase/download. I find this argument kind of strange, neither of these extensions are part of VSCode proper, sure they are nice but to ding the base editor because MS did not hand these out is a bit of a stretch.
Exactly. And it's important to write articles like this about VSCode, Android, Chrome, and any others engaging in this (increasingly common) marketing approach.
On the other hand, Safari's WebKit being open source allowed Google to build Chrome on the same engine. Years later, Chrome's Blink engine being open source meant the same for Opera, Brave, and Edge.
It is hard for individuals to run and maintain custom forks, but the benefits of open source in terms of preventing lock-in are substantial.
That Apple locks down iOS very tightly is a separate problem.
WebKit on Mac continues to be usefully open source, and I believe performance improvements that Apple has made for Mac Safari have been incorporated into Firefox, Chrome, etc.
Firefox does not use WebKit (and at this point neither does anyone else), but they can look at patches to WebKit to understand how Apple improved Safari's performance. Because Apple produces the hardware, the OS, and the browser, the choices they make in the WebKit implementation are highly informative.
> it shows how being FOSS isn't enough
This is true for every app on iOS: even if you have the source code, you can't necessarily run a modified version, and so you're missing one of the main user freedoms that FOSS should guarantee. I wish Apple would rethink this, but Safari is still usefully open source.
Just because you can't literally copy the code from one place to another doesn't mean you can't learn from it. I'm not a lawyer, but my understanding is it's fine to learn what series of system calls they're making and look at their optimizations.
I find this quote as important as yours:
"This mechanism ensures that high connectivity in a specific area of the brain, possibly manifested through some special talent (e.g. sports or music) is always countered by relatively low connectivity in another part of the brain"
