Hacker News Reader

Comment by publicfig | Hacker News Reader

It's really difficult for me to take this point seriously if the only proposed alternative is IRC. I understand the benefits of IRC for FOSS and have used it many times in the past, but there's a reason why projects are adopting Slack over IRC. It's easier to use, it deals with on/offline states a lot more gracefully, it allows joining and inviting to rooms much easier, it has a clean and easy to use design and it's available pretty much anywhere using the same interface without having to install a client through their web interface (which is the exact same as their app interface). Along side that, there are hundreds of other minor to major features (File Sharing! Ticketing/build integration! Link Previews! Editing a message after it's sent!!!) that make it much more useful for many use cases than IRC. I think there is definitely room for competition with Slack for FOSS projects, but trying to pretend like IRC is that ultimate solution will ignore the problem completely.

View on HN

but there are alternatives!

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!

OK, I'm rather impressed. I was expecting this to be, shall we say, at usual FOSS levels of user-friendliness for non-technical users, but the new client (Vector) is very easy to get started with.

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.

Thanks! Vector (http://vector.im) has had a lot of UI/UX focus - but the nice thing with Matrix is that it enables you to pick the type of app/client that you like - and whether that's a web client like Vector, a terminal client like weechat (http://matrix.org/blog/project/weechat-plugin/), a mobile app, or even a different service like IRC - that's entirely up to you!

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

This looks incredible! Thanks for posting it.

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

But using those bridges, how can I be assured that someone on the other side has access to stuff like file transfers or code snippets, or any of the other features?

You can't. Bridging necessarily means least common denominator for features. But any matrix client should support the features listed in the spec.

this is very cool. has this ever been ProductHunt-ed?

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 ?

hi - it's not normally this slow - and the slightly increased traffic due to the comment above shouldn't have caused it. We're looking into it!

and thanks for trying it out :)

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

it is probably more relevant for the HN crowd to link directly to http://matrix.org/blog/try-matrix-now/

When you, as a free software project maintainer, rely on proprietary software for your infrastructure, you send a bad message of "I expect my free software to be good enough for you, but your free software is not good enough for me."

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!

Not everyone is dogmatic about free software. Slack is better than the alternatives, and denying it out of dogma is not a virtue. Many people are pragmatic and just enjoy programming and getting things done in the most efficient way. Rather than complaining that people are "unethical" (?) for using closed source software, you'd help your cause more by developing an open source alternative that's actually better than Slack.

If the only thing that matters is technical superiority, then you can expect to continue to watch your freedom be stripped away. Sometimes free software is more convenient than proprietary software, sometimes it isn't. We can't be willing to trade freedom (in this case trading free communication tools for proprietary ones) for short-term convenience if we want to see a world in which users can control their computers.

Before 2005 the Linux kernel was managed by BitKeeper, then Git happened and took over the world. The free software folks that were criticizing the usage of BitKeeper for the Linux kernel weren't able to offer alternatives, whereas Git was born from the hands of the same pragmatists that were using BitKeeper. 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.

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.

> 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.

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 ;)

> Before 2005 the Linux kernel was managed by BitKeeper, then Git happened and took over the world. The free software folks that were criticizing the usage of BitKeeper for the Linux kernel weren't able to offer alternatives, whereas Git was born from the hands of the same pragmatists that were using BitKeeper.

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

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.

For example, for Windows I have been thinking about a non-profit foundation founded by hardware vendors for example.

I don't understand what you're talking about. A foundation to do what?

To develop and support Windows obviously.

Why not spend the same money to support free software? If you have the money and time to throw to Microsoft, which benefits no-one but Microsoft, why not give it to the free software community so everyone benefits?

I know that actually making Windows open source would not be trivial. I am focusing on the freedom to distribute as a first step. And yes I know it is up to MS whether to actually do this too of course.

I can turn your comment on its head and it works quite well: we can't settle for technically inferior free software if we want to see a world in which users can control their computers.

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.

> I can turn your comment on its head and it works quite well: we can't settle for technically inferior free software if we want to see a world in which users can control their computers.

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".

>> I can turn your comment on its head and it works quite well: we can't settle for technically inferior free software if we want to see a world in which users can control their computers.

> 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.

