Slack has raised our charges by $195k per year

Since you're a nonprofit that teaches coding, it could be a great time to consider self-hosting a FOSS chat tool.

Suggestions: Campfire [0] or Zulip [1].

Also, if the data in chat is being held hostage, the org might be using chat wrong. Right tool for right purpose. If starting over, perhaps consider if it would make sense to put that documentation or whatever it is that will get "lost" from Slack into a wiki or repo or other appropriate tool?

Big empathy, though. It must be pretty crushing. But that is why serious geeks have long been for FOSS.

  [0] https://once.com/campfire (recently became FOSS) 
  [1] https://zulip.com

I'm in Hack Club, the team is moving all of us to self-hosted Mattermost. It is unfortunate that we have to re-code so many things though.

The post says they're moving to Mattermost and has a screenshot of the same.

Yeah, I must have read the whole article except that sentence, which is buried at the very end, after all the images.

If those any of those 4 screenshot snippets are of Mattermost, it's not very clear. All I see is screenshots of what appears to be Slack.

They are indeed of Slack but the 4th says: “As you have probably read, Hack Club is moving to Mattermost”. But not here to litigate it. It’s easy to miss if you skim.

Does give you more things to 'hack' for the club. Not all bad I guess, and saving that amount of money is worth creating some 'new projects'.

> Also, if the data in chat is being held hostage, the org might be using chat wrong.

This is so important these days. A lot of project send users to discord, slack for documentation and help but they are not made for this purpose. Searching in chat channel for a specific problem is not a good way to handle documentation. I can't even use search engines to search that.

Zulip is great

mattermost is so so so clunky and uncomfortable, but hey, it's free...

Matrix would be a better alternative

Is it? We've been using it self-hosted for years, together with GitLab. It meets all the needs of a small company, and is very pleasant to work with for devs too (i.e., basic Markdown just works, so you can post anything from code to log snippets in a sensible manner).

Setting up Mattermost was one of the best decisions we've made with regards to our tools.

I've never used Mattermost before today. After checking out their site, I can see they are also a for-profit company. What does Mattermost offer that Slack does not, other than a bill lower than $195K/year?

Mattermost is open-core software: you can self-host and they can't turn you off or raise the price.

You can deploy it self-hosted without paying any fee, so you control your data much more.

Zulip is awesome. Super easy to self host. Upgrades go very smoothly. Their thread title concept is great (though they are relaxing its requirement lately). The only thing you don't get if you self host is the mobile notifications. This happened recently and it's a bummer but that's what they came up with to monetize the project, as is their right. Paying $5000 for chat is ridiculous to me when such good alternatives exist.

Last time I checked they cripple the self-hosted version, asking to subscribe for enterprise plan here and there. Source: deployed their chat locally a couple of weekends ago. Overall, I liked their Slack clone, they this one was a red flag to me. Now I’m not sure we want to deploy this, but I know very little alternatives. Zulip, but it cripples its self-hosted version too. It allows just 10 mobile users (notifications). Maybe Matrix it is then, but it’s not very suitable for airgapped company-wide deployment.

Still, crippling the self-hosted version feels like a red flag. Later on, they can easily introduce more features out of self-hosted version. That makes me feel more like ‘we’re business first, but we allow you plebs to contribute towards our success for free’ instead of ‘we’re business and we’re contributing into the community, and as a bonus, the community helps us back.’

What about the software nudging you to subscribe to their enterprise plans here and there? Did you turned off this, or just ignore?

What's your case for calling it open-core? The whole thing is AGPLv3, so... I'd call it FOSS with some components optionally being usable under Apache 2 terms

The problem with push notifications is that they need to go through the app provider and incur costs for it, that's not really their fault. If they'd not charge for it, they'd still go through their servers and would lose them money. So putting it behind a paid service you hook up to your self-hosted instance seems fair.

If you want to avoid it you'd need to build patched versions of the app and distribute them yourself to your users, so you pay Google/Apple directly for notifications instead of going through Zulip.

Funny you would mention GitLab - I find it extremely clunky, especially compared to GitHub. Maybe GitHub is primitive in comparison, but it never makes me hunt for basic functionality and the search just works for about everything.

