https://matrix.org is an open standard defining a communication protocol. The goal is to have an open ecosystem where any app can talk to any other app. You can talk to Matrix either natively - or via a bridge. We already have written bridges to IRC, Slack, XMPP and libpurple - if you visit #matrix on freenode you are also talking in the #matrix:matrix.org (https://vector.im/beta/#/room/#matrix:matrix.org) room in Matrix (and vice versa).

You can even connect to Matrix via your IRC client via http://pto.im/

Matrix is decentralised, you can run your own server (clone our server or write your own) and servers will create federated networks on a need-to-know per-room basis (see http://matrix.org/#about).

Matrix is free software, all our code is Apache2 licensed, you can clone it (https://github.com/matrix-org) and use as-it, modify it - or write your own client client and/or server (http://matrix.org/docs/spec/r0.0.1/)!

disclaimer: I work for Matrix.org!

I'd suggest making it clear that Vector is by far the most user-friendly way to use Matrix if you want to attract non-technical users to the service, but otherwise, well done.

Check out http://matrix.org/blog/try-matrix-now/ for a list of clients/apps that support Matrix!

Now, they mention that it can be used for decentralized machine communication too. I wonder if there any projects taking advantage of that.

EDIT: clicking on https://vector.im/beta/#/room/!cURbafjkfsMDVwdRDQ:matrix.org takes a long time to load. is this a consequence of the server ..or is the protocol slower ?

and thanks for trying it out :)

edit: AFAIK we've not been featured on product hunt

A lot of the features you mention are better served by email, and I am completely opposed to editing messages after they are sent (chat is append only!) There are IRC bots for ticketing/build integration, and they were around long before anyone used Slack!

But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom. Centralized network services are increasingly removing our control over how we communicate, and we must reject them for our free software projects. The ethical replacements (not alternatives, because Slack cannot be considered as an option) aren't going to get better if people aren't using them!

Or in other words, sometimes what you call proprietary software also represents innovation that can be copied and innovated upon should the need arise. Free Software activists sometimes make it sound like the whole movement has been a liberation effort, which is far from the truth, as most open-source software has been development for profit or for fun, having nothing to do with ideals.

> if we want to see a world in which users can control their computers

If we want to see that world happening, we must first ensure that the people building software can earn a decent living, because frankly, we deserve it. I mean, first come up with business models that work. And do note that there has been room for a single Red Hat.

Ideally people would recognize how much software is worth and pay even for free software. In practice people are pirating the shit out of everything and install ad-blockers while feeling morally justified in doing so. Therefore while I find closed platforms abhorrent, I can't help but think that it's a justified overreaction of the software industry when faced with hordes of self-entitled assholes.

But that aside, having users control their computers is not the primary motivation by which open source / free software gets built.

I very much disagree with this sentiment and I think it is very sad to see how pervasive this idea is that earning a living is first.

There will be good software even if people making software are not paid for it, just like there will be good music even if it is unlikely that good musicians are ever be able to "earn a decent living".

Maybe rather than trying to find new ways of making a living we should try finding new ways of living instead, ways that don't perpetuate exploitation under the pretense of a job "market".

> most open-source software has been development for profit or for fun, having nothing to do with ideals.

This shows the difference between "open source" and free software. That's why I call it "free software" and avoid the term "open source". This doesn't mean, however, that free software advocates do not have fun writing software ;)

Yes, but I don't see how that's a benefit of proprietary software. Before bitkeeper there was some Sun version control system that had a very similar model to git (which might've been released with the OpenSolaris thing, I'm not sure). The point is that "you got some free software because of proprietary software" is not relevant. Free software

> Linux itself, along with the GNU toolchain, happened after Multics, Unix, 80386 and MINIX. Well OK, the GNU project was started before 80386, but nevertheless it was started as a clone of Unix. You can see that from its recursive name.

GNU is a free software replacement for UNIX. You could argue "clone" and "replacement" are the same thing, but I'd argue the intention is different.

> Or in other words, sometimes what you call proprietary software also represents innovation that can be copied and innovated upon should the need arise.

Except you can't copy proprietary software due to software patents and a miriad of other "protections" that are designed to mistreat users. People make free software alternatives to proprietary software because they want people to have access to technology without losing their freedom.

> Free Software activists sometimes make it sound like the whole movement has been a liberation effort, which is far from the truth, as most open-source software has been development for profit or for fun, having nothing to do with ideals.

The free software movement has always been about freedom. The main advocates of the open source movement have always tried to ignore the freedom aspects (in particular, Eric S. Raymond who is a very unpleasant character). However, many people in the open source movement actually do care about freedom if you explain the free software movement to them. The fact that the "open source movement has won" is very sad because it will raise generations of programmers who will gladly give up their freedom for no reason.

> > if we want to see a world in which users can control their computers

> If we want to see that world happening, we must first ensure that the people building software can earn a decent living, because frankly, we deserve it. I mean, first come up with business models that work. And do note that there has been room for a single Red Hat.

SUSE has offerings in the same space (disclaimer: I work for SUSE).

> Ideally people would recognize how much software is worth and pay even for free software. In practice people are pirating the shit out of everything and install ad-blockers while feeling morally justified in doing so. Therefore while I find closed platforms abhorrent, I can't help but think that it's a justified overreaction of the software industry when faced with hordes of self-entitled assholes.

