Is atom dead, again?

After the acquisition of Microsoft, is atom dead?

There are still commits, but the lack of activity on the blog, the termination of project Xray, no Atom-related news at GitHub Universe and the general lack of new features (except Git, maybe)… it all makes me doubt there’s much of a future, to be honest.

1 Like

I also have the same feeling that the project is slowly dying

“Interesting”

https://electronjs.org/blog/electron-joins-openjsf

I just started a course and they coach is using Atom. Now I heard from a lot of people I should not use Atom but VSCode, now I really don’t know why, is there something bad with Atom? I actually like this editor.

@Micronetic:
Atom in hibernation (again) or an inch from being cancelled…?
@idleberg already said what there is to say.

To me Atom is a tool to code with.
I enjoy using Atom as it is in the here and now.

I suggest to finish your course; focus on coding.
Feel welcome to continue using Atom if you like it.

I really like Atom and I will continue to use it (tried vscode but didn’t like it) and I 100% will finish the course :wink:

2 Likes

Atom is as alive or dead only in as much as it has market share and contributors. There was already discussion on this very topic last year when Microsoft originally acquired GitHub and of assumption by extension Atom.

In reality, GitHub as a platform with server hardware and a community could be acquired on a company level, however Atom was developed under the MIT Open Source licence, has remained under this licence. Microsoft have their own ‘Open Source Licence’ Microsoft Public License (MS-PL) and if Microsoft had truly wanted to acquire Atom and change it, they could have attempted over the past 18 months or so to change the licencing in order to reinforce their positions on it. In reality, this has not happened as it is more hassle than it is worth to Microsoft. They’ll continue to develop VSCode whilst Atom remains Open Source software under a MIT licence. If developers want to support Atom directly they can still push commits upstream for bug fixes and features. Alternatively, as end users just use it as you wish.


Chicken-or-egg?
Playing devil’s advocate with some rhetorical questions:

  1. What would happen to an open source project if…?

    • The original / senior developers are reassigned to other projects while new staff is used.
    • Outside contributions (pull requests and suggestions alike) from the community are not evaluated and integrated by the project owner.
    • Project owner do not interact with the public to encourage health of add-on contributions.
    • Insiders (developers) do not feel confident to speak openly of what future plans are.
  2. Does the licensing type of a project matter if a project seems abandon by its owner?
    (as per public opinion)

1 Like

You quoted me about market share and contributors. - There’s a saying that ‘you can’t flog a dead horse’. In the world of software and code, if something isn’t being used by anybody or contributed to, then it is technically dead and hence depreciated. Graphics drivers for ISA graphics cards being something that springs to mind.

An egg can still grow into a new chicken given the right conditions, even if that egg isn’t nurtured by it’s originating chicken… Same with Open Source. Great analogy, thank you.

In general, typically, a project continues but may fork. The original project may still always continue. As an example, think about the history of OpenOffice.org and the reincarnations that this project has had over time. First Oracle then Sun Microsystems then Apache/Document Foundation. The most significant being when LibreOffice forked from what is now Apache OpenOffice. Yes, projects may stall but ultimately continue. Code can flourish in the wild given the right conditions or become depreciated when the world moves forward. Software licencing can help or hinder a transition process.

In other examples, Linus Torvalds slowed down/stepped away from development of the Linux kernel whilst he developed Git, and separately took a break in 2018 when he decided to re-evaluate his interpersonal skills with regard to the Linux Kernel Mailing List. The Linux Kernel was still maintained and developed during these times even when the project maintainer was in theory MIA.

The court of public opinion can only change a legal opinion over a course of due process. Abandonware and Orphan Works are actually things, but there are still criteria that need to be met before a project can be deemed abandoned and usually projects that are deemed Abandonware are still proprietary and copy-written. It is this point in which Abandonware resurrected projects are still at risk of being targeted by litigation if the derived works infringe the originating copyright. This is where Copyleft/Open Source licences help the developer community and occasionally originating developers. If you had created an Open Source project but could not complete it due to ill health, you can still leave legacy by your project being maintained by others.

