Reasons Not to Use Slack for Free Software Development

Contents
* Introduction and summary
* What is Slack? (A proprietary centralized communications hub web service )
* Free alternatives exist to the proprietary Slack
* Automattic/WordPress is sending the wrong message about free communications software
* Slack can change its TOS at any time
* Slack can cut you or your community off at any time
* You need to be online to use Slack
* Slack copies the contents of secret URLs
* Slack makes government surveillance easier
* Slack is a single point of failure for your community
* Slack's privacy policy guarantees very little
* A democratic government is a special case of a free and open source community
* Slack is focused on teams, not communities
* Slack limits are not advertised (like 5000 users maximum per "team")
* It costs a lot to search or delete older messages
* Your Slack discussions for free software projects are not public or findable
* Slack private messages may not be very private
* Slack may change ownership at any time
* What if Slack went free/libre and open source?
* Standards unify; incompatible services fragment
* The cost of changing later can be high
* Matrix.org is a better way forward
* Would I ever use Slack? Sadly, yes. :-(

Introduction and summary

I recently turned down a job interview with Automattic, that I had literally waited months for them to schedule, because they insisted I use Slack for the interview and have switched WordPress.org development over to using Slack. Automattic used to use IRC and Skype for such prospective employee chats and for WordPress.org developer chats. I had hoped to add a real-time component to WordPress via Node.js and Automattic's socket.io to help make WordPress into a premier platform for real-time communications, decision support, and sensemaking, and said that in my application. To me, using Slack to interview with Automattic felt like it would have been significantly inconsistent with my stated goals for my work there. Readily agreeing to use Slack at Automattic just for an interview would also indicate tacit approval of Automattic's move to use Slack for WordPress.org as if there are not significant consequences for the WordPress community (a community which I am part of as a WordPress plugin developer and as a WordPress.org Trac participant helping identify and fix a significant WordPress core bug).

It had taken me me weeks to write a no-doubt overly-long and overly-enthusiastic 180-page job application document as essentially a programming and FOSS autobiography intermixed with ideas about how what I had learned over the years could help Automattic (or, to some lesser extent, any other large FOSS effort, including Drupal/Acquia). So, that was a lot to walk away from as a time investment over something as silly-seeming as getting a Slack account for an interview. I enjoyed writing that application document overall, and I still hope some of the ideas in it can still help Automattic grow even more in a FOSS direction. That document is at least something for my kid to perhaps read someday many years from now. Of course, my kid may just read it and then say, not without significant justification, that I probably should have put the principle of family ahead of other principles in turning down any significant chance for a six-figure salary work-from-home job on FOSS. :-(

Naturally, I'm now biased by cognitive dissonance to defend that choice related to Slack. :-) Still, I can hope that if the global software community argues well together about this issue of using Slack or other proprietary SaaS offerings in free software projects, we may together eventually come to a good understanding of the situation. Perhaps some of what I say below is perhaps inaccurate or inapplicable (especially with me not being a Slack user yet, although it is probably only a matter of time before I end up becoming one for reasons of financial survival if more companies adopt Slack). Feel free to blog about this issue in your own way on your own sites, agreeing or disagreeing with any of it as you see fit. :-)

As a summary, the main issues in using Slack for free/libre software projects include:
* Proprietary vs. Free; free alternatives exist like Mattermost and Matrix.org and others
* Sending the wrong message about free software communications out of convenience
* Reduces interest in free software and public standards for communications
* Changeable Terms of Service
* Arbitrary termination of access possible with no archive
* Online requirement to access your previous messages
* Retrieves contents of all URLs you include in a message by default
* Centralizes communications in an unencrypted form
* Could inject malware, advertising, or disinformation from the central hub
* Privacy policy does not seem to prohibit much data mining
* Inappropriateness for large communities (design, limits, costs, privacy, archiving)
* Your messages may become controlled by a purchaser of the Slack company
* Standards like email or IRC unify, but services like Slack fragment the global free software community
* Matrix.org looks like a better choice of standard to support

Some of these issues also apply to any organization choosing to use a proprietary centralized third-party platform for communications. Others are perhaps ignorable by some free software communities (like data mining risks if they work completely in the open anyway).

These issues imply some principles and rules for free/libre software projects, which ideally:
* should use free software tools even if such tools are harder to use at first and need investment to make them better
* should expand to cover new niches when feasible
* should promote other free software projects and open standards, not proprietary ones
* should not ask users to agree to arbitrarily changeable terms by third-parties
* should not be at risk of having all their communications made inaccessible
* should support off-line browsing of their works
* should not access the content of URLs passed around except on request
* should be decentralized as much as reasonable
* should reduce the risk of single points of failure in society
* should use tools that respect privacy
* should use tools that can scale easily, cheaply, and which can support public archives
* should not put users at risk of having arbitrary new third-parties control their content
* should support unifying standards
* should be on the lookout for emerging free technologies and standards they can build on

Now, not all free/libre software projects might follow all these rules and principles, depending on how much they are works of expediency versus works intended to support a free/libre culture. For example many FOSS projects use proprietary IDEs or use things like GitHub issues or JIRA (proprietary services). But the further free software projects get from these sorts of ideals, the more problematical the situation becomes.

Below are some notes with more details on these major issues that go beyond what I sent Automattic. I don't even include all the points I sent Automattic here though, some of which were more specific to that company.

This essay is inspired by, and builds on, Drew DeVault's essay "Please don't use Slack for FOSS projects". Thanks for being one of the first to take a stand on this issue, Drew.

Richard Stallman also asked some insightful questions which contributed towards these answers, and asked me to write thirty lines on this topic. This is not really what he asked for, but maybe someone else can summarize this and rewrite it into thirty lines? I put it under a CC-BY-SA license to facilitate that.

He (RMS) has also pointed out this essay would be much better if it distinguished between whether issues related specifically to a non-free client application (which could be fixed by the efforts of free software developers), and issues relating to the proprietary nature of the service (which could not be fixed). After all, free software developers do routinely make free software that interfaces with proprietary services (e.g. Google GMail or Amazon S3). Such Cloud and SaaS systems may present issues (centralization, privacy, running proprietary software on other people's computers), but they are somewhat different issues than strictly client-side free software issues. I agree this is an important distinction and this essay would be better if I had made it (and I might revise it to add that at some point). That said, since the current Slack API TOS prohibit using the API to make competing products, it is not clear to me that free/libre Slack clients are possible without violating the Slack API TOS, which may make that distinction moot. A FLOSS Slack client both replaces the proprietary Slack webapp which Slack might decide to add advertising to at some point, and such a client also could easily support competing messaging services (like Matrix.org). The legality of the Slack API TOS prohibiting such use may eventually need to be tested in court, but that is not a prospect for any free software developer to look forward to given the uncertainty of what happens to their personal finances and free software in the meanwhile.

A big concern prompting my writing this essay is the fact that Automattic's move to Slack is now being used to pressure other free software communities like Drupal to move to Slack. This essay is in hopes of heading that off.

--Paul Fernhout

What is Slack? (A proprietary centralized communications hub web service )

Slack is a company with a proprietary webapp and backend service (also called "Slack") currently running on AWS servers that uses a proprietary API for messaging (although in a human readable JSON-based protocol). Slack stores all the messages you send to other Slack users on those centralized servers in an unencrypted form so the messages can be searched by you and others (including Slack itself for data mining). Slack the company claims (with some justification) Slack the service is easier to use and manage compared to IRC (if you use only Slack for all your communications), especially for teams in medium sized business. This is mainly because Slack is a pre-installed "software as a service" (SaaS) and supports some features email has but IRC does not like embedding HTML and images in chat messages. Slack also supports scrolling back through old messages and search, which IRC as an API does not (but email clients or some IRC clients do).

Slack has obtained US$340 million in investments, a lot of which could be used for advertising and US$80 million of which Slack is planning to invest in other companies developers to integrate their services with Slack, so expect to see a lot of Slack hype over the next couple of years.

As Richard Stallman says about Skype and I feel applies equally well to people handing out Slack invitations:

A nonfree program denies users freedom, which is unjust in itself. Making the ethical issue sharper, for you to use Skype is to encourage someone else to use Skype, which means you're pressuring someone else to surrender freedom as well.

Free alternatives exist to the proprietary Slack

Slack is a proprietary software similar to Skype, Google+, or Facebook, and free alternatives exist (Mattermost) or could be created in an even better way (as with Matrix). You can't run Slack on your own hardware at any price. You can apparently export your Slack project to Mattermost, which is free software.

MatterMost also integrates with GitLab, also free software. As GitLab wrote:

"Many larger organisations run all software on-premises, often because of security, scale and control. Since Slack doesn’t offer an on-premises version, we searched for other options. We found Mattermost to be the leading open source Slack-alternative and suggested a collaboration to the Mattermost team."

For many small to medium-size companies or non-profits, there can be business value in using Software as a Service (Saas) that someoen else hosts. Many small organizations do not have the IT staff needed to maintain, secure, and update communications software, whether a simple website or a more complex chat system. Thus the value in services like WordPress.org or DrupalGardens, or that of multiple third-party email hosts or website hosts.

However, even when outsourcing such services makes sense, picking a proprietary application using a proprietary API for a fundamental cross-organizational need like communications is very problematical for multiple reasons listed here.

Even Google Gmail, a centralized email system, supports a global standard (email). If you hooked GMail up to your own domain name, you can even switch from it to another provider and keep the same email address. You just can't do that with Slack.

Automattic is in the business of promoting FOSS communications tools and encouraging contributions by FOSS developers, a mission which, to me at least, is undermined by promoting a proprietary communications tool like Slack.

Automattic/WordPress is sending the wrong message about free communications software

A free software project like WordPress choosing to abandon IRC and choose Slack for free software developer chat sends a message that free software is not good enough for regular communications and is not worth investing in to improve to meet whatever needs the proprietary software meets. That has a negative impact of the future of free software projects including ironically even WordPress. That was perhaps my single biggest concern for Automattic's use of Slack and so not wanting to agree to use Slack for a job interview at Automattic.

See WordPress.org's statement about why they moved to Slack at: https://make.wordpress.org/chat/

WordPress.org's move to Slack by Automatic's choice is now being used to pressure other free software communities like Drupal into adopting Slack. See (also mentioned in more detail later): https://www.drupal.org/node/2490332

This is in some ways equivalent to the BitKeeper vs. Git issue, as Richard Stallman wrote about:

"For the first time in my life, I want to thank Larry McVoy. He recently eliminated a major weakness of the free software community, by announcing the end of his campaign to entice free software projects to use and promote his nonfree software. Soon, Linux development will no longer use this program, and no longer spread the message that nonfree software is a good thing if it's convenient. McVoy's great triumph was the adoption of this program for Linux development. No free software project is more visible than Linux. It is the kernel of the GNU/Linux operating system, an essential component, and users often mistake it for the entire system. As McVoy surely planned, the use of his program in Linux development was powerful publicity for it. It was also, whether intentionally or not, a powerful political PR campaign, telling the free software community that freedom-denying software is acceptable as long as it's convenient. If we had taken that attitude towards Unix in 1984, where would we be today? Nowhere. If we had accepted using Unix, instead of setting out to replace it, nothing like the GNU/Linux system would exist. ..."

Few free software (GPL) projects in the communications space have more visibility than WordPress, which runs about a quarter of the world's websites (according to Automattic). That is why promoting Slack by Automattic is so tragic. Automattic is in the business of promoting FOSS communications tools and encouraging contributions by FOSS developers in order to "make the web a better place". That is a mission which, to me at least, is undermined by promoting a proprietary communications tool like Slack. A big selling point of Automattic's services vs. say Wix or SquareSpace is that Automattic is a company specializing in reliable FOSS-based communications with open import/export standards and expandable with plugins and so on. It sends a very mixed message to the WordPress community when Automattic then starts promoting proprietary communications software as (implicitly) the best thing -- even going so far as to claim Slack is more "open" than IRC.

As an analogy, consider Seed Saver’s Exchange whose mission is “Saving America’s Heirloom Seeds”. Such seeds are free and open source in the sense that they are not covered by copyrights or patents, and you can save your seeds from this year’s crop and grow from them the next year’s crop (which you can’t legally do with a lot of commercial seeds now). As they say in their story, “Diane and Kent went on to form a network of gardeners interested in preserving heirloom varieties and sharing seeds. Today, with 13,000 members and 20,000 plant varieties, Seed Savers Exchange makes its home on 890 scenic acres in Winneshiek County, Iowa, at Heritage Farm.” Now, imagine if Seed Savers decided to “improve” those acres to make them more “open” to stakeholders who were coming for a big get together to create the future of Seed Savers. Imagine, to spruce up the place, Seed Savers replaced all the flowers by the main buildings with commercial proprietary flower varieties because they were easier for gardeners to get and cheaper to buy. Imagine they served only GMO produce from Monsanto at the get-together because it was likewise cheaper and easier to get and such food had some advantages claimed by Monsanto (a major developer of proprietary GMO seeds). Imagine they even announced a big partnership with Monsanto at the get together and on the CEO of the organization’s blog. And, imagine Seed Savers paraded these decisions in front of stakeholders of evidence of how hip and cool and “open” and heirloom-gardener-friendly they were being, and said that using Monsanto products at the heart of their operation did not matter to their mission because they were still growing heirloom seeds in the actual fields. And imagine people came along to suggest trying new varieties of free and open heirloom seeds to meet whatever needs Monsanto was supposedly meeting and just got told there was not enough time or money to consider that. How many stakeholders do you think would walk away from that stakeholder meeting shaking their heads in bewilderment? Or worse?

Slack can change its TOS at any time

Slack requires signing up and agreeing with a long Terms of Service (TOS); the TOS can be changed at any time, and historically such TOS have changed for the worse over time for other services once a lot of users adopt the service and become locked in by inertia and interlocking usages with other groups.

The Slack API TOS specifically currently prohibits using the Slack API to compete with any Slack core service. They say:

"You may not use the Slack API to replicate or compete with core products or services offered by Slack. You acknowledge and agree that Slack has or may in the future offer products or services that are similar to your Application, and nothing will prevent Slack from doing so...".

This could be seen as prohibiting even discussing Slack alternatives on software gatewayed into Slack for notification. Agreeing to an arbitrarily-changing TOS when you want to develop free communications software is just not a prudent thing to do for a free software developer, which was a personal reason of mine for not wanting to use Slack, since I would like to write free software (like Twirlip https://github.com/pdfernhout/Twirlip2 ) that competes with Slack as far as supporting all sorts of (near) real-time messaging (whiteboards, chat, NarraFirma, structured arguments, IBIS, etc.). BitKeeper, for example, prohibited using BitKeeper for developing BitKeeper alternatives.

Automattic is agreeing to, and essentially forcing thousands of free software developers to agree to, a Terms of Service agreement which Slack can terminate or change at any time. Given Slack is potentially a competitor to Automattic in the communications space, that seems problematical to me, given the TOS might be recrafted specifically to harm Automattic, or for that matter, free communications software.

For Automattic, there is a potential concern about Slack's TOS saying you can't use Slack APIs to compete with Slack and Slack can take your product ideas and do what it wants with them. applies potentially for Automattic and their WordPress integration with Slack.

Any organization, especially a governmental one, might want to have lawyers review the Slack TOS first, including in an employment context of what requiring Slack use is actually asking employees to agree to (especially given the terms can be changed at will by Slack).

Slack can cut you or your community off at any time

Slack can terminate the Slack service or any user at any time for any reason with no recourse (or at best, individual arbitration, preventing class action lawsuits). Remember when Twitter got rid of regular RSS feeds for tweets after everyone became dependent on Twitter as a core internet service? Letting your free software community become dependent on such a brittle resource is just unwise in the long term.

A big organization might be able to get some service level agreement; I don't know what is possible there.

You need to be online to use Slack

If you are not online, you can't access your Slack messages from your web browser (not sure about the mobile apps). Further, if you participate in a community and are dropped from the community, you lose access to your whole communications history with that group (unlike an email mailing list).

Slack copies the contents of secret URLs

Slack by default requests a copy of the content of any URL you include in a chat message so it can profile the contents to add summaries to the message. This means if you are using random unguessable URLs for communication, Slack has a copy of all that data. Slack calls this "unfurling":

"Note that our servers need to fetch every URL in a message in order to determine what kind of content it references. If you'd like to stop this from happening, set both unfurl_links and unfurl_media to false when posting the message."

Slack makes government surveillance easier

Slack centralizes communications in a non-encrypted searchable form making government surveillance trivial, and thus further altering the balance of power between citizens and government.

Slack is a single point of failure for your community

Slack could potentially inject unwanted messages into your message stream from a single global central server system (advertisement, disinformation, malware, whatever). Still, that is true for any centralized service. But as Slack aspires to completely replace IRC and other forms of chat and shared messaging (including screensharing), and has a lot of money to promote itself, this is still worrisome.

Also, if Slack is down, your community is down.

If Slack goes out of business, your community or business may go out of business if you are completely dependent on it, including for access to your organization's shared knowledgebase.

Slack's privacy policy guarantees very little

Slack' privacy policy does not prevent much data mining by Slack or for anyone who might pay them, and Slack is hiring data mining experts. This puts at risk users who rely on Slack but expect privacy. This risk is probably not the sort of thing free software developers interested in social change should be promoting.

From Slack's policy as of 2015-01-04, which they can also change at any time:

"To make the product better we have to understand how users are using it. We have a fair bit of data about usage and we intend to use it many different ways to improve our products, including research. This policy is not intended to place any limits on what we do with usage data that is aggregated or de-identified so it is no longer tied to a Slack user."

And then consider a current job description for a "Data Analyst" position at Slack:

"Apply your expertise in quantitative analysis, data mining, and the presentation of data to inform and influence product and business decisions"

Automattic is putting all its confidential information into a third-party system run by essentially a competitor in the web communications space with a privacy policy that does not seem to prohibit any sort of data mining of significance (like to summarize or "aggregate" all the internal discussion by Automatticians).

This privacy issue applies to any organization IMHO. It seems to me (not being a lawyer), that such a vague TOS by Slack might be sufficient grounds for, say government organizations, to, as a whole, never adopt Slack without substantial changes to such policies by Slack. Unless, essentially, government officials are comfortable with all the messages they or their staff ever sent potentially being reviewable by arbitrary third-parties for commercial gain or political gain without their knowledge? I think the answer there would probably be "no". :-)

For example, imagine if one group of officials from one political party paid Slack to data mine all the communications of another group of officials from another party? Whether the TOS permits it now (and I think it probably does permit that to some extent, even if Slack might be ill-advised to take money to do that), the TOS might permit it next year.

You also don't know who might buy Slack soon (Facebook, Google, Microsoft, IBM). What are the potential legal issues if a regulated business like IBM buys Slack and now has access to all the government's internal discussions about IBM or some other company? What if a billionaire individual like, say, Bill Gates or Tom Golisano buys Slack (or some chunk of it) so he can have a peak inside into internal governmental discussions about himself and his corporate holdings?

Now, personally, in some alternative reality, I might see someone making an argument that all government communications or even corporate communications of any nature should be on the record and easily publicly inspectable. I'm not saying I advocate for that because the practical consequences might be unmanageable in our current society -- just that I could see an argument for it in some hypothetical alternative reality. If the government decides to adopt such a complete transparency policy though, then Slack use might make more sense, given Slack is part of the public and so preferential access does not apply, even if Slack might not be the best way to make all government or corporate communications publicly available. Even then, asking citizens to agree with an arbitrary third-party TOS from Slack to review everything a public official or CEO or their staff has ever said to anybody itself is still problematical. But at least then we would just be talking accessibility, not fundamental privacy expectations or political balance of power.

I myself would not prefer Slack for any sort of communications one might want to have a record of like design documents or whatever. It is also not prudent to use Slack for communications one might not want an arbitrary third-party to have. Yet, I send emails around with ideas, and I know email is like a post card as far as data protection. I don't have much faith in encryption in practice, either. I assume all such communications are logged by multiple third-parties. There's even a small part of me, a part interested in history and archiving, who hopes that is true, so in 100 years people (and/or AIs) can learn about these "interesting" times we are living through. Assuming the logging consequences themselves taken across society (including both political and psychological aspects) were not seriously bad, which they might be. :-( Most of the work I do, I do in public whenever possible, since why pay the price of hiding stuff when the government and your connected and perhaps underhanded competitor probably has it all anyway? So, a bunch of these privacy concerns to me specifically are more about the principle of privacy than the practice, as well various unintended consequences of making data aggregation easy -- which is what Slack is designed to do.

By contrast, I'd suggest a lot of public officials or corporate executives might feel differently about that privacy issue in practice if they or their staff thought at all about it or the implications if Slack changes hands. But, I could easily be wrong about that; people take so many things about the web for granted now and just assume things about it being private. They do that even when they should know better, like with the Anthony Weiner scandal.

Of course, all systems have weak links (often the people involved, even if the software is perfect in some sense). I can also see the case for some organizations deciding they would rather trust some third-party with terrific data security teams to secure their information than, say, a locally-hired part-time IT consultant. And even teams of full-time well-trained professionals make mistakes (like with Steam's recent caching issues). So, this is not a black-and-white issue for many small businesses who might, in that sense, actually have more privacy in practice with Slack (ignoring Slack's data breach in March 2015 of course). The same argument can be made for Google's or Amazon's servers as well or other cloud technologies.

But somehow centralizing all the world's private instant messaging in Slack in an easily searchable unencrypted form (apparently the goal of Slack) feels different to me than spinning up an AWS EC2 instance to host a public website. Slack just poses a very tempting target for cybercriminals.

Also, even if you like Slack and want to outsource hosting for it for IT reasons, why not get a reliable third-party to host the FOSS Mattermost software for you instead, to avoid vendor lockin? If your host proves problematical or cuts off you arbitrarily or violates your privacy, you can then always move. That is the Automattic/WordPress.com business model, and it seems a sensible one to me.

A democratic government is a special case of a free and open source community

Many government officials might perhaps just shrug and say they use Facebook and Skype and SnapChat and so what is the issue with one more third-party service like Slack?

If you look at Slack solely from the point of view of public officials communicating with constituents who want to use it, it is hard to say there is any issue with such use given emerging practical necessity. If that is the way constituents want to communicate with their elected or appointed officials (instead of other proprietary services like Facebook or Skype or WhatsApp or open standards like email or IRC), it is indeed irresponsible-seeming to say no to that. That can be true even if one can still make a conceptual argument for supporting communication standards and not services.

However, even given the above point, as a personal opinion, I feel a democratic government, considered as a whole, is, in a way, a special type of free and open source community given a public interest mission which includes encouraging civic participation. Thus, like any FOSS community, a government should always lean strongly towards supporting free and open standards for communications.

As Professor Eric von Hippel of MIT suggests, typically 80% of significant product improvement ideas come from the user community in some contexts. Government choices of what software to use can have enormous impacts as to how many people use these systems, and thus how many people make suggestions about them as an informal "free and open source" community of ideas -- or who help improve such systems either as part of their jobs or on their own time out of fun or a joy in service. So, who is going to be getting all those improvement ideas coming from government employees or other citizens? And can such ideas be acted on in-house if needed?

In the internet age, free and open source software provides a way to distribute value to the public at no incremental cost. That is one reason why it makes sense for digital public works funded by tax dollars and charitable dollars to be accessible and free to all. Proprietary companies can then build on top of free and open source software if they so choose, as can anyone, with a level playing field. Since much of what government workers (at least at the Federal level) is in the public domain, ideally the ideas they contribute as users should be towards free and open systems anyone can build on.

Essentially, the government's choice of any proprietary communications platform is providing a huge subsidy to any product in terms of Quality Assurance (QA) and user-suggested improvements. It is unfair to other commercial competitors (or would-be competitors), if the government provides such a huge non-financial subsidy to just one commercial company. It is also unfair to the FOSS projects in that area, given the commercial competitor will likely be using software patents and other monopoly advantages to disrupt competitors whether FOSS or proprietary. By choosing FOSS communications tools, at least the government is providing that non-financial QA and innovation subsidy to, essentially, the public knowledgebase, creating a more level playing field for all communication tool developers who can then draw from that public knowledge.

Since citizens have many different preferences and needs as to how to communicate, ideally government systems should be based on accessible open standards supporting many different types of clients (like email and IRC do).

Since governments discuss many sensitive matters, they should always have the option of hosting such discussions on their own equipment to their own standards -- or choosing (via a publicly accountable process) a specific trusted vendor to host a specific system meeting specific requirements including supporting open standards and without vendor lock-in.

As the US GSA's 18F Group advocates, free and open source software makes a lot of sense for government IT acquisitions.

So, a government organization should require a high bar of justification for adopting a proprietary communications system for any purpose, especially a proprietary systems where content is controlled by a non-governmental third party (whether Slack or anyone else), given communications is at the heart of most government activity.

It may be OK and even desirable as above to support proprietary systems like Slack (or dozens of competitors) as needed for interoperation with the world beyond government offices, but proprietary systems are problematical at the core of governance (at any scale).

Slack is focused on teams, not communities

Slack focuses on small teams and central administration, but free software communities are more open and decentralized.

Slack itself is not well designed for broad communities with different roles for users. See for example what a Slack competitor called Ryver has to say about about Slack:

In today’s world, most teams are not limited to internal employees. Real-world team communications are fluid, constantly changing, and often require input from many stakeholders and non-employees, such as:
        • Important customers
        • Contractors
        • Vendors
        • Partners
        • Advisors
        • Investors
In most cases Slack makes you pay for each user and limits how many guest accounts you get and what they can do. Having to pay for each user means you tend not to invite a lot of people you’d like to have on the Team. This friction is like throwing sand into an engine. You need to have the freedom to invite anyone you want and not worry about money.

Slack limits are not advertised (like 5000 users maximum per "team")

Slack limits are not advertised. For example, the React project and the freeCodeCamp projects both abandoned Slack after trying it and hitting some unadvertised community size limit of 5000 users per team after which they were told to split up their community into multiple independent teams:
https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to-discord.html
http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-and-we-deeply-regretted-it.html
https://news.ycombinator.com/item?id=9754626
http://www.businessinsider.com/slack-free-unlimited-plan-has-limits-2015-6

From the freeCodeCamp post:

"In my desperation, I tried to manually send out the invites. That's when I was confronted with an ominous message: "You have reached the maximum number of users". My heart sank. Our contributors had sunk so many hours into building Slack features. We'd endorsed Slack to thousands of people on our Twitch.tv streams, and even mentioned it in interviews with the media. We were heavily dependent on their service. In a cold sweat, I started googling. There was literally nothing on web saying anything about Slack having a maximum number of users - only marketing material saying that free tier organizations could have as many users as we wanted. Apparently, we were the first community to ever hit Slack's undisclosed limit. ..."

Supporting millions of users communicating with each other via different preferred clients may just require a fundamentally different conceptual architecture than Slack uses to support small teams (perhaps more more like the kind of thing email with mailing lists does).

It costs a lot to search or delete older messages

Searching old messages past 10,000 (easily reached quickly in a big community) or *deleting* messages in a big community is not free-as-in-beer.

Slack is actually quite expensive for free communities at $8 per user per month as the lowest price point. At 500 users in a community, this would US$4,000 per month for a free software community that wanted to have complete archives available to Slack users.

Your Slack discussions for free software projects are not public or findable

Most free software projects want to be "on the record" with their discussions (at least, most of them). How can I now look at old developer chats about WordPress done on Slack? I just can't. Previously, there might have been public IRC logs, or I could have used a service like IRCCloud or set up my own software to log the WordPress developer IRC chat messages for me without agreeing to the Slack TOS.

Slack archives are not accessible publicly, unless each user who wants to see the archives signs up with Slack, which raises the cost per user (compared to say, just using GNU Mailman and Pipermail archives).

It looks like you could setup the new "SlackArchive" service to make Slack discussions publicly viewable, but now you are using yet another proprietary service to host your data.

There also seems to be "CloudPipes" to search Slack chats, as another proprietary service? I don't know how it works or what the limits are.

Since the Slack TOS prohibits competing with Slack, and Slack might move into these areas with paid services, how long will SlackArchive or CloudPipes' Google-to-Slack service even be around before Slack cuts off API access?

Slack private messages may not be very private

Administrators in some Slack configurations can see all private messages. This may be OK or even needed in some business contexts, and there is notice, and such terms could be rejected (by not using Slack or participating in the community). However, the Slack TOS as above could always be changed to not require notice.

Slack may change ownership at any time

Slack may be purchased at any time by another company (Facebook, Google, Yahoo, Microsoft, Apple, a hedge fund, a patent troll), meaning you do not know who will have a copy of your communications tomorrow, how such a new company will change the TOS, or what such a new company will do with any software you build onto Slack.

What if Slack went free/libre and open source?

Slack might also become FOSS and hostable at multiple places like Mattermost. If so, much, but not all, of my concerns outlined here would not apply.

Still, even then, as with Mattermost, I'd suggest such systems should ideally use some common communications backend that acts like Matrix.org (discussed below).

Standards unify; incompatible services fragment

Given other services that compete with Slack, there is a fragmentation issue and incompatibility issue, where free software developers may then have to sign up for many proprietary services if free software projects pick different proprietary services. See a list of such services here:
http://www.jordanhawker.com/posts/131477030371

What proprietary communication service should a free software community choose when, eventually, there may be dozens of proprietary Slack clones to choose from and none of them interoperate? Shouldn't the ideal answer be, "none of the above", and let's use a common standard like email, IRC, git, or something even better (like Matrix.org)?

Here is another link related to Slack and free software from the (GPL) Drupal community; see especially the comments:
"Evaluate whether to replace drupal IRC channels with another communication medium"
https://www.drupal.org/node/2490332

That topic's title was first something like "Replace IRC with Slack or Open Source version" until some Drupal community pushback.

From there:

Other open source projects still using IRC besides Drupal

        Fedora Project
        GNOME Desktop
        Asterisk
        linux
        python
        debian
        ubuntu
        git
        vim
        puppet
        bash
        docker
        postgresql
        nginx
        php
        Ansible
        mysql
        sensu
        OpenStack
        Mozilla
        Ruby On Rails
        @todo add additional examples

Open source projects using slack

        Wordpress increased the number of connected people 4x when switched (doesn't necessarily mean 4x the participation) @todo add a link to source of statistic. Their #wordpress support channel still remains only on IRC.
        @todo add additional examples

I was pleasantly surprised to read that list. :-)

Also from there, it at least there is a chance Drupal might stay FOSS with its communications as a possibility:

Proposed resolution

Possible solutions include:

        Waartaa is an open-source solution with a responsive web interface based on the MeteorJS library for browser-to-server communication and syncing. It connects to IRC on the back-end, giving users the choice of using the web interface or a traditional IRC client
        Slack, SASS. It meets most, if not all, of the requirements listed.
        Lets chat, F/OSS. Node+Mongo, meets many of the requirements listed, but not as integrated or used as slack. Also needs to be hosted locally.
        Hipchat, SASS. It meets many of the requirements listed. 3rd party integration.
        Mattermost
        @todo add additional proposals here

Unfortunately, the only "risk" listed up top on that page so far is:

"Some people might dislike new chat client, especially if it requires running an application just to communicate with the Drupal community."

As this essay shows, there are a *lot* more risks than that one. I don't even list that as a risk myself here. :-)

At least one commenter there (Antti J. Salminen) though adds:

"Personally I really do not want to see this happen. Thank you for the well-thought summary as it already has many of my objections covered. I'd add that IRC being an open protocol with huge amount of open source support means it's extremely flexible. Making chat participation easy can be achieved building on top of IRC. It's possible to set up all kinds of web-accessible interfaces and even gateway bots between different services so I'd argue things can be improved without a migration to something else. There are also ways in which these tools like Slack/Hipchat raise the barrier of entry rather than lower it. Most of them, like Slack, require registration. Everyone stays on their own little island that you have to separately register to. With IRC there is no registration and with so many open source projects on Freenode you may well already be set up to just join another channel. I wasn't convinced by the arguments put forth by the WordPress team at all. The only one that I do think is a good point is about the maintenance overhead. Regarding the WordPress participation: I think it's too early to assess the impact fully. The claims I've seen about increased participation were also made a pretty short time after the move so I'd like to know what's the latest on that."

As implied in the comment there from Antti J. Salminen, there is a huge difference between a *standard* everyone uses (email, IRC, whatever) and a *service* everyone uses (Google+, DropBox, Slack, HipChat, whatever). Standards bring people together (hopefully), services can pull them apart through fragmentation as services all try to lock people into into walled prisons. Granted, free standards is not exactly a free software issue specifically, even though you would hope free software developers would know better by now.

Still, despite that, there are indeed many things about IRC people don't like. There is a need here, no doubt. So, the circumstances are ripe for change, as they were in source control when people were getting tired of CVS issues, especially in far-flung distributed FOSS communities. But change to what?

Email is really a problematical way to discuss complex nuanced issues, as is chat. It is hard to track points and counterpoints and so on. The free software community could benefit from structured arguments and multi-perspective analysis about what technology platforms to use and why. :-) I'd even like to build such tools (based on ideas from the intelligence community).

Automattic was really on to something using IRC and internal advanced P2/O2 blogs instead of email for most of its internal work. But Slack is now starting to take all that over, and probably less flexibly than when content is hosted on WordPress and plugins are supported.

Of course, there may eventually be dozens of such Slack competitors, better or cheaper in various ways. So, I don't envy Automattic having to sort that all out or handle all the bridging and incompatibilities when, say, MariaDB decides to use Ryver, and Reactiflux is using Discord, and freeCodeCamp is using Gitter, and some key WordPress plugin developers decide to use some other proprietary walled garden like an improved HipChat, and then those groups all want to talk to each other. I guess it will be back to email or IRC then? :-) Or maybe everyone will just get an account for each of dozens of webapps -- although then what webapp will you decide to use to decide where to host your future talks etc.? :-)

Hey, I suddenly see a new WordPress plugin idea! :-) A WordPress plugin for deciding what proprietary communications system to use for every business conversation (AVAILO, Bitrix24, Campfire, ChatGrape, Clubble.io, Discord, Fleep, flock.co, Flowdock, Fuze, Gitter, Glip, Hall, HipChat, Microsoft Lync, Pie, qiscus, Ryver, Slack, Skype, SVYFT, Triplecube, Wiggio, Yammer, etc.). Maybe it could have a bidding/auction brokering function and so on so people could put money behind their preferences for each cross-community discussion? And I could take a penny for each transaction? My millions are made thanks to Automattic and these other businesses balkanizing themselves! :-)

And no doubt these lists will grow, so my plugin will be in tremendous demand soon. Maybe my billions will be made! :-)
http://beebom.com/2015/04/slack-alternatives-for-team-communication
http://alternativeto.net/software/slack/