People do pay for free software (myself included). However, the primary funding model in free software cannot be "for the actual software" because that wouldn't work. You need to have a new business model with free software

> But that aside, having users control their computers is not the primary motivation by which open source / free software gets built.

I disagree. Many large free software projects (FFmpeg, VLC, all of GNU, Debian) refer to themselves as "free software". This isn't a typo, it's because they care about software freedom and were started to offer free software alternatives to users like myself. There are many, many more smaller free software projects which do the same. While it is true that some developers don't care about free software and work on free software projects, that's like an author claiming that they don't care about freedom of speech while writing satire about a politician. There's a disconnect in that logic, and we should recognise the innovation that free software is.

There are some people like you who have an ideology that pushes them to always choose free software. There are some people who care a bit about free software but will abandon it if the costs are high enough. Then there are some people who don't care about it at all.

You better at least have something to offer the second group if you don't want to die out.

Well, users can't control their computers in that example. They can hope to control their computers, or hope that the developers which actually control their computers don't do anything nasty to them.

> There are some people like you who have an ideology that pushes them to always choose free software. There are some people who care a bit about free software but will abandon it if the costs are high enough. Then there are some people who don't care about it at all.

> You better at least have something to offer the second group if you don't want to die out.

Free software isn't going to die out. And this skirts around the fact that free software has plenty of innovation behind it. In any case, people are quickly rediscovering issues of freedom with the whole eBook thing. It's very condescending that people don't care about freedom. It all depends on how you frame the solution. "This open source software is always better" or "This free software protects your freedom".

> Well, users can't control their computers in that example. They can hope to control their computers, or hope that the developers which actually control their computers don't do anything nasty to them.

I don't mean to speak for hyperpape, but I think that was the point: it's evident that some users value convenience/features/usability/etc over the control of their computers, so unless free software is as good or better than nonfree alternatives then these users won't have control.

> > Well, users can't control their computers in that example. They can hope to control their computers, or hope that the developers which actually control their computers don't do anything nasty to them.

> I don't mean to speak for hyperpape, but I think that was the point: it's evident that some users value convenience/features/usability/etc over the control of their computers, so unless free software is as good or better than nonfree alternatives then these users won't have control.

If that is their choice, sure. But most users I've talked to (this is completely anecdotal, and I usually talk to strong-willed people) recognise the importance of free software and will do something about it. Maybe they won't replace all of their software with free software, but they usually are willing to lose some non-mission-critical functionality.

And besides, free software usually has better features, but that's not the pitch we should give. It's the wrong lesson to teach. The right lesson would be "it has almost anything you want and if you want more you can modify it, pay someone to improve it or ask a community to improve it without dealing with a company or developer which doesn't give a shit about you." Why not start the conversation about free software with "it respects your freedom, and usually has more features / is more reliable but you have the freedom to improve it or get others to improve it for you" rather than just "it has more features".

To many people, non-free software is sub-par because of its non-freeness.

Using (tacitly agreeing with and supporting) non-free software is consequently contra to their ethics.

No horses are involved.

You don't see a lot of pragmatists telling free software proponents that they should be using non-free software. Unfortunately, the reverse situation is very common.

Here, I think, we're talking about free software projects sending wrong or mixed messages to their users & contributors. Which is the adverse effect alluded to -- it obliges your users to use non-free software.

This may discourage some of your potential users & contributors, and that may reduce the quality of your project. And that, in turn, may be something you as someone running a free software project had not considered, and, on reflection, do not want.

Slightly perturbed you're using the word pragmatist as a synonym for someone that uses or advocates non-free software.

Arguably anyone casting an opinion is 'on their high horse', especially if it's orthogonal to your own opinion.

The exact same argument was made about not discouraging non-technical users who don't want to bother with the arcane-ness that is IRC, and the reply was that they don't matter.

> The exact same argument was made about not discouraging non-technical users who don't want to bother with the arcane-ness that is IRC, and the reply was that they don't matter.

Then they can email you if necessary. If there isn't a mail bot which takes email patches (or just emails) and converts them into IRC messages then that's something someone should be working on.