> >> I can turn your comment on its head and it works quite well: we can't settle for technically inferior free software if we want to see a world in which users can control their computers.

> > 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".

Get off your high horse. You cannot reasonably expect people to use sub-par alternatives and be happy with it.

You appear to be missing the point here.

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.

So when it's your choice what software to use, you can use your definition of better. The high horse comes when you try to tell other people to use your definition of better. Like the link we're discussing. The person is telling others, who've decided they like Slack better than the free alternatives, that they should stop using it. That's getting on a high horse.

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.

I'd change your qualifier from "when it's your choice" to "when it's your choice and your choice doesn't adversely affect anyone else".

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.

"This may discourage some of your potential users & contributors, and that may reduce the quality of your project."

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.

> "This may discourage some of your potential users & contributors, and that may reduce the quality of your project."

> 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.

Your point is valid - and we basically agree that there are different types of barriers to entry.

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).

> Slack is better than the alternatives, and denying it out of dogma is not a virtue.

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?

I don't think that aspect is a pro of Slack. However, the UI capabilities of Slack are certainly pros.

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.

In reality 90% of OS projects use Freenode, whereas everyone that uses Slack has it's own separate slack thingy that requires a new account.

Totally fair. Having to make a new account for every project is definitely not ideal, and I wish Slack had better integration for more seamless sign-up using existing identity providers.

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.

Denying something out of dogma is basically the definition of virtue.

Subjective virtue, perhaps. And that gets us squarely into the territory of "religion".

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

> Subjective virtue, perhaps. And that gets us squarely into the territory of "religion".

> 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.

Who is the other side of the conversation you mention in your first paragraph?

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?

>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.

So if one opensourced a windows program, you would consider this bad because others would have to use the proprietary Windows to run it?

While free software for Windows is better than proprietary software for Windows (because it could conceivably be ported to free software on other platforms), it is not (in of itself) practically free because you need to use proprietary software (Windows and system libraries) to use it.

If that program only worked on Windows, then you should not recommend its use unless that person were already using Windows. If there are Free alternatives, you should recommend them instead; you'd otherwise be forcing users to use proprietary software to communicate with you.

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

So, for the sake of argument:

- 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.)

If there is no way to contact you without using free software, I would probably just make a fork of your project. If you can't just sit in an IRC channel on freenode or just post an email I can use, then I don't understand why you are a maintainer of a free software project. Sure, use Slack if you wish, but don't force me to use it if I want to contact you.

I imagine that many maintainers who don't necessarily feel as dogmatic about free software hold the belief that "if you wish to contact me, you will use the tool I say." I've certainly "maintained" projects that are free software that I had no real desire of spending much time on, so if someone had a question it better come the way that I want, otherwise I can just ignore it. It's not a very kind or classy position, but I think a lot of people feel this way.

How many maintainers won't accept patchsets by email?

You don't need to run your own infrastructure---you just need to use services that are compatible with free software.

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.

So there's the issue of software being "open", as in being able to see the source code. Then there's the part about who is running the software.

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.

> 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?

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).

> 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?

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

Source code wise, the problem is non-free JavaScript served to the client:

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

It's desirable for the program running on the server to be Free so that I could run my own (if I chose to do so), and therefore be in control of my own computing. For example, I run my own GNU Social instance.

Which part of "can you view the source" is subjective?

By the same token, would you consider https://github.com/Debian an endorsement and enticement to run proprietary software ?

People use slack because they use it at work and don't want to have two different message clients and want to consolidate. Free software is not meeting the needs of corporate users and has failed them, so they are using Slack or HipChat instead. Your dogmatic stance on "I am completely opposed to editing messages after they are sent (chat is append only!)" is a good example of how open source is failing corporate user. I typo things all the time and want to be able to edit them, and don't care about your philosophical objections.

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.

I think what the previous poster is saying is just that - the free alternatives to Slack are not as good - and therefore they aren't using them.

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

To some it is.

> Centralized network services are increasingly removing our control over how we communicate, and we must reject them for our free software projects.

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.

There are many IRC servers. IRC daemons are available as free software that anyone can run. Freenode is not particularly problematic. It is an organization of servers run by a community, not a company. By asking someone to login to Freenode I do not entice them to use proprietary software like I would if I asked them to use Slack.

