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".
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:
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.
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."
>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.
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. 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.
 To be fair, STARTTLS can be chunked into basically any protocol. My point stands.
I use my own server (running free software, of course) to host my source code now:
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).
And that attitude is why most people won't take open source seriously.
IRC has rock solid file transfer. Depending on your IRC clients, it's easy to use as well.
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
How you search the created logfiles is up to you, znc is not a log management system, it merely creates.
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.
Ever seen IRCCloud or Quassel?
Simple "one-click" "just works™" IRC bouncers, perfectly integrating.
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.
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.
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.
Slacks growing usefulness is predicated on the fact that you people build bots for it.
Is that incorrect? I'm sure that list is incomplete, is there anything very significant I left off?
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?
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?
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.
> 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)
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.)
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.
* 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.
* 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:
* Google Reader
* 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.
One might be "what if a product shuts down?" This has happened before with chat (Campfire being spun out of 37Signals) and wasn't catastrophic.
In fact, this could be a long-term positive (but short-term pain in the ass) since it forces stagnating teams to update.
Probably one of the mental blocks here is that your exposure to a walled garden is bounded by the value you put in it, and it doesn't seem like "a few guys chatting in a Slack channel" is a lot of value. And yeah, it probably isn't for your median open source project, even accounting for the ease of underestimating the value of that chat. The median open source project is having a good day if two people are in its chat channel simultaneously. However, if you're a much bigger project, and you've got hundreds of lurkers and active ongoing conversation for hours a day that constitutes the "real" design of the project, etc., it is dangerous to let that be in a walled garden for "free". But, still, only dangerous relative to the value of what is in there.
"Site gets shut down" is just one possible exposure. More concerning is the "site becomes not free after all".
My synthesis of all this is that, yeah, there probably isn't a lot of concrete danger in using Slack for your communication, but that the signal it sends may not be what some people would expect. But even that depends; an open source Slack plugin may as well use Slack, whereas a GNU project wouldn't be caught dead there, and there's a whole continuum in between.
Why is the team developing the thing you find valuable getting compensated for that concerning?
It's about the value they'd have that would allow them to negotiate a deal you probably wouldn't have taken if it had been offered to you up front, i.e., "lock-in".
But I blame the project for letting themselves get locked in, not the company for trying to make the money.
Open source projects are usually unfunded and to a first approximation have a budget of $0. This makes them a strange case.
Can we please put this ridiculous circular argument to rest already? You can say that about ANYTHING, it's a vacuous fallacy.
The real circular argument is "if only people used XXX they would love it!" That's not what I'm saying. People are choosing a new alternative to IRC because of the feature set.
Early on in the smartphone wars, the best argument from the Android side was "well just look at the adoption."
That isn't circular. Adoption is an important measure of "does this solve a problem people have?"
People follow the herd. In terms of collaboration tools, they use whatever tools everyone else uses, and often get stuck with bad solutions because of network effect. Just how many companies use Skype for group chats? In each case you could probably trace it back to the CEO / upper management needing it for actual video calls, who then force this tool on the employees and because it has some group chat capabilities, nobody bothers to switch to something better. I've seen similar things playing with other tools as well. It's not the good one that wins, it's the first good enough that does.
Has GitHub been bad for open source software?
Has Google Groups?
Moving off of github is a simple clone. Google Groups is archived, and there are many other alternatives.
Unless you are paying for it, Slack message history vanishes.
IRC doesn't even have the concept of message history. Any such thing is done by individual clients/bots.
Bringing up message history as a negative is just straight-up disingenuous with that in mind - the answer to both possibilities is the same: use a bot.
Same thing with IRC. With Slack, however, I can pay later, and still have access to the history. With IRC, once it's gone, it's gone.
> Slack message history vanishes.
- Probably would have come across better if I didn't pitch IRC as better than Slack in general, but only that it's better for FOSS projects. This blog post wasn't meant to shame Slack in general, even if it kind of did in the end.
- Importantly, Slack has come out as saying that they don't want big public projects to host themselves on Slack. It's really just not a good use-case for Slack to put a FOSS project on it.
- In hindsight, a lot of the FOSS-friendly alternatives (Matrix, Gitter, etc) are quite good and I should have put more effort into researching them and discussing them in my article.
It's probably too late to steer the discussion, but please remember that my post addresses the use of Slack for FOSS projects, not in general.
I'm curious and need help finding a link to this source.
They can sign up with IRCCloud (or any quassel-as-a-service provider), and instantly be online.
Webinterfaces, clients for all platforms, and bouncer is integrated.
Seriously, there are modern solutions for IRC, use them.
Here is a list with the projects of the top of my head with which I'm in contact via IRC (quite often): Firefox (+OS, +sync), Qt (+Cpp, +QML, +QtCreator), Sailfish OS, IndieWebCamp, foss-gbg, golang, SELFHTML, Thunderbird, Clementine, Gnome (+calendar, +addressbook, etc.), Gimp, SyncThing, VLC, ArchLinux, ruby, Emacs, node.
I wouldn't go that far. Freenode is bustling.
I actually use a number of things through BitlBee  just to combine everything into one client. Scripting things in python is also fairly useful.
Yes, and that reason is that the current crop of up-and-coming developers have the same problem as past generations: They'd prefer to implement their own solutions vs. looking to the past.
Slack just happens to be the current darling in group communication. At some point, someone will make something that will change the fad-diet to The Next Big Thing.
In that case, we are talking about the freedom of the user to use software as they wish, to study it and modify it to suit their needs, and to share it with others. We're not talking about the freedom to go about their lives as they wish---that's a separate fundamental freedom, although it can certainly be restricted by nonfree software. Ideally, that software would also be Free, but that's their own choice.
But we should never encourage the use of proprietary software.
If you're talking about the "open source" development methodology, though, then the argument ceases to exist, because freedom is not important enough to discuss, and so those who adopt that perspective won't understand why it's bad to recommend Slack to someone, or even require it.
That said, GitHub wikis are just git repositories. You can clone them like this:
As for issues, it's only a little bit trickier - you'll have to use GitHub API, like this:
https://api.github.com/repos/hotsh/rstat.us/issues (from https://www.quora.com/How-can-I-export-backup-GitHub-issues)
So if part of your team wants to stay on IRC and part wants to use Mattermost with file sharing and messaging across PC and phone, and integrate with Mattermost apps (http://www.mattermost.org/community-applications/) all that is available.
IRC is still my preference, but it takes a fairly technical person to appreciate it and host their own server. If you're catering to more general people, having 1 technical person spin up Mattermost in docker might be a good solution.
Namely, is it still intended primarily for intra-team collaboration, or can it handle communication with the public as well?
It actually is included with the gitlab omnibus installation package now, and then it uses gitlab's LDAP for logins. I just had to set a few options in gitlab.rb because I wanted to use SSL and to set the external hostname.
So perhaps I'm hoding it wrong, but I've been using ZNC for a couple of years and every time I forget to close Xchat at work and people keep talking, I can't see what they said on my phone or at home. Also I can't scroll up nor search for stuff which were said in the past.
For me that is the biggest drawback with IRC.
A sensible alternative, which I also was able to push at work, is Mattermost http://www.mattermost.org/
Although I would love to see us using http://matrix.org/ but I don't expect our customers to install their own instance so we could federate any time soon.
Ever heard of Quassel?
An IRC bouncer where the client integrates with the bouncer – just scroll up to load more backlog.
Disclaimer: Am working on Quassel.
KeepBuffer = true
Buffer = 5000
It is mostly used for gaming, but coding with it is just as great. There are a lot of public servers also for all sorts of things. (http://discord.me/servers).
The voice is what we love it for, chat is awesome during the day when some of us are not able to talk over voice.
If your biggest concern with Slack is the invite-by-email hack, try Discord.
This is much ado about nothing.
Everything else is politics and philosophy. Some people really get into the very specific politics and the very specific philosophies of the FSF. What they don't seem to get is that the FSF merely has one out of infinitely many perspectives on why open source is important and what people should do about it.
It's fine if someone wants to run an ideologically pure (per FSF criteria) FOSS project, or not contribute to projects that don't meet their criteria for ideological purity. Where it gets counterproductive is asserting that one group's philosophy has some sort of primacy over the entirety of the FOSS world. It gets especially dicey when that group claims moral superiority over everyone else.
Instead of complaining about this or that FOSS project not being "true FOSS", the FSF should define a set of standards and practices that go beyond mere software licensing that DO meet their standards for ideological purity. Then a project that wants to comply with the FSF have an easy way to state up front that they are politically aligned with the FSF in every respect. Those who care about such things can use that information to set their expectations about how the project is run outside of the software licensing aspect. Maybe it draws them to the project, maybe it drives them away, but at least no one gets surprised and no mailing lists devolve into pointless political flamewars.
That way no one gets disappointed (for example) when a project wants to use Slack for communication, assuming that that project has not stated up front that FSF-compliant ideological purity is a goal. Alternatively, if a contributor to a self-declared FSF-compliant ideologically pure project wants to use Slack, the other contributors to that project have grounds for denying that on a purely philosophical basis. They can focus on maintaining their standards for ideological purity rather than continually arguing over whether or not FSF-compliant ideological purity itself is valid goal.
But maybe you don't care about freedom. I'm not sure why, but you probably have some shallow justification why "it doesn't matter for you".
Open is more than one form of software licensing, each license modified by the different idiosyncrasies and values of different people that develop software.
> Everything else is politics and philosophy
Open source IS politics as well. The origin of the term itself is a way to subvert Free Software
I'm not sure what the solution is, but IRC is lacking (and sometimes blocked at workplaces) & Slack seems to solve most of the issues, but it not wanting to support large open source communities is an issue as well. There is a hole in tools available.
Don't get me wrong, I love a great many FOSS projects; but my entire life does not need to be constructed of such. Posts like this smack of dogma and fanaticism to me, and engender mistrust of whatever projects the person in question is a part of. After all, if they're that dogmatic about one thing, then what's to say they aren't dogmatic about other things?
Today, you can look and see "Hey, Slack is a cool company. They get it. This isn't Microsoft of the 90's. They aren't going to abuse this power, they just want to make an amazing chat tool that improves all of our lives." (This is probably true) So it seems like it's ok to use Slack. The idea is that maybe this power corrupts eventually. Or maybe Slack as an entity may not always be run by people who get it. Maybe it's broken up into parts, or becomes a hollow shell as a holding company (cough Yahoo). Without an open platform and free source code, users are unable to move away.
The dogma is a rule that brings the potential long-term consequences to you when you're deciding what to do now. It gives you a twinge "Hmm, that feels dirty because it's proprietary. I'll keep looking". That way you don't have to imagine how Slack gets from Cool Company to Abusive Monopoly, you can just make an easy choice based on how you feel.
The choice I ultimately make is not always, or even often, open source. There is no blanket "always choose this" guiding rule for me.
I'm not a DD, so can't comment on how well it works - but I've had it on my todo-list s while to look at their real-world setup as inspiration.
Previously submitted to hn, but didn't gain any traction: https://news.ycombinator.com/item?id=10531061
If you're doing FOSS projects, you can probably get your way around a command line enough to install and run both of these in a $3 VPS or even an AWS instance.
Developers need to get their heads out of their rear-ends. If IRC is so great, why doesn't everyone use it?
This endless argument has been fought in multiple other products and fields as well.
Example: It's closed source.
Apparently that in itself is intrinsically "bad", and obviously so, because I've yet to see any explanation attached to that argument.
Using a closed source messaging system you never know, if 5 years down the line the company who owns you, and who is in control of your communication, decides that they would like to monetize your "contributions" to their system to synergize shareholder smileability, by adding ads to your projects channel.
Or they might want to change their pricing structure so suddenly the barrier to entry to your project is suddenly higher.
Or they get bought by google for their engineering talent and the whole thing ceases to exist.
Or they exclude the bot that you write and depend on a little bit from their network with no explanation given.
Or any other further or not so far fetched scenario in which the owners of the software can do whatever they want without consulting with you, leaving you with little alternatives.
Using a free protocol with free software, if these things happen wrt to the entity writing the code that you rely on or the the hosting of services you rely on, you're still inconvenienced, but these things do not impact you as much, because you're free to continue to use the code without the new sucky modifications, fork if if your able (or rely on some other entity taking over the code) and run the damn service yourself.
Forking and self-hosting aren't always the best solutions, but the more invested you are in a service the better they start to look.
If Slack starts doing that, and I want to continue to use my client software I'm pretty much screwed.
Ok perhaps that is a bit too harsh, but it is the essence of the argument. Its easy to get an open source tool that replaces IRC and works like Slack, you take $5M and you hire a half dozen engineers and a couple of designers and you build a set of tools and then you give it away for free and never see your $5M ever again. Welcome to the prisoner's dilemma, FOSS edition.
I've used it for a small team before but we quickly finished what we were doing and now it's dissolved. So I've been hearing awesome things about it and how people are using it and I haven't really had a chance to try it out. I've applied to join a few communities but I've never received a reply.
That process should be so much easier.
For open source projects or communities I think Discord fits the bill much better. It allows you to take part in multiple communities in one interface and you can use it without an official account.
My company installed slack and it was just like wildfire - the whole team was on it instantly and never have looked back.
If there was a client + bot setup that would offer the same functionality out of the box over IRC I'm sure we would have picked it up just as quickly. And I would have liked to be on the irc channel for a few of my favorite OS projects as well. But as far as I know, without there is no such setup?
And almost all do. Even newer ones like Elixir that started with Slack have now a mailing list and an IRC channel.
Ideally those can be the same thing; see the current Mailman interface, or Discourse, both of which can provide a forum-like interface to a mailing list.
Forums are more for new and normal users/fans of open source projects. Technical discussions happen over IRC. And even more longer insightful technical discussions (often over several days) happen on mailing lists.
Please don't repeat slack to IRC.
Well, I must admit, XMPP isn't the nicest protocol out there, and it has some issues (esp. with older software that implements it). One can't talk it with telnet client, and this is a downside. We've discussed it the other day: https://news.ycombinator.com/item?id=10900859
But it has advantages over IRC. To name a few:
- Universal federation. Private systems (that don't have S2S enabled) aside, any public XMPP server can talk to any public XMPP server. You don't need to have a separate account here, there and everywhere. Not that IRC really needs accounts (one can surely use it without signing up with NickServ etc), but sometimes it does.
- History access. Well, it requires server to have MAM (XEP-0313) support, but if it does, then everything is there.
- File transfers. Unlike Slack, it may not work for absolutely everyone but I think Jingle had gone through a lot of work and is quite capable of piercing quite draconian NATs. I'm not sure IRC's DCC is anywhere near. Well, and there's also in-band file transfers (XEP-0047) that's awful and sucks but still works for tiny content (short code snippets). And XEP-0363, although not many servers support it. XMPP's messiness has both down- and upsides.
- Integrations. I think there are as many XMPP bots as there are IRC ones. Either way, there are ton of libraries for most languages so one can hack their own simple XMPP bot literally in just a few of hours.
- Extensibility. XMPP can attach virtually arbitrary metadata to messages, or send extra information like typing notifications or delivery receipts. Well, it all depends on client support, but you don't need a committee to think of your own standard and make a ejabberd/Pidgin/Gajim/etc plugin or patch. And, possibly, think of compatibility approach for non-supporting clients. That's it. I don't think IRC has anything like this.
- OMEMO (of Axolotl/TextSecure/Signal fame). It's not mature, but one can already have multi-point end-to-end encryption for personal conversations. Sadly, not for chatrooms yet (MUC doesn't support PubSub, MUC2 aka MIX isn't yet here), but I'm sure it will work in the future.
This is a solved problem - get it together slack!
I'm on 3 slack teams, one with some former co-workers, one for a non-profit that teaches coding and one for a side project.
If any of them suggested IRC I probably wouldn't have bothered.
As it is, I have the desktop client on my Mac Mini, MacBook Pro and my Windows laptop and the app on my iPhone.
It's great. IRC is not. That's my opinion. You don't even give any good reasons why it doesn't work for open source projects.
I also like how the "IRC is better for your company" section doesn't actually give reasons as to why it's better. It instead lists multiple services you can employ to achieve the features Slack provides out the gate.
Is IRCCloud not closed source also?
 Quassel is an IRC bouncer/client combination which handles things like backlog archiving and so on properly – you can connect with multiple clients at once, just scroll up to load more backlog, use web clients, windows/mac/linux/Android/iOS clients, etc.
(The backlog lives in an SQL database, so tools like Quassel-Suche can easily query it, and you can easily export it. I personally stopped using bookmarks, and just search for links through Quassel-Suche instead)
IRC's biggest problem is what I would loosely term 'Grunginess'. Every single thing I've seen associated with IRC has this kind of Unix/Linux-y grunginess to it where nothing is easy and everybody rolls their own solution.
If you would like to experience this first hand, try setting up eir (https://freenode.net/eir.shtml) which is written in an unholy mixture of C++ and Perl. (The moment I see this combination I usually know I'm in for a ride.) Or try the python IRC library (https://pypi.python.org/pypi/irc) which has almost no documentation besides docstrings and needs to be puzzled out and examined and source-read before you can use it.
You want to be able to see messages in an IRC channel when you're not on? Don't worry, ZNC (http://wiki.znc.in/ZNC) is here to help, with powerful command line configuration action! Honestly IRC bouncers are kind of a red herring. Even if you can see what is typed in a room when you're not on using a bouncer, the real benefit of slack's message history is being able to see what's typed in a room before you joined, and being able to assume that this is a feature which is available to every slack user.
Slack's multithreading is beautiful. One of the biggest problems with running an IRC channel is that IRC is fundamentally broken. And when I say that I don't mean it in the shallow way most people do, I mean actually literally fundamentally broken. Here's why: The average human reads somewhere between 150-300wpm. A decent typist types at 60wpm. If we take 300wpm as an optimistic estimate of average reading speed, the moment you're having a lively discussion the channel is swamped at seven participants or so. Slack makes multithreading easy by associating multiple topic 'channels' together for a single group so that you can talk about one topic in this channel and another topic in that channel and it's not confusing or unwieldy, people who want to hear about certain topics can subscribe to a channel and people who don't can just not subscribe or leave. You don't have this 'stepping on each others toes' problem where three people want to talk about this and three people want to talk about that and they all use the same channel to do it.
Avatars, emoticons, that stuff is all a bit tacky but the core fundamentals of the design are a sound improvement over IRC, and IRC needs to respond to that.
A huge part of users uses now IRCCloud, or their own ZNC or Quassel setup.
And creating multiple channels is never an issue to separate topics.
- doubling as an IRC client
- providing open source projects pro level services similar to github.
“these communities are not something we have the capacity to support given the growth in our existing business.”
Though I do think they realize that getting these communities on there spreads the word about Slack and that is a good thing.
As a reverse on your first point, and something I didn't know, it looks like those folks who don't want to get rid of their IRC clients can connect to Slack:
What kind? A well organized, approachable irc client with an updated feature set to help share the things we do today. Slack has made channel based chat relevant again to a new, much wider audience. But it's not all new.
There was a time, however, where IRC made chat available to a much wider audience when it was much harder to connect.
Slack has done a nice job of positioning themselves near creating beginners and deserve the success from doing so.
I'm not sure how much more overhead open source communities would be over the free plans that already exist. Interesting to see that you can use an irc client to connect to slack.. just not sure why I couldn't use slack to do even more of my communicating in one place to be an irc client.
So many things are better than IRC. Even Jabbr.net is better.