@ShefStealth, your reply steers the conversation into another direction.

The mechanism of open source does give the source code from the Atom project a chance to survive. To have a StarOffice / OpenOffice / LibreOffice transformation for Atom’s code and add-on infrastructure will take resources. Such a new project will need formal backing from an organized & coherent group of people (read: organization). A worthy topic to perhaps discuss separately.

The topic of this discussion is not as wide. It is about the here and now. The question is if the project we know as Atom has a chance to survive under the ownership of Github.

My previous reply focussed on that core topic. No legality or practicality of transforming Atom into another project was touched on.

My own position:

  • I like using Atom as it is now.
  • Some functionalities in Atom are not as I would like it to be.
  • The Atom project is not healthy.
  • I have a low confidence that another group can absorb Atom successfully into a new project/product… unless it is Facebook.
  • Github should use the Atom project as proving ground for his interns. (read: Mentorship concept & learn by evaluating pull requests)
  • Github should focus their efforts in teaching people on how to use Github service through contributions to the Atom ‘universe’. (read: Tutorials on using git to contribute to the Atom ‘universe’ - Atom core and add-ons)

The implication of all of these ‘is atom dying?’ threads is that development progress has dried up or stalled since Microsoft’s acquisition of GitHub, and these threads in and of themselves seem to advertise or market to the wider world that Atom is in trouble, which in turn means that potential users might not even bother giving the project a chance if they believe that it is becoming EOL.

That developers have or are jumping ship to other platforms, and still don’t trust Microsoft due to their original stance on Open Source software. All of this has a baring on Github and Atom. The fact that when the acquisition was announced, alternative platforms had an uptick in their subscriber numbers reinforces this - but Github is still the market leader in this space.

If anything, Atom has all of the backing required to survive and thrive so long as developers continue to develop on and for it. Wherever there are shortcomings, if you do not like something then try to contribute to fix or improve it. This is the nature of all open source - it either survives in it’s current state, changes state or dies. It’s my belief that there may be a very slow change-state progressing but that ultimately Atom will still be here for a long time yet.

What @idleberg stated 22 days ago is what the public sees.
I may even include observations to see on the various Github projects -

  • some pull requests that does get timely attention.
  • monthly targets regularly not reached and now not even published.

Public opinion is about how perception is managed.
The core of developers seem very quiet.
Once active contributors on this forum are also silent.

@ShefStealth: I agree with your replies, though the best change to public opinion is “seeing and hearing” the “leaders” of the project.

If it’s about the word death, you are right. Neither Gnutella or the K-Meleon web-browser is dead. But they are irrelevant. To me, it feels a lot like Atom is on its way to irrelevance. Core issues, like data-loss or installation issues, have been around for years and a substantial amount of people still complain about them (I never had these troubles myself). It doesn’t seem like Microsoft/GitHub has the resources or the interest to fix these.

Microsoft did acquire Atom. I don’t see why they could be interested in changing its license, Atom doesn’t hurt them and they have a far more popular competitor (see Stack Overflow on Atom and Visual Studio Code for measure). They could pull the plug and shut it down if they wanted to. But they can’t kill it since it’s open-source. However, this is about first-party commitment and support. I have no insights on how many paid developers work on Atom, but it feels like there’s only so few of them. I guess it’s more likely that Microsoft will ultimately shut the financing of Atom and leaving it to the community – for better or worse.

Like neither of you, I have no facts to back up my claims. I guess the thread starter was hoping for some official statement to follow, but unsurprisingly there is none. Like there are no more blog posts and lots of broken promises. This is not how you build or nurture a community, so I think all concerns about Atom’s death march into irrelevance are justified.

1 Like

That is my experience, too. I ran into multiple problems, researched them, only to find there are issues that are open since 2015 or 2016.

On the other hand that means Atom hasn’t really been healthy since long before the acquisition?