However, as cyphar observes, there are always alternative methods for users & contributors to gain access - git repos (PR's), email - direct or lists, twitter, bug trackers, etc.

Slight aside -- I suspect there's some correlation between sophistication of question / contribution a user may be asking / making, and ability to navigate IRC. Either way, I don't see IRC's alleged complexity as being a barrier to any one who's serious, especially (as noted) in almost any project it won't be the exclusive method of communicating with members of the project.

Even more of an aside, I don't get this whole 'arcane-ness' (and similar) claims levelled against IRC -- is it genuinely that tricky? Most projects I've seen that includes IRC in their 'How to contact us' page provides links to IRC clients, clearly identifying their network & channel names, and even sometimes a link to a free web client that drops them straight into chat (so about the same level of convenience as Slack etc).

Can someone explain to me how having to create a separate account for every project you have a question about is a "better" than anything?

Devil's advocate: the only way to have a single "account" for all of your projects on IRC is if they all use the same server. Is that not a weird, perverse amalgamation in and of itself? Taken to the extreme, every project that wants to truly control its own destiny ends up using its own IRC server, and you're back to N tabs open somewhere.

Slack does have a few ways which can make it a little easier to sign-in on mobile, though, such as sending you an e-mail link that opens the app and signs in for you. Likewise, once you setup the desktop client, you don't have to relogin unless your password changes.

It's a small initial overhead -- one that IRC doesn't present if you're going to the same server as you mentioned -- but one that I don't think is quite that bad. I've never been in more than five distinct Slack teams, though, so, maybe this would just explode if we literally tried to replace IRC with Slack for the top FOSS projects.

I'm struggling to think of a time when it's ever a good idea to cast pragmatism aside.

> I'm struggling to think of a time when it's ever a good idea to cast pragmatism aside.

When choosing what ideals you want to strive for and what you want to see in the world.

It seems incredibly reductive to state that using proprietary software, in any way, somehow makes a FOSS project send an implicit message that it... I don't know what you meant, but, disrespects its users?

Did I disrespect the users of FOSS projects I worked on by using Windows / Visual Studio?

No, what you do on your own computer is your business. No one else has to use your proprietary setup. Other people do have to use your Slack channels to talk to you, which is an endorsement and enticement to run proprietary software.

In the case of IRC, it doesn't matter if there's a Free Windows client, because there are plenty of alternatives.

- I'm an author of some FOSS software

- I use Slack as the communication platform for said project for XYZ reasons

How do you suggest I word the README for my project? Do I tell/advise people to try other, less functional software if that software is subjectively more "open" than mine? Would my project somehow be "better" if I run all of my own infrastructure for it -- chat, bug tracking, etc -- using only FOSS software on FOSS hardware in my basement?

I mean, the logical conclusion here is that no FOSS project is really a FOSS project unless Richard Stallman could look at it and say "sure, morally, I have no problem using that project", right?

(This is off the path of the blog post in question, but I'm really interested in this sub-conversation.)

This highlights the difference between "open source" and free software: by using and recommending Slack, you make a statement that the freedoms of those who would collaborate with your project are not important. In general, projects that identify with the free software philosophy or the "open source" development methodology can collaborate with either community just fine---there are shared interests and goals. But if you use a freedom-denying service, then you cripple a community of contributors.

It does not matter if RMS personally says that he is okay with a particular project---the four freedoms are clear and basic; we don't need his personal endorsement. Further, just because you use Slack, that doesn't mean that your project is less free than another---if it's free software, then it's free software. But the community surrounding your project is shaped by your actions. And if the pressure is great enough, there may be no choice but for free software users to fork the project, and perhaps hope for better collaboration in the future.

Do you personally feel more safe, or better, whatever the adjective you want to use would be... about logging in to a remote server that uses software you can read the source for versus software you can't read the source for?

It seems like a sticky problem because even if Freenode purports to be open, and you can read the source code of what software they say they use, you can't actually see the source code powering their service, right? Like you can't just SSH to the boxes, and look at the source and say "ok, they haven't messed with anything, so I'm ok signing into their servers".

Like, you could see the very JavaScript running in your browser. You downloaded it, it's running locally. You can't see the backend, though. You can't tell how your data is being used. That's the thing that feels scarier to me, although admittedly, I use plenty of services based on closed source software as well as open source software, and it doesn't really give me too much pause.

I guess I just don't really understand the fervor around the "openness" aspect if you're not actually the one running the service. You're still at the mercy of a service operator who could be eroding the "freedom" you think you have.

I'm not sure how hard it would be, but conceivably you could join freenode and host your own ircd? I think the federation part (and ability to migrate/self-host) is the most important part here.

I don't think it makes much sense to bever let other projects/org run part of your infrastructure - the key point is that those organisations are open (so you can join Debian and take over an orphaned package you use, or you can run your own email and federate with others that use email).

IRC vs Slack is a bit one-sided, as IRC has some real problems at the protocol level - jabber/xmpp and Matrix are probably more sensible alternatives. But even then I don't think the main point is that everyone should do all the work of hosting all their infrastructure - just that it's goid to choose an infrastructure with as little lock-in as possible - and infrastructure that one can easily contribute to (eg: submit a patch for ircd or one of the bots etc).

Ah, sorry, I see where the confusion is. This is a different issue entirely:

  https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

  https://www.gnu.org/philosophy/javascript-trap.html

You can try to bludgeon and guilt people into using open source tools, but the problem is fundamentally that the tools that are Open Source are /failing/ a set of users. If you fixed the tools and ran HipChat and Slack out of business with Open Source competition, we wouldn't even be having this discussion. Lecturing people about Freedom(tm) and "Devsplaining" to users why they don't want the features they tell you they want isn't going to work.

If you want people to get off of Slack write an Open Source alternative that Slack users will freely choose to use instead. Compete in the market and win -- or else you're just pissing into the wind.

That makes no sense at all. Firstly, most people working on free software don't make assertions like, "My free software is good enough for you." Most of us are much more realistic and assert something more like "My free software might be good enough for you, here's why you should consider it."

Secondly, even if one were making that assertion that one's free software is good enough for others, why would that mean they should believe all free software is good enough for everyone? It just doesn't follow.

I am completely opposed to editing messages after they are sent (chat is append only!)

This isn't relevant. Your personal communication preferences are not universal. Slack's popularity shows people don't care about this.

But ultimately, even if Slack has more convenient features, we cannot rightly use it because it doesn't respect our freedom

Most developers aren't as dogmatic as this. You're in an extreme minority. Which is totally fine, and you should try to convince others if you feel they should be convinced, as long as you recognize most of us aren't in your "we". It's not true that I must reject Slack.

There is no reason that an open source project shouldn't use proprietary software. This isn't a religion.

So like IRC? Telling everyone to "use Freenode" is no better than Slack, both are centralised. You might have more client choice, but you're still logging into someone else's server.

I'm no fan of Slack, but I don't get the claimed conflict when using it with an open source project. Would it also be bad to host the project's source code on GitHub, or the web site on IIS?

Actually it's not completely irrelevant, as the fact that the host platform of proprietary software is free software has value in the security-based argument in favor of free software, but that's only tangential to the topic at hand.

Would it also be bad to host the project's source code on GitHub

Not necessarily, if really all you're using github for is hosting, then there's nothing wrong. That is, if you don't use their issues/PR system or other auxiliary services. This is how, for example, the linux project uses github. In this case, all that you're asking people to do is use git (free software) to download some stuff from servers owned by Github, Inc.

Running the website on IIS is fine though; this imposes absolutely nothing on your users or contributors.

Also it's worth noting that github's entire UI, at least for browsing (I didn't try creating an issue or editing a file), works just fine with javascript disabled.

Even if you can connect to GitHub without ever touching their proprietary JS, that's clearly not the typical route. Just like you can connect to Slack using nothing but open source clients, but one is "enticed" to use the proprietary client.

You can clone/pull anonymously from github and eg: email patches.

I'd say using github just for hosting read-only/read-mostly git is a bit like running http on IIS or email on Exchange - or indeed a propietary XMPP server that allows federation.

I'd prefer Free projects to use Free infrastructure - but building on established open protocols is good. Contrast with bitkeeper: you'd have to reverse engineer the protocol to pull/push - or with slack: there's no way to set up your own server snd federate with it.

So OK, sure, github is as bad as slack.

Some Free Software people certainly think that. It is imho at least problematic. For example, the unicorn web server developer, finds github problematic from the 'UX' side in addition to dependence on proprietary software and infrastructure (which creeps into the commit messages).

"Contributing to unicorn is socially as easy as contributing to git or the Linux kernel. There is no need to signup for anything, no need to ever touch a bloated web browser."[0]

[0]:http://bogomips.org/unicorn-public/20140801213202.GA2729%40d...

The web browser may be free, but all of the JavaScript you are running is proprietary.

>And there are many closed-source IRC clients.

But there are many free ones, and there isn't an official client that is proprietary. It's possible to use Slack, more or less, over IRC or XMPP, but they are second-class citizens. The recommended way to use Slack is via their proprietary web interface.

And even if the JavaScript files were not minified, they likely aren't available for user modification and redistribution because they are protected by copyright and a license that says "all rights reserved."

But the next point you make — "but you're still logging into someone else's server" — is not necessarily true. IRC is not a federated system, but a good way to think of it is as a federated protocol that has a central point of control at the federation level. Kind of like geopolitical federation: individual states in the US (theoretically) have sovereignty within their borders, but when it comes to interacting with their peers, the other states, they are controlled by a centralized power known as the US Federal Government. In the same way, a single IRC server can act independently so long as all the recipients of all of the messages that all of the clients are sending are also connected to this server. Once a recipient of a message is connected to a different server, then the irc network (the federal government, if you will) takes control.

Now, this all is mostly of theoretical interest, because in reality if you objected to the centralization of an IRC network, you'd be much better off just running your own network than applying to run a server for an existing network.

The reason to prefer Freenode's brand of centralization over Slack's is the same as the reason to prefer Debian to Apple. Debian and Freenode are community-run organizations, staffed by volunteers, which push to advance the values of free software. Apple and Slack are for-profit corporate organizations which are driven by the wills of their investors, not their users.

Yes, a proper federated IM network would be better than Freenode. But there isn't one, and just because Freenode isn't the best solution, doesn't mean it isn't better than Slack.

>> Yes, a proper federated IM network would be better than Freenode. But there isn't one.

Ah the short term memories of Silicon Valley.

http://xmpp.org/ + Pidgin. Support for DNSSEC. Support for TLS[1]. OTP is provably uncrackable. Support for that too! Though it has no major company backing it, the protocol's RFC has been published and there is public source code for both clients and servers. (There was support for Google until they realized 'uh we can make more money by Walling in our Garden' and in 2013 Hangouts came out, but there is a proper federated IM network that's secure(ish), agnostic and fairly robust).

>> But a good way to think of it is as a federated protocol that has a central point of control at the federation level.

Eh. IRC is inherently only as federated as the opers who choose to run their links and leaf nodes in a united fashion. In the late 90s/very early 2000s -- back when Freenode was OPN and even blackbox took tens of minutes to compile! -- there was so much drama with where people would fork off networks over trivial BS. I have a disagreement with my bud John, and drama ensues and a network gets forked. I can't just 'fork' off from the US. Some gentlemen in the 1860s tried to do it and didn't fare quite well.

[1] To be fair, STARTTLS can be chunked into basically any protocol. My point stands.

[1] https://github.com/davexunit

I use my own server (running free software, of course) to host my source code now:

https://git.dthompson.us/

And I should add that I'm only human, imperfect. There are very few people that never use proprietary software. We all make compromises, myself included, but I do my best to use and promote free software and reject proprietary software as much as I can manage.

That's the crux of it. Some people just don't care and want to communicate. What is easiest to use is the only valid metric for the majority.

Then maybe those other free software projects should get good.

1) People who can actually spend the time to do the work of implementing improvements.

2) People who are willing to make user experience a priority over other things.

The first requires skilled people to spend a significant amount of time. This is time that those skilled people could be spending with their families, so they usually expect to be paid for it. The supply of skilled time that doesn't cost money is very limited.

The second requires incentives to be aligned in favor of getting and keeping inexperienced users. If you aren't willing to delete some code you spent a bunch of time working on in order to improve the user experience, you aren't going to succeed.

None of this requires the software to be proprietary. But it does require that it is monetized somehow -- Perhaps through patreon for example, but that is also non-free software.

It's not interesting and serves no purpose on HN.

(earlier comments in furtherance of said pissing match deleted)

No you don't. You send the message that you're using what you believe are the best tools for your team.

IRC is open (VERY open), easy to use, and less centralized than Slack. The only real benefit of Slack is easier file transfers; but even then you could probably just set up an IRC macro to send someone a link to the file on Dropbox.

Now, the Slack client is much, much more slick than any IRC client I've seen. But if someone writes a great IRC client that looks like Slack (and has things like URL previews, etc), I doubt you'd have as many detractors.

Also a good notification system, multiple session support, native mobile clients, easy third party integrations, baked in searchable history, team support, and easy enough for the non-techies to use.

(And my current rewrite of QuasselDroid will do so, too)

> multiple session support

There are web-based IRC clients that support this. In fact, I would not be surprised if under the hood Slack started out life as a web-based IRC client - it's a very similar (though much more polished) experience.

> native mobile clients

There are native mobile IRC clients; and Slack's mobile client is nothing to brag about - I've seen it take 10-15 minutes for messages to propagate to the mobile app. It also tends to hang frequently when using it.

> easy third party integrations

I don't know that it gets any easier than IRC - it's a plaintext protocol that's open and well-documented, and even easier to use than HTTP. As a kid over 25 years ago, I wrote an IRC bot in Perl - and the protocol hasn't changed a lot since then. There are mature IRC libraries for nearly every programming language / stack.

> baked in searchable history

Granted - this doesn't exist by default in the client - but an Open Source project could easily set up an IRC log bot (of which there are many, and they provide interface / search / etc). And then you can just search the history via private message with the log bot.

> team support

This is a management feature; you can also easily just create password-protected channels (yes, this is a feature of the IRC protocol and not any particular client).

> easy enough for the non-techies to use

IRC is a little more difficult than Slack, but then again I don't know that most open source projects have much reason to interact with people who are not technical enough to connect an IRC client (at least in the scope of the project).

That misses the point entirely.

Sure I'm a technical guy, I could spend time figuring out how to make an IRC chat robot that would maybe offer a third the features Slack ships with out of the box. But why should I have to? I certainly don't enjoy it.

If I'm working on an open source project, would you rather me spend hours configuring IRC, or working on the open source project?

I benefit just as much, or possibly more, from improved usability as your non-technical grandma. And as long as attitudes like yours are prevalent, IRC ain't never gonna beat Slack.

You shouldn't have to; but Open Source projects tend to be (with good reason) wary of using closed-source products like Slack. You can't foresee what the needs of an open source project will be in 10 years, or whether Slack will still be around then. Should something happen to Slack (they go under / get purchased / decide to terminate non-paid accounts / whatever), you'll be relying on their APIs and service to recover your data and maybe migrate it to a new platform. They can make all the promises they want today, but who knows what their business looks like in a decade.

Anyone remember SourceForge? GitHub is at least just a set of management tools / interfaces on top of a relatively vanilla Git repository (and Git is open source). Ideally, someone would build a web-based IRC client with all this functionality integrated and call it a day - though I suspect that's how Slack got started, and the restrictions they have are just so they can make some money from selling their product.

I mean, you need 4 pieces of information to connect to an IRC server: Server name, port, a username, and the #channel name you want to join (most IRC networks provide user and channel registration services via "admin" bots).

However, to be honest, for open source projects, 'chat' of any kind should be for quick and unimportant discussions, or help. Important decisions should be hashed out on mailing lists so that people in other time zones can participate, so they get archived, and so people can take their time to write something that is well-reasoned.

What happens when a topic of discussion is debated intensely on a different timezone and you wake up to more than 500 messages to read? Do you read them all?

I think this is a reason for people who really don't engage on IRC for anything other than "Hi, I have a problem, can anyone help me?".

If you do anything meaningful and engage on different channels you know there is no keep up with everything being said or discussed.

Sorry if I sound harsh but I keep hearing the same tiring argument and keep pointing people to the same thing over and over and over. If you want IRC and history, please use an IRC bouncer. With Docker and cheap hosting solutions it's almost a no brainer. Do one better, add SSL to your bouncer and connect to, at least on Freenode, using SSL as well. Win-win.

IMO this is one more example of a technical community being generally dismissive of the importance of user experience. UX is THE reason Slack gained the traction it did. And I don't just mean in the client, I mean also mean the experience of going from zero to having everything working with the expected bells and whistles and the experience of adding a new feature. There is real value in being able to set it all up in three minutes and a couple of clicks without having to learn the technical underpinnings of a platform well enough to bring up a server and find and configure a bunch of individual bots.

Microsoft has made billions locking people up in the name of convenience.

You can have these things if you care or you can use its simplest form. Don't want to use a bouncer? Use a web client.

People keep repeating OSS. But now OSS is more about having being recognized than really believing in it. Using closed source software is one point.

I'm no radical, I use a Mac and I shed a tear every time I have to use Lightroom because I haven't find the drive to move to Darktable or Sublime instead of Atom.

Anyone who wants to avoid the possibility of lock-in using Slack should be laser-focused on making IRC competitive rather than trying to convince people that poor UX is just the price of freedom.

Source: have been using IRC since late 1993.

This entire thread has been about whether IRC can offer a competitive experience to services like Slack, Gitter, etc. I don't think anyone is arguing that you cannot use IRC at all without tools but even you were just saying (https://news.ycombinator.com/item?id=11013780) that you need the money and skills to run a server to have a first-class experience.

> Source: have been using IRC since late 1993.

Ditto but the world has moved on quite a lot since then and many of us think that IRC needs to as well or it will continue declining into obscurity.

* Proprietary protocols are generally a bad deal, and especially so for open source projects. Proprietary clients (gmail, for instance) don't matter as much unless you are RMS.

* Chat should not be a central component of an open source project, but an 'extra' for occasional real time communications. If important stuff happens there, it will alienate people who can't participate because of time zones or other reasons.

Someone else wrote the comment you linked.

> * Chat should not be a central component of an open source project, but an 'extra' for occasional real time communications.

I generally agree that chat shouldn't matter enormously but the problem is that we don't really have a great free alternative. Slack has an interesting hybrid which is largely chat but with some elements which are closer to mailing list style (persistence, search, rich formatting, quasi-attachments) and the only other alternatives I see people regularly using are Google Groups or Git Hub issue tracker, neither of which are open.

The big problem is infrastructure: once we start talking about building a consistent experience with an open project, that means running servers, handling security and support work, etc. That's not a problem for well-staffed projects but it's an ongoing hassle for smaller projects. This would seem like a good place for a non-profit to provide infrastructure.

> If important stuff happens there, it will alienate people who can't participate because of time zones or other reasons.

Interestingly, this is a major reason I see cited in _favor_ of Slack. With IRC, you aren't involved if you weren't logged when a conversation started but with Slack you still receive notifications and can view or search the history.

I just can't possibly have the time.

Additionally, some of the problems are purely intractable, despite anyone saying any different. Further problems are social rather than technical.

I need a chat that works on all my devices, delivers messages to all my devices, keeps track of mentions (again, across all devices), has searchable history (yep, everywhere). Bouncers speak IRC in both directions when that makes absolutely no sense. It'd be like having a mail server speak SMTP instead of IMAP, no way to pull, only to get pushed at.

Even something like IRCCloud where they have their own protocol which is actually purpose-built, can't change fundamentals of how the protocol is and gets used in practice.

Presence is simply unsolved, and pretty valuable for obvious reasons -- so I can decide how and if to contact someone. To try to discern this on IRC I have to keep in mind, for every contact, do they use whois status, do they send away messages, do they use an away nick, or more probably none of the above.

Nicks being mutable but also used for addressing messages is beyond insanity. Sure, let someone decide to be "princess sparkles" for a day or whatever, but I NEVER want to have to figure out who is who in order to be able to open a query window, don't want an existing query window to stop working because they changed their nick for a joke in some channel I'm not in, I never want to split logs of messages with people based on whether they were john or john|break... etc.

Regardless of MY technical competency or capacity for burning time, I will still need non-technical project-helper person to be able to spend an afternoon to create a handful of Trello boards and channels, and make those boards' changes push to their respective channels.

And even though I myself can suck it up and jump those hurdles, I'll never get a majority of my friends or colleagues to do so. Never in a million years. And that alone matters more than any other complaint because as a chat platform, it's the network, stupid.

I use IRC all the time to talk with people who are experts in some particular technology, and need absolutely none of this infrastructure.

It's your choice if you want to read them or not. This is better than IRC, because IRC doesn't give you that choice.

Nailed it, IRC isn't a significant barrier for a real contributor. If you don't have the time to figure out IRC, you don't have the time to significantly contribute to a project.

Especially in a corporate setting, the result is a simple username/password login to a webpage or the mobile client, it Just Works™, and has a user-friendly interface.

And don't suddenly bite you at 10,000 messages. ;-)

Most open source projects can not pay for the archiving feature - so messages are deleted and gone forever.

They aren't deleted and gone forever. They're simply not searchable. If at some future point you decide to pay, your entire history is made available to you.

I realize that doesn't help projects who will never want or be able to pay, but it's an important point for those who might.

Most things in slack are available in some form with irc, but not preconfigured out of the box. And some things on irc can take some fiddling to get set up right, and you can't count on everyone else to have enabled support.

But I would love to learn how to do that, for example with ZNC which is online all the time.

That logs the logs in an SQL database, you can search with Quassel-Suche (a web-based search engine for quassel backends), and we have clients for Windows, Mac, Linux, iOS (kinda) and Android (with a better Android client in beta) and a webclient.

You get contiguous logs like in Slack, Push Notifications (with the Android beta, soon), and you can search through your logs.

In fact, I don’t bookmark things in my browser anymore – I send them in a query to myself, and just use quassel-suche half a year later to find them, or, if there hasn’t been much activity in the channel, just scroll up (infinite scroll to load more logs).

There's also services like https://botbot.me that offer easy setup of this

But perhaps I'm wanting too much from a chat system.

What about all the integrations with other services?

Those things can be kind of cool for a company, but when I'm hanging out, on, say #postgres, it's to ask a question or discuss functionality, not see pull requests roll through the screen.

From this, it sounds like the only substantive difference you're hung up on is message persistence. If that's being provided by a stable third party (i.e. a log bot, the technical details of which are irrelevant), what else are you missing?

For end-user support people are still more than capable of using a desktop IRC client, as evidenced by the WEALTH of people that ask questions on #fedora, #debian, #ubuntu, etc every single day.

Oh yes that is definitely uber-geek.

Setting up Node-red on a VPS, and logging a dozen IRC rooms you're interested in, storing in a MongoDB, and creating a search DB... over TOR is being an "uber-geek".

And it took me 10 minutes to set up. No programming required, interestingly enough.

It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested?

Also, the article is trying to make you aware of a fundamental reason to NOT use slack for FOSS -- it's closed source.

The things that Slack does better than IRC are integrated into Slack. They just work, and the whole system is designed to make them work smoothly.

"Don't use Slack for FOSS projects because it's not FOSS" is an intellectually coherent argument. But "don't use Slack for FOSS projects because IRC is just as good" is not.

``It sounds like someone needs to make an IRC client that is approachable to encourage a new generation of people to be interested?''

Yes. It sounds... very much like this? :)

