The code isn't being sunsetted, and anyone who wants to take it and keep working on it is free to do so.

But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it is, indeed, an end of sorts. "The community" is almost never large and organized enough to keep a project like this vital. At best, they can only slow its descent into obscurity.

I agree.

Correct me if I'm wrong, but most projects started by some form of organization end up being dead after handing them off to the community. That is, unless they make their code from the ground up to be as most readable and modular as possible.

I remember many projects made by Sun Microsystems that just died when Oracle took over, even if the code is still there.

The history of Zulip is one of my favorite counter-examples to this trend. They have seen great growth and success since spinning off from Dropbox!

https://zulip.com/history/

Not really a counterexample as zulip started life *outside* dropbox.

I wouldn't really call Zulip a counter-example. It wasn't aband^H^H^H^H^H released to the community, it was spun off as a separate company. They offer paid products, have employees, an office in San Francisco, etc.

OT, but: ^W deletes a word, so you don't need to spam ^H. (Though it is a dangerous habit when writing in a browser tab.)

There are some things worse than death, like what MySQL experienced: being turned into a zombie designed to eat the brains and infect people who used to use it when it was truly free, all in the name of tricking people into switching to Oracle's expensive SQL server.

What? MySQL continues to work just fine. 8.0 (which was admittedly released two years ago) was the biggest release in ages in terms of new features and removal of things that should have been removed decades ago. Then there's MariaDB, which is named differently purely for copyright reasons and could be considered the 'real' MySQL (since its dev team are Monty and friends). I don't think MySQL came out of Sun's disintegration badly at all.

To be more precise: 8.0 finally has proper utf-8 out of the box, support for complex replication topologies (including multi-master), window functions, CTEs, etc.

MySQL has been and continues to be a major success for Oracle, and in 8.0+ and beyond the feature set, correctness, and performance have improved substantially; MySQL continues to evolve and currently is in a good spot. It is even more attractive in modern times thanks to systems like Vitess, which add major features (online schema change, excellent horizontal scaling) that give alternatives a run for their money. What are you even talking about?

Then explain MariaDB?

https://www2.computerworld.com.au/article/457551/dead_databa...

>Dead database walking: MySQL's creator on why the future belongs to MariaDB

>MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle

>It's fair to say that MySQL creator Michael "Monty" Widenius is not a fan of Oracle. When the company announced in April 2009 that it was purchasing Sun, Widenius saw a bleak future ahead for the (still) wildly popular open source database, which Sun had snapped up in 2008.

>The day the Sun purchase was announced, Widenius responded in the tried and true open source fashion — he forked MySQL, launching MariaDB, and took a swathe of MySQL developers with him.

>"Many of the original MySQL core developers, including me, didn't believe that Oracle would be a good owner of MySQL and we wanted to ensure that the MySQL code base would be free forever," Widenius explains.

>Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB

>Widenius and a number of other MySQL developers started a company, Monty Program Ab "to provide a home both for MariaDB — the new MySQL — and for all MySQL core developers".

>"Monty Program Ab is owned by the employees and uses the 'hacking business model' as a way to drive the company," Widenius says.

>Although MySQL is still widely used — Db-engines.com ranks it as the third most popular RDBMS after Oracle and Microsoft SQL Server, compared to MariaDB coming in at #35 — Widenius still believes the database has a bleak future under Oracle's stewardship.

>Oracle's treatment of MySQL and its community since its purchase of Sun has proved Widenius' original fears correct, the developer says. Not mincing words, Widenius says that Oracle has made it clear "that they have no love for open source, working with the community, or MySQL in general".

>Widenius cites as examples of Oracle's disregard for open source principles the September 2011 announcement of commercial extensions to MySQL, the bugs database not being public any more, and a lack of test cases for new code in MySQL 5.5 and 5.6.

>Widenius is also scathing of the quality of Oracle's MySQL development efforts. "Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB," he says.

>He also says that security issues are not addressed quickly enough.

>"Instead of fixing bugs, Oracle is removing features," Widenius says.

>"The MySQL documentation was never made open source, even [though] it was promised in the MySQL conference in April 2009," he adds.

>"Flagship features promised for MySQL 6.0 have never been released, even if they were fully developed and ready to be released," he says, referring to online backup for all storage engines and foreign keys for all storage engines.