I don't understand this "entice" business. The natural way to use Slack is to use it in a web browser, which could easily be an open source web browser. And there are many closed-source IRC clients.

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?

When you use Slack, you don't "use it in a web browser", you use the (proprietary) software, delivered by Slack Technologies, which happens to run in a web browser. The fact that the web browser is itself free software is as irrelevant as the fact that the kernel and user-space services supporting skype on linux/bsd systems are open source. The actual software, everything that actually relates to the task at hand (group communication), is non-free.

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.

But just visiting the project page on GitHub downloads and executes proprietary JavaScript. If that's a problem for Slack, why isn't it a problem for GitHub?

You don't have to visit Github's web ui at all if you're just using it as repository hosting. At least users and contributors don't have to, the maintainer needs to occaisionally for configuration reasons.

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.

Don't all contributors have to at least set up an account through the web interface?

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.

> Don't all contributors have to at least set up an account through the web interface?

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.

Oh yeah, good point, projects can't bring their own user authentication system, so all your contributors have to have github accounts.

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

Contributors won't be able to push to GitHub, but they can still push to a mirror repo or some other setup that then pushes to github.

GitHub's proprietary JavaScript is a problem, amongst others.

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

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 natural way to use Slack is to use it in a web browser, which could easily be an open source web browser.

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.

I don't think I've seen anyone worried about running proprietary JavaScript in a browser before. I suppose that's consistent, but I don't know how many would agree with it. The utility of a web browser is deeply limited if you only use it to run open source code. As I already asked, do you also advocate against hosting the code on GitHub? That seems like the same problem.

The source of the JavaScript is open by virtue of being an interpreted language, and as such it can be edited and modified by the end user.

This is absolutely not true! The "source" is often minified JavaScript code, which is not the source code. In legal terms, it is a binary. It's a build artifact, the output of a program, not a human. Source code is the preferred form of modifying a program. The developers of a web application certainly don't use this form of their program when hacking on it. Giving someone a concatenated, minified version of a JavaScript web application is not giving them software freedom.

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."

So Freenode is centralized... kinda — I certainly wouldn't argue that it isn't, at least.

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.

I'm agreeing with you in the larger sense (Debian + IRC are way more 'community-run' (both in the literal sense and the community feeling you get after spending 3 years in #openbsd (i.e. Deb/IRC == Woz)), and Slack + Apple is refined, user-accessible, and designed with traditional capitalist values (i.e. Steve Jobs). But your comparison of IRC leafs = the state/commonwealth gov't :: IRCs hub (assuming there is one) = the federal gov't is real flawed.

>> 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.

