I still like Zulip after about 5 years of use, e.g. see https://oilshell.zulipchat.com . They added public streams last year, so you don’t have to log in to see everything. (Most of our streams pre-date that and require login)
Zulip seems to be A LOT lower latency than other solutions.
When I use Slack or Discord, my keyboard feels mushy. My 3 GHz CPU is struggling to render even a single character in the browser. [1]
Aside from speed, the big difference between Zulip and the others is that conversations have titles. Messages are grouped by topic.
The history and titles are extremely useful for avoiding “groundhog day” conversations – I often link back to years old threads and am myself informed by them!
(Although maybe this practice can make people “shy” about bringing up things, which isn’t the message I’d like to send. The search is pretty good though.)
When I use Slack, it seems like a perpetually messy and forgetful present.
[1] Incidentally, same with VSCode / VSCodium? I just tried writing a few blog posts with it, because of its Markdown preview plugin, and it’s ridiculously laggy? I can’t believe it has more than 50% market share. Memories are short. It also has the same issue of being controlled by Microsoft with non-optional telemetry.
Zulip is light years ahead of everything else in async org-wide communications. The way the messages are organized makes it extremely powerful tool for distributed teams and cross-team collaboration.
The problems:
Clients are slow when you have 30k+ unread messages.
It’s not easy (possible?) to follow just a single topic within a stream.
We used IRC and nobody except IT folks used it. We switched to XMPP and some of the devs used it as well. We switched to Zulip and everyone in the company uses it.
We self-host. We take a snapshot every few hours and send it to the backup site, just in case. If Zulip were properly federate-able, we could just have two live servers all the time. That would be great.
Is this actually a problem? I don’t think most people want federation, but easier SSO and single client for multiple servers gets you most of what people want without the significant burdens of federation (scaling, policy, etc.).
It is definitely a problem. It makes it hard for two organizations to create shared streams. This comes up e.g. when an organization with Zulip for internal communications wants to contract another company for e.g. software development and wants them to integrate into their communications. The contractor needs accounts at the client’s company. Moreover, if multiple clients do this, the people working at the contracted company now have multiple scattered accounts at clients’ instances.
Creating stream shared and replicated across the relevant instances would be way easier, probably more secure and definitely more scalable than adding wayf to relevant SSOs. The development effort that would have to go into making the web client connect to multiple instances would probably be also rather high and it would not be possible to perform it incrementally. Unlike shared streams that might have some features disabled (e.g. custom emojis) until a way forward is found for them.
But I am not well versed in the Zulip internals, so take this with a couple grains of sand.
EDIT: I figure you might be thinking of e.g. open source projects each using their own Zulip. That sucks and it would be nice to have a SSO service for all of them. Or even have them somehow bound together in some hypothetical multi-server client. I would love that as well, but I am worried that it just wouldn’t scale (performance-wise) without some serious though about the overall architecture. Unless you are thinking about the Pidgin-style multi-client approach solely at the client level.
That page is a “dark pattern” to make you think you can turn it off, when you can’t.
In addition, extensions also have their own telemetry, not covered by those settings. From the page you linked:
These extensions may be collecting their own usage data and are not controlled by the telemetry.telemetryLevel setting. Consult the specific extension’s documentation to learn about its telemetry reporting and whether it can be disabled.
It still sends some telemetry even if you do all that
I’ve spent several minutes researching that, and, from the absence of clear evidence that telemetry is still being sent if disabled (which evidence should be easy to collect for an open codebase), I conclude that this is a misleading statement.
The way I understand it, VS Code is a “modern app”, which uses a boatload online services. It does network calls to update itself, update extensions, search in the settings and otherwise provide functionality to the user. Separately, it collects gobs of data without any other purpose except data collection.
Telemetry disables the second thing, but not the first thing. But the first thing is not telemetry!
Does it make network calls? Yes.
Can arbitrary network calls be used for tracking? Absolutely, but hopefully the amount of legal tracking allowable is reduced by GDPR.
Should VS Code have a global “use online services” setting, or, better yet, a way to turn off node’s networking API altogether? Yes.
Is any usage of Berkeley socket API called “telemetry”? No.
Even though we do not pass the telemetry build flags (and go out of our way to cripple the baked-in telemetry), Microsoft will still track usage by default.
Also, in 2021, they apparently tried to deprecate the old setting and introduce a new one:
So basically it seems like it was the old trick of resetting the setting on updates, which was again very common in the Winamp, Flash, and JVM days – dark patterns.
However it looks like some people from within the VSCode team pushed back on this.
Having worked in big tech, this is very believable – there are definitely a lot of well intentioned people there, but they are fighting the forces of product management …
I skimmed the blog post and it seems ridiculously complicated, when it just doesn’t have to be.
So I guess I would say it’s POSSIBLE that they actually do respect the setting in ALL cases, but I personally doubt it.
I mean it wouldn’t even be a dealbreaker for me if I got a fast and friendly markdown editing experience! But it was very laggy (with VSCodium on Ubuntu.)
Yeah, “It still sends some telemetry even if you do all that” is exactly what VS Codium claim. My current belief is that’s false. Rather, it does other network requests, unrelated to telemetry.
At the risk of belaboring the point, it’s a dark pattern.
This was all extremely common in the Winamp, Flash, and JVM days.
The thing that’s sad is that EVERYTHING is dark patterns now, so this isn’t recognized as one. People will actually point to the page and think Microsoft is being helpful. They probably don’t even know what the term “dark pattern” means.
If it were not a dark pattern, then the page would be one sentence, telling you where the checkbox is.
They probably don’t even know what the term “dark pattern” means.
I’d say that most people haven’t been exposed to genuinely user-centric experiences in most areas of tech. In fact, I’d go so far as to say that most tech stacks in use today are actually designed to prevent the development of same.
The thing that feels new is how non-user-centric development tools are nowadays. And the possibility of that altering the baseline perception of what user-centric tech looks like.
Note: feels; it’s probably not been overly-user-centric in the past, but they were a bit of a haven compared to other areas of tech that have overt contempt for users (social media, mobile games, etc).
How would you do this differently? The same is true about any system with plugins, including, eg, Emacs and Vim: nothing prevents a plug-in from calling home, except for the goodwill of the author.
I think the question stands: how would you do it differently? What API would allow plugins to run arbitrary code—often (validly) including making network requests to arbitrary servers—but prevent them from phoning home?
Good question! First option is to not let them make arbitrary network requests, or require the user to whitelist them. How often does your editor plugin really need to make network requests? The editor can check for updates and download data files on install for you. Whitelisting Github Copilot or whatever doesn’t feel like too much of an imposition.
More fun: you have to design a plugin API that doesn’t allow phoning home but does allow using network services. This is basically impossible. You can define a plugin mechanism that has fine-grained permissions and a UI that comes with big red warnings when things want network permissions though and enforce policies in your store that they must report all tracking that they do.
nothing prevents a plug-in from calling home, except for the goodwill of the author.
Traditionally, this is prevented by repos and maintainers who patch the package if it’s found to be calling home without permission. And since the authors know this, they largely don’t add such functionality in the first place. Basically, this article: http://kmkeen.com/maintainers-matter/ (http only, not https).
We don’t necessarily need mandatory technical enforcement for this, it’s more about culture and expectations.
I think that’s the state of the art in many ecosystems, for better or worse. I’d say:
The plugin interface should expose the settings object, so the plugin can respect it voluntarily. (Does it currently do that?)
The IDE vendor sets the expectation that plugins respect the setting
A plugin that doesn’t respect it can be dealt with in the same way that say malware is dealt with.
I don’t know anything about the VSCode ecosystem, but I imagine that there’s a way to deal with say plugins that start scraping everyone’s credit card numbers out of their e-mail accounts.
Every ecosystem / app store- type thing has to deal with that. My understanding is that for iOS and Android app stores, the process is pretty manual. It’s a mix of technical enforcement, manual review, and documented culture/expectations.
I’d also not rule out a strict sandbox that can’t make network requests. I haven’t written these types of plugins, but as others pointed out, I don’t really see why they would need to access the network. They could be passed the info they need, capability style, rather than searching for it all over your computer and network!
Sure, but they don’t offer a “disable telemetry” setting.
What I’d do, would be to sandbox plugins so they can’t do any network I/O, then have a permissions system.
You’d still rely on an honour system to an extent; because plugin authors could disguise the purpose of their network operations. But you could at least still have a single configuration point that nominally controlled telemetry, and bad actors would be much easier to spot.
The really bizarre thing is that Google Groups, the discussion-board-turned-mailing-list, is clearly abandonware….
BUT Google Groups, the foundation for the authorization system used in many other Google products, is thriving!
Want to give access to GCP resources to a bunch of specific users? Use a Google Group. Want to create a website on Google Sites that’s accessible by only a small group of users? Use a Google Group. Same with Photos, Classroom, Workspaces, etc.
It is weird, but you can kind of see how it happened. Remember that Google Groups was a very early side project (22 years ago – back when “social media” meant LiveJournal and MySpace), begun when they acquired Deja’s huge USENET archive. Groups was originally used to make that archive searchable, which got them huge reputation points from the older geek crowd, but it was also their way to Embrace and Extend, and probably Extinguish, the largest chat forum not already stored on the web. (And unlike with a lot of their very early projects, this one came with an large pre-existing user base, and so I imagine it was a high-visibility property, where bugs would get noticed and get talked about.)
Anyway, my point is just that Groups has been around through a couple of iterations of Google’s hey-let’s-make-all-our-things-interoperate frenzies, so it’s not entirely surprising that at one of those times it actually got dragged into doing something important.
People were mentioning this in the HN thread. Are these actually the same product or just two things with the same name? If Google just straight up named a completely different product Google Groups that’s a pretty damning indictment of their commitment to Google Groups the public discussion board.
I have no idea how it works internally of course, but the groups have the same members and appear the same in each Google product including the discussion board part.
I think they’re the same thing with different applications / ways of accessing. When my previous employer moved over to Gmail, etc., they started migrating some GNU Mailman groups to Google Groups and/or spinning up new mailing lists using Groups. I could also access external groups that I was subscribed to with my work address via the same interface. It felt very cobbled together but all seemed to be the same product / tool.
I don’t know - but note that Microsoft has sort of gone the other way - now there is overlap with azure ad “groups”, teams, mailing lists/aliases kind of
Been a long slow decline, it’s frustrating to watch it degrade. Imagine being an engineer assigned to this unloved thing; or worse, a product manager. Career death.
https://groups.io is a good replacement for email lists. It’s mostly a for-pay product.
https://www.usenetarchives.com/ is a good search engine for pre-2000 Usenet. Like Google’s old Deja archive which has been nearly unusable via Google Groups for years now.
I assumed it had been abandoned back when I was reading the Clojure group on it in 2012 or so and it basically just … stopped doing any spam filtering whatsoever? Someone must have commented out the “actually filter spam” lines of code and no one at google must have noticed.
Not long after that we lost the ability to view the (plain text) messages in the archive without enabling JS. It would also frequently refuse to display messages to you, even in a public group, unless you logged in.
This is all terribly predictable, and as usual some people learn the lesson from it and others don’t. It’s good to see that the author of the article above seems to be in the former category.
Yeah I’m leaning toward advocating for a Zulip/mailing list combo. That’s what Isabelle uses. I’ve started doing some development on SourceHut but haven’t yet used mailing lists. I’ll have to see what their UI looks like. Personally I more enjoy the phpBB internet forum style of interaction (I wonder whether you can date internet users by this method?) so would want any mailing list software to have a front-end of that sort.
I want to like Discourse but it’s just so… whitespace-y and javascript-y? My mind kind of slides off the page, there aren’t any delineations between different page elements. And why do I see a visible loading circle every time I click to load a page of text?
It’s refreshing to hear there’s still a demand for this kind of platform, people often question why I’m building brand new forum software in 2023 but there’s clearly a desire for some groups/orgs to self-host and own their data. This post got me thinking about a google groups importer and mailing list functionality!
It’s refreshing to hear there’s still a demand for this kind of platform, people often question why I’m building brand new forum software in 2023 but there’s clearly a desire for some groups/orgs to self-host and own their data.
So, something I was tinkering with for a while was Usenet. There used to be decent Web front-ends for it (my first development job was with a company who sold one - the manual is still online!).
I’ve often wondered if you could use NNTP as the basis for a system like this in modern times. A combined NNTP server + web portal, such that folks could use their own newsreaders or the Web interface. Then just host that. Very “smol Web” aligned.
I did a deep dive and it has a lot of things I’d want from a Google Groups replacement.
OP wrote this, though:
It’s also tempting to use GitHub Discussions since all these projects are developed on GitHub anyway, but I think this tendency should be resisted. GitHub is wonderful now but fundamentally proprietary, same as Google Groups.
If it was “left to die” you wouldn’t get new bugs like monospace fonts failing to render. It is being actively sabotaged from inside, wittingly or unwittingly.
Saying things are “left to die” implies that they will die if not constantly tinkered with and “upgraded.” But this sort of attention is likely what’s causing most of the problems. No doubt none of these problems existed before the move to the more bloated interface a year or two ago; leaving it alone would have been the best possible thing for it.
I can’t speak in details, but Google often neglects products to death in such a way that they have less than one full-time engineer paying attention to each product. It would not surprise me to learn that a half-dead Google product literally has only half an engineer allocated. Combine this with Google’s monorepo strategy, where it is very common for cross-cutting changes to affect your code from halfway across the company, and it is easy to imagine that the decay is natural.
When we talk of sabotage, we should imagine deliberate additions to the system which compromise or weaken it. I don’t think that that’s the case here.
I suppose unwitting sabotage is an oxymoron. Better to say harm, as there’s no way to know whether it’s due to incompetence or malice. Hard to imagine some Google manager isn’t aware of the predictable effect of rewriting the front end 1-2 years before dropping the number of maintenance engineers to a skeleton crew.
In general, yes; assume that the engineers are aware and management is clueless. (Google management is actually relatively technical and clueful, but it’s a general pattern worth recognizing.)
You’re saying to assume that managers have no clue about the effects of their decisions? They have no concept of the maintenance burden of newly written code vs. code that has been in use for a decade? They allocate engineers and funding with no notion of the consequences?
And what’s the relevance of the general case if we’re talking about Google? Are you just changing the topic?
I still like Zulip after about 5 years of use, e.g. see https://oilshell.zulipchat.com . They added public streams last year, so you don’t have to log in to see everything. (Most of our streams pre-date that and require login)
It’s also open source, though we’re using the hosted version: https://github.com/zulip
Zulip seems to be A LOT lower latency than other solutions.
When I use Slack or Discord, my keyboard feels mushy. My 3 GHz CPU is struggling to render even a single character in the browser. [1]
Aside from speed, the big difference between Zulip and the others is that conversations have titles. Messages are grouped by topic.
The history and titles are extremely useful for avoiding “groundhog day” conversations – I often link back to years old threads and am myself informed by them!
(Although maybe this practice can make people “shy” about bringing up things, which isn’t the message I’d like to send. The search is pretty good though.)
When I use Slack, it seems like a perpetually messy and forgetful present.
I linked to a comic by Julia Evans here, which illustrates that feature a bit: https://www.oilshell.org/blog/2018/04/26.html
[1] Incidentally, same with VSCode / VSCodium? I just tried writing a few blog posts with it, because of its Markdown preview plugin, and it’s ridiculously laggy? I can’t believe it has more than 50% market share. Memories are short. It also has the same issue of being controlled by Microsoft with non-optional telemetry.
+1 on zulip.
category theory https://categorytheory.zulipchat.com/ rust-lang https://categorytheory.zulipchat.com/
These are examples of communities that moved there and are way easier to follow than discord or slack.
Zulip is light years ahead of everything else in async org-wide communications. The way the messages are organized makes it extremely powerful tool for distributed teams and cross-team collaboration.
The problems:
We used IRC and nobody except IT folks used it. We switched to XMPP and some of the devs used it as well. We switched to Zulip and everyone in the company uses it.
We self-host. We take a snapshot every few hours and send it to the backup site, just in case. If Zulip were properly federate-able, we could just have two live servers all the time. That would be great.
Is this actually a problem? I don’t think most people want federation, but easier SSO and single client for multiple servers gets you most of what people want without the significant burdens of federation (scaling, policy, etc.).
Sorry for a late reply.
It is definitely a problem. It makes it hard for two organizations to create shared streams. This comes up e.g. when an organization with Zulip for internal communications wants to contract another company for e.g. software development and wants them to integrate into their communications. The contractor needs accounts at the client’s company. Moreover, if multiple clients do this, the people working at the contracted company now have multiple scattered accounts at clients’ instances.
Creating stream shared and replicated across the relevant instances would be way easier, probably more secure and definitely more scalable than adding wayf to relevant SSOs. The development effort that would have to go into making the web client connect to multiple instances would probably be also rather high and it would not be possible to perform it incrementally. Unlike shared streams that might have some features disabled (e.g. custom emojis) until a way forward is found for them.
But I am not well versed in the Zulip internals, so take this with a couple grains of sand.
EDIT: I figure you might be thinking of e.g. open source projects each using their own Zulip. That sucks and it would be nice to have a SSO service for all of them. Or even have them somehow bound together in some hypothetical multi-server client. I would love that as well, but I am worried that it just wouldn’t scale (performance-wise) without some serious though about the overall architecture. Unless you are thinking about the Pidgin-style multi-client approach solely at the client level.
This is a little off topic, but Sublime Text is a vastly more performant alternative to VSCode.
[Comment removed by author]
Also off-topic: performant isn’t a word.
It is though. https://dictionary.cambridge.org/dictionary/english/performant
I feel like topic-first organization of chats is, which Zulip does, is the way to go.
VSCode’s telemetry can be disabled
https://code.visualstudio.com/docs/getstarted/telemetry#_disable-telemetry-reporting
It still sends some telemetry even if you do all that
https://github.com/VSCodium/vscodium/blob/master/DOCS.md#disable-telemetry
That page is a “dark pattern” to make you think you can turn it off, when you can’t.
In addition, extensions also have their own telemetry, not covered by those settings. From the page you linked:
I’ve spent several minutes researching that, and, from the absence of clear evidence that telemetry is still being sent if disabled (which evidence should be easy to collect for an open codebase), I conclude that this is a misleading statement.
The way I understand it, VS Code is a “modern app”, which uses a boatload online services. It does network calls to update itself, update extensions, search in the settings and otherwise provide functionality to the user. Separately, it collects gobs of data without any other purpose except data collection.
Telemetry disables the second thing, but not the first thing. But the first thing is not telemetry!
It took me awhile, but the source of my claim is from VSCodium itself, and this blog post:
https://www.roboleary.net/tools/2022/04/20/vscode-telemetry.html
https://github.com/VSCodium/vscodium/blob/master/DOCS.md#disable-telemetry
Also, in 2021, they apparently tried to deprecate the old setting and introduce a new one:
https://news.ycombinator.com/item?id=28812486
https://imgur.com/a/nxvH8cW
So basically it seems like it was the old trick of resetting the setting on updates, which was again very common in the Winamp, Flash, and JVM days – dark patterns.
However it looks like some people from within the VSCode team pushed back on this.
Having worked in big tech, this is very believable – there are definitely a lot of well intentioned people there, but they are fighting the forces of product management …
I skimmed the blog post and it seems ridiculously complicated, when it just doesn’t have to be.
So I guess I would say it’s POSSIBLE that they actually do respect the setting in ALL cases, but I personally doubt it.
I mean it wouldn’t even be a dealbreaker for me if I got a fast and friendly markdown editing experience! But it was very laggy (with VSCodium on Ubuntu.)
Yeah, “It still sends some telemetry even if you do all that” is exactly what VS Codium claim. My current belief is that’s false. Rather, it does other network requests, unrelated to telemetry.
That is an … interesting … design choice.
At the risk of belaboring the point, it’s a dark pattern.
This was all extremely common in the Winamp, Flash, and JVM days.
The thing that’s sad is that EVERYTHING is dark patterns now, so this isn’t recognized as one. People will actually point to the page and think Microsoft is being helpful. They probably don’t even know what the term “dark pattern” means.
If it were not a dark pattern, then the page would be one sentence, telling you where the checkbox is.
I’d say that most people haven’t been exposed to genuinely user-centric experiences in most areas of tech. In fact, I’d go so far as to say that most tech stacks in use today are actually designed to prevent the development of same.
The thing that feels new is how non-user-centric development tools are nowadays. And the possibility of that altering the baseline perception of what user-centric tech looks like.
Note: feels; it’s probably not been overly-user-centric in the past, but they were a bit of a haven compared to other areas of tech that have overt contempt for users (social media, mobile games, etc).
How would you do this differently? The same is true about any system with plugins, including, eg, Emacs and Vim: nothing prevents a plug-in from calling home, except for the goodwill of the author.
Kinda proves the point, tbh. To prevent a plugin from calling home, you have to actually try to design the plugin API to prevent it.
I think the question stands: how would you do it differently? What API would allow plugins to run arbitrary code—often (validly) including making network requests to arbitrary servers—but prevent them from phoning home?
Good question! First option is to not let them make arbitrary network requests, or require the user to whitelist them. How often does your editor plugin really need to make network requests? The editor can check for updates and download data files on install for you. Whitelisting Github Copilot or whatever doesn’t feel like too much of an imposition.
Capability security is a general approach. In particular, https://github.com/endojs/endo
For more… https://github.com/dckc/awesome-ocap
More fun: you have to design a plugin API that doesn’t allow phoning home but does allow using network services. This is basically impossible. You can define a plugin mechanism that has fine-grained permissions and a UI that comes with big red warnings when things want network permissions though and enforce policies in your store that they must report all tracking that they do.
Traditionally, this is prevented by repos and maintainers who patch the package if it’s found to be calling home without permission. And since the authors know this, they largely don’t add such functionality in the first place. Basically, this article: http://kmkeen.com/maintainers-matter/ (http only, not https).
We don’t necessarily need mandatory technical enforcement for this, it’s more about culture and expectations.
I think that’s the state of the art in many ecosystems, for better or worse. I’d say:
I don’t know anything about the VSCode ecosystem, but I imagine that there’s a way to deal with say plugins that start scraping everyone’s credit card numbers out of their e-mail accounts.
Every ecosystem / app store- type thing has to deal with that. My understanding is that for iOS and Android app stores, the process is pretty manual. It’s a mix of technical enforcement, manual review, and documented culture/expectations.
I’d also not rule out a strict sandbox that can’t make network requests. I haven’t written these types of plugins, but as others pointed out, I don’t really see why they would need to access the network. They could be passed the info they need, capability style, rather than searching for it all over your computer and network!
That’s exactly how it works: https://code.visualstudio.com/api/extension-guides/telemetry
Sure, but they don’t offer a “disable telemetry” setting.
What I’d do, would be to sandbox plugins so they can’t do any network I/O, then have a permissions system.
You’d still rely on an honour system to an extent; because plugin authors could disguise the purpose of their network operations. But you could at least still have a single configuration point that nominally controlled telemetry, and bad actors would be much easier to spot.
There is a single configuration point which nominally controls the telemetry, and extensions should respect it. This is clearly documented for extension authors here: https://code.visualstudio.com/api/extension-guides/telemetry#custom-telemetry-setting.
The really bizarre thing is that Google Groups, the discussion-board-turned-mailing-list, is clearly abandonware…. BUT Google Groups, the foundation for the authorization system used in many other Google products, is thriving!
Want to give access to GCP resources to a bunch of specific users? Use a Google Group. Want to create a website on Google Sites that’s accessible by only a small group of users? Use a Google Group. Same with Photos, Classroom, Workspaces, etc.
It’s the weirdest outgrowth of a product ever.
It is weird, but you can kind of see how it happened. Remember that Google Groups was a very early side project (22 years ago – back when “social media” meant LiveJournal and MySpace), begun when they acquired Deja’s huge USENET archive. Groups was originally used to make that archive searchable, which got them huge reputation points from the older geek crowd, but it was also their way to Embrace and Extend, and probably Extinguish, the largest chat forum not already stored on the web. (And unlike with a lot of their very early projects, this one came with an large pre-existing user base, and so I imagine it was a high-visibility property, where bugs would get noticed and get talked about.)
Anyway, my point is just that Groups has been around through a couple of iterations of Google’s hey-let’s-make-all-our-things-interoperate frenzies, so it’s not entirely surprising that at one of those times it actually got dragged into doing something important.
People were mentioning this in the HN thread. Are these actually the same product or just two things with the same name? If Google just straight up named a completely different product Google Groups that’s a pretty damning indictment of their commitment to Google Groups the public discussion board.
I have no idea how it works internally of course, but the groups have the same members and appear the same in each Google product including the discussion board part.
I think they’re the same thing with different applications / ways of accessing. When my previous employer moved over to Gmail, etc., they started migrating some GNU Mailman groups to Google Groups and/or spinning up new mailing lists using Groups. I could also access external groups that I was subscribed to with my work address via the same interface. It felt very cobbled together but all seemed to be the same product / tool.
I don’t know - but note that Microsoft has sort of gone the other way - now there is overlap with azure ad “groups”, teams, mailing lists/aliases kind of
Been a long slow decline, it’s frustrating to watch it degrade. Imagine being an engineer assigned to this unloved thing; or worse, a product manager. Career death.
https://groups.io is a good replacement for email lists. It’s mostly a for-pay product.
https://www.usenetarchives.com/ is a good search engine for pre-2000 Usenet. Like Google’s old Deja archive which has been nearly unusable via Google Groups for years now.
I assumed it had been abandoned back when I was reading the Clojure group on it in 2012 or so and it basically just … stopped doing any spam filtering whatsoever? Someone must have commented out the “actually filter spam” lines of code and no one at google must have noticed.
Not long after that we lost the ability to view the (plain text) messages in the archive without enabling JS. It would also frequently refuse to display messages to you, even in a public group, unless you logged in.
This is all terribly predictable, and as usual some people learn the lesson from it and others don’t. It’s good to see that the author of the article above seems to be in the former category.
Honestly a pretty damn good argument for email mailing lists, grotty though they may be.
How about a Sourcehut mailing list - maybe self-hosted?
https://man.sr.ht/lists.sr.ht/
https://man.sr.ht/lists.sr.ht/installation.md
(I’m a very happy paying customer of the hosted Sourcehut offering, having migrated there from GitLab, after in turn leaving GitHub).
Yeah I’m leaning toward advocating for a Zulip/mailing list combo. That’s what Isabelle uses. I’ve started doing some development on SourceHut but haven’t yet used mailing lists. I’ll have to see what their UI looks like. Personally I more enjoy the phpBB internet forum style of interaction (I wonder whether you can date internet users by this method?) so would want any mailing list software to have a front-end of that sort.
I want to like Discourse but it’s just so… whitespace-y and javascript-y? My mind kind of slides off the page, there aren’t any delineations between different page elements. And why do I see a visible loading circle every time I click to load a page of text?
The writing on the wall has been there for years. What’s more shocking to me is that people still rely on it.
It’s refreshing to hear there’s still a demand for this kind of platform, people often question why I’m building brand new forum software in 2023 but there’s clearly a desire for some groups/orgs to self-host and own their data. This post got me thinking about a google groups importer and mailing list functionality!
So, something I was tinkering with for a while was Usenet. There used to be decent Web front-ends for it (my first development job was with a company who sold one - the manual is still online!).
I’ve often wondered if you could use NNTP as the basis for a system like this in modern times. A combined NNTP server + web portal, such that folks could use their own newsreaders or the Web interface. Then just host that. Very “smol Web” aligned.
apparently the D forum is that exactly. it has a modern looking forum web UI but it hooks into NNTP in the backend
https://github.com/CyberShadow/DFeed
Oh, damn! That’s amazing - exactly the design I was thinking of. I have some immediate use cases for this, thanks for sharing :)
I’ve been thinking GitHub Discussions might be the 2023 successor to Google Groups, especially for programming teams.
https://github.com/features/discussions
In 2021 they launched a private repo version:
https://github.blog/2021-03-09-github-discussions-now-available-for-private-repositories/
I did a deep dive and it has a lot of things I’d want from a Google Groups replacement.
OP wrote this, though:
… which is a valid concern.
If it was “left to die” you wouldn’t get new bugs like monospace fonts failing to render. It is being actively sabotaged from inside, wittingly or unwittingly.
Saying things are “left to die” implies that they will die if not constantly tinkered with and “upgraded.” But this sort of attention is likely what’s causing most of the problems. No doubt none of these problems existed before the move to the more bloated interface a year or two ago; leaving it alone would have been the best possible thing for it.
I can’t speak in details, but Google often neglects products to death in such a way that they have less than one full-time engineer paying attention to each product. It would not surprise me to learn that a half-dead Google product literally has only half an engineer allocated. Combine this with Google’s monorepo strategy, where it is very common for cross-cutting changes to affect your code from halfway across the company, and it is easy to imagine that the decay is natural.
When we talk of sabotage, we should imagine deliberate additions to the system which compromise or weaken it. I don’t think that that’s the case here.
[Comment removed by author]
I suppose unwitting sabotage is an oxymoron. Better to say harm, as there’s no way to know whether it’s due to incompetence or malice. Hard to imagine some Google manager isn’t aware of the predictable effect of rewriting the front end 1-2 years before dropping the number of maintenance engineers to a skeleton crew.
In general, yes; assume that the engineers are aware and management is clueless. (Google management is actually relatively technical and clueful, but it’s a general pattern worth recognizing.)
You’re saying to assume that managers have no clue about the effects of their decisions? They have no concept of the maintenance burden of newly written code vs. code that has been in use for a decade? They allocate engineers and funding with no notion of the consequences?
And what’s the relevance of the general case if we’re talking about Google? Are you just changing the topic?