>"Most of the original MySQL developers have left Oracle. Without people that can understand and explain the code it's almost impossible for Oracle to develop MySQL further even if they wanted to."

>As further evidence of disdain for MySQL users, Widenius cites what he describes as "sharp" increases in licence and support fees, a lack of an open roadmap and no way for the community to participate in the database's development.

>"Why is the price for a MySQL OEM license higher than for Oracle Express?" Widenius asks.

[...]

What exactly does these words prove? Monty has been known to shit on Oracle's efforts just because they are from Oracle, regardless of their quality (as do many others, proven by this very discussion). He's the head of a competing fork that they're trying to monetize, I would take his words with a shovel of salt.

The real problems with MySQL are:

- the bugs database is not public (as he's said)

- all development is going behind closed doors; MariaDB is more open to the public

That's it. Quality-wise it's better than MariaDB IMHO. And they pay more attention to low-level stuff that doesn't add too many new features but greatly improves things like reliability (such as rewriting the underlying InnoDB storage format). Although that one did introduce a significant feature (transactional and fully atomic DDL, which MariaDB implemented only partly and recently).

MariaDB has its share of problems. For example, they have exactly the opposite issue of what he's describing: in their first releases they've imported mountains of code from other MySQL forks without much testing (especially from Percona), things like Cassandra and TokuDB that went practically unmaintained for years and are now in the process of being removed. All to toggle as many feature checkboxes as possible ("look at how much shiny new stuff we ship!")

I personally don't use new MariaDB releases until at least their 5th or 6th patchset.

I also don't really understand this question:

> Then explain MariaDB?

Monty didn't want to work under Oracle. He left and started a competitor. What else to explain?

>2013

For a time it did seem MariaDB would replace MySQL. But your link is almost 10 years old and since that time MySQL has seen it’s biggest release (iirc ever) in terms of features and bug fixes. Meanwhile MariaDB and it have diverged and aren’t really 1 to 1 replacements as they were in 2014.

Precisely.

This is a responsible way to handle the ceasing of maintenance while allowing any and all interested members of the Atom community to fork and maintain versions.

I have a much more optimistic view of development communities than you do, and I expect to see Atom endure in some forms.

There had been at least one attempt to fork and revive Atom since, as the post mentions, Atom hasn’t seen feature additions in many years.

The problem, as I understand it, is that Atom’s relationship with electron makes it very difficult to work on the core of the editor. Namely, while VS Code is downstream from Electron, and can get feature benefits just by updating their Electron version, Atom is upstream from Electron, and new Electron features needed to be more manually integrated.

Then why did they say they are sunsetting it!? It's in the freaking article

No it's perfectly reasonable. That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit. And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase, they're the same sort of project serving the same sort of market, and the community is much better off with only one of them.

Instead of letting it slowly bleed out and randomly catching stragglers with outdated marketing materials lingering on the web, they give it a swift death. Atom can go into the history books as an open source project that defined the industry for a decade.

> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase

It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.

Also, the core editor experience of VS Code, the Monaco editor, predated Atom by several years. It was used from the very early days of the Azure Portal and also in IE's Developer Tools. It didn't become "VS Code" until sometime after Electron stabilized out from under Atom, but parts of it have existed for longer than Atom.

Slack does not aim to build a superset of features of Atom.

IntelliJ idea also includes most or all features Atom does, but that does not validate this statement:

> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase

They both use Electron as their framework, but that's about where the code similarities end.

Electron could probably be described as "a big chunk" of Atom's codebase. The rest of VS Code has a lot of similar functionality to Atom, so calling it "a rewrite" doesn't feel that far off (except insofar as it was redesigned as well, but that's sort of semantics)

> And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase

Atom and VSCode projects have always been separate projects. Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.

If I remember correctly, Electron was made for Atom (by GitHub).

Atom Shell, which was renamed to Electron, was made for Atom. Electron is not Atom. They both use javascript, too, but that doesn't mean they share code.

Yep https://www.electronjs.org/blog/electron

from the article "This is a tough goodbye. It’s worth reflecting that Atom has served as the foundation for the Electron framework, which paved the way for the creation of thousands of apps, including Microsoft Visual Studio Code, Slack, and our very own GitHub Desktop."

Yes. As the comment you’re replying to said, “Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.” Code is no more a “rewrite of Atom that reuses a big chunk of the original codebase” than Slack is.

“both using Electron" refers to a period of time that occurs after "Atom has served as the foundation for the Electron" and my quote states that Atom -> Electron -> Spark

I'm not an expert on this at all, I'm just quoting, but Spark is being used rhetorically as if it's an outlandish to consider it to be a descendent

> That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit.

One should make a difference between (1) access to the source code to look, find bugs, make minor adjustments and (2) everybody with that access to be able to actively participate in the development.

In the sense of (1), open source is "some part of a commons". That's what the license gives you.

In the sense of (2), open source may or not be open to a community approach. It's fully legitimate for some company or other group of maintainers to provide (1) but deny anything related to (2). You are free to fork and make your own community, but there is nothing that guarantees you that your pull requests are accepted or even looked at, bug reports reacted to or anybody listening to wishes, concerns or other opinions about the project. It's nice if that's provided, and one could argue that some part of the spirit of open source is to enable a community, which in turn helps the original creators (and could be a major motivation to open source something), but nobody should be upset if maintainers choose otherwise.

It's nice if it's clearly communicated how maintainers see this though.

I’ve never seen anyone actually using atom, so would hardly say it defined anything much less than the whole industry.

I actually prefer what they're doing. Consider most open source projects. Our involvement with them goes something like:

1. I need feature X

2. I find library WeLoveX

3. Is WeLoveX a good investment for my larger product?

4. Ambiguity happens here

The ambiguity happens because I have one prominent indicator: release activity. If it's changing lots, does that mean it's active and a solid foundation? Or does it mean it's actually probably not quite ready for prime time yet and hasn't found stability? On the flip, if there's very little release activity, does that mean it's dead, the developers have moved on and maybe there's something better out there? Or does it mean it just does its job really really well and doesn't need a constant stream of tweaks?

It's nice to have a general statement of disposition towards the product by the original authors.

> Apache Retirement Home for Veteran Projects

Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat.

I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding foundations like the ASF.

Not everything in ASF is dead. OpenOffice probably is, but NetBeans is still being actively developed. Good thing, too, alongside IntelliJ it was probably the IDE most oriented toward getting people started writing Java code, rather than as a portal into the vast and confusing plugin ecosystem (looking at you, Eclipse).

Back in the day it also had decent PHP support (don't know how true that still is).

I think this conflates several concerns which are unrelated. In particular, for a project to be under ASF stewardship does not mean it doesn't have large companies backing it. Look at projects like Kafka, Pulsar, Camel, Arrow, Spark, Flink, Pinot, Superset, Druid, etc. pp., they are all thriving and have strong funding.

It's only a retirement if no releases happen afterward.

Most people using Atom or any other open source project, would likely have based their decision at least partly on the organization backing the project, especially in a professional setting.

For the most part, when a different organization picks up the development of the project (if one does) it's a completely new project at this point (there are exceptions, such as a backing organization continuing to back the project, but deciding that it's better supported by an independent trust, and therefore building a transition plan for that).

The best example of this is looking at any Apache supported project today. There are very few projects that were handed over to the Apache foundation that people would want to continue using in their post Apache handover date, even if they were amongst the lucky few that still have active development (OpenOffice, for example).

Sunsetting is absolutely the right term/approach to use.

If the community actually cares enough, they can fork it and continue on with development.

Probably under a new name - I’d expect MS to be in control of the “Atom” trademark and branding, and they would stop further use.

if you attempt to sell, or commercially utilize the atom name in a fork of the project, i can see why microsoft would stop you.

It's just a name, but they should be able to call themselves a 'fork of Atom'.

I'd expect them to put the project out to Apache pasture (Apasture?).

"sunsetting" is better than corp-speak saying "handing it off to community maintenance"

Especially, if there isn't a dedicated community to maintain it.

I'll take honesty over corp-speak any day.

That said we probably only get honesty, because they want us using vscode instead.

Corporate speak involves blatant ambiguity and kafkaesque messaging. "Sunsetting" has a very direct meaning for GitHub, whether it gets supported by the community is something else.

I agree in principle, but I find it hard to imagine that there's enough interest to find someone who is willing to maintain the software and the package registry.

Speaking of packages - of the six featured packages I get offered on atom.io, only one had a release in the last two years, and half have been unchanged for half a decade. Atom's already dead.

A lack of releases could mean dead, but it could also mean finished. As in, complete: not in need of more features, and having no bugs of sufficient severity to bother fixing.

Finished is a state more software should aspire to reach. Sadly, with the advent of connectivity in everything, it's getting rare for even firmware to be finished.

Something as complex as a code editor will never be finished. There will always be new languages, new tooling, and better ways to edit.

Most real world problems have almost infinite demand for more and better software. The final text editor will be the one that reads the minds of the users and product manager and writes the code for you.

Sadly this is not the case for Atom. Many packages are just broken, half baked or missing essential features that their vscode counterparts do have.

GitHub is owned by Microsoft, the company that invented "Embrace, Extend, Extinguish".

We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

I know that perception of Microsoft will never go away in the open source community, and maybe it shouldn’t, although I’m not convinced Microsoft of 2022 is particularly worse (or particularly better) than most other companies operating simultaneously in open source and proprietary spaces.

The context of “embrace, extend and extinguish” has kind of been diffused over the years, though; it never meant “buy a product and kill it,” but rather meant adopting open standards and adding proprietary (not necessarily closed, which is not the same thing) extensions to them that end up becoming de facto standards, so your product is perceived as better at the task then the fully standards-compliant original. What happened with Visual Studio Code and Atom isn’t an example of this at all. For a start, they’re just two products that are competing in the same space; they’ve never had the same extension standards, so the idea of “embracing and extending” just isn’t relevant here.

Secondly, Microsoft obviously didn’t buy GitHub to shut Atom down. I’ve seen the arguments that once Microsoft did buy GitHub, Atom was doomed, but Code was already arguably more popular than Atom when Microsoft bought GitHub in 2018: Stack Overflow’s developer survey showed VSCode as far more popular among surveyed users (34.9% to Atom’s 18.9%). If those numbers had been reversed—if Code never made a real dent and Atom kept growing—then I have little doubt Atom would be the one continuing.

Lastly, I suspect the runaway popularity of Visual Studio Code is pretty good insurance against a hypothetical “Visual Studio Code Pro” replacing the existing VS Code. This would almost certainly cause a fork (or more than one!) to be created, and it’s highly likely such a fork would get immediate backing and support from one or more technology companies willing to pay for continued open source development.

However, I don’t think that’s likely, because I don’t think that’s how Microsoft is interested in monetizing Code. It’s not a source of income in and of itself. It doesn’t have to be. If it just so happens to have great GitHub integration, maybe your company will pay for GitHub enterprise features. If you’re used to using it, you may be more likely to pay for GitHub Codespaces. If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure. And so on.

No, they didn't buy GitHub to shut Atom down. But they did create VSCode to cut off GitHub's growing expansion of their business through Atom. They could have just extended Atom with Azure plugins etc, but instead they essentially forked it and poured tons of resources and hundreds of developers into it. That effort helped suppress the valuation of GitHub, so that they could buy it for cheaper (or at all?).

The revenue generating upsell for VSCode is already here and it IS GitHub Codespaces. They are going to add features you can't live without based off code synthesis (sky's really the limit here) and gate those off saying it can't run locally because it's too resource intensive. They'll charge you (or your company) by the second for all usage.

It would be much harder or impossible for them to do this if Atom and an independent GitHub had been further entrenching in this space for the last decade.

Many of the biggest developer tooling projects big corp are building now existentially threaten smaller developers and apps, by design.

Don't give Microsoft a pass here.

I'd be willing to bet that even if Microsoft did create VSCode for the purposes of cutting Github's expansion, the effect that VSCode had on Github's valuation is extremely overstated here. The total valuation comes from a range of factors, but let's say there are two major ones: number of users and number of paying organizations. The latter is almost completely not dependent on Atom (companies would not use Atom as a deciding factor to use Github) and while some users might use Github because they used Atom first, I don't think that this is large enough that the migration from Atom to VSCode negatively impacted the valuation.

I think a simpler explanation is correct: Microsoft saw that open source developer tools are gaining a lot of popularity and also knew that it could help revitalize/modernize their image, so they authorized the funding for the creation of a (mostly) open source code editor, and it gained popularity because it was good.

> If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure

This. Microsoft share price depends on the size of their recurring revenue from cloud. They can easily write off a few million on VScode for bringing more users to Azure

VS Code "Pro" is very 1998.

My money is on VS Code 365.

It’s already here. They went with the name GitHub Codespaces.

That is a very good analogy. Considering that Office was also an offline product before it became a cloud-subscribed web/desktop hybrid.

VS Code Pro already exists. It's called Visual Studio.

Despite the name, they have basically nothing in common. They don't share a user interface, they don't share plugins, they don't share hotkeys.

One of the main complaints many of the C# developers on my team have when they have to touch languages that aren't well supported by Visual Studio is that they don't know how to work VSCode.

They do share some plugins actually, that is why VS nowadays also gets a node instance running on the background.

And also why C++ workloads depend on .NET being available.

I'm well aware of the differences between the two products, since I use both on a daily basis. My answer was a bit flippant, sure, but they are both IDEs developed by Microsoft and Visual Studio is definitely the "Pro" version of the two.

Like when they sunset the closed-source .net framework and created the open source .net core?

Or when they sunset the closed-source PowerShell and created the open-source PowerShell Core?

Like those?

I’m not sure the term has ever been applied to Microsoft’s own products…

Atom was developed before the acquisition. Which brings us to the second proud tradition of the tech titans, acquiring companies to end the products the acquirer doesn't like.

Well yeah, if you have two very similar products (editors/IDEs based on web technology), one of them much more successful than the other, putting a lot of effort into the less-used product sounds a bit hard to justify...

Does Microsoft not "like" Atom, or has its market share dwindled to the point that it is no longer worth maintaining?

If you look at the contribution activity it dropped off after acquisition of GitHub by Microsoft and it seems that development was redirected to VSCode.

The writing was on the wall for a long while now, and was one of the reasons why the JuliaCommunity stopped advocating Juno/Atom as a platform and instead switched to VSCode

Probably a bit of both if I was to hazard a guess. MS has VS Code, which is definitely the elephant in the room as far as go to IDEs in the environments I’ve been in lately. So right now they’re spending engineering time on both VS Code and Atom, so they may as well focus their resources on the more popular one.

Look at the Atom repo, very few commits in the last year, and it's not like there are loads of open pull requests (serious PRs do get merged), and it's been strongly dropping off for a long time. It's the programming community that abandoned Atom, not Microsoft.

> Which brings us to the second proud tradition of the tech titans, acquiring companies to end the products the acquirer doesn't like.

Atom is inferior in every aspect to Visual Studio Code. Atom was on life support for too long.

it was dead already, or at least, shown inferior to vscode in feature set. If anything you can accuse MS, it's using its market position and the VS brand name to "steal" adoption, but that completed before the aquisition too.

But Atom isn't, is it? It was started prior to Microsoft, to which Microsoft bought Github, and are now "sunsetting". While i don't think Atom was enough competition to actually warrant any real discussion here, the timeline seems quite fitting to EEE no?

They embrace, extend, and extinguish products they don't make money on, so that people are forced to use products that they do make money on.

Microsoft doesn't make money from VS Code. Atom was retired due to a lack of activity with the project. I've never even seen anyone use Atom, since the time it was released 8 years ago.

Hence the parent comment:

> We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

I don't think it would serve their interests, so I'm not worried about it, but who knows? This cynicism is directed towards Microsoft because they've earned it.

Had two coworkers at my last job use it when they needed to edit some of our legacy PHP stuff (we were mostly a .NET shop) but even they switched to VS Code eventually because the writing was on the wall for support.

> Microsoft doesn't make money from VS Code.

They harvest an astonishing amount of data from it.

I'll go Nova before I go VS Code Pro.

"VS Code Pro" came out in 1997

Note that this will lead to unmaintained Electron Apps until at least 2032.

We're basically fucked.

When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block).

Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.