Pidgin is awful for group chat. So is every other jabber client out there. I want to like it because it's open-source, but it's just unusable for many use cases (e.g. try to participate in a conversation using a home and a work computer, or just try to find a groupchat UI that isn't awful).

Wow, you really nailed it. Freenode isn't free.

So this[1] isn't your github profile then? Because publishing FOSS via a proprietary service would be you saying that free software like Gitlab isn't good enough for you.

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

Yes, that is my GitHub profile. I no longer host new projects there as of a couple years ago because I do not support the GitHub monoculture, but I do occasionally use it to send patches and file issues for projects hosted there.

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.

What about the hardware that are used to build your server? Is that an open source platform?

Linus Torvalds uses Google+ extensively to communicate.

Have we all voted to give Linus the ability to think for us? If I have a question about anything regarding GNU/Linux (or git, or even C development), by all means, I will take whatever Linus says as gospel. But when it comes to which tools we use and how that relates to freedom, we should all think for ourselves.

Linus has never been like... a Stallman-esque bastion of software freedom obsession.

Linus also spends a lot more time communicating via mailing list. Google+ is like a side thing for him.

Yes, and his G+ posts are seldom Linux-related.

Linus has very little to do with the free software movement.

And I haven't bothered to figure out which parts of my creep-blocking software I need to disable to read whatever he writes, so his "extensive communication" gets ignored.

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

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.

> I expect my free software to be good enough for you, but your free software is not good enough for me.

Then maybe those other free software projects should get good.

Maybe those free software projects could use some help in the form of users trying it out and giving feedback.

"feedback" isn't enough to make a free software project good enough. I can give plenty of feedback to a project in the form of pointing out user experience problems. It doesn't help. What helps is

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.

In all honesty, you're bringing nothing new to the table here. This is the same FOSS-uber-alles pissing match anybody can see and participate in by spending five minutes on 4chan's tech board.

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

(earlier comments in furtherance of said pissing match deleted)

Its really difficult to take you seriously if your only real argument is "But but FREEDOMMMMMM". Freedom is being able to say "fuggit, I'm using a better product because I effing well can." Its you exercising your freedom to not log in. Its not demanding everybody do things your way so you don't have to do it anyone else's way.

"When you, as a free software project maintainer, rely on proprietary software for your infrastructure, you send a bad message of "I expect my free software to be good enough for you, but your free software is not good enough for me.""

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

I love Slack, but I agree with the author. Slack's unsuitability is more around licensing terms and the ad-hoc nature of OSS. Slack borrows generously from IRC -- in fact, Slack is basically "Corporate IRC". It's a huge reason as to why Slack is so popular: IRC made sense in the 80s, and it still makes sense today.

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.

> The only real benefit of Slack is easier file transfers

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.

Don't forget an android client that both gets near-real time notifications and doesn't eat your battery. Plus a really nice authorization flow on mobile; everyone who has to identify a mobile client should steal however slack does it.

So, IRCCloud? They already do exactly that.

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

The context of this discussion is open source projects. While I agree that these are all useful features, I'm not so sure they would be useful for open source projects whose membership tends to change relatively frequently. Also, many of these features are features of the client, not the protocol.

> 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).

> 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.

> 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.

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).

"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)."

And that attitude is why most people won't take open source seriously.

you don't every single feature for something to be a useful alternative.

> The only real benefit of Slack is easier file transfers

IRC has rock solid file transfer. Depending on your IRC clients, it's easy to use as well.

No, and no.

Have you tried out irccloud.com? It addresses most of what most people think Slack is better than IRC at.

The only big thing that Slack has over IRC is being able to catch up on what was said earlier.

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.

> The only big thing that Slack has over IRC is being able to catch up on what was said earlier.

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.

The reason you keep hearing the same things over and over is because people keep giving technical solutions to experience problems, and so aren't really solving the problem.

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.

Well, we are discussing chat for open source projects, rather than, say, what to use at a company. Some technical knowledge might be expected in this crowd.

That's effectively telling everyone that if they aren't comfortable a) researching the available programs, b) paying for a server to host it, and c) learning enough to support a running container, manage SSL certificates, install security updates promptly, they shouldn't be part of the community. That's bad for growing the community, particularly since there are many people who participate in OSS now who don't have all of those skills or the time to spend supporting a service even if they do.

And the price for convenience is, eventually, hassle migrating to a different service every time something doesn't work to your liking. Need to pay Slack for features? Jump another hoop. What for?

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.

I've been using free software for a couple decades. I get why it's valuable but having watched what is and is not adopted really underscores if we want people to use OSS we need to offer a competitive experience. Years of cajoling people did not get them to use Linux because the desktop experience sucked. Years of advocacy did not get them to adopt Mozilla in great numbers but people did respond when Phoenix/Firefox focused on UX and was actively improving during Internet Explorer's great stagnation.

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.

Exactly 0 of those things are required to interact on IRC.

Source: have been using IRC since late 1993.

> Exactly 0 of those things are required to interact on IRC.

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.

My points are not about the tech so much as:

* 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.

Sorry, yes, I had the wrong tab open for that message and attributed it to you by mistake.

> * 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 have all of the knowhow to be able to set up an irc client in screen or set up a bouncer, to use something like irccloud, to get xdcc working, etc. etc., to work around all of the usability problems of IRC, having done all these in the past.

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.

Chat in general, as per my earlier message, is for pretty ephemeral stuff. You should not be entrusting important decisions to it. Plenty of networks, like Freenode, solve the 'who is this person' thing in that, for instance, no one else can grab a nick for more than, say, 30 seconds.

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

Why? There are plenty of non-technical ways one can contribute to a project. Requiring a high level of technical ability is only going to encourage a monoculture, and cause FOSS solutions to ignore the needs of non-technical users.

