But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.
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.
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.
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.
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.
[...]
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?
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.
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.
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.
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.
It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.
> 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
They harvest an astonishing amount of data from it.
> 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.
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
Atom is inferior in every aspect to Visual Studio Code. Atom was on life support for too long.
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.
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.
https://news.ycombinator.com/item?id=9872976
https://thenextweb.com/news/microsofts-cross-platform-visual...
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.
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 doubt that switching an editor requires a disaster-recovery plan.
I guess they have lots of "solutions" to "design and implement".
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.
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.
And also why C++ workloads depend on .NET being available.
My money is on VS Code 365.
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.
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
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 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.
We're basically fucked.
Or when they sunset the closed-source PowerShell and created the open-source PowerShell Core?
Like those?
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.
It’s not GitHub anymore though. It’s Microsoft and Microsoft must advance the Visual Studio brand.
They use open source as a marketing buzzword, not as a philosophy, and it shows.
I think perhaps TypeScript is the only counterexample.
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.
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
I don't know if it started when MS bought them, but it's when I think the decline became very apparent.
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.
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.