On the other hand, many such services may fail, like Kato which died on August 31, 2015 -- taking all your organizational memory with it unless you exported it first, and even then what can you easily do with the export?
http://venturebeat.com/2015/07/13/chat-app-kato-will-shut-down-on-aug-31-because-slack/

"WHY... In short — Slack ate the world and we failed to gain traction. Our SAML- and SCIM-enabled enterprise product had no takers from larger companies. he unique Kato features that made it stand out from the competition—proper multi-team support, swim-lane multi-chat design, great search, Vim-based keyboard shortcuts, the fast-forward button (esp. on mobile), and flexible group mentions—weren’t unique enough to get a critical mass of people publicly excited about the product.

All this forced us to stop working on Kato in January—we “pivoted” the company to Sameroom.io, the multi-protocol gateway that connects chatrooms across services.

We were hoping to keep Kato running on autopilot indefinitely—to wait things out, but our software eventually disagreed: the service started getting sick, causing annoying issues on a daily basis.

Since we are committed to operating with 100% uptime and we can no longer give it our best effort, we have to kill Kato. It’s a pity."

Sadly, frankly, brokering what proprietary services to use is not the business I want to be in though, helping smooth over a Babel of proprietary systems as opposed to replace them all with free software and open standards (whether Mattermost, eXo, Hack Chat, Kandan, Kollab, kune, Let's Chat, Rocket.Chat, Twirlip, Zulip, or improvements to email, IRC, Matrix.org, or other standards). So, once again, my millions and billions slip away. :-) But financial obesity can be pretty ugly as a social thing, anyway. So, maybe I am better off to avoid it.

Also, as Kato said in their Swan Song, it looks like they then created sameroom.io provides a paid service to bridge some chat systems, and likely they would just compete with such a plugin in various ways. Of course, when you use sameroom.io, presumably you are now trusting yet another specific (potentially aggregating) third-party with all your bridged external communications (apparently the same one behind the failed Kato).

That makes me think of another billion dollar idea. :-) There are bound to be proprietary bridging competitors to sameroom.io. So, I could create a WordPress plugin to use to bid on what proprietary bridging competitor to use for any specific external communication...