> 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?

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.

Isn't one of the major points of using Slack is that you can just search later on if anything useful was said. You're not supposed to need to read everything

>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?".

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.

That's an extremely elitist viewpoint, that will do nothing but tell people that they aren't welcome in open source. Which is a terrible thing.

No. A bouncer is not a solution. Hence why you keep hearing that argument.

Ever tried IRCCloud, or Quassel with Quassel-Webserver and QuasselDroid (beta)?

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.

A screen session, a bouncer, Quassel, or ircCloud can all allow you to catch up with irc.

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

I often have the situation that I asked someone something, then the next day, or next month I have the same problem again and want to search for that one link or answer without bothering everyone again. That is not possible with IRC (yet?)

Practically speaking, Slack does not do this either.

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

Yup, we're facing this problem right now in the Clojurians group, where there's usually less than 24 hours worth of history before it disappears.

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.

Turning on logging in most IRC clients is very easy. But once again this is an extra step and means learning the client a bit. One nice thing is that I can have those logs offline and search them whenever and however I like. I regularly do search my irc logs to find that links I didn't save, or re-read an important discussion.

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.

Thing is, I use Xchat at work, on my Phone a native Sailfish OS IRC client, om my Android AndChat, on my iMac Textual and on my laptop a different instance of Xchat. And in between those clients are offline so they can't get continuous logs which they could save for offline search.

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

Well, maybe try Quassel?

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).

Nice, I will check it out :)

Almost everyone I work with uses ZNC. I've stuck with my same old method of tmux/screen and a text mode client. Apparently ZNC isn't hard to set up or use but I have no direct experience with it.

Mozilla solves this by having logs for the developer IRC channels by just having a bot that puts up the logs on a web server. E.g. see http://logs.glob.uno/?c=developers

Yes some of the chanels I use do that, but most of them don't.

Many channels have a logging bot which pushes logs to a publicly accessible archive.

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

Just set up an IRC log bot to log all channel traffic to a web site (can't be bothered to look one up; but I know they existed when I last messed with IRC 20 years ago).

I am using ZNC but it's not obvious how to make it to log everything and make it searchable.

How on earth could it get more obvious to tick the tickbox labelled 'log'?

How you search the created logfiles is up to you, znc is not a log management system, it merely creates.

Uhm, ZNC runs on the console, there can not be a "tickbox labeled 'log'" because there is no GUI?

znc comes with an web GUI to admin/configure it.

IRC clients can log.

And if the person who wants to refer to something was offline at the time...?

Then you set up a bot that logs on channel (there are even dedicated services for that). Or use a client on a remote server to which you then connect (e.g. weechat).

It works mostly like this: I have a problem, let's say with QML, I log into their IRC server, ask the question and it is fixed. Then I don't work with QML for a month or two, then I remember that during the session two months ago they also linked to some cool tool but I can't find the link anymore (for example), I would like to be able to go back there and just search for my conversation. In the meantime I wasn't in that chanel or logged in into that server.

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

And if the person who wants to refer to something was offline at the time...?

>> The only big thing that Slack has over IRC is being able to catch up on what was said earlier.

What about all the integrations with other services?

What do I need that for for my open source project? I could probably get github notifications, or bugs, or something via a bot in IRC if I wanted, but I just don't see the need. Chat is by its nature not supposed to be the hub of an open source project, because it's a real time thing in a distributed group of people who may not be able to do real time.

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.

Chat is by its nature not supposed to be the hub of an open source project, because it's a real time thing in a distributed group of people who may not be able to do real time.

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?

People have been building IRC bots for decades that integrate with other services.

Very true, but there is a ton of stuff that Slack provides out of the box.

Fedora uses IRC for all the various group meetings and it works out pretty well, IMO.

OpenStack does as well. They use bots to log and capture high points which are then posted publicly for discussion/reference.

Considering the overlap of redhatters between the two I'm not surprised.

To be fair to your first point, if you set up a bouncer or use a client inside of screen/tmux you can absolutely catch up on what was said earlier in IRC.

And then you're back to the "easier to use" point. Maintaining an IRC bouncer is a chore that only an uber geek could love.

I set my ZNC up in 5 minutes and haven't touched it in 2 years other than to change my silly vhosts.

Really? I just leave irssi running on my linode, I don't even bother running a local client most of the time, I just SSH in and use it. The only exception is when I'm on mobile, and I have irssi-proxy running for that one special case.

I think part of this debate is that for some people, the above is a pretty normal and easy way of doing things, and for others, it's a large barrier to entry.

If setting up an IRC client is a large barrier to entry for a coder, I would have some serious doubts about the merits of their code.

Cool.. but I think you just underscored bjt's point.

"Uber geek"

Really, having a $10 VPS and using screen or tmux is "uber-geek"? Look, if you can code in virtually any programming language I'd like to think you have the ability to use screen and irssi in under 10 minutes. We are talking specifically about open source projects, not general IM across a business (though I'd still use IRC there, just give everyone hexchat/xchat/whatever nice GUI client you want).

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.

