You can pry emacs/vim from my cold dead hands -- Microsoft is trying (and succeeding) in google-chrome-ing it's way into the productive developer space. If that's true, I wonder what the Firefox in this analogy is? Atom? Emacs/Vim?
I assume these extensions require communicating with some central server (owned by Microsoft) to exchange information with peers at some point during its use.
Allowing the extension to run in contexts outside of VS Code could be an issue for them?
> I assume these extensions require communicating with some central server (owned by Microsoft) to exchange information with peers at some point during its use.
So I'm no WSL expert but why would Windows Subsystem for Linux or SSH need to communicate with some central server? Also unless they're doing some obfuscation, you're going to see those URLs in the binary to start with, no? Or you just... watch where it calls out to?
> Allowing the extension to run in contexts outside of VS Code could be an issue for them?
How? If it's a warranty issue then they should just issue the right statements in the license and make sure no one is under the impression that there's a warranty attached?
I tried to think of some too but security doesn't pass my admittedly simple sniff test.
I'm having trouble with the question, it sounds like it's equivalent to "why bother open sourcing useful, currently-working software X", and that's just the "why is open source good" question, right?
I can somewhat understand WSL being closed source -- maybe it's got some proprietary MS stuff in there that is legally restricted, or they just don't want people using the interfaces they used? But tools like SSH grow because they're open source, not because they're closed, seems somewhat misplaced there.
Vendor lock-in is what i would see as bad-faith actor's action. A product being good should be the only lock-in required.
Are these the only reasons you have problem with it being closed source?
I'll happily use the closed source version when MS is developing who can handle 4 digit number of issues and likely to fix issues you care about and more.
If someone black lists your SSH server publicly, you seem to have a bigger problem than an extension being closed source.
The bigger risk is that MS would start selling your usage without you even knowing, don't forget it's an advertising company as well.
It's totally fine for other people to be fine with the trade off, but for me VSCode is an incremental gain, not a huge absolute one -- maybe it will have some killer feature (or more likely some partner/employer will force it on me because it's the current zeitgeist and because of some custom plugin) that I'll need someday, but that day is not today.
But I am also not a full on fanatic -- the world is gray, not black & white (for me at least). Since I am familiar with popular good open source tooling in this space, I'm surprised others who might feel the same might compromise at this particular junction, and that was my knee jerk reaction.
I can't say I do as much for the F/OSS community as others out there do but I donate to the authors of the tools I use, the EFF, and Letsencrypt (the amount of value they deliver is insane) from time to time.
- First one is the stance. If I'm developing open source software, I want to build it on open source pillars. This ensures that I can just share the project file with the repository.
- Second one is access to source. I've chatted with a guy who had a problem with Eclipse CDT. He also reported a bug. I reproduced the bug and reported to bugzilla under his report. Someone looked to it in 24 hours after my reproduction and it's fixed and pushed.
I'm using Linux and open source software most of the time for the past 15 years. Open source tools gave me a better overall experience because being able to diagnose and workaround a problem makes my life much easier. If I can I'll push a patch, otherwise I'll report.
I have some closed source applications inevitably and if they're a bit complex and have some bugs, I'm a sitting duck waiting for answers to my e-mails and updates which fix bugs. This doesn't happen all the time because every developer has a time budget and will rightly spend its time on higher impact bugs. If you hammer a piece of software enough, you'll probably hit a bug which is not a big impact for most people but affects you in a big way. These kind of problems turn your relationship sour with that app.
This is why I use Eclipse for last 16 years or so. Yes it's not the prettiest, it's not the fastest but, it's well polished under the hood, I can access the devs and the source and it's overall stable and extremely feature rich.
Long Answer: I didn't say that only open source can fix bugs in 24 hours but, in order to get your bug fixed in 24h in a closed source software, you need to pay some top dollar for that service. Otherwise you'll most probably wait for the next point release which may or may not contain a fix to your bug.
In most closed source software, the process is completely opaque after your bug report is acknowledged. You don't know when will it fixed or ever be fixed. That's not a joyful wait sometimes.
OTOH, you're absolutely right. Not all bugs in OSS is fixed in 24h straight. Some got never fixed or fixed out of the tree. Also, an awful lot of software dies. OSS projects probably die more because they are one man shows most of the time unless they get a loyal following and they are very very good. However, you can compile and patch a dead open source project. You can't revive closed source software once it's dead and bit-rotten.
I want to give a couple of fresh examples, from Intel.
I have an HP Spectre X2 detachable tablet PC which runs Windows 10. This PC has an embedded Intel Wireless Dual AC 7265 card. Out of the box, thing works great. Rock solid. Windows updated its driver in some point and that driver which, has WHQL seal and everything, crashes that wireless card. You need to reset the card every time the card goes low power mode and comes back.
Intel has an even more recent driver, which does not fix the issue. The PC has a full fleet of updates too. BIOS, ME firmware, board FW and what not. Nope. The problem is still there. What's the best solution? Roll back that driver to initial version. Now it works. Can Intel fix this? Of course! In 24h? Why not? Will they fix it? Of course not! Why? AC 7265 is EOL, so no incentives. However, on paper all of these drivers support 7265.
2nd example is e1000e Linux driver, again from Intel. This is an open source Intel Ethernet card driver which supports whole fleet of cards. From lowish-end to top end silicon. Intel added a new feature to this driver and some cards started to crash, incl. mine (relevant bugzilla is [0]). Patch is isolated, distributions rolled it back relatively quickly and many people are back on track. Kernel people are still looking at it without rush since, everything is working without the latest patch.
Who wrote the last crashing patch? Intel. Can they fix it? Of course! Even in 24h? They may if they really want to. Will they fix it? Of course not! Why? Not enough incentives.
Bonus: While unrelated to both, I've waited a company to change a string comparison to case insensitive mode (or just capitalize the first name of the file they bundle) for a software that I bought for over a year. I reported that thing 10+ times! They didn't fix it ever. I changed the name of the file on every update. Over and over.
On the polish side, you're not entirely wrong, but it's debatable. On the UI side, most of the applications doesn't have the level of polish of paid applications however, some of the open source software is extremely capable and stable at the foundation level.
Amarok can handle ~350GB music archive with its metadata without even sneezing but, JuK shivers and dies when encounters the archive (both open source). Eclipse is a very robust piece of software while its UI is old, dated, and relatively ugly (I like it as it is though). Similarly Digikam is probably the best large photo management application out there with some very nifty features. There are not many multi-TB capable photo libraries out there. All of these software is free software. Also, Darktable, while is not the best, I use it more than my many paid and expensive photography applications because its tools and results are so good. These are the ones I use regularly. Not any of these applications force you to use it in a particular way because many people have provided feedback to it and they have large development teams and user bases.
I think we can say that software without big user bases force the workflow of the developer because, developer(s) cannot think any other way. Genuinely asking, can you provide some examples to such software? I may be biased since I'm using this thing 15+ years and may have lost some perspective, honestly.
> Linux is great if all you're doing is developing software with popular tools/languages,
I want to politely disagree with this. I'm an old school C++ developer who uses Eclipse and takes some photos and postprocess/edit them with purely free software and, I think it works better than most Mac tools that I paid substantial money.
> but if you want to use your computer like a normal person for a change, it's pretty bad. I've consistently had issues with basic functionality like HiDPI scaling, trackpad and wifi drivers, power management, and just general polish.
I didn't recently install Linux to any modern laptop built in ~2 years but, I have an HP EliteBook 850 G2 at office. This thing is running Debian since day one and almost everything (Trackpad, WiFi, power management) is working out of the box (I didn't compile anything or fiddle under the hood) and it runs solid 7 hours before its battery depletes. In your defence the fingerprint reader was unsupported at that time so I didn't fiddle with it and since I was not doing any hard work, I disabled its discrete graphics. I only reboot it when I install a new kernel to it.
My office desktop has a 2K display and, everything scales on XFCE4 and GTK out of the box. I didn't do do any tweaking. On the polish side, out of the box DEs are all ugly. A good theme and a good wallpaper makes them top notch I think. I personally use XFCE4 on my desktop and KDE on my laptop (and home desktop) and, I can say that, KDE can boost productivity of an average user 3-4x just with included search & indexing facilities and usability features.
> That's not to say that Windows and macOS are amazing and perfect - they aren't. But they're a whole lot better than Linux for normal use.
Nothing is perfect. Neither Linux, Windows or macOS. they are all tools. I love Linux because I believe what it stands for and I can work blazing fast with it but, I also have a Mac and support my families Windows systems. macOS is the most time-efficient system out there. Linux with KDE is a very close second. Well, windows is the same experience for me since Windows 95 (productivity wise, not stability).
Progress is only possible if we're honest to each other and ourselves. I'm not a Linux zealot and if I sounded like one, I'm genuinely sorry.
Because it still does not support ed25519 keys and because it is closed source you can do absolutely nothing to fix it.
Now I can't play it. And as that, I am sure there are tons of other (more useful than a game) software that people just lost access to run and they did not have the source code to migrate it or pay someone else to do it.
I guess we can gauge how much embrace+extend+extinguish MS is doing by whether Atom gets winded down or goes into maintenance mode. I know it's not as popular as VSCode is now, and development has slowed since it burst onto the scene, but if anyone at Github actively works on Atom maybe those people should be worried about being reassigned.
> "Embrace, extend, and extinguish" (EEE),[1] also known as "embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors.
> Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. > Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard. > Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
Embrace: MS enters the lightweight editor (Atom) space with VSCode
Extend: MS extends VSCode with proprietary WSL/SSH/whatever code that they use their deep pockets to maintain and push people to VSCode ("it works better with WSL")
Extinguish: VSCode becomes the defacto standard. It remains to be seen whether Atom will be affected by this in actuality but it's already been supplanted in popular marketing IMO. VSCode is already more popular than Atom AFAIK.
[0]: https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...
Sadly, too many people haven't been around for long enough to have seen it all before, and they fall for the new shiny every time. Then we get a few years of bad results where one product dominates and that part of the industry only evolves in the directions that suit the business controlling that one product, until eventually sufficient opposition has built up that a viable competitor is produced and we start to move forward again.
The Chrome teams (the ones that deal with standards, improving chrome, etc) are certainly filled with good people trying to improve the web, but there is such a conflict of interest there with a more open web or a web with certain features. Those employees are obligated to be on the wrong side of those discussions in really insidious/subtle ways sometimes, and those at the level at which strategy is conducted have a clearer view but have an even stronger incentive.
https://chromium.googlesource.com/chromium/src/+/master/docs...
For Microsoft, the text editor market is not something they need to dominate, but they absolutely do need positive developer mindshare. Why would they possibly care about extinguishing the competition?
> For Microsoft, the text editor market is not something they need to dominate, but they absolutely do need positive developer mindshare. Why would they possibly care about extinguishing the competition?
> You're not going to convince me that EEE applies to text editors for pushing Azure. Decisions on what Cloud platform to use are not made by a developer's choice of text editor, but by executives over fancy dinners, or the CEO's personal favourite in a startup.
For positive developer mindshare, every little bit matters. For pushing Azure adoption, every little bit matters. New generations of developers using VSCode in coding bootcamps and undergraduate courses will keep the habit of using VSCode for a very long time. One click deploy-to-Azure plugins that works just that little bit better than the equivalent deploy-to-<somewhere else> or with remote development functionality will combine with the loss-leader that is cloud credits to make it just that little bit easier to choose Azure. Just that little bit of better integration with Github and NPM.
All of this seems far fetched, but it's how you build market share from behind. Microsoft is in it for the long haul, even if the pace is glacial, progress is progress. Again, it's not necessarily bad for every involved developer, it will definitely be great for most in terms of productivity or other benefits. Microsoft's incentives must be aligned with getting rid of the competition if possible, it's how for-profit public companies work, but before that's even possible, they need mind-share -- you can't just buy mind-share, you have to build it sometimes.
I love that post, because it encapsulates exactly the kind of internal logic that traps not-fully-open organizations.
MS can't open source the remote Dev extensions, because the service that runs it (and much of the client code) comes from other, proprietary offerings and codebases. More concretely, they come from other teams that aren't used to open source, are discouraged from getting used to it, and/or don't have approval from legal to release code in the open.
This is not an EEE trap, this is normal bureaucracy for an organization the size of MS. Consider that for almost all of VSCode's lifetime, the OSS version has been perfectly full featured, only missing telemetry and copyrighted brand marks. Remote Dev extensions are less than a year old.
They have the same problem with the C# debugger: owned by a proprietary team, can't get permission to open source it.
It is extremely hard to open source "some" or "most" of your code, especially in a company whose USP is tight integration between pieces. The legal quagmires are horrendous. A tool that crosses so many lines, like an integrated IDE, are backed into positions like this.
Disclosure: I work for Microsoft in a totally unrelated department.
Also, fwiw i'm a lifetime vim devotee... used it as my primary IDE for a long time and still use it daily. But vscode won me over exactly with the remote code extensions. Now it's the only proprietary software on my toolchain (apart from my BIOS).
One reason of course is "embarrassment" as it's "ugly" code and you want to run a full review and audit and eventually cover private APIs from other modules. That's however solvable.
More complicated is another reason: Legacy software often contains code contributed by contractors and acquired from external vendors, where there is no license for making it open source. Sometimes such third party code is even deeply webbed in and legal review is a pain as you have to figure out the origin of essentially each line of code. This can be a lot of work.
I observed how Sun did this with Solaris and over multiple years managed to bring it down to a handful libs with third party code (some internationalisation thing comes to mind, meanwhile replaced in the illumnos sphere)
Make sure there's no offensive variable names and comments left over from that one guy who used to work here.
(And maybe not everything is offensive, but un-offensive terms exist?)
"It's now very common to hear people say, 'I'm rather offended by that.' As if that gives them certain rights. It's actually nothing more... than a whine. 'I find that offensive.' It has no meaning; it has no purpose; it has no reason to be respected as a phrase. 'I am offended by that.' Well, so f'in what." --Steven Fry
Except that "normal bureaucracy" is built on, and is infact an EEE Trap...
EEE is part of MS Culture, if you believe the rhetoric it "was" part of the culture (past tense) but things like this show it is still very very much ingrained in the very fabric of MS
>Consider that for almost all of VSCode's lifetime
Hmm VSCode is about 5 years old, so 20% of its life now has been Extending OSS with proprietary code, that is not a good statistic IMO
> It is extremely hard to open source "some" or "most" of your code, especially in a company whose USP is tight integration between pieces. The legal quagmires are horrendous. A tool that crosses so many lines, like an integrated IDE, are backed into positions like this.
Whatever the underlying cause, this strikes me as a perfectly good reason to be skeptical of Microsoft's forays into open source. It doesn't really matter what their intentions are—what you're describing is a company that can't do open source properly.
> Also, fwiw i'm a lifetime vim devotee... used it as my primary IDE for a long time and still use it daily. But vscode won me over exactly with the remote code extensions. Now it's the only proprietary software on my toolchain (apart from my BIOS).
I do want to clarify that I do not think VSCode is a bad tool -- it is a fantastic tool, evidenced by how many people are getting value from it and investing in it. You could technically run VIM inside it if you wanted, so on some level it's probably strictly better on some level. I was mostly worried about it being a trojan horse of sorts, I don't use it so I hadn't heard about the remote extensions and it caused my knee-jerk reaction -- appreciate you adding the context and showing that this was anticipated by the VS team.
vim scp://user@example.org//path/to/file
(Basically edits a local copy and pushes saves as scp uploads)
I've found this very useful in combination with a decent ssh config file.
One thing I'm jealous of VSCode (as an Emacs user), is the Google Docs-style collaborative editing. Seems particularly useful for pair programming in the covid-work-from-home era.
Same thing is done by JetBrains: you can have the open-source Idea CE for free, but if you want e.g. Spring-specific support in Java, you have to pay.
Whether this is a right balance for you, is for you to choose.
[Update: I didn't know the closed parts of VSCode are given away, too]
Technically, somewhat similar. Socially, hell no! If you visit the Idea home page, it's a normal product page. It offers to buy the full product or download the free edition. Their business is pretty obvious. On the other hand, VS Code page has misleading "Free. Built on open source." in big letters under the headline. What's their business?
e.g. if you look at the docs presently https://code.visualstudio.com/docs , you see some signs of it already with a section dedicated to azure containing extensions dedicated to managing and deploying to parts of azure from within VSCode.
Don’t get me wrong, my organisation has a several decade long partnership with Microsoft and they are one of our greatest business partners on the tech side, but the company hasn’t changed one bit. They’ve simply changed what is is they are selling from software licenses to cloud, and having lots and lots of easily available mostly open source tools is how they do that best.
Just look at their image transformation from evil monopoly to open source champion. But everything they do, works better if you buy their products. .Net core runs perfectly well without Azure, but it works just a tad better with things like application insights. VSC works perfectly well on Linux or OS/X, but it works just a little bit better with Azure integration or/and on Windows with WSL.
On a windows cpu with WSL, it takes like 30 seconds to recompile a simple nextjs frontend...
WSL makes 0 sense when you have unix/bash available in the OS like is the case with Linux/Mac anyways.
Maybe the azure part... But I stick to heroku/netlify/vercel anyway.