Or, again, I could just try to help support free and open communication standards like email, IRC, Matrix.org, and similar things... :-)

The cost of changing later can be high

It may now be very costly for Automattic to move away from the proprietary Slack software which it has now widely promoted. Just think of all the Automattic employees and thousands of WordPress.org participants who would also have to change the tools they use. Automattic has by now also created multiple bots and such that integrate with Slack. That all will be used to justify not changing from using of Slack now.

As far as Automattic’s new cost/debt issues moving away from a proprietary service like Slack, that is the exact reason to avoid such proprietary services in the first place. :-(

Everything people suggest along those lines of a big cost of switching is, to me, proof of what I’m saying is true. :-)

And that’s the reason a lot of people use FOSS WordPress over Wix or SquareSpace or whatever as a primary community communications platform, even, and perhaps especially, if they choose to host WordPress at WordPress.com. :-) Knowing WordPress.com users could easily leave is an incentive for Automattic to keep innovating and stay responsive. What is Slack's incentive to keep innovating or stay responsive after they have locked you and all your friends in?

Matrix.org is a better way forward

A much better alternative is to support Matrix.org. See for example this Hacker New discussion of the Drew Devault article ("Please don't use Slack for FOSS projects"), which mentions free alternatives to Slack: https://news.ycombinator.com/item?id=10486541