> having a $10 VPS

Oh yes that is definitely uber-geek.

No, having a cheap VPS handle automatable tasks isn't ubergeek.

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.

We're talking about chats for open source programming projects, not the local book club. In that context, setting up an IRC bouncer or running a command line client in tmux on a VPS is not really a high bar.

It is if you want the project to appeal to a wide range of people, besides just techies.

Really?

Ever seen IRCCloud or Quassel?

Simple "one-click" "just works™" IRC bouncers, perfectly integrating.

IRCCloud costs money these days, and it's no more open-source than Slack in any case.

There's a difference between an open protocol and an open client. The latter... doesn't matter quite so much. The former is pretty important.

Slack supports connecting via IRC or XMPP.

Which is additional configuration to pay for and/or take the time to set up. And that you have to think ahead enough to realize you need this before you actually need it.

So all of the things you've noted, IRC is perfectly capable of doing. It's just that no one has built the interfaces (or the bots) for doing so.

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.

"Just build a bot" is such a cop-out. With the right "bots", you could make Unix talk(1) competitive.

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.

So IRC can do all this stuff, but nobody has done the work to do it. That is another way of saying IRC doesn't do this stuff. That might be why people like Slack rather than IRC.

``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? :)

Actually, people have. They just haven't packaged it all up into a happy-clicky single click deployment. There is a little bit of configuration involved, but I have confidence that a majority of folks here could do it in two cups of coffee or less.

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.

I suppose I'm just perplexed at this persistent view that one can just handwave away the fact that IRC doesn't do everything Slack does simply by saying that it could.

Again, IRC != slack, they're not the same type of thing. IRC is a protocol, slack is a product built upon a (proprietary?) protocol that slack built to do pretty much the same thing IRC does (with arguably more features built in).

Also, no one is arguing whether people like slack more than IRC -- the point I'm trying to get across is that IRC is capable, but only lacks the development of a client, and forging of standards that would allow features that slack has.

All the bot stuff is copyable pretty much 1:1, the great design, and built in features of slack require a much better IRC client to be built. But that's the only thing standing in the way.

Taking the walled garden over developing an open source solution is widely accepted in the world at large, but it should not be the defacto solution for the FOSS community.

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

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

This is a good point, and the case can certainly be made that source code hosting should be done on sites that are powered completely by FOSS.

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.

Not that I know much about Slack, but by using GitHub you don't give up control over your repository, or its history. Every single project member has a fully working copy that can be used if GitHub for some reason decides to go rogue, and it's accessible through open source software.

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.

That's true that many of the things I mentioned (not all) are possible through clients building in the functionality on their end, but that leads to another problem that slack can avoid, which is a unified interface for all users. While file transfers may be made easier on one IRC client that some users are using, it has to be completely compatible with the user who is connected through Irssi or another less capable client. This limits the possibilities of a client (which, mind you, is actually a big selling point for a lot of IRC users including myself). And I agreed on the fact that it's closed source and that can be an issue. But like I said above, that means that there is room for FOSS solutions, not that IRC is the answer.

@tptacek:

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?

Please reply to posts directly for the sake of keeping the thread tidy. If you don't see a reply link for a post, click the timestamp (e.g. "17 minutes ago") to go to the permalink view for a given comment, where a reply box will be available.

Thanks -- reply button didn't show up, wasn't sure why, didn't know about this trick to leave comments.