I really like Atom, much more than any other editor I used before. A text editor is something I use every single day, both for work and for private projects. A few years ago I made the effort to hack vim into submission, but Atom, as flawed as it is, is still better. I now made the effort to make Atom what I want it to be, as far as I can. For me it would really be a pity if it died.

1 Like

Personally, I think the acquisition of Github by Microsoft did not hurt Atom as much as Facebook ditching nuclide and atom-ide-ui (Oh well, maybe Facebook ditching nuclide and atom-ide-ui is an indirect consequence of Github’s acquisition by Microsoft?) Anyway the discontinuation of the nuclide project marks the decline of Atom usage for me at least. With nuclide and the atom-ide-ui been discontinued (and a plethora of atom-ide-ui related packages left unmaintained), Atom is no longer a viable light-weight IDE for me, but more of a heavy-weight text editor which only has very limited use for me now.

Considering how fast modern languages iterate with new versions and feature updates, the lack of updates of related Atom packages makes Atom less and less useful for developers. A couple years ago I used Atom extensively for things like Go, Dart, React, Vue, Erlang and Solidity development, but now the popular Atom packages I used for those languages are either outdated lacking new language feature support or completely broken, that I’m forced to use VScode instead.

I actually dislike VSCode a lot when compared to Atom in the overall philosophy of how the editors are designed. For me VSCode is too opinionated and lacking extensibility in the UI, that it forces you to use keyboard for a lot of extension functionalities as the extensions cannot extend the GUI as freely as in Atom. Also I find the functionalities provided by some of the Atom’s autocomplete+ based autocomplete packages are superior to their VSCode counterparts. For example I remembered having far better productivity when developing Solidity contracts with Atom’s autocomplete features back then when Atom’s solidity related packages were still maintained and fully featured for the Solidity 0.4.x language versions.

But right now with all those packages left unmaintained and all the languages iterating new features so fast, I as a user simply have little choice but to move to VSCode despite a less user-friendly UI design and inferior productivity (for me at least).

I agree with pretty much all of that. I’ve been forcing myself to use VSCode over the last few weeks. I’ve managed to get equivalents for most of the packages I use in Atom, but I still don’t like the visual style and UI restrictions.

The one positive thing about it is that it seems designed as an IDE first, rather than an editor with IDE features. Installing the Python extension, for example, is a breeze compared to all the separate Atom linters/debuggers/grammars etc you have to find…

For reasons other than you think, see this announcement by Facebook

TL;DR

We’re making Visual Studio Code the default development environment at Facebook and teaming with Microsoft to help enhance their remote development extensions in an effort to enable engineers to do remote development at scale.

It’s kind of funny how people tend to think that open source is a kind of magic that maintains software awesome through time. If a project was abandoned and you want a fork or continue it you would need to find people who:

  • Know the language the project is made
  • Know the tools that are being used or have the time to learn them.
  • Understand the way the code is organized
  • Have the time to add new features
  • Want to spend their time on the project

Projects like OpenOffice and Linux Kerner are big enough to spend resources to find these people but are the exception, not the rule. In most cases, it doesn’t worth it.

2 Likes

The reason is why

Why Visual Studio Code?

Visual Studio Code is a very popular development tool, with great investment and support from Microsoft and the open source community. It runs on macOS, Windows, and Linux, and has a robust and well-defined extension API that enables us to continue building the important capabilities required for the large-scale development that is done at the company. Visual Studio Code is a platform on which we can safely bet our development platform future.

Since Atom released the Github package they focused on it and in newest releases there were tones of changes in that package but not a lot for the others.

Some package authors decided not to maintain their packages because the API is hard to work on. It doesn’t get updated and they don’t add new features to allow the authors to improve and make better packages.

If they want to continue making Atom and make it great they, I think they should publish a roadmap and allow contributors to work on it, and they also should brooming all the open PR and issues because there are a lot of them open for years.

1 Like