Some posters mention Matrix.org as an alternative. Here is more information about it:
http://www.matrix.org/
http://www.matrix.org/docs/guides/faq.html

"Matrix is an open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers. ... Matrix’s initial goal is to fix the problem of fragmented IP communications: letting users message and call each other without having to care what app the other user is on - making it as easy as sending an email. The longer term goal is for Matrix to act as a generic HTTP messaging and data synchronisation system for the whole web - allowing people, services and devices to easily communicate with each other, empowering users to own and control their data and select the services and vendors they want to use ... Matrix is an open initiative which acts as a neutral custodian of the Matrix standard. It’s not actually incorporated anywhere at the moment but we are looking at the best legal structure for the future (and as of October 2015 we have hopefully found one). Whatever the legal structure, we are committed to keeping the Matrix project open. ... We firmly believe it is what is right for the consumer. As people begin to use interoperable communications tools, service providers will see the benefit and compete on quality of service, security and features rather than relying on locking people into their walled garden. We believe as soon as users see the availability and benefits of interoperable services they will demand it. ..."

As was said in Hacker News comments, Slack vs. IRC is not like BitKeeper vs. Git; it is more like BitKeeper vs. CVS. We have yet to see what the
"Git" equivalent of real-time communications is; could Matrix be that?

Matrix is even better than Mattermost in this regard. Still, I can hope we see bridges between Mattermost and Matrix.org, and I don't see in theory why such bridges are not possible, like if the Mattermost frontend is overlayed a Matrix.org backend.