Sounds like premature optimization.

I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly, if and when something like this happens. And I'd say the risk of it happening in the next three to five years is pretty minimal at this point.

> I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly

Once you start making full use of your editor, switching to a new one and reaching the same level of proficiency takes a long time. I can edit code even in notepad, but I can't ever be as fluid in it as my main editor. I've changed my editor multiple times and it's a huge pain every time.

I don't know why Microsoft would do that - VSCode is HUGELY popular and at the forefront of Microsoft "I'm cool now guys!" 'open-source' movement.

> Contingency planning for this could be a small but wise time investment for dependent teams.

I doubt that switching an editor requires a disaster-recovery plan.

Modern tech companies love to look busy and find the most perplexing solutions for the most basic problems.

I guess they have lots of "solutions" to "design and implement".

I am sticking to my Intellij products for this very reason. They work great and the motives of the company are straightforward.

Same, but nvim

While any software can be cancelled, I'd say Atom is being cancelled because of investment in VS Code (both currently owned by MS), I don't see any reason to think it's "inevitable" that VSCode will be cancelled, except in the sense that eventually everyone dies and the earth falls into the sun.

> When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block).

the normalization of this behavior within the industry makes using emacs or vim even more satisfying.

it's nice to having an unchanging cement foundation to stand upon once-in-awhile.

