6 ms·

Given that Microsoft for all intents and purposes killed Atom (along with their really promising xray project [0]) almost immediately after the acquisition [1]

Given that Microsoft for all intents and purposes killed Atom (along with their really promising xray project [0]) almost immediately after the acquisition [1] even after explicitly claiming they wouldn't [2], please excuse me for not seeing the GitHub acquisition in the same positive light. [0] https://github.com/atom-archive/xray https://github.com/atom-archive/xray [1] They never officially announced it, but they almost certainly de-staffed it to the point where it's barely on life support: https://imgur.com/a/jQBHsUk https://imgur.com/a/jQBHsUk [2] https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman_future_ceo_of_github_ama/e0a2b2e/ https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman... Update: What a surprise, the VSCode fanboys are coming in droves to downvote and say nothing more than how Atom was going to die anyways. Sure, maybe it was, but that's not the point. The point is Microsoft _actively pulled development resources away from Atom after explicitly claiming they wouldn't_. I get that a lot of people like VSCode better than Atom, but _please_ put things into perspective for a moment and consider if you'd make the same comment if the same thing happened to _your pet project that happened to be #2 in popularity but then got axed after being acquired by the company who owned the #1 after claiming they wouldn't do exactly that_. Whatever your opinion might be on Atom vs VSCode, can we not at least agree that this kind of behavior is something we should hold acquiring companies accountable for? It might not make any difference to their bottom line at the end of the day, but the least we should do is hold them to the fire in the court of public opinion.

chipotle_coyote 7y ago
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 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.
- lewisl9029 7y ago
  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.
  - slightwinder 7y ago
    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.
  - sequoia 7y ago
    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.
    - ss3000 7y ago
      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.
nl 7y ago
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?
- pjmlp 7y ago
  Making use of idle cores.
  - nl 7y ago
    Harsh, but true...
kbumsik 7y ago
Please not call MS "killed" atom. Even before MS acquisition Atom was clearly losing in the competition.
pjmlp 7y ago
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.
nirui 7y ago
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 https://github.com/atom/atom/issues/14922 2: https://github.com/atom/atom/issues/14909 https://github.com/atom/atom/issues/14909 3: https://discuss.atom.io/t/atom-keeps-losing-settings/61617 https://discuss.atom.io/t/atom-keeps-losing-settings/61617 (This one was in 2018 while the other two was in 2017)
- steelbrain 7y ago
  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 :)
  - nirui 7y ago
    Some information (https://github.com/atom/atom/issues/17060 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 :)
sequoia 7y ago
> 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.

chipotle_coyote 7y ago

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 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.

lewisl9029 7y ago
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.
- slightwinder 7y ago
  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.
- sequoia 7y ago
  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.
  - ss3000 7y ago
    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.

nl 7y ago

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?

pjmlp 7y ago
Making use of idle cores.
- nl 7y ago
  Harsh, but true...

kbumsik 7y ago

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

pjmlp 7y ago

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.

nirui 7y ago

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

steelbrain 7y ago
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 :)
- nirui 7y ago
  Some information (https://github.com/atom/atom/issues/17060 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 :)

sequoia 7y ago

> 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.