Not much of an issue. Did this get more annoying in the newest versions?

I personally see any kind of subscription as a technical debt.

> mattermost is so so so clunky and uncomfortable

I'm quite sure they are open to pull-requests..

Mattermost is AGPLv3. You can deploy the whole stack and own your data without paying a cent to Mattermost the company.

I've literally never seen this in my self-hosted Mattermost. Where do you see it?

I think it is time we all start moving away from renting software back to owning it (or at the very least, owning a perpetual license). The subscription model is does not exist on a stable plateau. Every company that runs on a subscription model will (and must, by virtue of incentives) to attempt to "develop new revenue streams".

> Searching in chat channel for a specific problem is not a good way to handle documentation

I just wanted to highlight this. I am so happy seeing this written down explicitly and finally.

Throughout the years I struggled so much finding relevant and accurate information about a feature of a product because it was scattered in chat channels, inadequate for providing reliable data (out of date or uncertain staleness, evolving or straight up wrong suggestions found, tangential only, patial, ...). Big names do it (Unity3D, DevExpress, ...). To make the matter worst both official support personel and power users promote its use, defend its use against critique to the last blood, despite of the obvious shortcomings and unreliability for average users. It is just the lazy excuse of providing the necessary knowledge.

That's how they describe themselves: https://github.com/mattermost/mattermost

> Mattermost is an open core, self-hosted collaboration platform that offers chat, workflow automation, voice calling, screen sharing, and AI integration

> Maybe Matrix it is then, but it’s not very suitable for airgapped company-wide deployment

Element is literally built for airgapped company-wide deployments - this is precisely what https://element.io/server-suite is? It was originally built to install onto SIPRnet; it's been airgap-first since day 1.

Interesting. Notably, they also call themselves "open source" in the "About" of the repository. I'm not aware of any critical extensions which are closed-source. The change you've highlighted was made 4 months ago under a commit that gives no explanation: https://github.com/mattermost/mattermost/pull/31247/files , and the discussion there is private.

Notably, they do have some "source-available" code that goes into the enterprise release, at https://github.com/mattermost/mattermost/tree/master/server/...

This mainly seems to relate to metrics and fuzzy search, though it's possible more will move here in the future (it looks like this is a relatively recent development). Until recently they also had experimental support for Bleve full-text search (now seemingly deprecated), but the elasticsearch enterprise feature seems to be the replacement (otherwise they use postgres's ILIKE for built-in text search)

So, all told, Mattermost was open source, and may be moving to open core. Which means now is probably the best time to create a community-maintained fork. The team edition, and almost all features, are currently still open source.

I'm selfhosting rocket for a small team (https://www.rocket.chat/install). I think they have a limited number of users, but the license is MIT.

Self-hosted ntfy¹ would be a cool alternative. Works really great for me.

¹ https://docs.ntfy.sh/

yawn it's very, very old to tell people "do it better else shut up", which is exactly what you did.

people can have an opinion you know. this is my opinion.

How are you expecting the devs to get paid with zero incentive for customers to do so?

> Also, if the data in chat is being held hostage, the org might be using chat wrong.

A lot of the data people are worried about is their chat history, because Hack Club isn't really just a nonprofit that gives people things, it's also a community. So it's less about documentation and more about people's chats with each other. (disclaimer: i am not official hack club hq)

It's not lazy, it's by design. We have chat messages because the actual knowledge is stored inside of people, and chat messages are the most searchable way to see what people know outside of being able to ask them personally.

So why don't all of these people simply write it down in a notion/document store and meticulously keep it all up to date?

Because the business does not want that. We demand efficiency, so we understaff engineering departments sufficiently that there is always a little crunch, so that slightly-too-few engineers have to work slightly-harder-than-they-want to make the business successful. The end result of this intentionally engineered "lack of time" is that things like maintaining meticulous documentation are ignored, and the only time the knowledge is shared is in a frantic slack message.

The business is designed to do this. It's not laziness. It's the standard operating procedure to increase efficiency and profit.

Unfortunately it works. Companies will never go back - who would give up the opportunity to extract more from customers on demand?