Absolutely. Why continuously reinvent the wheel when there are far more interesting problems to work on :)

:)

Why would this happen to VsCode? VSCode is a proprietary form of Atom is not? It’s hugely successful Microsoft would never do such a thing.

Sort of?

They maintain a trademark on the name Visual Studio Code and some other bits. And it is maintained by a Microsoft team.

But the code itself is MIT licensed. You can build it yourself. I have. There are one or two forks of it out there.

The codebases of VS Code and Atom are unrelated to each other.

Indeed. At least I’m not the first person to make this mistake

https://news.ycombinator.com/item?id=9872976

https://thenextweb.com/news/microsofts-cross-platform-visual...

https://news.ycombinator.com/item?id=17221917

The whole point of github is that anyone can fork the project and continue working on it. The code isn't going away, it's going to get archived.

The point of MS/Github announcing that they are sunsetting the project is that they are basically no longer spending time and money on the project. Projects this size have a lot of things that need attention like security fixes, legal stuff, trademarks/branding, etc. Basically, they do the right thing here by giving people some time to deal with this in whatever form they care to do that before pulling the plug.

Anyone interested in taking ownership of atom now has six months to get organized; I'm sure if somebody steps up, Github would end up doing the right thing and e.g. support them by e.g. transferring domain names, and other things they control. But somebody would need to step up for that to happen.

