Counter thesis: what "killed" Atom is the balance of user enthusiasm quickly shifting to VSCode. Well before the acquisition was even announced, VSCode started grabbing developer mindshare real, real fast. I remember being an Atom user who resisted that tide for a while, but it became pretty clear that VSCode was taking off like a rocket and Atom, well, wasn't.

If commit activity graphs are really a meaningful measure, look at VSCode's:

https://github.com/microsoft/vscode/graphs/commit-activity

The number of commits per, uh, date unit (the graph is not super clear on that axis, honestly) across the entire length of VSCode's activity graph rarely drops as low as the highest number of commits per date unit for Atom.

I'd have preferred to see both survive and do well, but that really hasn't been the way the text editor space seems to have worked. Editors that are conceptually awfully similar to one another tend to have one dominant player: TextMate (at least for Macs), then Sublime Text, then Atom, then very quickly Code. Given that Code and Atom are probably the closest of any two in that list, this just isn't that surprising.

It would be delusional of me to claim that VSCode wasn't already winning in terms of mindshare by a large margin when the acquisition happened. That's not what I'm claiming here.

Atom still had a healthy number of active contributors (presumably most of them were from GitHub) making improvements to the product on a daily basis to make it a perfectly viable tool for the people who chose to use it (and despite the much smaller developer base they continued to innovate with projects like xray and tree-sitter)... That is until the Microsoft acquisition happened.

Before anyone jumps in with the causation vs correlation argument, I think any reasonable person looking at the evidence would agree that the timing is convenient enough to make it highly unlikely to have been a coincidence, especially considering that most of those contributions were from employees at GitHub who were _getting paid to work on Atom_, so the only reasonable explanation for the contributions to stop abruptly within a month is that they _stopped getting paid to work on Atom_.

To add insult to injury they even had the audacity to claim they wouldn't do exactly what they did. That is the crux of my issue with how they handled this acquisition.

I agree, it's probable that there's been a decision to de-prioritize Atom in favor of VSCode. And sure, I get being upset about that, and about GitHub not confirming that this is what's happening if it really is what's happening.

But the words of the linked Reddit comment from Nat Friedman were "we will continue to develop and support both Atom and VS Code going forward"; that's a true statement today. Atom is currently being developed and supported. That's a case of adhering to the letter of the statement rather than the spirit, I know. But that circles around to the problem of VSCode's rapid ascent in mindshare -- if your company ends up owning two very similar editors and they both have roughly equal downloads and community interest, you might try to support both equally. But if one of them has orders of magnitude more downloads and community interest than the other, you're going to focus your efforts on the popular one.

How many of those github-people were officialy working on atom and how many were just random githuber who supported company-focus and followed social pressure?

It's quite possible that this was just a random side-effect from a shift in focus, instead of a planned sabotage.

From Microsoft's perspective, what's the advantage to them or their users to pay for two somewhat similar free offerings to be worked on in parallel? Given that one was gaining in popularity by leaps and bounds while the other was rapidly losing market share and relevance, what course would you recommend? "Fund both indefinitely, to keep the handful of atom users that want new features happy"? Be reasonable.

I don't think anybody's expecting them to fund both indefinitely, but given that their soon-to-be new CEO went on the record to say that they would actually keep funding Atom development, I feel it's fairly reasonable to expect that they wouldn't pull funding from Atom almost completely as soon as the acquisition went through. That's a really shitty move no matter how you look at it.

He said "we will continue to develop and support both Atom and VS Code going forward," which at least of right now is still happening -- Atom 1.45 was released last week, along with 1.46 beta 0. The conjecture that they've effectively defunded it is reasonable, but it's still conjecture, and even if they have it doesn't actually break Friedman's (possibly quite deliberately worded) statement.

I agree it was stupid of them to placate people by making promises they don't intend to keep.

Maybe Microsoft helped killing Atom, but I don't think Atom is completely innocent by itself.

I was an user of Atom and later switched to VSCode. It took me few months of weighting all the options before I made the switch. That's how much I love Microsoft -- Very little.

Don't know if they got it fixed, but there was a design flaw in Atom: Bug inside some Atom plugin (`linter-ui-default` is one of it if my memory is correct) can reset the entire Atom into it's default setting, and it happens randomly (See link 1, 2 and 3).

This problem pisses me off so much and so many times. The last time it happened, I accidentally deleted my backup configuration `config.cson` when trying to recover the setting. Yes, it is technically my fault, but no, really, it is not. So, after seeing all my life flashed before my eyes, I decided to stop living ... with Atom, I had enough.

VSCode is generally a better editor when compare to Atom. I mean, VSCode has it own issues, sure. But for me, so far those issues are mild and usually got fixed quickly.

1: https://github.com/atom/atom/issues/14922 2: https://github.com/atom/atom/issues/14909 3: https://discuss.atom.io/t/atom-keeps-losing-settings/61617 (This one was in 2018 while the other two was in 2017)

Author of `linter` / `linter-ui-default` here. The package in no place in its code rewrites the entire Atom package configuration. It does however observe it's own configuration. If observing in itself resets the Atom config, then it's out of the hands of the package and a bug in Atom core.

It's possible that one of the linter providers had that issue, and since Linter providers are only called by the linter package, they wouldn't exhibit the issue on their own. It's not uncommon to have issues that seem like it's the linter's fault since all of the providers do nothing and seem harmless unless invoked by the linter package.

I would've helped to debug this, had somebody pinged me on any of the issues. Oh well :)

Some information (https://github.com/atom/atom/issues/17060) indicates that the problem is related to `atom.config.set`. `linter-ui-default` is one plugin that triggers it.

So maybe it's not a bug of `linter-ui-default` after all. Sorry dear innocent man, my judgement is not always on point :)

What killed atom was that not even with rewriting stuff in C++ they were able to match what Microsoft is able to do with pure JavaScript on Electron.

Lack of delivery killed Atom, not Microsoft.

> Microsoft for all intents and purposes killed Atom

I don't think so. When VS Code came out my reaction was "Wow! It's like a 1.0 version of Atom!" I.e. an electron (or similar) based editor that works, whereas atom always seemed like a beta release. I tried to use atom a bit but it came with little out of the box and the plugin ecosystem was a complete mess. I filed an issue asking if obsolete/dead plugins could be somehow removed from the plugin repository, but nothing came of it.

Atom wasn't killed, it died on its own.

Please not call MS "killed" atom. Even before MS acquisition Atom was clearly losing in the competition.

I switched from Atom to VSCode well before the acquisition, and I personally know many others that did too.

What need does Atom fill that VSCode doesn't?

Making use of idle cores.

Harsh, but true...