I do not know whether Matrix works well or will succeed, or whether there are currently better alternatives to it, but their heart is clearly in the right place from a free software / free culture perspective based on what they write above. So, in contrast to Slack, Matrix is more the kind of thing free software developers should be supporting as a standard. That's the kind of thing WordPress and Drupal communities should then be emphasizing interfacing with and using IMHO instead of Slack. WordPress/Automattic has already committed to Slack apparently, but at least Drupal/Acquia has not.

Even for WordPress.org, it seems like they could switch over to Mattermost in a short while and then go from there towards Matrix.org integration.

Ultimately, a standard like Matrix.org is a better general solution than a specific FOSS solution like Mattermost, even if Mattermost may be a great piece of software. That's the difference between email as a standard versus a specific locally-hosted email client/server combination as a standard.

Of course, I have my own ideas for a way forward (Twirlip/Pointrel, as a step towards a "social semantic desktop"), but Matrix.org has social momentum, and likely whatever I want to do could be built on Matrix.org or otherwise be compatible with it.

Would I ever use Slack? Sadly, yes. :-(

I use Skype for business. I signed up back when it was peer-to-peer, before Microsoft bought it. I also use GitHub (which at least supports the git standard for the core of its services, even if its issues are locked in). I could be using GitLab instead. Call me a hypocrite perhaps, but Slack is just the newest threat to free software and free discussion, and it is sad to see us going backwards as a global community.

But as for Slack use by me personally, it's true that I'd rather not agree to another random company's TOS. :-) And I really don't want to see Slack succeed in destroying IRC without something better that is FOSS replacing IRC real soon now.

Realistically, I may well have to get a Slack account eventually if everyone starts using it. I'm not independently wealthy and I have to find paying programming work now and then, and I live in a rural area and can't be too picky, especially regarding work-from-home jobs. It was probably a dumb idea for my family to not interview with Automattic over the Slack issue, and my wife is (justifiably) very angry with me about it. Automattic only hires about 20% of people it interviews, and I had some other much smaller concerns about me fitting into the company (no place is perfect), so taking a stand on Slack relating to an interview is not the same as, say, if I already worked at Automattic and loved it and quit over just Slack.

As long as the Slack TOS doesn't specifically make me agree not to develop FOSS communications software (or have some other restriction few FOSS programmers or few average people would willingly agree with), I probably would have no significant problem getting a Slack account for work (beyond grumbles as above). I have not looked recently at whatever TOS Skype has have since Microsoft bought them; I just use Skype mostly for work stuff at other people's suggestion. I would probably treat a Slack account the same way, but I would be sad about it.

However, in contrast, the Automattic case is special, given Automattic is in the communications business, and the kind of work I'd like to do at a place like Automattic would have been replacing the need for using Slack with WordPress plugins. If Automattic is so strongly committed to Slack, it means such work is likely not possible there.

The issue of Slack use came up again in the context of a job application I made to a governmental organization interested in using Slack, my having mentioned the issue with Slack and Automattic. Unlike with Automattic, I told them I would have no major problem using it there in the context of work. I have different expectations about government than someplace like Automattic (both positive ones and negative ones). Regarding Automattic, the issues isn't so much about Slack itself as what Automattic's promoting Slack (over other FOSS solutions, even Automattic's own P2/O2 blogs) said about Automattic and how feasible work was that I wanted to do as my day job there. A governmental organization using Slack might be problematical and perhaps ill-advised IMHO (as with privacy or availability guarantees), and I'm sure there will no doubt eventually be some other governmental choices I might feel that way about. :-) But Automattic using Slack was IMHO long-term self-destructive for both Automattic and the WordPress.org community given WordPress is a FOSS communications tool supported by (sometimes ideologically-motivated) free software developers -- even if perhaps Automattic maybe can't quite see that yet or has forgotten that somehow.

Still, I may be wrong about that; I hope I am indeed wrong about that as far as it impacting Automattic as they have done a lot of good for the world so far and they still seem like a cool company, all things considered. Their big bet on JavaScript and Calypso is something I really admire (even if I can quibble about React vs. Mithril and JavaScript vs. TypeScript).

So, it is not the end of the world to me to use Slack (though I'd rather not, since I might write competing messaging software and I also don't like Slack's Terms of Service). No doubt everyone will be using Slack soon, and it will become a broad job requirement. The world and IRC can only stand so long against US$340 million worth of Slack-funded hype, especially given IRC really is not that easy to use to begin with and Slack does address some serious usability issues (even if introducing different issues about privacy and central control of information). Again, and worth repeating from the Hacker News article, the issue of Slack vs. IRC is not "BitKeeper vs. Git" but "BitKeeper vs. CVS". We still have yet to see what is the Git equivalent of Slack. But I hope we do see something like that soon (whether Mattermost, Matrix.org, or something else).

What bothered me most regarding Automattic and Slack was Automattic apparently just giving up on improving fine-grained real-time collaboration via WordPress, leading to a conflict between stated values (promoting free and open source communication tools like WordPress, the base of their prosperity) and actions (getting people to use a proprietary communication tool including at WordPress.org to develop FOSS). I might expect that conflict between statements and actions of many many people, even at any governmental organization perhaps given politicians are politicians and are always making shifting alliances related to politics. I am no stranger to it in my own actions too sadly (as with working for NBCUniversal instead of developing FOSS, despite having claimed to believe FOSS is overall the better way). But when your business revolves around promoting the value of free communications software like WordPress, that conflict does not bode well, even if it is true we all have multiple principles to balance and choose priorities from (like family vs. FOSS or difficult business decisions about core competencies vs. an essential need for instant messaging in a distributed company). That Slack situation mostly suggests what I wanted to do there with improved real-time collaborative decision support and sensemaking tools for WordPress was not likely to go well if Automattic has abandoned the field of real-time messaging to Slack.

Trying to come up with an analogy about some action that Automattic might take and I would approve of, and which I would be appalled if government would take, imagine if both Automattic and a state government in the USA decided to implement an "Employee Stock Ownership Plan", where all the assets of the organization would be distributed equally among the employees. In the Automattic case, while one might question whether such a plan will work given Manuel De Landa's point about all real systems being mixes of meshworks and hierarchies, such a plan would still be exciting to try. I'd be very interested in writing democratic decision support software to help make that work as well as it could for Automattic. Such a plan would not be in conflict with Automattic's fundamental mission of making the web a better place (whether one agreed with it as a prudent business model or not). By contrast, if a state government was going to vote to distribute all public lands equally among legislators and current legislative employees, then as a citizen, I'd have a big problem with that, whether or not I got a cut. :-) Further, if the state government was going to use eminent domain to claim all the rest of land in the state (which it also implicitly owns) to distribute all that land likewise to legislators and their staff members, to implement a feudal model across the state with Dukedoms for current legislators, Baronies for current staffers, and non-voting serfdom for all other state residents not currently working for the legislature, I'd have an even bigger problem with that. :-) I would not take a job implementing software for such a project, even if I got to release all the software I wrote as FOSS, and I could work from home, and I got paid a million dollars a year, and I got a title of "Baron", and I was granted round the clock police protection (which anyone would need in that situation to protect from neighbors with pitchforks). Such a plan done by a state government would violate the notions of public trust, public stewardship, and democratic process implicit in a state government's mission. If such a plan was being discussed seriously in state government, the most responsible thing any state citizen in a democracy could do would be to first politely (or maybe even impolitely :-) explain why such a plan was a terrible idea in a democracy, and then if needed because the plan goes forward anyway, oppose such a plan. Joining up with such a plan would be seen by most of the community as a compete violation of a public trust.

Of course, feudal systems have their own dynamics, and have been stable for hundreds or thousands of years with mutual obligations between serfs and Lords and various social benefits (including fast flexible decision making and high security with low taxes). So, it is not like you can't make a case for feudal systems of government depending on your priorities or likely social position in the resulting changeover. :-) But that is just not the form of governance we have right now in the USA or what political officials in the USA have been elected to oversee. Likewise, there are many proprietary communications software development projects, and some like Slack are indeed nice in some ways, but proprietary communications software development is not what Automattic shepherds with WordPress.

If a state government uses Slack, one could even see that as government trying to be progressive and efficient, even if the choice specifically was unwise for reasons listed here. That choice would not be a betrayal of the state's mission of good governance -- even if it was a bad idea. Governments try stuff all the time; some plans are always going to turn out to be bad ideas because they were incompletely thought out or subject to unknowns only discoverable by doing, and you learn from that experience, and you move on. By contrast, a company like Automattic that has succeeded among users and FOSS developers based on promoting the value of FOSS communication tools to make the web a better place is betraying its mission to promote proprietary communication tools like Slack external to the company -- no matter how convenient or useful they are. Internal to the company one might make a case, although even then, it is probably unwise overall since it will still implicitly be promoting the tools and be used as an example to others, as in: "See, even Automattic uses proprietary communication tools in house, so why set up in-house P2/O2 WordPress blogs when we can just use Slack?" Is that really the message Automattic wants to be sending into the world related to its mission of making the web a better place? Is that a good message for Automattic to be sending for its very own survival as a business? If I really believed in that mission, how can I support that betrayal whether before or after I was hired?

Granted, a more practical person might argue I should have used Slack to argue against Slack at Automattic (as one Automattician advised me), and maybe that would have been prudent including for me and my family (assuming it is not currently against the Slack TOS). So, I won't say it is a completely black and white issue. In that sense, it was a probably a dumb personal decision to refuse an interview at Automattic based on Slack, and I may well be paying for that decision in multiple ways for a long time to come (some mix of costly and time-wasting unhealthy long commutes, working on proprietary stuff, less productive working conditions on-site in noisy spaces, lower pay, family disapproval, etc.). Although, there was only a 20% chance of getting hired from the point of an interview anyway, so it most likely would not have worked out anyway. And I can still hope other jobs at other places might potentially have their own advantages comparable to Automattic's in their own ways even if they come with various different disadvantages.

Likely that refusal will have zero effect on Automattic as well. Presumably thousands of people who make the resume cut are literally waiting months just for job interviews there. Automattic likely has no shortage of willing would-be Slack users. Given Slack is indeed a cool piece of technology from a webapp UX perspective (ignoring all the other various issues), a lot of would-be Automatticians might see using Slack as a real plus to working there and likely have Slack account already.

Still, Automattic is ten years old in an ever changing industry and may or may not be here in another ten years depending on how such decisions like asking FOSS developers to use Slack play out. By contrast, most governmental organizations in the USA are typically about two hundred years old and are going to be here ten years from now pretty much no matter what they do or what software they use or abandon for whatever short-term or long-term reasons. :-) That is true even if faces may change and policies may change at governmental organizations over time based on civic feedback.

So that's why, for me, a governmental organization or big business choosing to use Slack would get an eye roll, but Automattic choosing to use Slack gets a deep sad frown. :-(

--Paul Fernhout
http://www.pdfernhout.net/

The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.

Initial publication date: 2016-01-05 Update: 2016-01-06 (added Slack competitor list and WordPress plugin idea; opinion on government and FOSS; fixed some typos)
Update: 2016-01-11 (added feudal analogy, reclassified eXo as FOSS, added point on QA/innovation subsidy, added point on client/service FOSS distinction, added more proprietary services to list and stuff on Kato demise and sameroom.io, added practical point near end).
License: CC-BY-SA 4.0 International or later