To have all the features you get for free out of slack, you have to do a lot of work and maintenance to get out of IRC and mailing lists.

Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX. Google groups mostly fixes this because they're really just a forum that supports emails.

IRC is terrible because everyone has their own client, so you never actually know what someone will see when you post something. Post a link, - will it get auto-expanded? How will it look? Will it get auto-linked? If you @ someone, will they get notified? if so, how visibly?

IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.

Slack has mindshare, which leads to having a ton of integrations with other platforms, which just multiplies its effectiveness.

I 100% agree that I wish they offered a publicly visible option, so anyone can view without logging in. I also wish they natively supported self-registration.

I have to echo another commenter on here. If you want the best of all worlds, a forum is what you're looking for. Publicly visible, easily linkable, long form, asychronous communication. Whether that's google groups or something else is up to you.

Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.

> Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients

Unfortunately, the Slack gateway implementation is subpar. In my experience, it will send me the last message I sent before I disconnected when I reconnect, but it won't send any of the other messages that were sent in the meantime. The other problem is that group chat only works over the IRC gateway, not the XMPP one (at least I could join it from my XMPP client, but I couldn't send any messages to it).

In contrast, the old XMPP server we used would just replay messages in group chat when you reconnected, so at least you wouldn't miss anything when you weren't connected.

Edit: s/Slack implementation/the Slack gateway implementation/

I think slack calls them gateways, not bridges. And if you compare to matrix bridges, gateway seems like a suitable name.

> IRC also has the multi-login problem - it gets confused if I log in from my phone and my laptop. To get a persistent history of IRC requires running an external service which is way beyond most users.

This part I really do find annoying about IRC. I use IRC by far the most but this still gets me. Even if you run it in a screen somewhere it's a hassle from a mobile device. There's solutions for all of it, but you have to string a series of things together to get to something just about every other option offers you out of the box. Unless you have a particular need for IRC or have used it for a while and know how to deal with it, the other options are more appealing to newcomers. Depending on how young your project or community is that can make all the difference.

> Mailing lists by themselves are terrible, because there's no history. You can't scroll up to find context for the conversation. You can get public archives, but then where you actually use the mailing list and where you go to look at history are completely separate, which is a terrible UX.

Gmane actually works really well at addressing the problems you describe in terms history. Their NNTP gateway allowed me to download and search the git mailing list messages since 2009 in my email/news client.

> What limitations do mailing lists impose on open source development that are not present in other tools?

None, in my opinion. On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages — that is coherent enough to be highly useful when searching archives later.

> On the contrary, they are the only tool that demand a structure — just by the nature of e-mail messages

Newsgroups also have this structure and they have the advantage of easily doing an archive search (by being able to download part of or the entire message archive of a given group and using the search features of your mail/news client).

The problems with mailing lists?

Quoting is still a problem. Most answer above. Some below. Many nitpick in between.

Threading is easily broken. Especially if Outlook users are involved.

Formatting is an issue. There is no markdown or whatever for links. Some people insist on line lengths and other stuff.

> Quoting is still a problem. Most answer above. Some below. Many nitpick in between.

One thing I've noticed on Hacker News, Slashdot, and even reddit is that if someone quotes the post they're responding to, they'll invariably post their response below it. And if they quote multiple parts of the parent post, they'll interleave their responses. I don't recall ever seeing a response where the quoted text is below it.

I've really never understood the rationale behind top-posting. It makes it much more difficult to understand the context of the response without having to jump between the original message and the response.

> Threading is easily broken. Especially if Outlook users are involved.

That's because Outlook does not follow the relevant RFCs in terms of maintaining a message through through the In-Reply-To and References headers.

> Formatting is an issue. There is no markdown or whatever for links.

Most GUI clients will make links clickable. There are also conventions such as using astericks, _underscores_, or /slashes/ for bolding, underlining, or italicizing text, but a lot of clients don't render them consistently, IME.

> Some people insist on line lengths and other stuff.

There is an RFC that adds format=flowed to the Content-Type header. Then every line that ends in a single whitespace character will be joined with the next line and wrapped at screen width instead of at the position of the CRLF characters. Clients that don't support it will still see the wrapped text.

The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.

Sure, there's lots of freely available alternatives, but even tiny (but non-zero) costs in time and money are the difference between widespread usage and relative non-use.

I setup Gitter on a GitHub repo for a project by clicking a button and accepting a pull request that Gitter auto-generated for me to add a link to the repo's Gitter channel in my project's README. That's the competition that every older tool is failing miserably to meet, let alone exceed.

> The primary benefit of 'Slack' over "older tools" is that the former are free – not just financially but in terms of how much time, effort, and energy is required to set them up and maintain them.

You are ignoring the costs that come from lock-in (inflated prices, lack of innovation) and migration in case the proprietary solution shuts down. That's the psychological tendency of humans that these companies exploit.

Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.

Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.

A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.

It's tradeoffs all the way down!

> Lock-in is a cost of any solution tho. Whatever solution one picks, it's going to cost time and energy and, probably at least indirectly, money to migrate to another.

That's not lock-in. Lock-in is when you are dependent on a (quasi-)monopoly, not just any potential migration cost.

> Non-proprietary solutions 'shut down' too, e.g. because the unpaid developers burn out and quit.

No, actually, they don't. The point, as above, is that it's not the sole decision of another party when a 'shut down' happens, that is, again, there is no monopoly. First of all, if you have free software running on your own machine, there is noone but you who can decide to just shut it down today, but also, in the long run, you can just take over maintenance of the software yourself, or you can buy/hire a software developer to do it for you, or you can get together with other users of the software to hire a developer.

Also, more generally, with regards to open interfaces/protocols rather than necessarily free software: No, email cannot be "shut down" because "the unpaid developers burn out". And changing my email client or server or hosting service does not necessitate everyone else I want to communicate with to do the same.

None of that guarantees that you can keep using things indefinitely at an arbitrarily low price, but that's besides the point: The price is determined by a market, and not by a (quasi-)monopoly.

> A lot of people reasonably believe that 'free' solutions are inherently riskier, all else being equal, because (generally) no one is being compensated to maintain and support it.

Well, yeah, those people are just clueless, if only because they confuse freedom with not paying for something. If you want to have something maintained, how about you pay for it? How does it make any sense to say that you prefer being forced to pay for something because you otherwise fear that it's not being maintained if you don't pay for it?

Also, none of this has anything to do with open protocols (which was the primary topic of this thread, kindof): Microsoft is being paid very well for maintaining Outlook and Exchange, which is both proprietary software. They still speak SMTP with the rest of the world, instead of forcing everyone to buy Outlook and Exchange to be able to communicate with their users.