zan8in
what about a new fork, folks
It is hard to see Atom slowly dying and not fixing it's mistakes. (Which is clearly possible as VSCode is showing us). VSCode is Ok but is getting close to a IDE, since It is hard to point a direct alternative to Atom, a simple hackable open-source text editor, that proves Atom is still needed.
I am not a contributor of Atom to know the real challenges, but just brainstorming I have some ideas for this possible fork:
Same UI, same keybindings; Updating deps versions; Ensure to keep compatibility with the current packages and themes; Maybe removing Less and CoffeeScript; Maybe rewriting the core parts and with luck make it faster, minimal, optimizable, but without rust, just the hackable our common javascript, html and css; Maybe integrating some popular packages by default.
@atom-community started a fork at https://github.com/atom-community/atom/ a while ago. If anyone wants to continue development there we would be happy to keep it going.
I'd like to see an active healthy Atom fork. I believe that calls for a team that can handle it.
Skills needed for a team wanting to successfully fork Atom:
- General JavaScript skills (or a willingness to learn and some prior programming experience in another language)
- The Atom core repo is pretty much a 100% JavaScript codebase.
- Some familiarity with the NodeJS and Electron ecosystems is a plus, can also be learned along the way, but it is a lot
- Familiarity with web dev is a plus (JS, HTML, a bit of CSS) for the front-end parts of Atom and its packages, as well as to better understand the Chromium/"browser" aspects of Electron
- C++ skills (perhaps surprisingly?), for various native packages Atom depends on that need maintenance and updates
- A willingness to learn about Atom's many default/bundled dependencies and packages (many lines of code across many repos, requiring some knowledge of many programming languages, such as the various syntax highlighting support packages for all the programming languages).
- These packages are a part of the Atom experience. And their tests may break in CI when changing Atom core. Not breaking existing packages is an important part of a successful Atom fork, IMO.
- Familiarity with CI and tests (gotta keep the app from breaking)
- Open source maintainership
- Practical skills to manage repos and handle community contributions
- Diplomacy and a willingness to work through the politics/personal opinions that inevitably rise up
- Time, time time, effort effort effort, lots of both. Atom is a big project.
(Note: No one person needs to have all these skills! Any one of the above is helpful. I personally believe a team with all of those skills collectively is pretty much a requirement, though.)
Major development to-do items:
- Get CI working again, particularly Windows CI on newer Windows CI images
- (Atom's Windows CI currently runs in an older Windows image, which is being deprecated/discontinued, but the tests fail in the newer Windows images at the moment)
- Continue the forward march of Electron updates
- General maintenance
- Work on bug fixes for issues users report
- Review PRs from the community (if there are any/if the fork would get really big and active)
- Update dependencies, including the many default/bundled packages (this is a huge amount of code across a huge number of repos)
Unclear if needed, but the fork may need to re-implement or replace the functionality of the atom.io website:
- Study and re-implement (or code an alternative to) the functionality of
atom.io, in case that site goes down.-
atom.iohosts Atom's packages API thatapminteracts with to publish or download/install packages, and a web interface to browse info about the packages. - atom.io is also involved in the automatic Atom app updates on macOS and Windows (API docs)
- And it is involved in some additional user flows, such as getting an auth token for the
githubpackage. - It hosts the "Flight Manual" (user manual for how to use, develop packages for, or update/tinker with Atom itself.)
- Would be nice to have a proper website for the fork, for continuity with Atom's "accessible" and "welcoming" branding and project spirit.
-
Sorry for the long post. I hope that if there is passion for a fork, that this can point people in the right direction.
Please we all have to agree to a community standard and I hope the archive does not affect the fork at all
@atom-community started a fork at https://github.com/atom-community/atom/ a while ago. If anyone wants to continue development there we would be happy to keep it going.
I'd like to join the team, it seems pretty interesting :D
It will be really hard to find people with the skills and time to work on this. I think the first thing would be to create a site where people could join to share ideas.
#25511 Zed will be the next generation of Atom
~~Zed is proprietary closed source software. this is misinformation. Please do not take advantage of this dying open source project to promote a proprietary product.~~ Retracted. see more...
I think the first thing would be to create a site where people could join to share ideas.
Complementing what @DeeDeeG said, people that want to help with a fork could join at Atom Community Discord (Link by @UziTech https://github.com/atom/atom/issues/25510#issuecomment-1152796764). There we can discuss next steps.
As for people making forks left and right, let's first discuss on Discord. There we can gather ideas. Also, don't forget: Atom is not only the editor, there are LOTS of NPM packages that are just used by Atom (maybe we can generate a monorepo with all dependencies?) and also people need to fork the Flight Manual and generate a new site that will be able to search and get packages.
Finally, and this may sound harsh, but forking the repo and not making any commit ever is easy - this will not keep the editor alive! So let's join at discord and discuss - if one is not willing to even join a public discord server we have to accept that it's over...
#25522 is the future, Zed is not @zhaolinlau because it is not having builds yet Stand for Atom. Do Not Archive.
"Stand for Atom. Do Not Archive." It doesn't matter what you're going to write here in a little space, it will be archive on mentioned date. The reasons are obvious and I agree that Atom development was abandoned ages ago. You can literally able to see. Currently Atom and even Atom community fork uses many deprecated version of packages, and the code is quite messy, it'd be rather be great if the community able to rewrite Atom, as a fresh and clean IDE or even next generation of Atom. But I doubt that wouldn't be possible or anytime soon, as VSCode most likely already taken its place over Atom and chances that people are moving to VSCode after Atom was officially unsupported, so therefore a lack of motivation, less contributors, overall it feels like Atom will totally going to be archive.
And most important that GitHub is now owned by Microsoft, so all decisions are made and executed by them, I can see after GitHub released their GitHub Codespace, it was so expected. A GitHub issue page won't going to change their mind. Overall creating random issue pages, arguing about text editors isn't the solution to keep Atom alive in future.
If there is a new fork of atom, contact me! I'd love to keep it alive and contribute. Thanks!
@cyberdev101 join the discord server, we're discussing a fork right now. We're trying to organize things and separate tasks to at least breath life in Atom after the sunset, then think about any modernization.
as VSCode most likely already taken its place over Atom VSCode and Atom are different beasts altogether in my opinion. VSCode is for people that want a stable, safe, etc editor. Atom is for people that want a slight unstable, but hackable, editor. Atom probably calls for people that use Vim and Emacs but want something more "visual" with a more wide-spread language.
It's not a critique for you, specifically, Ruzie - it's more that I heard this same argument over and over, and I believe most folks - Atom users included - need to understand that Atom will never take VSCode, Sublime, or InteliJ's place because it is not the idea either. The idea is to make something that can be almost infinitely customizable, open-source, code editor. Without Atom, we're back at Vim and Emacs as the only options...
It's not a critique for you, specifically, Ruzie - it's more that I heard this same argument over and over
I wrote my expression that what I've saw among most of developers, and this isn't a critique, I don't think by this way it can slow down any growth of popular IDEs.
Without Atom, we're back at Vim and Emacs as the only options...
Personally I don't use emacs but vim, yes. That's way too much to jump to vim or emacs in this days, I've heard that atom-community already working on it, I assume a little bit patience and hard work will grow Atom again. It's not that "a IDE support has officially ended so you can't use them", still you can and even maintain.
I don't believe that GitHub actually cares about the future of Atom in any sense, hardly surprising given that GitHub is a Microsoft subsidiary and their own VSCode is doing relatively well if we are going to be frank about it.
That being said I personally do not like VSCode for a number of reasons, that we will not go into here.
I emailed GitHub regarding forking Atom and wanted them to express there view on it, I was hoping that this would then lead to a discussion about whether or not the components of the atom.io website and the packages etc are also all open source as it was quite rightly raised by another poster that this would need to be forked also to retain the complete functionality of Atom as is today.
Unfortunately I did not receive a response to my email, not even so much as an "it's open-source do as you wish".
Assuming that all of the components of the atom.io site are also open-source and available in the repositories then moving this is not too difficult it will need to be built on a new site and the core atom source amended to use the new site.
From where I sit that is the easy part, the more challenging bit is unpicking the application's years of development to understand it well enough to be able to fix any outstanding bugs, provide on-going support and develop security patches as well as add new features.
Those are all things that are within my capability and I am sure others would come along for the ride, however the question we must ask ourselves before submitting ourselves to a zero free time contract is this.
"Is it in the communities best interest to continue to support Atom, and by support I mean with the development of on-going security and bug patches as well as the addition of new features and so on."
I think for me to do this I would like to see some data be that via social media or forum polls that show me there is a demand of more than a handful of users that cannot see any other choice but to continue using Atom.
Like wise I would need to see some commitment from other developers to support me with this venture as it would be foolish to think you could handle this alone.
There is a famous quote that says "Impossible is simply the limit of man's imagination", and keeping Atom alive is certainly not impossible if we have the creativity to continue.
However there is another quote that says "It is a capital error to hypothesis without data", and what we do not have not is the data of how big the user base is and how many of that user base would come over to our port, we need to know what the demanded is to asses the viability of the project.
That's my thoughts on this.
I am open to question's, discussion and debate, but please keep it polite in respect of the public nature of the Internet.
@softorangetech11 Thank you for creating the poll.
i deleted the poll
Bruh
I don't believe that GitHub actually cares about the future of Atom in any sense, hardly surprising given that GitHub is a Microsoft subsidiary and their own VSCode is doing relatively well if we are going to be frank about it.
That being said I personally do not like VSCode for a number of reasons, that we will not go into here.
I emailed GitHub regarding forking Atom and wanted them to express there view on it, I was hoping that this would then lead to a discussion about whether or not the components of the atom.io website and the packages etc are also all open source as it was quite rightly raised by another poster that this would need to be forked also to retain the complete functionality of Atom as is today.
Unfortunately I did not receive a response to my email, not even so much as an "it's open-source do as you wish".
Assuming that all of the components of the atom.io site are also open-source and available in the repositories then moving this is not too difficult it will need to be built on a new site and the core atom source amended to use the new site.
From where I sit that is the easy part, the more challenging bit is unpicking the application's years of development to understand it well enough to be able to fix any outstanding bugs, provide on-going support and develop security patches as well as add new features.
Those are all things that are within my capability and I am sure others would come along for the ride, however the question we must ask ourselves before submitting ourselves to a zero free time contract is this.
"Is it in the communities best interest to continue to support Atom, and by support I mean with the development of on-going security and bug patches as well as the addition of new features and so on."
I think for me to do this I would like to see some data be that via social media or forum polls that show me there is a demand of more than a handful of users that cannot see any other choice but to continue using Atom.
Like wise I would need to see some commitment from other developers to support me with this venture as it would be foolish to think you could handle this alone.
There is a famous quote that says "Impossible is simply the limit of man's imagination", and keeping Atom alive is certainly not impossible if we have the creativity to continue.
However there is another quote that says "It is a capital error to hypothesis without data", and what we do not have not is the data of how big the user base is and how many of that user base would come over to our port, we need to know what the demanded is to asses the viability of the project.
That's my thoughts on this.
I am open to question's, discussion and debate, but please keep it polite in respect of the public nature of the Internet.
Hmm, makes a lot of sense. This is the right plan to execute.....
i left Atom (never hated .... used it for a bit, but vscode just fit me better) but I LOVE the idea of a fork and you know ... sometimes i will go out of my way to use it and see what it's like. Back when i switched to vscode from atom ... vscode reminded me of atom mixed with sublime, but Atom seemed clunkier and slower doing the same thing. not saying i will stop using vscode in this case but if Atom gets TLC it needs ... I can see myself using either/both at times ... even just to see improvements that have been made
I love the idea of a fork by the community that loves Atom
The main reason I moved from Atom to Kate was how much faster it launches and the responsiveness. All development switching to a fork may actually be a good thing.
If anyone wants to help, we're at https://github.com/pulsar-edit now.