For me, it is Convos (web front end that uses redis for state tracking) + UnrealIRCD (IRC daemon) + Anope Services (channels, users, permissions, etc). It isn't as pretty as the Slack UI, but it could be.

Surely this suggestion can only seriously be made for projects that are also not hosted on GitHub.

Neither Github nor Bitbucket (I use bitbucket more than github) are open source.

The shining hope is the darkness is Gitlab (https://about.gitlab.com/) though, which is a wonderful tool. That, and someone with deep enough pockets to start a publicly hosted gitlab that everyone in FOSS can use.

How about your communication in Slack? Can it be withheld or otherwise become inaccessible, or is it completely accessible through open source tools and possible to export continuously to a useful format? If not, then there's quite a difference.

Slacks growing usefulness is predicated on the fact that people build bots for it.

It's not that IRC can be as good as slack -- IRC is NOT the same kind of thing as slack, they are different. IRC is a protocol, slack is not, slack is a product. My point is that the right product needs to be build AROUND IRC to make it viable/interesting.

From the previous comment, it seems like the features people are loving slack for are:

- Well designed interface

- File sharing

- Inviting/sharing channels with people

- Functionality provided by bots

Is that incorrect? I'm sure that list is incomplete, is there anything very significant I left off?

Probably more too.

There are interfaces and solutions for everything suggested.

Use quassel or irccloud as frontend and bouncer (on Windows, Linux, Mac, Android, iOS and the web), use the standard bots, etc.

That way the slack-only features could be offloaded to another open source service or protocol.

By the time that protocol mercifully died the thought of implementing a client would rightly give programmers nightmares.

The argument I see in this thread (not yours necessarily) seems to suggest that in order to implement modern features demanded by users we ought to favor grafting plugins and protocol extensions on top of IRC rather than use something that actually supports said features out of the box.

Why not just use Matrix.org?

https://matrix.org/

Having a standard and a committee usually means that something has stagnated, not that it is alive and improving.

Most experienced engineers are glad about the existence of a standard/committee. This is what lets people build stuff that can inter-operate. Without such specifications written somewhere, people are going to build random shit that doesn't work together because of small differences in implementation

IRCv3, meanwhile, hardly changes IRC at all.

There's no indication from the IRC standards work that IRC is heading in the direction that people who use Slack need it to go: it's not going to index channels, it's not going to allow long message lines, it's not going to deliver previous messages to users who join channels, &c &c.

> This is a pretty silly comparison, because the web is changing so fast that people regularly express concern that it's evolving too quickly.

This only serves to prove my point -- standards/committees do not imply stagnation. Also, I think you're conflating common complaints about web development (frameworks, libraries, paradigms) with core work done by W3C and friends.

> IRCv3, meanwhile, hardly changes IRC at all.

> There's no indication from the IRC standards work that IRC is heading in the direction that people who use Slack need it to go: it's not going to index channels, it's not going to allow long message lines, it's not going to deliver previous messages to users who join channels, &c &c.

Just because something changes doesn't mean it's necessarily getting better. If you have looked into WHY they do not make those changes, then it should be clear to you whether they will nor will not make those changes in the future. My bet is that someone (or multiple people) on the standards committee do not think that is the purview of IRC, and those are not features it should be concerned with. If there is no good reason for them not making those changes (in your mind), then you can go off, and make your own protocol built on top of IRC that implements those desired features. This is how you build an ecosystem of composable concepts. This is how the networking stack is built. It works.

@justin_vanw

> you're ignoring that period between standardization and the release of google chrome where there were effectively no changes and no browsers that were compliant.

> Suddenly competition led to a huge uptick in the speed of change of the web.

What's your point? Competition is pretty much always around unless it's suppressed. Your complaint is not against standardization, your complaint is against the suppression of competition.

Suddenly competition led to a huge uptick in the speed of change of the web.

Matrix (as someone with the project has already replied to your comment)

Zulip

Mattermost

LetsChat

RocketChat

I also noticed a lot of the comments recommended Mattermost as well.

Anyone interested, you can find Mattermost install guides here: http://www.mattermost.org/installation/

Puppet, Docker, Cloud Foundry, Heroku, plus guides to install directly on Ubuntu, Debian and RHEL/CentOS/Oracle Linux, etc.

Forums available for any help getting started beyond docs: https://forum.mattermost.org/

(I realize that it has other features, like automatic logging. But, on the one hand, to suggest that people making meaningful and useful patches to open source projects would be incapable of figuring out IRC is absurd, and on the other hand, to suggest that putting a typical IRC client in a web browser with few other UI changes is some kind of major ease of use shift is equally absurd.)

[1] https://github.com/Nordaaker/convos

For any wide-usage FOSS project, that'll describe quite a lot of their users.

> Gitter is bad for many of the same reasons Slack is. Please don’t use it over IRC.

The barrier isn't skill or knowledge, it's investing a small amount of time in figuring out IRC. Anyone can do it, there's loads of resources about setting up IRC expressly written for a non-technical audience (which you can provide to new contributors).

Yes, you are. You may think you're not, but you are

- User experience. In 2016, I'm not using the hacker's AIM to collaborate. I know many people love it, but there are seriously better options. Syntax highlighting inline and file attachments that Just Work are fantastic.

- Product development. I want products I use to be continually improving. Not yearly but weekly. If something breaks, I don't want to fix it because I'm not here to build a chat program or manage one.

Things I don't care about:

- Closed Source. A dedicated team paid to work on the product full time, financially incentivized to expand the ecosystem is a major plus.

- A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.

There is a reason large teams collaborate over Slack as opposed to IRC. If IRC filled people's needs, they would use it. It doesn't.

> - A walled garden. This sounds like the same as #1. Slack allows many integration points, including chatbots that can be programmed to do anything. I'm not sure it is that closed off.

Give it time. You'll come to realize that there are some good reasons - many of them quite grounded in practicality - why those of us who have been around for a while place some value on these things.

I realize this sounds caustic, but to say "Well, you're wrong" without giving adequate reasoning beyond "I've been around a while, so I know better" contributes nothing to the discussion.

* http://www.dwheeler.com/oss_fs_why.html

* Internet Explorer in the 2000's.

* Look how Microsoft got everyone by the balls with Office software for many years.

* Look up the whole Bitkeeper fiasco with the Linux kernel.

* https://en.wikipedia.org/wiki/Vendor_lock-in

* Did you catch all those people freaking out because Parse is shutting down?

* Were you there when Twitter shut down a lot of people integrating with it?

* Unix is fairly open in terms of its interface, but plenty of people got stuck on proprietary ones over the years, only to see most all of them disappear in favor of Linux and the various BSDs.

I'm no RMS, and don't have problems with proprietary software, but am very wary of getting locked in to something, rather than simply buying a product that I use and can easily switch away from when there's something better that comes out. And chat protocols are very much about positive network externalities that leave you tied to something, like it or not.

I'm not saying you're wrong, but maybe phrasing your comment a little less combatively would be nicer.

The bit about the top post was just evidence to how visible to our community these kind of things are, in response to the great-grandparent's request for "name some examples", as if they were hard to come by. They're not hard to come by: you literally don't have to look farther than the most popular article of the last 24 hours on this very site.

Sorry if that seems combative, but them's the breaks. Argue from a sound position or else you'll get corrected.

Also, supporting your opinion with a coincidence (Facebook killing Parse) does not give you a "sound position".

Uh... It's not a "coincidence" that commercial products tend to die before their users want them to. It's basically the norm. Commercial software services tend to live, what, maybe a decade at best? I cited Parse as a particularly apt example, but let's try some others you might remember, trying to pick examples from a broader time range, all of which were very popular in their prime and had many teeth-gnashing users at their death:

  * Geocities
  * Google Reader
  * ICQ
  * Napster
  * Twitter's API Access
  * Deja News / Google Groups

"Technology changes, economic laws do not." -- Hal Varian, who is now the chief economist at Google.

Open Source projects can not afford to pay for archiving Slack messages. A lot of important discussions will vanish.

So you're no more likely to lose your logs via Slack than via IRC or XMPP if you set things up correctly.

1. Freedom the run the program, for any purpose. 2. Freedom to study and change the program (source code required) 3. Freedom to redistribute copies. 4. Free to redistribute your modifications. (source code required)

For the kind of people who frequent hacker news, I would expect you to be familiar with these very basic principles of software ideology. If you disagree with them, that's fine, but let's not pretend that proprietary is anywhere close to FOSS in the realm of freedom. Sometimes you must sacrifice functionality and usability to use FOSS, and that's a choice that only you can make, but what I don't want is you making that choice for me because you don't understand the basic ideas of software freedom.

On the subject of Slack, I can give you a quick example of this. Let's say you want a good chat app but it needs to be secure, and you don't want to trust another company (slack). So obviously you want to self-host internally right? Oh, sorry, no source code, no self hosted version, too bad, fuck off and wait until slack releases a self-hosted version. Oh, and if they do, and you want to implement your own internal feature X, too bad, fuck off, you get what you are given.

Very disappointed in the level of understanding of these things on hn lately.

  > Very disappointed in the level of understanding of these
  > things on hn lately.

Counter-example: What if I don't care about that?

Qnd thats not even a counter example... Its just... Lazy.

That's just one point.