Apache taking ownership of a project would require that there is some community still there to work on it. They have an incubation process for this kind of thing. But there's also a thing called the attic in Apache where dead projects go after they stop being maintained.

> something that Github, of all companies, should understand

It’s not GitHub anymore though. It’s Microsoft and Microsoft must advance the Visual Studio brand.

Microsoft has never understood open source. This is why they bought GitHub and npm, and paid Docker to make it work on Windows, and why GitHub and the most important parts of VS Code are proprietary software.

They use open source as a marketing buzzword, not as a philosophy, and it shows.

I think perhaps TypeScript is the only counterexample.

I think they understand open source (and show it by many projects) but like you said, it is not their core philosophy.

They are a proprietary software and cloud vendor super house. They are very successful like that. Open Source is 3-4 level down to their main strategy.

All of the id Software code was release to open source essentially sunsett'ed. That was never a problem.

the code is only one of many artifacts within a project . you have multiple support channels for bugs and features, builds, distribution , monitoring / ops (crash and perf reports), developer apis and a dozen more – each requiring time, attention, people and effort .

fork the code and start a new project with resources to take care of those and many other artifacts if you are so inclined . you have the license to do so

just fork it, no one is stopping ;)

GitHub has been sh*tting the bed left and right. I audibly laughed when I saw this article.

I don't know if it started when MS bought them, but it's when I think the decline became very apparent.

It's not an open source project - it never was, it's commercial, corporate project releasing code licensed as Open Source.

"It's not open source, it's code licensed as open source". Hmkay... I find it impressive how concisely you're contradicting yourself in that sentence.

The project is not open source. The code it releases is open source. There's no contradiction - it's perfectly normal for a company to release their code under an open license; Chromium is another example of this. It's technically open, but for almost every practical purpose it could be closed and it would make no difference.

What you're trying to say is "I don't like the way it's run". Okay, fine. That doesn't make it "not open source".

I have projects where I don't accept patches. "It works for me" and I just don't feel like reviewing patches. Is that not "open source" in spite of being MIT licenced?

"I can do with the code what I want" is the entire and only point of Open Source and Free Software, something Stallman and many others have been pretty clear about over the years.

>"I can do with the code what I want" is the entire and only point of Open Source

This is not true at all, as evidenced by http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... You are mistaking Open Source for public domain.