Microsoft promising `dotnet watch` for a while and then dropping that certainly doesn't help with the already pretty damaged view of Microsoft not caring about open source developers. Here is the gist of the situation from Microsoft's point of view:
> Throughout the last year we’ve been working to enable the best possible Hot Reload experience in Visual Studio 2022 and .NET 6. Part of our goal was to also explore making this feature available to customers through a variety of mechanisms such as bringing the full power of Hot Reload to as many .NET and C++ developers as possible when running through Visual Studio 2022 debugger, supporting Hot Reload when running .NET 6 apps without the debugger, and the very basic Hot Reload support we added to the .NET SDK tools through dotnet watch.
> As we reflect on what was accomplished, and what is still in front of us, the backlog continues to grow. This includes many high value scenarios that will benefit the broadest number of developers, including focus areas such as .NET MAUI, Blazor, adding support more types of edits, more optimized experience when working with XAML apps, and much more.
> With these considerations, we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022 so we can focus on providing the best experiences to the most users. We’ll also continue to pursue adding Hot Reload to Visual Studio for Mac in a future release.
So, first they wanted "bringing the full power of Hot Reload to as many .NET and C++ developers as possible" but now they shifted to "focus on providing the best experiences to the most users".
Best part of this whole thing is the pull request which was opened (https://github.com/dotnet/sdk/pull/22217) but " locked and limited conversation to collaborators" straight after opening it as Microsoft anticipated the backlash but still went ahead with the change.
Seems they still have a lot to learn before they can indeed be trusted.
I didn't read that as, "Our focus is changing from A to B," so much as, "We originally hoped to ship A + B, but A ended up being more work than we expected. B is achievable and impacts more developers, so we're focusing on that first".
Ugh. I've been using dotnet core on Linux since it was introduced. While it mostly works fine, I always had the feeling that Linux (and mac probably also) is a second class citizen. They care about Linux compatibility inasmuch as it allows you to build the application on a Linux-powered CI server and deploy to another Linux server. Developing outside of Windows? most of their tools are not available or have a greatly diminished feature set (for example, you can take a memory dump of a running dotnet application, but can't really inspect it without a Windows VM).
If not for JetBrains Rider, dotnet development on Linux would be close to impossible IMHO.
When looking for my next gig I'll probably be switching to something else.
I haven't had much experience with .NET on Visual Studio, but I would say that Jetbrains Rider is probably the best thing you can get for .NET work on Linux.
As a matter of fact, they implemented their own hot-reload functionality themselves [0][1].
I actually preferred Rider even before fully moving my .NET work to Linux. If you have any experience with IDEA, you'll feel right at home (they are very similar and can be operated with pretty much the exact same shortcuts).
Personally, I prefer Rider to VS on all platforms, including Windows. It has much better performance, feels like a modern IDE, and after doing Java for a few years in between .NET gigs using IntelliJ I've gotten to prefer how IntelliJ-platform IDEs work anyway. The "Structure" pane is super useful.
Whereas, Visual Studio... well, let me just say first that I know real people work on that product, some of them are probably reading this, and if so, I appreciate you.
Unfortunately, every time I've ended up having to switch from Rider to Visual Studio for some edge case scenario or to do an Azure deployment (before we moved that process into CI), I'd end up frustrated. Even with VS 2022, which is better, it's slow compared to Rider. Also, despite a couple of cosmetic coats of paint and new icons and such for VS'22, it doesn't really feel like a modern IDE or like it's changed noticeably since 2010 or so. Granted, stability is often a plus, but there's a ton of workloads in there that I don't think are relevant to a modern cross platform .NET Core 3.x/.NET 5/6 development experience and I suspect supporting all of that is a factor in why it's so slow.
I haven't even gotten into how much worse the performance in VS gets when you add ReSharper to the mix, and even with all the genuine refactoring improvements in VS in the past decade, I still feel like I'm working with a couple of broken fingers when I don't have ReSharper active. Better refactorings, better intellisense.
Generally yeah, but as mentioned in https://news.ycombinator.com/item?id=28969338 Microsoft also actively refrain from adding features to the dotnet sdk in order to have less people to use them, VSCode included, in order to stuff the same features into VS.
I'm honestly a bit surprised that people are still using Visual Studio (sans Code) these days. It was a decent IDE ten years ago, but nowadays I'd put it far down the list (not least because it means that you have to develop primarily on Windows which is... uhm... yeah, no thanks). Is the VS experience much better when you are using C# instead of C++?
If you're writing C# you basically only have Visual Studio and JetBrains Rider to chose between, and seemingly Microsoft is trying to get more people to use Visual Studio so lots of features are being added to Visual Studio instead of the SDK.
C# support in Visual Studio Code is abysmal, hence no one uses it even if they use Visual Studio Code for other languages.
The problem is VSCode isn't open source either. Code-OSS is the open source version from microsoft.
The extensions owned by Microsoft are proprietary.
So you can't run the c/c++, pylance, remote ssh, remote containers, c#, etc extensions in open source builds of Code - OSS like VSCodium.
And for some of those, if you manually try to install the extensions using the .vsix file, they fail because the extensions are hardcoded to work only on VSCode builds signed by MS.
Pylance being proprietary is so disappointing, given it's the spiritual successor to Python Tools for Visual Studio (PTVS). PTVS was an open source Visual Studio extension, which later was ported to VSCode.
90% of PyLance is open source though, via the PyRight extension upon which its based. I'm not saying it's not disappointing its proprietary, but it's sorta inline with the "open core" philosophy that a lot of corporate open source work aligns itself with.
Ay, you're not wrong. But even granting them that, they disappointingly say “The Pyright extension for VSCode ... is not guaranteed to be ... maintained long-term.”
The only parts of the C/C++ extension that are proprietary are parts like intellisense, which were lifted wholesale out of visual studio. Which is to say, they were never open source to begin with. All the work the cpptools extension team has done has been open source.
The C# extension is open source, and is run in VSCodium. It's a fork that just swaps out the debugger component, which is a drop-in replacement since it's a binary download. The whole stack otherwise - OmniSharp for VSCode, OmniSharp-Roslyn bindings, and the underlying Roslyn language language services - are all OSS.
I don't think people will swap out VS Code for the full fledged Visual Studio. The people using Code for .Net Core work will likely spend the money on Rider. Everyone else will be kind of puzzled at the comparison; it seems pretty heavy for Python (or Ruby, Clojure, etc.)
Looks like Microsoft has figured out where their feet are and are taking careful aim.
To the person who downvoted me: I'd like to hear some arguments. Perhaps you don't need to. But that's irrelevant -- the world at large does. That's the main point of the post, too.
The Visual Studio Code thing is kind of a shame. It seems like a variant of "embrace, extend, extinguish" inasmuch as things like Atom exist (which microsoft also owns, womp womp, but didn't for 3 years after Atom started). It competes in the space, keeps competitors weak by being the best so that it gets all of the users and mind-share and resources, but doesn't go all of the way with them because it could compete with their proprietary products...so while being the best is a good thing, it's not a good thing when it creates a monopoly-like product in a space good enough to suck up landscape resources so that no viable competitors not under Microsoft's thumb could ever start approaching parity with their proprietary products.
Definitely dents Microsoft's nascent open-source credit with me and, like so much of Microsoft's history, seems actively damaging in a monumental way to the history of computing itself for Microsoft's benefit.
Visual Studio Code has also some official extensions that are not open source and the official build contains a few proprietary features by default.
The only thing I like with Visual Studio Code is that they were able to promote a cross text editor way to have auto-completion and other IDE-like features, thanks to the Language Server Protocol. Now I can use these features in Vim and Kate.
> Visual Studio Code has also some official extensions that are not open source and the official build contains a few proprietary features by default.
I don't understand how that is remotely ok. VSCode's main binary links statically against Blink (as it uses Electron) which is under LGPL, at the very minimum they should provide a way to relink that binary as per LGPL requirements.
I don't think there s a static linking going on there, else it would be impossible to use Electron for closed source software. Though it is used for things like Discord.
Unfortunately there are extensions & features that (last I checked) only work in VSCode but not VSCodium. 'Remote Development' extension was the one I found out was apparently closed source.
That one is based on "proper" VisualStudio's remote development features, so it originated from a closed source product. Having observed that multiple times, I assume that open sourcing it is a major effort as this probably includes some third party code or patent licenses or something which prevent open sourcing. At least I don't see the business case Microsoft would play there in keeping it closed but freely available.
But who knows.
And: That aside the role Microsoft nowadays plays in the open source world is reason for concern, while their current actions are mostly positive.
The business case is a combination of Discretionary Pricing, and Moat - those are the business school names for the strategies you can look up if you like..
The Discretionary pricing comes in the Tiers, while the Moat is provided by VS Code reducing the chance of real competition against Tier 1 or 2.
The removal of hot reload from VS Code is to provide differentiation between Tier 2 & 3, to drive customers to paid versions.
--
Tier 1 .. Visual Studio Enterprise - expensive
Tier 2 .. Visual Studio - low medium cost for a business
Tier 3 .. Visual Studio Code - 'free' in exchange for your info (via telemetry) and reduces the chance of a truly open competitor challenging the above tiers. This one must walk a line between being less useful than above tiers so there's value to buy them, while being more useful than other 'free' competition in the short term so they attract mindshare away from other OSS that might otherwise grow to challenge the higher Tiers
VSC being marketed as open source is certainly a grey area (there are arguments both in favor and against), but it's not a bad situation as it seems.
IntelliJ IDEA is a competitive "open source based" product, with a significant market share (which qualifies as "viable competitor not under Microsoft's thumb").
VSC's "base open source" product is actually equally or more capable than IDEA - see VSCodium; its existence is proof that in worst-case scenario, a capable open source editor would still exist. Although there are some omissions, I think that given the MIT license, in theory a competitor could also build a series of commercial plugins - if I'm correct, this would actually be an interesting scenario.
gates, ballmer, allen, nadella etcetera etcetera microsoft lives in the grey area. i’m pretty sure epsteins plane was grey. pretty sure they were all good buds.
I think the idea here is "dumping". By subsidizing a free, best-in-class editor Microsoft prevents any competing paid options from gaining a foothold. This is not too different from their old strategy with IE.
Making a paid product for something that's a choice of the individual user is a non-starter these days.
What I mean by that is something without network effects. If your company uses Google Docs, you don't have much choice because that's where everything is (modulo apps that can sync to it so you can use a different editor).
For something like VSCode, at the end of the day it's still just a text editor. My use of VSCode doesn't stop my teammate from using vim.
For something like that, do you know how much of a pain in the ass it is at most companies to get them to buy something? The issue isn't even if it's $5 or $500. It's just going through the process of figuring out how to buy something, getting approvals, figuring out how to deal with the invoice, etc. Unless I'm already super committed to it, there's no chance when I can simply download any number of free options out there.
Even if it's explicit policy at a company that employees can expense a text editor or IDE, a large proportion of people will still never bother. I saw the "Please buy Sublime Text!" pop-up all the time at my last job, and that was at a small startup where everyone knew the company was happy to pay for it.
I understand what you mean, of course. I am not sure if anti-dumping was ever applied to products given away for free with zero unit cost economics. If applied incorrectly, Apple and Microsoft could argue that Linux and Linux-based OSes being free is illegal!
Dumping operates by selling below cost. If you sell below cost and your competitors don't, nobody buys from them but they still have to pay rent and the salaries of their factory workers if they want to maintain the ability to resume production, which drives them out of business. If you sell below cost and your competitors match you, they lose money on every sale, which drives them out of business.
Then you have no competitors and can start charging the monopoly price, and no one tries to enter the market for fear you'll start dumping again.
Charging nothing for a product with no unit cost doesn't work like that. You're not forcing anyone to sell at a loss and the intent isn't to raise prices after they're gone.
The concern there is that you could come to dominate the market (even if the price remains zero) and then leverage that into other markets. If one IDE has more users than any of the others (market dominance) and it integrates with the vendor's hosting service and their proprietary APIs for their proprietary operating system and their app store and payment systems, that's more like tying than dumping.
Doesn't this describe a lot of significant software in the present?
IE and Skype were criticized for being terrible pieces of software, and people were desperate for something to come and disrupt their target markets. Now Chrome and Discord are being criticized for being so functionally superior to their predecessors - as well as every other option - that nobody is left with a choice anymore.
Developers don't want to choose anything besides Chrome because nearly everyone has been convinced to use it from the quality of the product, so sites are broken on other browsers, causing more people to move to Chrome. Critical information found nowhere else on the internet is locked within Discord, because almost everyone wants to use Discord, so you have no choice but to also use Discord to communicate with those people and view that information.
In the process, Discord becomes the sole owner of that crucial information, and Chrome becomes the single deciding factor in how web standards are developed.
Not "the best" per se.. Rather "good enough" and part of other tools the customers already use, while keeping them free so it becomes a matter of having to spend extra $$$ for another product.
Take Teams for example. It's a pig of an app IMO. Slow (takes almost a minute to start on my otherwise-fast M1 Mac), extremely high memory use, constant errors "Oops something went wrong + cute pic of ice cream", a mess visually and not dense enough UI. They focus all their time on adding new features rather than optimising. They also focus very strongly on the "for everyone", trying to be a jack of all trades, master of none.
Slack does a much better job at team collaboration IMO. Especially for tech users, it's fast, shows a lot in small screen space and isn't as heavy (though I really miss the IRC bridge!). But Teams comes for free with O365 and integrates fully with that ecosystem. So no hassle with integrating with your ID Provider etc, it's just plug and play. So if you'd want to have slack at work you'd have to make an unreasonably strong business case for all the extra cost and work.
Another example: Sharepoint. I doubt you could find anyone who would consider Sharepoint best at anything. Yet it's still used heavily in favour of other options, because it's again free if you're already in the MS ecosystem, and it integrates with all the other tools like OneDrive and Teams (both basically just layers on top of Sharepoint). So even if you're not using sharepoint, you're using sharepoint :P
I do agree they are the best at the VS Code niche. But usually this is not their game, they go for 'good enough'. Maybe it's because their developers dogfood VS Code so they couldn't stand it being slow :)
For example, VS Code is highly optimised and doesn't suffer the performance drawbacks that usually come with electron. They have optimised the hell out of it. However they never bothered to do the same with Teams, probably because they own that space anyway.
It’s tricky though, because they will compete hard on some things if they sense it’s vital. Look at SQL Server, 2005 was probably the most improvement I have ever seen in a single ms release. But once they establish a lead they crank down the dial and cruise.
Decisions at large enterprises is large driven by compliance considerations. I once asked why we were picking a specific Microsoft product when it was inferior to the alternative and the answer i got was "The Microsoft platform is approved". So because we had some random Microsoft product we have already paved the way for the dump truck in the future. That's the magic of Microsoft.
To be completely clear, I don't blame the guy. The approval process sucks, so if you get to bypass that, it's a huge win for your own sanity.
I think they're arguing that you'd need to make a much better business case for Microsoft competitor products than you would something else, because you're up against the "we already have this at home" response.
> The big issue here is that Microsoft has an internal struggle going on at the moment. On one hand they want to be seen as a new version of Microsoft who loves Open Source, but on the other hand they want to actively block advances in OSS projects like the .NET SDK which could undermine their own commercial offerings.
For years, the narrative has been that MS doesn't want to give away their tools for free because they don't want to undermine the commerical offerings of their ecosystem. There used to be a ton of companies making development tools, components, and so on. Microsoft mostly made money with Windows, Office, and so on, so they could give away their own tools almost for free (but preferred not to in order to keep the vibrant ecosystem running). It is really odd that anybody at MS cares about whether VS or VS code or an external tool is more popular.
Also this whole infighting between departments seems to be contaproductive. If I were top level management, I would tell people to get their shit together. If instead of working together to make the best products possible, a manager tells off an employee for working on the C# extenstion for VS (because it hurts his personal goals) I would at the very least reprimand the manager. That VS code has poor .NET support, or for another example that MS graphical toolkits have so much churn and they don't use them themselves, are really embarrasing mistakes. I'm sure people have been fired for lesser problems...
In 2000, I worked at a web company that was a “Platinum Partner” with MS, and we did a lot of consulting work with them for various large clients. Me and another guy were invited to come out to learn about this new platform that MS was building called “Cool”, which was the internal name for c# at the time, and the early forms of .NET.
While we were there, Scott Guthrie (I’m 99% sure it was him) was supposed to lead us in some discussion but wasn’t there, and someone filled in for him. We learned later it was because he had been called into Bill G’s office and got dressed down a bit because Scott had basically created his own version of Apache web server to use within the dot net tools. It was rudimentary and temporary, but the reason he did it was because he had been trying for months to get the IIS team to give him a version of their server for use within the dot net dev tools, and they just kept putting him off. So he went around them and built his own. They found out, went up the chain, and Scott got dragged into the office to be told to cut it out and work with them instead.
Granted, this is 20 years ago, so my memory might not be as crisp, but it stuck with me as a lesson that Microsoft was not a single company, but like 10-15 different little companies, and they competed among themselves as much as they worked together. And as OSS was coming up at the time I thought, “they have no chance to survive what’s coming.”
In a .NET Rocks episode there is a guest that recalls his team using him as means to get information, because he was an external contractor, and it was easier for him to get the required information from another team, than having both teams talking directly.
> Microsoft was not a single company, but like 10-15 different little companies, and they competed among themselves as much as they worked together.
This is true for probably most – if not all – companies above a certain size. In my experience it really takes off at about 100 people, and it gets worse from there. My armchair psychology take is at that level you no longer know everyone in the company personally and "cliques" begin to form.
It has always like that, that is why we lost Managed DirectX, XNA, .NET Native, C++/CX, the Longhorn failure, MAUI vs Forms vs WPF vs WinUI vs UWP vs Blazor.
I am not affected by this as licensed VS user, but I also don't like how this story has been playing, and join my voice to those complaining how this was handled.
> I know what you think. You might think I’m reading too much in-between the lines here, but trust me on this one that I am not wrong.
No, I don't think I will trust you as telling me to trust you is not a valid qualifier. And, I do think you're reading too much in between the lines. For example
> but more importantly they also won’t deny it.
Please stop with low effort clickbait.
There are no mentions of all the positive outcomes that have emerged from their open source shift. In other words, it does focus too much on recent drama rather than putting this in the context of all their contributions.
Nor, considering the title of the article, has there been any consideration for the overall ecosphere of the tech giants that are playing in this space. If you ask the question, then look at who the others are. I cannot think of two worse companies to 'trust' than Oracle and Apple and represent the antithesis of openness. There are existing contributors, Google and Facebook, who do plenty and can somewhat be trusted considering their nature, and despite their reputation. There you will find a similar pattern, some things are open and some are proprietary Looking at the context of their contribution over the past few years I would put them firmly in the latter category. The answer to the headline is: yes, somewhat.
Lots of "commercial open source" products use limited features in the open source tool to sell the "pro version". Maybe what we're seeing is not MS being awful, but executing a pretty normal open/premium type strategy (hi there ElasticCo).
As a developer I'd love to be able to use .NET like I do Python, Go, JavaScript and Nim (ok, and Java, too). I love being able to write software that can run anywhere, using the editors and tooling that I like. VS Code is amazing in that it fits into my world. VS on the other hand, forces me to run a specific OS, and use a prescribed tool chain. FWIW, sometimes the prescribed way might be better, but it's not the way I want to do it.
There are a few scenarios where it breaks. UWP and Xamarin is dicey. Ironically, it hasn’t been able to edit android layouts involving ConstraintLayout and a few other common layouts/views for a few releases now (ironic because they also make Android studio, which has best in class android layout editing).
Visual Studio is great for the common platforms/languages, but as soon as you try going cross platform or adding unloved platforms (UWP, Xamarin) it gets bad. Unfortunately, those also happen to be the things Rider is bad at.
> Maybe what we're seeing is not MS being awful, but executing a pretty normal open/premium type strategy
There is a difference of degree, if not kind.
It's one thing for a smaller vendor to offer an 80% solution for free, and 20% enterprise features where there is competition to protect the market and the users.
It's quite another for a monopoly-level player that, for example, owns GitHub, to flex and threaten the market.
I'd support some serious anti-trust looks at what's going on across all of BigTech. MisterSofty is not alone in needing a review.
The software is still open source. If you want the premium feature for Hot Reload, then it’s like $13 a month for a license for Linux/Mac/Windows. Everything else is fully supported for free.
Again, what pisses people off is not that some features are premium but rather when features are promised to be free/open source, was working in the open source version but then pulled back to be a premium feature when Microsoft changed their mind.
While that’s true, since we are talking about trust… I can trust Microsoft’s intentions more than I can Googles or Facebooks.
Microsoft wants to make money by charging for features. Unlike Apple, they consider developers to be actual customers. So I trust them to take care of our needs, and trust that their only ultimate motive is to get us to willingly empty our wallets in order to be more productive at work.
They won’t steal our data to sell to political relations companies like Facebook, create walled gardens and charge us 30% to import goods to our own captive customers like Apple, or arbitrarily try to control what can and can’t be done on the internet like Google.
They will just charge money for features like a normal business.
Why would trust anything to any company? They are not entities that you can trust and then everything is fine. They are face-less entities that turns on a dime if it makes them profit, because that's how capitalism works.
Don't look for companies intentions, look for their actions, as that's the only thing that matters.
Windows Home or Pro have mandatory "telemetry", as do a lot of their applications. It's even in the .NET Core CLI tools and has to be explicitly disabled.
> to sell to political relations companies like Facebook,
They own LinkedIn.
> create walled gardens and charge us 30% to import goods to our own captive customers like Apple,
They tried with Windows S.
> or arbitrarily try to control what can and can’t be done on the internet like Google.
They certainly tried in the 90s until they were stopped by the government. They saw the web (and Java) as an existential threat.
If they haven't been as successful as some of they competitors in doing evil in particular areas, that's not for lack of trying.
They own part of facebook, and they steal an incredible amount of data from Windows these days.
They have been trying to create a walled garden, with UWP and Microsoft Store. They have done poorly in the market but attempted a number of walled garden platforms.
Windows store is an attempt to charge 30% as Apple did.
They have tried in many ways to exert control on the internet, but have been outcompeted there by Google. One example of their control is SmartScan which scares users away from downloading programs they do not approve - a kind of walled garden. Many of their OSS plays are exerting significant control on users.
>> They won’t steal our data to sell to political relations companies like Facebook, create walled gardens and charge us 30% to import goods to our own captive customers like Apple, or arbitrarily try to control what can and can’t be done on the internet like Google.
I don't mean to unnecessarily defend Microsoft (they're a billion-dollar multinational organization and don't need my help).
It's just that if we want to say they're 'evil', I think they are so in different ways from FAANG. Could they do what Apple or Facebook do? Sure. But doing so would mean giving up their idnetity and becoming a pale version of their competitors.
I'm not sure anyone really enjoys working with Visual Studio anymore. It was compelling, back in the day, when I was doing desktop apps. But for web development I just don't think it has any real edge over other tools in this space.
In my experience it's also a resource hog. I have to quit and restart it every so often to keep it from bogging everything down.
I should also note that modern Visual Studio is way too heavy. Just compare it with another leader of commercial IDEs - JetBrains. Now, with latest Clion and Rider they rival VS while being more modern and sleeker. Not to say they are crossplatform.
Sure. There is just one thing though: we tend to treat companies like people. So e.g. if they say something today, we expect it to be valid also tomorrow. We also tend to expect them to behave in a way humans do, that is, if they present a certain vision, we somehow expect they would follow. And if they follow certain steps, we assume they walk the talk and give them credit for that.
But the reality is much more complex. You have competing teams of individuals each with their own interests. You have managers who come and go. You have sudden decisions that change everything during one afternoon. As an employee, you believe in something only to discover a few months later you were in fact mistaken.
I'm not cynical, but the best strategy is to be realistic. We all know Microsoft will do everything in their own interest and they are not basically different from any other company. That's a fact. Whatever they say about their love for Linux or Open Source is correct as long as it benefits them, not an inch more. Whoever goes in their way will be mercilessly crushed, as happened in numerous companies in the past like Lotus, Novell, Borland and so many others. Don't build your business based on their products, and if you do, have a backup-up plan and an exit strategy ready.
I am an advocate of such kind of features, however the way this situation was handled is quite messy, the feature was already there and available on dotnet watch, when they decided to kill it.
I own a VS license, so it doesn't affect me, but it leaves a sour taste.
Open source is a philosophy and ideology. Software freedoms are important.
People who release some software as open source and some software as proprietary don't believe in software freedoms. You can't mix and match without philosophical inconsistency.
IMO free software is a philosophy and an ideology. Microsoft's actions (proprietary VSCode extensions, crippling dotnet) are designed to generate goodwill, but hurt the freedom of its users anyway.
Individual people can be trusted, but trusting a corporation is a contradiction in terms. The leadership of any team can be replaced pretty quickly and goals can pivot on a dime. Or, like with Sun, the company may be acquired by another with completely different objectives.
If you want commitments from a company, get it in writing (in this case in the license).
I also don't get this part:
> They won’t develop cool features like these any more and most frighteningly, they won’t accept pull requests or community contributions which could add these features back into the SDK - and that is a bleak outlook for the open source community in .NET.
What stops someone from forking the SDK and adding this functionality? Or are there non-open-source components this all relies on?
> What stops someone from forking the SDK and adding this functionality? Or are there non-open-source components this all relies on?
I've felt the benefits of Microsoft's OSS push over the last decade, and I've been an advocate for their work. As such, I've never felt the need to run VSCodium, and I've been OK with sending Microsoft telemetry from my VSCode install (though I would prefer it was opt-in, rather than opt-out).
But now they are trying to have their cake and eat it too - they want to keep up the "developers, developers, developers" mantra, because they can deeply their tooling with Azure and nudge devs in it's direction. But they also still want to maximise revenue from their commercial IDE, Visual Studio. And as a result, they are half-arsing both goals, a strategy that is absolutely doomed.
And you know what, for a feature like `dotnet watch`, it's just so completely unnecessary, as VS would still be a very different and vastly more capable IDE than VSCode. This really feels like some high-head in the background is pulling new strings, and I really don't like it.
I'm also 100% certain that if `dotnet watch` is discontinued, someone will reverse engineer it (very easy with dotnet!) and release it as a third party dotnet global tool, which makes this whole situation even more pointless.
I hope VSCodium does start to add in functionality that Microsoft is trying to keep for themselves, starting with the dotnet watch code that was written and not merged - extra functionality would be a very compelling reason to use VSCodium.
I honestly don't really like VSCode or see the hype. To me it feels very clunky. I'm spoiled with IntelliJ but I also use regular Visual Studio Notepad++ and Vim and I've Xcode in the old days, and all seemed better than VSCode.
#1 issue is that the extensions are all written in TypeScript and run in the background. When I click to go to a definition, rename, run, or even save, I get that "progress bar" and it takes at least a second. A lot of extensions are also buggy. Vs a "real" IDE like IntelliJ or Xcode, which does those operations almost instantly with significantly less bugs.
If VSCode isn't a "real" IDE, then it competes with other text-editors like Notepad++, Vim (not counting advanced versions like Spacemacs), etc. But those are way faster and less cluttered because text editing is all they try to do.
> I honestly don't really like VSCode or see the hype. To me it feels very clunky.
It's funny because I've been trying WebStorm and it brings my i9 16" MacBook to a crawl so VSCode feels much "faster". It doesn't help that simple operations like renaming anything are multi-step processes or are just apparently missing (no apparent way to delete a file or visit its parent folder from the command palette)
I agree with the rest. VSCode to me is just a little step up from Sublime Text for UI and base features, but it's still a far cry from proper IDEs like WebStorm (of which I like the proper refactoring features)
VSCode extension are written in Typescript but most of them rely on a language server for things like refactoring, type hints, code completion etc. These language servers run as native process (written in Go, C# etc), so are (roughly) as fast as your machine is.
If these operations take over a second it may be an issue with your machine or install of VS Code
I've felt that VSCode (and Sublime, etc..) are all text editors when you download them.
Then you install extensions/plugins to move them slightly more towards the direction of IDE.
I see text editors as fast. IDEs as slow but full of features. This allows you to find a middle ground that works best for you. That is as long as you don't do the rookie mistake of installing 100 extensions, 90% that you'll never use but you read about them in a blog & they sound awesome! Kind of like we all do for books, videos, etc.. Someday I'll use them!
> I see text editors as fast. IDEs as slow but full of features.
Me too. The problem with VSCode (and Atom and maybe Sublime) is that even basic IDE features are slow are buggy. And when I'm using an IDE, I constantly use "basic" features like jump to definition, find definition, rename, etc.
IntelliJ is impressive in that you can type, rename, type, jump to definition, rename, etc. and the operations are so fast that they don't disrupt your flow. Vs in VSCode where the operations will pile up in the background. Not to mention, IntelliJ's operations are usually successful, but VSCode's are usually not.
If VSCode could do basic things like jump to definition and rename properly, while still being super fast, then it would be really useful. But idk if it's just me but even in TypeScript I don't get those capabilities.
Not sure if it's you or me. I have a few extensions installed. But I'm fairly confident, especially in TypeScript, that F12 on Windows will jump me to any definition. If I click F12 on code that defines a class or React component, it pops up a window showing me different files & code that is using said class/component.
I'm generally weary of MS having too much influence over open source with Github and VSCode, particularly due to their history.
My creep alarm went off a bit when I recently started a project to test the waters with TypeScript. I was asking on a forum how to deal with native JS dependencies without types, and he answer I got was "Are you using VSCode? It will just find the community maintained type packages for you".
It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it. If one were to pursue an EEE strategy, this would not be a bad way to start.
> It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it.
Certainly “making a better product that’s easier to use” isn’t something we should be discouraging.
They are not forcing you to use their solution. You can go your always go your own way.
I am primarily a vim user with VS Code as my secondary editor. I have never ever used their one-click solutions.
I have seen someone choosing "Yes" to everything VS Code said after installation, and in no time their machine was filled with bloat that they would never ever need.
But I see this as a good thing. It is making programming set up easier for the uninitiated, which is good.
I disagree that making setup easier for the uninitiated is good.
The uninitiated should begin with a bare-bones text editor and a shell prompt. If you don't understand what is happening from that level, you will never understand what is going on in complicated frameworks. You will be the programming equivalent of your grandmother who thinks Facebook is the internet.
Okay, but, does that enable you to solve the problems you want to solve using computers? We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution.
I would not be as hard-line as the other commenter in terms of suggesting that everyone should start with bash and vim, however I think it is a valid point that learning the principals of computing is valuable, and tools which abstract that away are not always doing you a favor.
> We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution.
I of disagree that time-to-solution is the true end-goal. It might be, depending on your use case, but there may be other constraints. For instance, let's say I make a piece of software, and I have a choice between choosing an "easy" solution which takes me 100 hours to complete, or a hard version which takes 500 hours. And let's say the easy version allows the user to complete their task in 30 seconds, where the hard version allows them to complete their task in 10 second. That means every time my code is executed, I have saved 20 seconds of the user's time by doing things the hard way.
Now let's say my code is executed on average 1000 times per hour. That means every hour my product is out there, I save about 5.5 hours of user time for doing things the hard way. In only 72 hours, that 400 hours of productivity I "lost" is made up for, and for the rest of the lifetime of the product it's pure upside.
At the end of the day, programming is about making computer hardware do what you want. If we let ourselves get too far away from the computer, it's hard for us to do that well.
And the best way to spend as little time as possible solving problems is solving them the right way. Which you can achieve best with some understanding of what's actually going on in the background.
If you know the basics you can apply them to any tool. If you only learn to build software using a specific framework, IDE etc. you're probably going to have problems if anything in the setup changes. One day in a simple text editor and a shell taught me more about how Java builds work than years of formal education, because all those years were spent in an IDE and nobody even explained what the classpath is.
There's a lot of truth in this. Getting the uninitiated to the point of solving problems is not a bad thing, per se, but too much of that creates cargo cult programmers, and that is a very bad thing. And very common.
If your goal to solve a problem, then you should use something that helps you solve that problem quickly. If your goal to learn how to solve problems, then you probably shouldn't. Those are both valid use cases, but they are very different.
This is a false equivalency, you can always go back and learn how the lower layer works. Tons of people learn how to drive, and many of them go on to learn how their car works.
Get people excited and empowered, then teach them some arcana.
Although I sympathize with this line of thought, remember that we’re all uninitiated by the standards of a few decades ago. The time was when you were uninitiated if you couldn’t hand assemble your programs to a series of hex digits. Indeed, I own a copy of a book aimed at children that teaches you how to do just that for the BBC Micro and ZX Spectrum. (The publisher released it as a free PDF if anyone is curious: https://yurichev.com/mirrors/machine-code-for-beginners.pdf)
that PDF is awesome and i have never seen it before. i had to teach someone about programming from absolute zero and i followed a very similar approach. starting with what a transistor is, a basic intro into a cpu, what machine code is, low level languages and high level languages which took us into a python hello world. you could see the wheels turning at the end of the session...
That sounds amazing. It makes me want to learn more about transistors, and how CPUs actually work at an EE level. My studies started with registers and machine code as the "ground truth" - but it would be cool to have an intuition about what is actually physically happening inside the CPU and memory.
I agree with what you are saying, and probably it is part of the nature of progress to continually move some of the core topics out of the realm of CS common knowledge to make way for the new. However I think not all things are created equal.
For instance, I think basically everyone can agree that moving from assembly to C and other high-level languages was basically a strict upgrade, and obviated the need for assembly programming in all but a few specific use cases.
By contrast, using the command line and shell programming is every bit as relevant as it was 20 years ago, and I don't see that changing any time soon.
Both assembly and the shell are difficult and alienating to newcomers. But learning is mostly academic at this point, while learning the other opens up entire new worlds in terms of what you can do with a computer.
In other words, learning assembly is like learning latin. Maybe interesting, but not particularly useful. Learning bash is like learning Chinese. Not particularly easy, but there's a lot you can do with it right now.
See I disagree that it's a good thing. I think accessibility is a good thing, but I would rather see it in the form of better development stacks from the ground up.
Just building more tooling to cover up pain points by wrapping them in more and more layers of bloat is just making a mess. You wind up needing a super complex system to do simple things, which nobody really understands, and which uses a ton of unnecessary resources. If you extend that strategy ad infinitum, you need Moore's Law to persist just to keep performance stable while running more and more layers of VSCode plugins.
I also don't necessarily think some barriers to entry are always a bad thing. Things like notebooks are great for giving people access to a simple programming environment which is easy to set up. But if someone is going to be committing code to a serious project I'm working on, I don't mind if they have to know enough about computers to at least run a few commands in the terminal.
It seems to be me you are arguing against the very nature of complex systems, and the way we have built the entire computing stack for the last 80 years.
Lower level technologies need to be more flexible to allow usage in many different cases. On top of that we build different abstractions that are suitable for only a restricted number of uses cases, but that make them much simpler to think about and work with. By thinking at this higher level we are able to build much more complex logics than we would have before.
I certainly wouldn't want to be stuck in a world where we still have to do everything in assembly because we were too afraid to embrace the compiler.
I'm not against abstraction in principal, but in my opinion it should be intentional and measured.
Progress isn't only about building and endlessly taller stack of abstractions such that we eventually can't see the computer underneath. Sometimes it's about looking at the stack we have, and building a smaller and smarter one based on the lessons we learned along the way.
Not at the margin, no. If you can solve a problem by clicking a button, why the hell would you spend more time doing it any other way? Some sort of principle? Seems poorly justified.
It should still be possible to solve the problem manually, though. Inevitably someone will run into some special case where clicking the button doesn't work and more control is needed.
Arguments that more powerful tools should exist are not arguments that having a button for things is bad. It would be better if more things were just buttons.
If they know how that btn click solves the problem, then that's fine. But if they are an engineer and they don't know what the btn does, then they aren't really an engineer in that sense. While that btn click may help them solve that problem, knowing how that works is important to motivate solutions for other problems that are analogous to it which is the job of an engineer.
If they're an enduser, btn click is exactly what they should use. If they are an engineer, and clicking btns is all they know, then they are going to be a very limited engineer. This too is fine and there is a place for that. But, if such an engineer starts to think that they are a great engineer because they solve all the problems quickly whenever there are btns, they are going to be a liability for teams when there aren't any btns to click. Because they are going to be too arrogant to listen to those who might know how to solve them which aren't necessarily btn clicks (because to them all solutions must be btn clicks). You see, it's more than a matter of principle. It's about the calibre of the engineer you want to produce.
This is a whole chain of assumptions not rooted in anything I said. I'm not saying you don't need to learn anything. I'm saying there's no sense in making trivial tasks harder than they need to be. Of course you need to understand how to fix problems when there isn't a button to click. That doesn't mean more buttons to fix things is bad.
If that also puts a single entity in charge of determining what features go into, and/or what fixes remain out of, that "better product", then there is a very real control issue.
Look at the case of the Web, HTML+CSS+JS standards and specifications (Drew DeVault triggered DDoS measures simply trying to access documentation), and the inability of even G-MAFIA scale companies from being able to sustain their own independent browser engine cores (Microsoft and MSIE).
Control is the ability to determine the options of others. A single entity providing an overwhelmingly appealing programmatic interface is a locus of control.
Pretty much all community types come from a single repository with a consistent naming scheme. For example, if you use “lodash”, types are available via “@types/lodash” from DefinitelyTyped (the DT repo is now maintained by the typescript team). This is even tracked on npm. VS code can just see if “@types/$package” exists and then prompt you to add it
VSCode is open source, so relying on it isn’t relying on something proprietary. (The standard builds do contain some closed source telemetry stuff IIRC.)
When you open a Python project, the recommended Python extension is Microsoft's proprietary Python extension with Pylance which refuses to run on VSCodium or Linux distribution builds of vscode-oss. I refused to install it, so I didn't test whether you can enable the older open source LSP instead. And I couldn't find any other Python extensions sadly.
Yeah I think this is just one example of how VSCode can serve to blur the lines of what are OSS dependencies, and what are proprietary ones. It takes a certain amount of vigilance to have a truly open source development workflow on VSCode.
> makes it very easy for developers to become reliant on proprietary workflows without even realizing it.
Most young developers don't care due to inexperience and coolness factor. As code becomes more sophisticated, build reproducibility starts to become a problem.
And, Microsoft is trying to own the toolchain's strategic points this time, making reproducing a build almost impossible without their tools.
Yes exactly. And a lot of this stuff is open-in-name-only. Like I tried to implement an LSP for a language I am working on using Sublime and nvim as test benches, and the documentation is so bad and some of the interfaces are so convoluted that it seems like it's basically impossible to do without starting with their VSCode starter project or reverse-engineering an exiting LSP.
And with the push towards remote development, I can see things moving toward a world where the default is not even running things locally. Lines get blurred, and sooner or later you're depending on proprietary Azure services without even realizing it.
On the other hand, Eclipse is still steadily improving. They're already very good in remote development. Lately they've implemented "build into docker". Concerning containers are a more open technology (many runtimes, open standards, etc.), there are still very good real IDEs with very rich features.
How is eclipse doing in terms of performance these days? I used it maybe 10 years ago for some C++ and Java development, and it was quite capable, but it had the feeling of being a lurching behemoth.
That's been a huge & awesome improvement in VS Code & Visual Studio with package managers. I think there are plenty of items to be worried about but I don't think this is one. It's a nice feature.
I say this as someone who had to search through a crazy large GitHub repository of community Types back in the day all the time. Then you end up having to send some PRs & wait for them to get approved if you hope to use the types in a larger team or as part of a build process. You could also create your own fork until they're approved & then go back & update the package.json.
That's why Microsoft can't "own" open source. So they decided to "own" the open source developer by owning the source repository he uses, owning the editor, owning one of the most popular languages (Typescript) he uses, the command line shell, he uses along with grabbing all the Linux commands and make them available on their own platform.
This is not about proprietary code (owning the code), anymore, but about owning the platform and making people use it. I doubt, they have a clear plan, right now, instead they hope, that it will play out positively for them, in the future. A few years from now, I wouldn't be surprised, if you'd need a Microsoft account to log into Github.
I agree that they probably don't have a clear plan here. I would speculate that they saw the writing on the wall that Linux and OSS had won, and they just started doing anything and everything to gain influence in that space.
And there's no company I trust less not to abuse that influence once they see the opportunity to use it in an anti-competitive way without consequences.
The plan, as near as I can tell, is watching Google leverage Chrome and Android user base into votes for standards.
Microsoft finally realized standards and interoperability was the future. They also realized that a requirement of being able to extract profit in that future was having power to influence standards.
Consequently, open source tools (and more importantly, the dev/user share that comes with them) get Microsoft votes. Either explicitly or via mind share.
And when it's a corporate priority or matter of survival, they use those votes to advance Microsoft's interest.
We've seen this with Chrome / web standards for years now. Most of the time it's good for users, but sometimes it's just that important to corporate reveneue.
I mean MS basically invented leveraging market share to drive web standards. IE was famous for flaunting W3C and implementing things their own way, much to the chagrin of web developers even to this day. It's the kind of behavior which got their hand slapped for anti-trust in the 90's.
It's hard to say it's "copying google", it's more of a return to form now that the regulatory environment seems to have relaxed on anti-trust.
That makes two of us. But if your takeaway from the 90s was 'W3C was in the right and timely, and MS decided to go another way just because,' then we have very different memories.
>>This is not about proprietary code (owning the code), anymore, but about owning the platform and making people use it.
FOSS, early on created a whole bunch of concepts and ideology that was very useful for framing the issue. Back then, it did make sense to focus on open vs proprietary code license etc.
That was a long time ago though, and most of what we know about the software industry wasn't known yet. These days we know software's best businesses are about control and power. OS can be used for strategic commodities, while convenient bottlenecks like app stores, cloud platforms or key dev tools.
A lot casual assumptions got made about links between norms at GNU, linux, etc and what OS is.
We need an update to OSS language. What does freedom, or openness mean today? As it stands, it's hard to say whether or not such and such violates such values, because the values are vague and unarticulated. We can fall back to 1980s FOSS, but that's somewhat dated.
We can't trust MS with anything, and the same can be said about every tech giant.
Therefore it really is a problem that MS has managed to get hold of github and npm. In my opinion it would be beneficial if this kind of "important infrastructure" belonged to a non-profit organization.
It is the runaway nature of our late-stage capitalistic "utopia" that large companies just absorb anything that touches their edges, continually growing larger, and absorbing ever more. Skype, LinkedIn, GitHub, StackOverflow, and Slack were all nicely-running, profitable businesses, with agendas that made them attractive to end users. But their owners all had a price, and now they're all part of monstrous companies with agendas that do not necessarily line up with mine. On the one hand, this is perfectly understandable. On the other, I think the government needs to stop these sorts of mergers and acquisitions to create vertical (as well as horizontal) monopolies. We're living in an age of modern-day "robber barons," and we need the government to return to policies from those days, including STEEPLY progressive taxes, and vigilant anti-trust action. Unfortunately, the Citizens United ruling will make this an impossibility until it is "repealed" with new law.
There are a lot of things that China does that other countries don't do, some of these things are bad, and personally I wouldn't want them to be implemented where I live (social credit score, censorship etc.). I don't see how engaging in a race to the bottom with China here is a particularly useful line of thought.
The CCP has recently been favoring anti-trust policy. Having enormous all-encompassing companies that absorb everything is not necessarily a great economic strategy.
"I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." - Charles Babbage
The only people benefitting from these mega-mergers are the handful of VC's and the C-levels involved. Everyone else suffers harm, including the government, which has reduced influence on actual governance. Money talks, even in Communism, and huge mega-corporations also impact China's government's ability to govern. I expect them to limit these sorts of arrangements more strictly than the US.
Absolutely not. Look at Microsoft for 20 years and you'll see all the red flags showing up. Owning github, vscode and linkedin is yet another EEE strategy.
Too much FUD and overreaction from people who dont even use Microsoft products here.
MS simply said they are prioritizing one particular feature for launch in 2 week for their premium (paid) IDE. Another company has already implemented this feature in a competitive IDE (JetBrains Rider). Mac support coming soon. Community can work on that feature themselves or wait til after the launch in 2 weeks for VS Code support.
This is quite issue with any big product - open source never found widely applicable model of operating that isn't dependent on some companies.
Linux relies heavily on corporations using it.
Gecko is dead without Mozilla - if Mozilla bankrupts, no one has enough manpower to develop Gecko.
Even if code is GPL-licensed and in ongoing development, main contributor can easily force their design choices on downstream forks. If you redesign some system, downstream forks have to reimplement their changes on top of refactored code. And they don't have enough manpower for that.
Well, governance of open source is probably not solvable, like most of human relations.
The problem is when an open source project is owned and controlled by one large player. It's much healthier to have diverse stakeholders with different interests, none of which is completely in control, as is the case with Linux.
JetBrains did their own Hot Reload feature for Linux. The community is working as it should. The problem is everyone wants premium features for free. HotReload is a new feature, existing folks don’t have it now. If you want it on Linux, it’s going to cost $13 a month for a Rider license. Otherwise, keep developing without HotReload as devs have been for the past 5 years for free.
When I was talking about "unsolvable", I meant there is no single "best way to do it". All choices have tradeoffs.
"One large player" can make hard, but neccesary choices. Multiple stakeholders can have conflicting interests, so they can stick with conservative way.
One large player can use its control in ways detrimental to users. Multiple stakeholders can go with incremental changes that benefit everyone involved.
Idk I get what you are saying, but at least for me personally, if I am investing in making something part of my workflow, it makes me really uncomfortable knowing it's fate is in the hands of only one corporation who's interests can easily become un-aligned with my own. Slow progress can be frustrating, but it's better than being left out in the cold from one day to another.
Nope. Linux users care that they use Linux. They don't care if anybody else happens to use it or doesn't. There's no 'Linux Corporation' that has to maintain sales to survive.
What people prefer is not a popularity contest. If that was the case, looking at it from a cars analogy, nobody would ever buy 'unpopular' cars like Lamborginis or even Mercedes, they'd only buy Fords.
I get the impression that its current state is something like CSS in the era of Internet Explorer 4 to 6: there's a published specification which Microsoft is nominally behind, but the de facto standard is "What Visual Studio Code does", and there's nontrivial divergence between the two.
Can anyone who works with LSP indicate whether that impression is accurate?
LSP appears to be alive and well with editors that are not VS Code. The entire point of LSP is to decouple the text editor from the language, and it works.
If VS Code has more support for LSP it is because Microsoft has poured money into it, invented LSP to begin with, and popularized it with VS Code to begin with.
296 comments
[ 3.4 ms ] story [ 283 ms ] thread> Throughout the last year we’ve been working to enable the best possible Hot Reload experience in Visual Studio 2022 and .NET 6. Part of our goal was to also explore making this feature available to customers through a variety of mechanisms such as bringing the full power of Hot Reload to as many .NET and C++ developers as possible when running through Visual Studio 2022 debugger, supporting Hot Reload when running .NET 6 apps without the debugger, and the very basic Hot Reload support we added to the .NET SDK tools through dotnet watch.
> As we reflect on what was accomplished, and what is still in front of us, the backlog continues to grow. This includes many high value scenarios that will benefit the broadest number of developers, including focus areas such as .NET MAUI, Blazor, adding support more types of edits, more optimized experience when working with XAML apps, and much more.
> With these considerations, we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022 so we can focus on providing the best experiences to the most users. We’ll also continue to pursue adding Hot Reload to Visual Studio for Mac in a future release.
So, first they wanted "bringing the full power of Hot Reload to as many .NET and C++ developers as possible" but now they shifted to "focus on providing the best experiences to the most users".
Best part of this whole thing is the pull request which was opened (https://github.com/dotnet/sdk/pull/22217) but " locked and limited conversation to collaborators" straight after opening it as Microsoft anticipated the backlash but still went ahead with the change.
Seems they still have a lot to learn before they can indeed be trusted.
If not for JetBrains Rider, dotnet development on Linux would be close to impossible IMHO.
When looking for my next gig I'll probably be switching to something else.
As a matter of fact, they implemented their own hot-reload functionality themselves [0][1].
[0] - https://twitter.com/JetBrainsRider/status/145148793146664961... [1] - https://www.jetbrains.com/rider/nextversion/
Whereas, Visual Studio... well, let me just say first that I know real people work on that product, some of them are probably reading this, and if so, I appreciate you.
Unfortunately, every time I've ended up having to switch from Rider to Visual Studio for some edge case scenario or to do an Azure deployment (before we moved that process into CI), I'd end up frustrated. Even with VS 2022, which is better, it's slow compared to Rider. Also, despite a couple of cosmetic coats of paint and new icons and such for VS'22, it doesn't really feel like a modern IDE or like it's changed noticeably since 2010 or so. Granted, stability is often a plus, but there's a ton of workloads in there that I don't think are relevant to a modern cross platform .NET Core 3.x/.NET 5/6 development experience and I suspect supporting all of that is a factor in why it's so slow.
I haven't even gotten into how much worse the performance in VS gets when you add ReSharper to the mix, and even with all the genuine refactoring improvements in VS in the past decade, I still feel like I'm working with a couple of broken fingers when I don't have ReSharper active. Better refactorings, better intellisense.
The developers build the 'support'... But why would they give a shit about the VSC experience when none of them use it? It's a shame.
C# support in Visual Studio Code is abysmal, hence no one uses it even if they use Visual Studio Code for other languages.
Irregardless of how anyone feels about using JS/TS on the server side it's really, really widespread - and VSC is the IDE of choice.
It is one of the few privileged pieces of software that is used daily. Not just for me, either...
The extensions owned by Microsoft are proprietary. So you can't run the c/c++, pylance, remote ssh, remote containers, c#, etc extensions in open source builds of Code - OSS like VSCodium.
And for some of those, if you manually try to install the extensions using the .vsix file, they fail because the extensions are hardcoded to work only on VSCode builds signed by MS.
Looks like Microsoft has figured out where their feet are and are taking careful aim.
To the person who downvoted me: I'd like to hear some arguments. Perhaps you don't need to. But that's irrelevant -- the world at large does. That's the main point of the post, too.
Definitely dents Microsoft's nascent open-source credit with me and, like so much of Microsoft's history, seems actively damaging in a monumental way to the history of computing itself for Microsoft's benefit.
The only thing I like with Visual Studio Code is that they were able to promote a cross text editor way to have auto-completion and other IDE-like features, thanks to the Language Server Protocol. Now I can use these features in Vim and Kate.
I don't understand how that is remotely ok. VSCode's main binary links statically against Blink (as it uses Electron) which is under LGPL, at the very minimum they should provide a way to relink that binary as per LGPL requirements.
no, the closed source part can stay closed source but relinking against a custom version of Blink must be allowed.
Just run "strings" on the code binary: you'll see symbols coming straight from Blink like this one: https://github.com/chromium/chromium/blob/72ceeed2ebcd505b8d...
But who knows.
And: That aside the role Microsoft nowadays plays in the open source world is reason for concern, while their current actions are mostly positive.
The Discretionary pricing comes in the Tiers, while the Moat is provided by VS Code reducing the chance of real competition against Tier 1 or 2.
The removal of hot reload from VS Code is to provide differentiation between Tier 2 & 3, to drive customers to paid versions.
--
Tier 1 .. Visual Studio Enterprise - expensive
Tier 2 .. Visual Studio - low medium cost for a business
Tier 3 .. Visual Studio Code - 'free' in exchange for your info (via telemetry) and reduces the chance of a truly open competitor challenging the above tiers. This one must walk a line between being less useful than above tiers so there's value to buy them, while being more useful than other 'free' competition in the short term so they attract mindshare away from other OSS that might otherwise grow to challenge the higher Tiers
IntelliJ IDEA is a competitive "open source based" product, with a significant market share (which qualifies as "viable competitor not under Microsoft's thumb").
VSC's "base open source" product is actually equally or more capable than IDEA - see VSCodium; its existence is proof that in worst-case scenario, a capable open source editor would still exist. Although there are some omissions, I think that given the MIT license, in theory a competitor could also build a series of commercial plugins - if I'm correct, this would actually be an interesting scenario.
What
What I mean by that is something without network effects. If your company uses Google Docs, you don't have much choice because that's where everything is (modulo apps that can sync to it so you can use a different editor).
For something like VSCode, at the end of the day it's still just a text editor. My use of VSCode doesn't stop my teammate from using vim.
For something like that, do you know how much of a pain in the ass it is at most companies to get them to buy something? The issue isn't even if it's $5 or $500. It's just going through the process of figuring out how to buy something, getting approvals, figuring out how to deal with the invoice, etc. Unless I'm already super committed to it, there's no chance when I can simply download any number of free options out there.
Then you have no competitors and can start charging the monopoly price, and no one tries to enter the market for fear you'll start dumping again.
Charging nothing for a product with no unit cost doesn't work like that. You're not forcing anyone to sell at a loss and the intent isn't to raise prices after they're gone.
The concern there is that you could come to dominate the market (even if the price remains zero) and then leverage that into other markets. If one IDE has more users than any of the others (market dominance) and it integrates with the vendor's hosting service and their proprietary APIs for their proprietary operating system and their app store and payment systems, that's more like tying than dumping.
IE and Skype were criticized for being terrible pieces of software, and people were desperate for something to come and disrupt their target markets. Now Chrome and Discord are being criticized for being so functionally superior to their predecessors - as well as every other option - that nobody is left with a choice anymore.
Developers don't want to choose anything besides Chrome because nearly everyone has been convinced to use it from the quality of the product, so sites are broken on other browsers, causing more people to move to Chrome. Critical information found nowhere else on the internet is locked within Discord, because almost everyone wants to use Discord, so you have no choice but to also use Discord to communicate with those people and view that information.
In the process, Discord becomes the sole owner of that crucial information, and Chrome becomes the single deciding factor in how web standards are developed.
Not "the best" per se.. Rather "good enough" and part of other tools the customers already use, while keeping them free so it becomes a matter of having to spend extra $$$ for another product.
Take Teams for example. It's a pig of an app IMO. Slow (takes almost a minute to start on my otherwise-fast M1 Mac), extremely high memory use, constant errors "Oops something went wrong + cute pic of ice cream", a mess visually and not dense enough UI. They focus all their time on adding new features rather than optimising. They also focus very strongly on the "for everyone", trying to be a jack of all trades, master of none.
Slack does a much better job at team collaboration IMO. Especially for tech users, it's fast, shows a lot in small screen space and isn't as heavy (though I really miss the IRC bridge!). But Teams comes for free with O365 and integrates fully with that ecosystem. So no hassle with integrating with your ID Provider etc, it's just plug and play. So if you'd want to have slack at work you'd have to make an unreasonably strong business case for all the extra cost and work.
Another example: Sharepoint. I doubt you could find anyone who would consider Sharepoint best at anything. Yet it's still used heavily in favour of other options, because it's again free if you're already in the MS ecosystem, and it integrates with all the other tools like OneDrive and Teams (both basically just layers on top of Sharepoint). So even if you're not using sharepoint, you're using sharepoint :P
I do agree they are the best at the VS Code niche. But usually this is not their game, they go for 'good enough'. Maybe it's because their developers dogfood VS Code so they couldn't stand it being slow :)
For example, VS Code is highly optimised and doesn't suffer the performance drawbacks that usually come with electron. They have optimised the hell out of it. However they never bothered to do the same with Teams, probably because they own that space anyway.
At the end of the day, you only employ so many top-tier folks, and you have a current corporate focus.
To be completely clear, I don't blame the guy. The approval process sucks, so if you get to bypass that, it's a huge win for your own sanity.
Why is having to demonstrate that something is worth the cost and effort of doing it "unreasonable"? Isn't that simply "a business case"?
Here is his keynote at VSCode day, https://www.youtube.com/watch?v=hilznKQij7A
For years, the narrative has been that MS doesn't want to give away their tools for free because they don't want to undermine the commerical offerings of their ecosystem. There used to be a ton of companies making development tools, components, and so on. Microsoft mostly made money with Windows, Office, and so on, so they could give away their own tools almost for free (but preferred not to in order to keep the vibrant ecosystem running). It is really odd that anybody at MS cares about whether VS or VS code or an external tool is more popular.
Also this whole infighting between departments seems to be contaproductive. If I were top level management, I would tell people to get their shit together. If instead of working together to make the best products possible, a manager tells off an employee for working on the C# extenstion for VS (because it hurts his personal goals) I would at the very least reprimand the manager. That VS code has poor .NET support, or for another example that MS graphical toolkits have so much churn and they don't use them themselves, are really embarrasing mistakes. I'm sure people have been fired for lesser problems...
While we were there, Scott Guthrie (I’m 99% sure it was him) was supposed to lead us in some discussion but wasn’t there, and someone filled in for him. We learned later it was because he had been called into Bill G’s office and got dressed down a bit because Scott had basically created his own version of Apache web server to use within the dot net tools. It was rudimentary and temporary, but the reason he did it was because he had been trying for months to get the IIS team to give him a version of their server for use within the dot net dev tools, and they just kept putting him off. So he went around them and built his own. They found out, went up the chain, and Scott got dragged into the office to be told to cut it out and work with them instead.
Granted, this is 20 years ago, so my memory might not be as crisp, but it stuck with me as a lesson that Microsoft was not a single company, but like 10-15 different little companies, and they competed among themselves as much as they worked together. And as OSS was coming up at the time I thought, “they have no chance to survive what’s coming.”
I’m still not sure if I was wrong or not yet.
https://imgur.com/XLuaF0h
https://bonkersworld.net/organizational-charts
This is true for probably most – if not all – companies above a certain size. In my experience it really takes off at about 100 people, and it gets worse from there. My armchair psychology take is at that level you no longer know everyone in the company personally and "cliques" begin to form.
I am not affected by this as licensed VS user, but I also don't like how this story has been playing, and join my voice to those complaining how this was handled.
No, I don't think I will trust you as telling me to trust you is not a valid qualifier. And, I do think you're reading too much in between the lines. For example
> but more importantly they also won’t deny it.
Please stop with low effort clickbait.
There are no mentions of all the positive outcomes that have emerged from their open source shift. In other words, it does focus too much on recent drama rather than putting this in the context of all their contributions.
Nor, considering the title of the article, has there been any consideration for the overall ecosphere of the tech giants that are playing in this space. If you ask the question, then look at who the others are. I cannot think of two worse companies to 'trust' than Oracle and Apple and represent the antithesis of openness. There are existing contributors, Google and Facebook, who do plenty and can somewhat be trusted considering their nature, and despite their reputation. There you will find a similar pattern, some things are open and some are proprietary Looking at the context of their contribution over the past few years I would put them firmly in the latter category. The answer to the headline is: yes, somewhat.
As a developer I'd love to be able to use .NET like I do Python, Go, JavaScript and Nim (ok, and Java, too). I love being able to write software that can run anywhere, using the editors and tooling that I like. VS Code is amazing in that it fits into my world. VS on the other hand, forces me to run a specific OS, and use a prescribed tool chain. FWIW, sometimes the prescribed way might be better, but it's not the way I want to do it.
Visual Studio is great for the common platforms/languages, but as soon as you try going cross platform or adding unloved platforms (UWP, Xamarin) it gets bad. Unfortunately, those also happen to be the things Rider is bad at.
There is a difference of degree, if not kind.
It's one thing for a smaller vendor to offer an 80% solution for free, and 20% enterprise features where there is competition to protect the market and the users.
It's quite another for a monopoly-level player that, for example, owns GitHub, to flex and threaten the market.
I'd support some serious anti-trust looks at what's going on across all of BigTech. MisterSofty is not alone in needing a review.
Microsoft wants to make money by charging for features. Unlike Apple, they consider developers to be actual customers. So I trust them to take care of our needs, and trust that their only ultimate motive is to get us to willingly empty our wallets in order to be more productive at work.
They won’t steal our data to sell to political relations companies like Facebook, create walled gardens and charge us 30% to import goods to our own captive customers like Apple, or arbitrarily try to control what can and can’t be done on the internet like Google.
They will just charge money for features like a normal business.
Don't look for companies intentions, look for their actions, as that's the only thing that matters.
Windows Home or Pro have mandatory "telemetry", as do a lot of their applications. It's even in the .NET Core CLI tools and has to be explicitly disabled.
> to sell to political relations companies like Facebook,
They own LinkedIn.
> create walled gardens and charge us 30% to import goods to our own captive customers like Apple,
They tried with Windows S.
> or arbitrarily try to control what can and can’t be done on the internet like Google.
They certainly tried in the 90s until they were stopped by the government. They saw the web (and Java) as an existential threat.
If they haven't been as successful as some of they competitors in doing evil in particular areas, that's not for lack of trying.
They own part of facebook, and they steal an incredible amount of data from Windows these days.
They have been trying to create a walled garden, with UWP and Microsoft Store. They have done poorly in the market but attempted a number of walled garden platforms.
Windows store is an attempt to charge 30% as Apple did.
They have tried in many ways to exert control on the internet, but have been outcompeted there by Google. One example of their control is SmartScan which scares users away from downloading programs they do not approve - a kind of walled garden. Many of their OSS plays are exerting significant control on users.
>> They won’t steal our data to sell to political relations companies like Facebook, create walled gardens and charge us 30% to import goods to our own captive customers like Apple, or arbitrarily try to control what can and can’t be done on the internet like Google.
It's just that if we want to say they're 'evil', I think they are so in different ways from FAANG. Could they do what Apple or Facebook do? Sure. But doing so would mean giving up their idnetity and becoming a pale version of their competitors.
In my experience it's also a resource hog. I have to quit and restart it every so often to keep it from bogging everything down.
But the reality is much more complex. You have competing teams of individuals each with their own interests. You have managers who come and go. You have sudden decisions that change everything during one afternoon. As an employee, you believe in something only to discover a few months later you were in fact mistaken.
I'm not cynical, but the best strategy is to be realistic. We all know Microsoft will do everything in their own interest and they are not basically different from any other company. That's a fact. Whatever they say about their love for Linux or Open Source is correct as long as it benefits them, not an inch more. Whoever goes in their way will be mercilessly crushed, as happened in numerous companies in the past like Lotus, Novell, Borland and so many others. Don't build your business based on their products, and if you do, have a backup-up plan and an exit strategy ready.
I own a VS license, so it doesn't affect me, but it leaves a sour taste.
People who release some software as open source and some software as proprietary don't believe in software freedoms. You can't mix and match without philosophical inconsistency.
If you want commitments from a company, get it in writing (in this case in the license).
I also don't get this part:
> They won’t develop cool features like these any more and most frighteningly, they won’t accept pull requests or community contributions which could add these features back into the SDK - and that is a bleak outlook for the open source community in .NET.
What stops someone from forking the SDK and adding this functionality? Or are there non-open-source components this all relies on?
I've felt the benefits of Microsoft's OSS push over the last decade, and I've been an advocate for their work. As such, I've never felt the need to run VSCodium, and I've been OK with sending Microsoft telemetry from my VSCode install (though I would prefer it was opt-in, rather than opt-out).
But now they are trying to have their cake and eat it too - they want to keep up the "developers, developers, developers" mantra, because they can deeply their tooling with Azure and nudge devs in it's direction. But they also still want to maximise revenue from their commercial IDE, Visual Studio. And as a result, they are half-arsing both goals, a strategy that is absolutely doomed.
And you know what, for a feature like `dotnet watch`, it's just so completely unnecessary, as VS would still be a very different and vastly more capable IDE than VSCode. This really feels like some high-head in the background is pulling new strings, and I really don't like it.
I'm also 100% certain that if `dotnet watch` is discontinued, someone will reverse engineer it (very easy with dotnet!) and release it as a third party dotnet global tool, which makes this whole situation even more pointless.
I hope VSCodium does start to add in functionality that Microsoft is trying to keep for themselves, starting with the dotnet watch code that was written and not merged - extra functionality would be a very compelling reason to use VSCodium.
#1 issue is that the extensions are all written in TypeScript and run in the background. When I click to go to a definition, rename, run, or even save, I get that "progress bar" and it takes at least a second. A lot of extensions are also buggy. Vs a "real" IDE like IntelliJ or Xcode, which does those operations almost instantly with significantly less bugs.
If VSCode isn't a "real" IDE, then it competes with other text-editors like Notepad++, Vim (not counting advanced versions like Spacemacs), etc. But those are way faster and less cluttered because text editing is all they try to do.
It's funny because I've been trying WebStorm and it brings my i9 16" MacBook to a crawl so VSCode feels much "faster". It doesn't help that simple operations like renaming anything are multi-step processes or are just apparently missing (no apparent way to delete a file or visit its parent folder from the command palette)
I agree with the rest. VSCode to me is just a little step up from Sublime Text for UI and base features, but it's still a far cry from proper IDEs like WebStorm (of which I like the proper refactoring features)
The only thing that comes close is TRAMP in emacs, but unfortunately since emacs is single threaded, any network blips means the UI is blocked.
If these operations take over a second it may be an issue with your machine or install of VS Code
The major silly thing with VS Code is that it has no support for floating windows.
Then you install extensions/plugins to move them slightly more towards the direction of IDE.
I see text editors as fast. IDEs as slow but full of features. This allows you to find a middle ground that works best for you. That is as long as you don't do the rookie mistake of installing 100 extensions, 90% that you'll never use but you read about them in a blog & they sound awesome! Kind of like we all do for books, videos, etc.. Someday I'll use them!
Me too. The problem with VSCode (and Atom and maybe Sublime) is that even basic IDE features are slow are buggy. And when I'm using an IDE, I constantly use "basic" features like jump to definition, find definition, rename, etc.
IntelliJ is impressive in that you can type, rename, type, jump to definition, rename, etc. and the operations are so fast that they don't disrupt your flow. Vs in VSCode where the operations will pile up in the background. Not to mention, IntelliJ's operations are usually successful, but VSCode's are usually not.
If VSCode could do basic things like jump to definition and rename properly, while still being super fast, then it would be really useful. But idk if it's just me but even in TypeScript I don't get those capabilities.
My creep alarm went off a bit when I recently started a project to test the waters with TypeScript. I was asking on a forum how to deal with native JS dependencies without types, and he answer I got was "Are you using VSCode? It will just find the community maintained type packages for you".
It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it. If one were to pursue an EEE strategy, this would not be a bad way to start.
Certainly “making a better product that’s easier to use” isn’t something we should be discouraging.
I am primarily a vim user with VS Code as my secondary editor. I have never ever used their one-click solutions.
I have seen someone choosing "Yes" to everything VS Code said after installation, and in no time their machine was filled with bloat that they would never ever need.
But I see this as a good thing. It is making programming set up easier for the uninitiated, which is good.
The uninitiated should begin with a bare-bones text editor and a shell prompt. If you don't understand what is happening from that level, you will never understand what is going on in complicated frameworks. You will be the programming equivalent of your grandmother who thinks Facebook is the internet.
> We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution.
I of disagree that time-to-solution is the true end-goal. It might be, depending on your use case, but there may be other constraints. For instance, let's say I make a piece of software, and I have a choice between choosing an "easy" solution which takes me 100 hours to complete, or a hard version which takes 500 hours. And let's say the easy version allows the user to complete their task in 30 seconds, where the hard version allows them to complete their task in 10 second. That means every time my code is executed, I have saved 20 seconds of the user's time by doing things the hard way.
Now let's say my code is executed on average 1000 times per hour. That means every hour my product is out there, I save about 5.5 hours of user time for doing things the hard way. In only 72 hours, that 400 hours of productivity I "lost" is made up for, and for the rest of the lifetime of the product it's pure upside.
At the end of the day, programming is about making computer hardware do what you want. If we let ourselves get too far away from the computer, it's hard for us to do that well.
If you know the basics you can apply them to any tool. If you only learn to build software using a specific framework, IDE etc. you're probably going to have problems if anything in the setup changes. One day in a simple text editor and a shell taught me more about how Java builds work than years of formal education, because all those years were spent in an IDE and nobody even explained what the classpath is.
If your goal to solve a problem, then you should use something that helps you solve that problem quickly. If your goal to learn how to solve problems, then you probably shouldn't. Those are both valid use cases, but they are very different.
Get people excited and empowered, then teach them some arcana.
For instance, I think basically everyone can agree that moving from assembly to C and other high-level languages was basically a strict upgrade, and obviated the need for assembly programming in all but a few specific use cases.
By contrast, using the command line and shell programming is every bit as relevant as it was 20 years ago, and I don't see that changing any time soon.
Both assembly and the shell are difficult and alienating to newcomers. But learning is mostly academic at this point, while learning the other opens up entire new worlds in terms of what you can do with a computer.
In other words, learning assembly is like learning latin. Maybe interesting, but not particularly useful. Learning bash is like learning Chinese. Not particularly easy, but there's a lot you can do with it right now.
On the other someone could have said the same to your regarding assembly code and so on.
Just building more tooling to cover up pain points by wrapping them in more and more layers of bloat is just making a mess. You wind up needing a super complex system to do simple things, which nobody really understands, and which uses a ton of unnecessary resources. If you extend that strategy ad infinitum, you need Moore's Law to persist just to keep performance stable while running more and more layers of VSCode plugins.
I also don't necessarily think some barriers to entry are always a bad thing. Things like notebooks are great for giving people access to a simple programming environment which is easy to set up. But if someone is going to be committing code to a serious project I'm working on, I don't mind if they have to know enough about computers to at least run a few commands in the terminal.
Lower level technologies need to be more flexible to allow usage in many different cases. On top of that we build different abstractions that are suitable for only a restricted number of uses cases, but that make them much simpler to think about and work with. By thinking at this higher level we are able to build much more complex logics than we would have before.
I certainly wouldn't want to be stuck in a world where we still have to do everything in assembly because we were too afraid to embrace the compiler.
Progress isn't only about building and endlessly taller stack of abstractions such that we eventually can't see the computer underneath. Sometimes it's about looking at the stack we have, and building a smaller and smarter one based on the lessons we learned along the way.
If they're an enduser, btn click is exactly what they should use. If they are an engineer, and clicking btns is all they know, then they are going to be a very limited engineer. This too is fine and there is a place for that. But, if such an engineer starts to think that they are a great engineer because they solve all the problems quickly whenever there are btns, they are going to be a liability for teams when there aren't any btns to click. Because they are going to be too arrogant to listen to those who might know how to solve them which aren't necessarily btn clicks (because to them all solutions must be btn clicks). You see, it's more than a matter of principle. It's about the calibre of the engineer you want to produce.
I envision, with all this no-code babble, that the future "average coder" of 10 years from now will be a click-monkey.
Sadly, most people like not knowing things. I theorize that it empowers them to keep their brain free of potentially useless clutter.
Look at the case of the Web, HTML+CSS+JS standards and specifications (Drew DeVault triggered DDoS measures simply trying to access documentation), and the inability of even G-MAFIA scale companies from being able to sustain their own independent browser engine cores (Microsoft and MSIE).
Control is the ability to determine the options of others. A single entity providing an overwhelmingly appealing programmatic interface is a locus of control.
Most young developers don't care due to inexperience and coolness factor. As code becomes more sophisticated, build reproducibility starts to become a problem.
And, Microsoft is trying to own the toolchain's strategic points this time, making reproducing a build almost impossible without their tools.
And with the push towards remote development, I can see things moving toward a world where the default is not even running things locally. Lines get blurred, and sooner or later you're depending on proprietary Azure services without even realizing it.
Moreover, Eclipse has LSP support too.
Maybe these should be made more visible.
I say this as someone who had to search through a crazy large GitHub repository of community Types back in the day all the time. Then you end up having to send some PRs & wait for them to get approved if you hope to use the types in a larger team or as part of a build process. You could also create your own fork until they're approved & then go back & update the package.json.
Open Source: Too good to fail.
That's why Microsoft can't "own" open source. So they decided to "own" the open source developer by owning the source repository he uses, owning the editor, owning one of the most popular languages (Typescript) he uses, the command line shell, he uses along with grabbing all the Linux commands and make them available on their own platform.
This is not about proprietary code (owning the code), anymore, but about owning the platform and making people use it. I doubt, they have a clear plan, right now, instead they hope, that it will play out positively for them, in the future. A few years from now, I wouldn't be surprised, if you'd need a Microsoft account to log into Github.
And there's no company I trust less not to abuse that influence once they see the opportunity to use it in an anti-competitive way without consequences.
Microsoft finally realized standards and interoperability was the future. They also realized that a requirement of being able to extract profit in that future was having power to influence standards.
Consequently, open source tools (and more importantly, the dev/user share that comes with them) get Microsoft votes. Either explicitly or via mind share.
And when it's a corporate priority or matter of survival, they use those votes to advance Microsoft's interest.
We've seen this with Chrome / web standards for years now. Most of the time it's good for users, but sometimes it's just that important to corporate reveneue.
It's hard to say it's "copying google", it's more of a return to form now that the regulatory environment seems to have relaxed on anti-trust.
Granted, early versions of IE made a hash of the standards that did exist, and didn't place an emphasis on compliance.
But the more accurate phrasing would be "W3C wasn't prepared for web adoption, and wasn't as agile as the early web needed."
People forget we wouldn't have gotten AJAX and descendents without IE's non-standard XMLHttpRequest support.
FOSS, early on created a whole bunch of concepts and ideology that was very useful for framing the issue. Back then, it did make sense to focus on open vs proprietary code license etc.
That was a long time ago though, and most of what we know about the software industry wasn't known yet. These days we know software's best businesses are about control and power. OS can be used for strategic commodities, while convenient bottlenecks like app stores, cloud platforms or key dev tools.
A lot casual assumptions got made about links between norms at GNU, linux, etc and what OS is.
We need an update to OSS language. What does freedom, or openness mean today? As it stands, it's hard to say whether or not such and such violates such values, because the values are vague and unarticulated. We can fall back to 1980s FOSS, but that's somewhat dated.
Therefore it really is a problem that MS has managed to get hold of github and npm. In my opinion it would be beneficial if this kind of "important infrastructure" belonged to a non-profit organization.
https://www.ft.com/content/01b7c7ca-71ad-4baa-bddf-a4d5e65c5... https://www.reuters.com/world/china/exclusive-china-readies-...
The only people benefitting from these mega-mergers are the handful of VC's and the C-levels involved. Everyone else suffers harm, including the government, which has reduced influence on actual governance. Money talks, even in Communism, and huge mega-corporations also impact China's government's ability to govern. I expect them to limit these sorts of arrangements more strictly than the US.
MS simply said they are prioritizing one particular feature for launch in 2 week for their premium (paid) IDE. Another company has already implemented this feature in a competitive IDE (JetBrains Rider). Mac support coming soon. Community can work on that feature themselves or wait til after the launch in 2 weeks for VS Code support.
As interesting as all the murky politics are, I didn’t need all of the long form prose to build to that question.
In fact you could have just straight up led with the question.
And then answered it even more simply. Any of
Nope
Probably Not
Hell No
Not Even
would have worked. I’m not sure why this is such a drama or surprise to anyone.
Linux relies heavily on corporations using it.
Gecko is dead without Mozilla - if Mozilla bankrupts, no one has enough manpower to develop Gecko.
Even if code is GPL-licensed and in ongoing development, main contributor can easily force their design choices on downstream forks. If you redesign some system, downstream forks have to reimplement their changes on top of refactored code. And they don't have enough manpower for that.
Well, governance of open source is probably not solvable, like most of human relations.
"One large player" can make hard, but neccesary choices. Multiple stakeholders can have conflicting interests, so they can stick with conservative way.
One large player can use its control in ways detrimental to users. Multiple stakeholders can go with incremental changes that benefit everyone involved.
There is no silver bullet.
Nope. Linux users care that they use Linux. They don't care if anybody else happens to use it or doesn't. There's no 'Linux Corporation' that has to maintain sales to survive.
What people prefer is not a popularity contest. If that was the case, looking at it from a cars analogy, nobody would ever buy 'unpopular' cars like Lamborginis or even Mercedes, they'd only buy Fords.
I get the impression that its current state is something like CSS in the era of Internet Explorer 4 to 6: there's a published specification which Microsoft is nominally behind, but the de facto standard is "What Visual Studio Code does", and there's nontrivial divergence between the two.
Can anyone who works with LSP indicate whether that impression is accurate?
LSP appears to be alive and well with editors that are not VS Code. The entire point of LSP is to decouple the text editor from the language, and it works.
https://github.com/search?q=language+server+protocol
If VS Code has more support for LSP it is because Microsoft has poured money into it, invented LSP to begin with, and popularized it with VS Code to begin with.