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