No worries... I'm not sure exactly why the reply button is hidden when this "trick" allows you to reply regardless. HN mods might be able to shed more light on this.

That's a neat trick, and not one that I knew about. I would also like to know why the reply button doesn't appear at times -- I presumed some kind of rate-limiting.

Is there a reason why the replay button doesn't appear sometimes? I always wondered about that.

To you and the others curious about why the reply button doesn't show up, there is a buffer period after a reply appears before you can reply to it, to mitigate flame wars and such. It's usually a few minutes.

Uhhh does that mean we just found a bug?

If you mean the fact that you can circumvent this, then I'm not sure. It's possibly intentionally left in so that more experienced users have a way around that limitation.

- offline mode integrated - search - usable mobile clients - inline images - notification control - usable interface for private and group chats - access control and authentication integrated

Probably more too.

But do any of those features feel like they couldn't be built into a good product built around IRC?

Anything can be built but irc has huge fragmentation of clients, so dev focus is thinly spread, developers have not apparently been interested in changing the ux for decades, and most of the (small number, despite what this article says) users like it how it is.

@tptacek:

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

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?

@publicfig:

Not all? Which aren't possible?

And yes, it is true that slack avoids this problem -- the same way apple avoids having to deal with disparate use models for their hardware and software. You are arguing for a walled garden right now. That is the antithesis of what FOSS should be built on.

So this is the place where standards come into play -- by finding reasonable ways to implement these features ON TOP of a protocol, people can implement them (or NOT implement them) consistently across clients. As long as the feature standards were written to degrade gracefully (as in they would still work reasonably well if your client didn't support any advanced features), there would be little problem with clients that didn't implement certain features.

If you're using a client that doesn't support certain features, the beauty of FOSS is that you can actually change that client. You can make your tool better. That, or switch to a better tool?

That no one has built the interfaces for doing so?

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.

Isn't there any way to "mount" a custom protocol on top of the IRC protocol, like Microsoft Comic Chat did in the nineties? If I recall correctly they encoded custom commands in plain text the client could correctly interpret to draw the comic panels.

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

Incredibly hacky and fragile - the MSN Messenger protocol of yesteryear was similar. It was originally a plaintext-only protocol that was simple to implement, but many features were grafted on top over the years while trying to maintain backwards compatibility.

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.

> "Isn't there any way to "mount" a custom protocol on top of the IRC protocol"

Why not just use Matrix.org?

https://matrix.org/

IRC is constantly evolving as a protocol, and v3.3 is currently work in progress, so improvements are being made. See http://ircv3.net/

Except not really, and it hasn't changed in any significant way in over 20 years.

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

While standards and committees might be slow to implement changes, their existence certainly does not mean some language/technology has stagnated. By your logic, the web has stagnated.

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

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

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.

@tptacek:

> 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.

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.

There were several listed in the comment section including:

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

Zulip

Mattermost

LetsChat

RocketChat

http://mattermost.org/ is good. We will use it in our company with 300 devs.

Thanks for the heads up. I'm going to try this out. I have a small team of developers right now and Slack hasn't been working out as well as we had hoped.

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

Fantastic!

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/

Isn't slack basically just IRC over port 80?

(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.)

There is also Convos [1] a web front end client to IRC that addresses some of your concerns. It uses Redis to maintain state.

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

I used to think that too, but irccloud.com solves almost all of the issues you mention.

Why not Gitter? It's really easy and plugs right into your Github.

That's fine unless you're not a developer, don't have a Github account, don't know what it is and don't want one.

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

How is Slack better? At least with Gitter you just need a GitHub account, with Slack you have to create a new account for every Channel you might want to use.

Did you read the article?

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

I chat with non-technical people on IRC everyday. If setting up an IRC client is "too much work", contributing to FOSS is "too much work." Don't force everyone onto a proprietary platform because its modestly more usable than IRC.

And don't dismiss your non-technical users out of hand like that. It's elitist, and it sends precisely the wrong message.

I'm not dismissing non-technical users, I'm acknowledging that plenty of them seem to use IRC just fine, contrary to what people are saying itt.

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).

"I'm not dismissing non-technical users"

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

Reply on news.ycombinator.com