Open-Source Slack Alternative Mattermost Gets $50M Funding(itsfoss.com)
itsfoss.com
Open-Source Slack Alternative Mattermost Gets $50M Funding
https://itsfoss.com/mattermost-funding/
116 comments
It is a bit unusual, but ultimately it's similar to the quite common "you can have the code under AGPL or negotiate something else with us" plus something unusual, i.e. a MIT-licensed binary.
Ultimately if you're okay with running AGPL code you're okay with running Mattermost. Which means as long as you don't intend to fork it and not share your changes you should be fine.
Ultimately if you're okay with running AGPL code you're okay with running Mattermost. Which means as long as you don't intend to fork it and not share your changes you should be fine.
> Ultimately if you're okay with running AGPL code you're okay with running Mattermost. Which means as long as you don't intend to fork it and not share your changes you should be fine.
That's not how [LA]GPL works. You are free to fork, and not share the changes. The modified source code can be provided only to the people whom you gave the binary (Edit: AGPL has bit more terms, as said in comment below), and you can make it private to the rest of the world (though you can't add additional restrictions).
As Mattermost is dual licensed under AGPL, anyone who uses it under the terms of AGPL can live safe as long as they obey AGPL.
Software pieces using GPL licenses can't add additional restrictions to the software, but of course authors are free to dual license under different terms.
Say for example some one can specify the following for their project: "We provides the project under the terms of MIT for you to modify and run for your own purposes." This might look a harmless statement, but it could mean something very different and may be intentionally written, that essentially makes it non-free. GPL doesn't allow such additional clauses.
Disclosure: IANAL. So I don't know how/if it works in court
That's not how [LA]GPL works. You are free to fork, and not share the changes. The modified source code can be provided only to the people whom you gave the binary (Edit: AGPL has bit more terms, as said in comment below), and you can make it private to the rest of the world (though you can't add additional restrictions).
As Mattermost is dual licensed under AGPL, anyone who uses it under the terms of AGPL can live safe as long as they obey AGPL.
Software pieces using GPL licenses can't add additional restrictions to the software, but of course authors are free to dual license under different terms.
Say for example some one can specify the following for their project: "We provides the project under the terms of MIT for you to modify and run for your own purposes." This might look a harmless statement, but it could mean something very different and may be intentionally written, that essentially makes it non-free. GPL doesn't allow such additional clauses.
Disclosure: IANAL. So I don't know how/if it works in court
[deleted]
> AGPLv3 requires a program to offer source code to “all users interacting with it remotely through a computer network.” It doesn't matter if you call the program a “client” or a “server,” the question you need to ask is whether or not there is a reasonable expectation that a person will be interacting with the program remotely over a network.
From https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser
From https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser
Forgive me if I'm wrong but wouldn't you be allowed to fork it and not share your changes anyway? As far as I know a copyright license is only required if you do share it.
Of course you couldn't share any derived binaries without a valid copyright license, but for internal use there shouldn't be any problem.
Of course you couldn't share any derived binaries without a valid copyright license, but for internal use there shouldn't be any problem.
There might be problems even for internal use because it's licensed under AGPL not just GPL, so the source must be distributed to network users, even if you don't share the binaries with them.
It might work for your company's internal chatroom but not for selling Mattermost as a service.
That's the intention anyway, I'm not a lawyer, I don't know if AGPL was tested in court, and whether it would hold up.
It might work for your company's internal chatroom but not for selling Mattermost as a service.
That's the intention anyway, I'm not a lawyer, I don't know if AGPL was tested in court, and whether it would hold up.
[deleted]
So if I understand correctly, AGPL allows single users to use the software but they cannot provide this software as a service? I've also seem some open source SaaS offer a dual license for single users and corporations. MIT or Apache for single users and GPL for corporations.
You can provide the software as a service BUT you have to give the source code to all users, including your modifications if you have made any.
In other words - you can't sell SaaS based on AGPL software + proprietary secret sauce, you have to share back your secret sauce with all users.
It doesn't prevent you from selling it as SaaS, I could sell vanilla Mattermost as a service under AGPL, my selling point might be that I provide high reliability and excellent support.
Do you have an example of that dual license?
I don't see how that would work, the first person you give an MIT license to can re-distribute it under MIT to anyone else, including corporations.
Usually for dual-license you have the opposite, you would have a restrictive license like AGPL for the public, and you would sell non-free licenses with no redistribution rights that allow modifications without sharing back, for corporate clients who want to add their secret sauce to the software without having to give away the secret sauce for free.
In other words - you can't sell SaaS based on AGPL software + proprietary secret sauce, you have to share back your secret sauce with all users.
It doesn't prevent you from selling it as SaaS, I could sell vanilla Mattermost as a service under AGPL, my selling point might be that I provide high reliability and excellent support.
Do you have an example of that dual license?
I don't see how that would work, the first person you give an MIT license to can re-distribute it under MIT to anyone else, including corporations.
Usually for dual-license you have the opposite, you would have a restrictive license like AGPL for the public, and you would sell non-free licenses with no redistribution rights that allow modifications without sharing back, for corporate clients who want to add their secret sauce to the software without having to give away the secret sauce for free.
Is this Mattermost's answer to the current debate around the ethics of FAANG (and others) using open source software to make lots of money without substantially contributing back to the OS projects financially or in code?
My understanding is that, Mattermost is okay with others making money from their software if they don't modify it - which will practically work for some, but not all, small companies, and will be very difficult for the big companies to use. If the big companies want to modify and use Mattermost-server for free they are forced to contribute back the changes to the OS project, and then can make as much money as they want. Or use option 2, pay Mattermost a bunch of money for the privilege of not contributing back code to the OS project. In other words FAANG and co can either contribute to Mattermost financially or in code - their pick.
My understanding is that, Mattermost is okay with others making money from their software if they don't modify it - which will practically work for some, but not all, small companies, and will be very difficult for the big companies to use. If the big companies want to modify and use Mattermost-server for free they are forced to contribute back the changes to the OS project, and then can make as much money as they want. Or use option 2, pay Mattermost a bunch of money for the privilege of not contributing back code to the OS project. In other words FAANG and co can either contribute to Mattermost financially or in code - their pick.
This honestly seems like a pretty good compromise if it works out like you have described it.
So if they accept contributions from the community does the copyright on those get reassigned to mattermost?
No, that's not how copyright works.
There are software projects that use/require copyright assignment (notably many GNU projects require assignment to the FSF).
Yes but in these situation the copyright assignment is a separate contract underwritten by the person committing. What (I think) driverdan means is that an OSS licence legally cannot substitute this separate contract - one cannot automatically assign one's own copyright to another entity by following an OSS licence.
No, it's a "grant to Mattermost and to recipients of software distributed by Mattermost a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your contributions and such derivative works."
https://www.mattermost.org/mattermost-contributor-agreement/
https://spinpunch.wufoo.com/forms/r3z8zqm0ew6pcc
https://www.mattermost.org/mattermost-contributor-agreement/
https://spinpunch.wufoo.com/forms/r3z8zqm0ew6pcc
Dual licenses are not uncommon.
Dual open source licenses where one applies to the compiled version and one applies to the source are not terribly common.
What does it even mean to have an open-source license on a binary? Aren't those two things kind of contradictory?
Yeah, this struck me as odd too until I realised that the MIT license says nothing about source code. It just talks about redistribution. So what they are saying is that the binary is redistributble for any purpose, but if you want to distribute changed versions of the source code you have to do it under AGPL. That's weird, but potentially OK. The only thing it does is allow you to redistribute the binary without having to supply the source.
The reason I say "potentially OK", though is I wonder if a binary can be assigned a copyright as distinct from the source. The binary is only a machine translation of the source after all. Not a lawyer, so I'm not certain, but it seems a bit odd. I can't imagine a situation where anyone would challenge you, though --- they are giving you extra rights, not removing them.
The reason I say "potentially OK", though is I wonder if a binary can be assigned a copyright as distinct from the source. The binary is only a machine translation of the source after all. Not a lawyer, so I'm not certain, but it seems a bit odd. I can't imagine a situation where anyone would challenge you, though --- they are giving you extra rights, not removing them.
Advertising as "open source under license X" when, if you read the fine print, license X does not actually apply to the source code is pretty uncommon.
We recently switched from Slack to Mattermost and love it. My only gripe is that replies show up in the main room thread which makes catching up on posts almost impossible.
There is a request to implement collapsible threads[0] but I haven't seen any new updates address this.
I'm hoping this new funding round amps up a few developers to take on this much-needed feature.
[0] https://mattermost.uservoice.com/forums/306457-general/sugge...
There is a request to implement collapsible threads[0] but I haven't seen any new updates address this.
I'm hoping this new funding round amps up a few developers to take on this much-needed feature.
[0] https://mattermost.uservoice.com/forums/306457-general/sugge...
Interesting, that's actually one of my biggest complaints in Slack. If a discussion should be public, it should be visible. Threads in Slack are a pain to pay attention to because they're "hidden" from view in the main channel. I appreciate how MM keeps threaded messages in the channel.
This is the biggest thing blocking us from moving from Slack to MM. With Slack you have the option of replying to a message in the channel and keeping it fully visible, just by replying in the main chat, so why don't you just do that and not use threads?
> so why don't you just do that and not use threads?
Sometimes multiple topics are being discussed at the same time in the same channel, threads are helpful here.
Sometimes multiple topics are being discussed at the same time in the same channel, threads are helpful here.
Slack only recently got threads at all -- I realize it's easy to get used to them but maybe reconsider whether it's really become a show stopper. You probably would have used Slack before they implemented threads, after all...
We've switched to on-premises MM from HipChat at the beginning of the year.
I miss the video conf functionality of HipChat, but other than that I think MM was the right decision for us. Everyone on the team seems to be happy with it.
I miss the video conf functionality of HipChat, but other than that I think MM was the right decision for us. Everyone on the team seems to be happy with it.
Rocket.Chat has the same issues. Why do they think this is a good idea to put the thread comments in the main room. It's an absolute mess.
> We recently switched from Slack to Mattermost and love it.
> ...makes catching up on posts almost impossible.
Seems odd those 2 statements are in the same comment. How can you love a product that has such a big flaw in the basic workflow? For the record, I've never even heard of Mattermost until today, but just thought that was strange to read your comment.
> ...makes catching up on posts almost impossible.
Seems odd those 2 statements are in the same comment. How can you love a product that has such a big flaw in the basic workflow? For the record, I've never even heard of Mattermost until today, but just thought that was strange to read your comment.
I don’t think it’s strange to “love” something just because you can point out its flaws. It’s not like the alternative is perfect, and depending on your point of view, it might have flaws that are more fundamental or hard to fix.
I was going to post the same message as the parent poster
Let try it with an couple of other examples
I love the ford abc but the steering feedback makes it impossible to steer
I love the new Panasonic tv, but the way it shows black makes it impossible to watch movies
I love the ford abc but the steering feedback makes it impossible to steer
I love the new Panasonic tv, but the way it shows black makes it impossible to watch movies
That's fair. I don't know, I guess it just read funny to me at first, but you're right.
When open source projects get VC funding, it makes me trust them less. Eventually, the investors are going to want their money back with a profit. When that happens, the companies are going to try to monetize their offering often in ways that are detrimental to the open source project.
Any VC funded company gives me this feeling.
Twitter scaled up ads a whole lot to become solvent.
Moviepass went from an amazing deal to an okay one.
Netflix's content catalog and price went from great to okay.
Facebook went from "Myspace but with photos" to the massive advertising machine it is today.
The great-for-users but usually lossy beginnings of these companies are a play to acquire users, so they can pull the profit switch later on.
Twitter scaled up ads a whole lot to become solvent.
Moviepass went from an amazing deal to an okay one.
Netflix's content catalog and price went from great to okay.
Facebook went from "Myspace but with photos" to the massive advertising machine it is today.
The great-for-users but usually lossy beginnings of these companies are a play to acquire users, so they can pull the profit switch later on.
Just wait till Uber and Lyft investors start demanding profits...
I'd say I trust more companies that already are earning money and open source something, it's less likely that they will bait and switch to a proprietary. Or some like mattermost or mariadb are clean about a possible business plan. Way better than a non standard open source license and vague prospects of VC money.
Can you explain with an example what you mean by "detrimental to the open source project"?
Sincere question: what's the point of GitLab or Mattermost being open source when they clearly want to control/restrict/monopolize use of their applications?
IIRC GitLab is "open core" which just means it's not fully open source and Mattermost is not really fully open source either, it its own confusing way.
The purpose of open source was to give users full and unrestricted power. To free them from lock in and allow them to be the masters of the software they use.
It seems that these companies view open source as a marketing trick and perhaps a way to save on development costs. They're making a mockery of open source and should probably be shunned for it.
IIRC GitLab is "open core" which just means it's not fully open source and Mattermost is not really fully open source either, it its own confusing way.
The purpose of open source was to give users full and unrestricted power. To free them from lock in and allow them to be the masters of the software they use.
It seems that these companies view open source as a marketing trick and perhaps a way to save on development costs. They're making a mockery of open source and should probably be shunned for it.
I think it is a pretty fair as they have people working full time in their products since their conception. I'd rather companies providing their source and strugling to monetize their product than companies selling just closed source alternatives.
Restrictions could be provided by people through OSS, these companies don't prevent these alternatives from existing. The lack of interest does. The same could be said about many OSS that strugle to receive donations.
I could agree that a world where only OSS without monetization exists, where people donate and keep people investing their time on improving OSS without needing restrictions. The reality is that without these restrictions, people are not willing to pay.
Restrictions could be provided by people through OSS, these companies don't prevent these alternatives from existing. The lack of interest does. The same could be said about many OSS that strugle to receive donations.
I could agree that a world where only OSS without monetization exists, where people donate and keep people investing their time on improving OSS without needing restrictions. The reality is that without these restrictions, people are not willing to pay.
> what's the point of GitLab or Mattermost being open source when they clearly want to control/restrict/monopolize use of their applications?
- We can fork it if we really don't like that direction, but think what's there is valuable.
- We can propose Merge Requests (as they are on GitLab) that might be higher priority for us personally than for the company, which might accept them just not have the resources to work on them itself as quickly as we'd like.
- We can fork it if we really don't like that direction, but think what's there is valuable.
- We can propose Merge Requests (as they are on GitLab) that might be higher priority for us personally than for the company, which might accept them just not have the resources to work on them itself as quickly as we'd like.
> Mattermost is not really fully open source either, it its own confusing way.
Honestly curious: In which way is Mattermost not Open Source? As far as I can tell the code is under AGPL, which may not be the most popular FOSS license, but is generally accepted as being one.
Honestly curious: In which way is Mattermost not Open Source? As far as I can tell the code is under AGPL, which may not be the most popular FOSS license, but is generally accepted as being one.
> IIRC GitLab is "open core" which just means it's not fully open source
Gitlab CE is fully open source. Gitlab EE is proprietary. The same company produces both, but you can decide to use only the former, and remain fully in control.
This is certainly not the vision of the future that supporters of a fully-FOSS world like me wish to see, but seems strictly better than most proprietary companies, which still use FOSS code/libraries while contributing little or nothing.
Gitlab CE is fully open source. Gitlab EE is proprietary. The same company produces both, but you can decide to use only the former, and remain fully in control.
This is certainly not the vision of the future that supporters of a fully-FOSS world like me wish to see, but seems strictly better than most proprietary companies, which still use FOSS code/libraries while contributing little or nothing.
GitLab & its CEO call it 'open core':
https://news.ycombinator.com/item?id=17225725 https://about.gitlab.com/2016/07/20/gitlab-is-open-core-gith...
https://news.ycombinator.com/item?id=12128546 https://about.gitlab.com/2016/07/14/building-an-open-source-...
https://news.ycombinator.com/item?id=17225725 https://about.gitlab.com/2016/07/20/gitlab-is-open-core-gith...
https://news.ycombinator.com/item?id=12128546 https://about.gitlab.com/2016/07/14/building-an-open-source-...
I'm not denying that - what I described is what 'open core' means.
From your link: "We ship GitLab CE which is open source and GitLab EE that is closed source."
Exactly what I wrote!
From your link: "We ship GitLab CE which is open source and GitLab EE that is closed source."
Exactly what I wrote!
I wasn't disagreeing with you, just explaining (though it seems you knew) why the other commenter recalled the phrase in relation to GitLab.
I'm pretty amazed at the number of chat offerings that don't offer encryption. (From a quick Google search it seems Mattermost doesn't either.) I'm still holding out for Matrix to deliver (I know it's currently working for some people), but my understanding is that it's not enabled by default yet:
https://github.com/vector-im/riot-web/issues/6779
Mattermost does offer transport level encryption, via HTTPS. For most things, that's plenty good enough.
But for many organizations, they want unlimited viewing of the messages anyway, so E2E would be a non-starter.
It all depends on your needs.
Mattermost would never be a good solution for a global chat system, nor would it be a good fit for wide-open public/untrusted access chat either, both of those are where E2E type encryption would really shine.
But for many organizations, they want unlimited viewing of the messages anyway, so E2E would be a non-starter.
It all depends on your needs.
Mattermost would never be a good solution for a global chat system, nor would it be a good fit for wide-open public/untrusted access chat either, both of those are where E2E type encryption would really shine.
Work is underway at IETF on MLS for E2E encrypted group messaging, https://datatracker.ietf.org/wg/mls/about/
We're looking at MLS for Matrix too. The only reason E2E isn't enabled by default on Matrix today is E2E-enabled search isn't finished yet
I thought you were also waiting for cross-signing (which seems to have progressed quite well) to land?
Isn't E2E search mostly a client-side matter? Unless using homomorphic encryption, of course, which I don't think OLM is capable of?
Or are you planning on using another trick, similar to hashing the strings client-side when a new message is received, then sending the hashs and later searching those server-side?
I'm curious since I haven't seen that mentioned other than using pantalaimon as some kind of server-side search engine. I can ask or discuss this further in matrix(-spec):matrix.org as needed/preferred.
Isn't E2E search mostly a client-side matter? Unless using homomorphic encryption, of course, which I don't think OLM is capable of?
Or are you planning on using another trick, similar to hashing the strings client-side when a new message is received, then sending the hashs and later searching those server-side?
I'm curious since I haven't seen that mentioned other than using pantalaimon as some kind of server-side search engine. I can ask or discuss this further in matrix(-spec):matrix.org as needed/preferred.
Cross-signing is basically there at the SDK & server level; just needs the UX to be added into Riot, but we prioritised https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-... so running a few weeks behind.
E2E search is entire client-side, and works thanks to https://github.com/matrix-org/pantalaimon/tree/search. We're not doing homomorphic stuff; instead we're thinking about encrypting the tantivy indexes and storing them serverside.
E2E search is entire client-side, and works thanks to https://github.com/matrix-org/pantalaimon/tree/search. We're not doing homomorphic stuff; instead we're thinking about encrypting the tantivy indexes and storing them serverside.
What blows my mind about Mattermost is the server requirements... for what essentially is a message broker, you have need a multi-gig box for a deployment that can support 8 people. Part of the problem is their tech stack.
Generally the requirements depend on factors like network speeds and estimated storage usage per user. Here's more information on Mattermost hardware requirements: https://docs.mattermost.com/install/requirements.html#hardwa...
Would love to learn more if you have concerns about server hardware requirements.
Would love to learn more if you have concerns about server hardware requirements.
That sounds like overestimating just to be safe. I run an MM instance for triple that number of people on an ARM SOC with 2GB RAM and it works beautifully. Not only that but I compile it from source on the same box with no problems.
For someone who has no experience with Mattermost, can you explain? This seems crazy.
Is there an open source slack alternative that's simple to setup? I'd settle for just a react gui with the nice screens.
The trend of commercial open source apps to be a major PITA to deploy & hack on is kind of tiresome imo.
The trend of commercial open source apps to be a major PITA to deploy & hack on is kind of tiresome imo.
https://github.com/mozilla/mattermost-heroku/
Go hit this “Deploy to Heroku” button.
Alternatively, Mattermost also has a Docker container: https://github.com/mattermost/mattermost-docker
Go hit this “Deploy to Heroku” button.
Alternatively, Mattermost also has a Docker container: https://github.com/mattermost/mattermost-docker
To be honest (and partial, since I haven't self-hosted many contenders), I didn't find Matrix that complicated to setup. The most complex and resource-hungry part is federation, but you can likely do without if you don't need it (since it is one of the biggest selling points of the tech, I am afraid there shouldn't be many guides omitting that part).
I did it trough Yunohost on my server, but I hear there is a handy Docker-ansible playbook, and that the Archlinux package works pretty well (synapse is also available trough pip). I guess someone could cook up a non-federating server implementation some day…
I did it trough Yunohost on my server, but I hear there is a handy Docker-ansible playbook, and that the Archlinux package works pretty well (synapse is also available trough pip). I guess someone could cook up a non-federating server implementation some day…
Zulip (https://zulipchat.com/) is pretty easy to setup - if you deploy to Ubuntu or Debian.
Have a look at https://rocket.chat/install or https://sdelements.github.io/lets-chat/
If you need on-prem and LDAP but don't want to pay, check Zulip. We evaluated Mattermost, but its LDAP is not free.
Slightly bothersome, but you can use gitlab as a SSO provider for mattermost, and gitlab can be easily (free) integrated with LDAP.
From https://docs.mattermost.com/deployment/sso-gitlab.html
> Only the default GitLab SSO is officially supported. “Double SSO”, where GitLab SSO is chained to other SSO solutions, is not supported. It may be possible to connect GitLab SSO with AD, LDAP, SAML, or MFA add-ons in some cases, but because of the special logic required they’re not officially supported and are known not to work on some experiences. If having official AD, LDAP, SAML or MFA support is critical to your enterprise, please consider Mattermost Enterprise Edition as an option.
> Only the default GitLab SSO is officially supported. “Double SSO”, where GitLab SSO is chained to other SSO solutions, is not supported. It may be possible to connect GitLab SSO with AD, LDAP, SAML, or MFA add-ons in some cases, but because of the special logic required they’re not officially supported and are known not to work on some experiences. If having official AD, LDAP, SAML or MFA support is critical to your enterprise, please consider Mattermost Enterprise Edition as an option.
Odd statement.
Works like a charm for us with AD backed SSO on GitLab.
I believe this is what we use at CERN, and as far as I can tell it works good enough.
I believe mattermost actually ships w/ gitlab included , or you can host your own seperate/existing gitlab installation.
I am using it currently with freeipa with zero issues.
I am using it currently with freeipa with zero issues.
Or you can try Mattermost-LDAP: https://github.com/Crivaledaz/Mattermost-LDAP
My experience with Zulip has also been pretty great. We (a startup) found that it keeps the conversation more focused.
I see a lot of cool Slack competitors. Including Keybase Teams. But raising $50M seems like a lot for an open source one!
It makes me hopeful that we will be able to raise that kind of money soon for our platform. We also have AGPL dual license. However, our goal is more ambitious: we built a platform (https://qbix.com/platform) to let ANYONE build their OWN social apps and plugins, and then let communities host them. Like Wordpress + Plugins but for Web 2.0 (think Facebook rather than blogs).
I imagine building a Slack competitor would take about a month of focused work. And then anyone would be able to install it, on one machine.
But, we spent all these years building the tech and doing security audits. What are your recommendations business-wise, to take it from here to getting funding like this? (Without compromising the vision.)
It makes me hopeful that we will be able to raise that kind of money soon for our platform. We also have AGPL dual license. However, our goal is more ambitious: we built a platform (https://qbix.com/platform) to let ANYONE build their OWN social apps and plugins, and then let communities host them. Like Wordpress + Plugins but for Web 2.0 (think Facebook rather than blogs).
I imagine building a Slack competitor would take about a month of focused work. And then anyone would be able to install it, on one machine.
But, we spent all these years building the tech and doing security audits. What are your recommendations business-wise, to take it from here to getting funding like this? (Without compromising the vision.)
I find rocketchat a much better match and the mobile version also work very well.
Some things I have issues with rocketchat is the insane amount of node_modules, random crashes, uses mongodb, and it's a pain to customize
I wish they made rocketchat simpler to integrate with an existing website.
I am very disappointed by Slack decision to remove screen sharing. We won't be paying customers from now on.
Screenhero was an awesome product. I don't get why they are killing it.
Screenhero was an awesome product. I don't get why they are killing it.
Screen sharing products seem to be finicky or massive out of control and hard to use apps.
Maybe there is a technical reason screen sharing is so wonky.
Maybe there is a technical reason screen sharing is so wonky.
We are using Mattermost for over a year at work, and I would love to get a native client for their app, even a bare bones one. Currently running it with https://github.com/EionRobb/purple-mattermost but something more supported would be great
you mean like... the official dekstop client @ https://github.com/mattermost/desktop ?
It's odd that that page refers to the desktop client as "native". The parts of an electron app that are native to the OS (as opposed to the OS-independent HTML/JS) are irrelevant to most people's desire for "native" apps.
Electron is not native.
Electron is not native.
The client is just an electron app (ie a very thin wrapper around a webpage). One of the more glaring examples is unable to monitor inactivity and set away status correctly.
Electron is not native.
As someone who uses their self hosted version day in and out, best wishes to them!
Does Mattermost support drawing on screen share? It is one of the killer features for me in Slack, and at some point Google Hangouts had it but removed it, and Meet does not have it.
We've been using a combination of Discord / Telegram / Google Meet instead of Slack and haven't had any problems. There are lots of great alternatives out there.
I'm no slack advocate, but you just described using three services to replace one. There will be some extra mental overhead to such a setup, even if it is not huge. I think something like mattermost carries the advantage of one service, one interface, one place for things; it's a little easier than "oh, in which did I put that?".
They also just described 3 services where you don't own the data.
Also none of them are open source
If anyone from Mattermost is listening, it would be wonderful if they offered the whitelabel deployment (for SSO) of apps as a service. For a startup without any presence on the Apple or Google app stores or specific mobile needs, it would be amazing to have someone package that up for enterprise customers and take care of keeping the app up to date.
Why would Mattermost do this and not a specific provider?
That depends on what you mean by "provider", I suppose. Google is not going to be interested in doing this, I suppose a consultancy or MSP could offer this as a service if they resell Mattermost, but I don't know if Mattermost has that sort of sales network or system.
On the other hand, for enterprise plan users it would make sense to rely on Mattermost for app distribution, and they have the expertise to publish the apps and ensure they're approved in the respective stores. Would a reseller or MSP necessarily have that competency? I come from the IT world where the answer would definitely be "no", but I could see it being part of contracted out work. Who owns the app then after that contract is up?
On the other hand, for enterprise plan users it would make sense to rely on Mattermost for app distribution, and they have the expertise to publish the apps and ensure they're approved in the respective stores. Would a reseller or MSP necessarily have that competency? I come from the IT world where the answer would definitely be "no", but I could see it being part of contracted out work. Who owns the app then after that contract is up?
You mean a company monetizing an open source project gets funding. Why do we persist in the 1-1 OSS project-company mapping fallacy
In this specific case, isn't it the Mattermost company that funds most of the development of the OSS project ?
Yeah, this is true in a lot of cases. But it seems to go against the spirit of open source and turn it into a shared source model... maybe that's fine, but it ends up with people using open source as a marketing vehicle to attract developers rather than being truly "free and open source" where governance and viability isn’t tied to a single company’s fate.
If it has an open source license, it is 100% truly "free and open source". That's a good thing, not a bad thing! There's nothing magic about foundations or volunteer organizations that make some things more open sourcey than others. That's the beauty of it, the lifetime of the code isn't bound to the lifetime of whoever made it, for whatever reason they chose to make it or stop making it. It's just the license, not who wrote the software, and not why they wrote it. Everyone gets the benefit of their labors regardless.
Volunteer communities and nonprofits are no silver bullet either- they're great when they exist and function well, but they don't always, and are highly dependent on who's involved, how much, and why. If there's a big, strong, vibrant community behind something, that's a good sign for whatever that thing is, but very few projects rise to that level of centrality in people's lives. There's also no shortage of projects without funding which have terrible or nonexistent communities surrounding them. Usually good communities arise during the long tail of maturity, like years or decades after whatever it is has reached a plateau of collective usefulness. Good software leads to good communities, sometimes, eventually, but it generally doesn't go the other direction. Something has to be great for years before it becomes that critical and that supported of a piece of infrastructure. That's why it's good that open source is only a factor of the license, not who made it, not who maintains it, not why they maintain it, and not how it's funded. That's literally what is special about it and makes open source a useful and good thing.
Volunteer communities and nonprofits are no silver bullet either- they're great when they exist and function well, but they don't always, and are highly dependent on who's involved, how much, and why. If there's a big, strong, vibrant community behind something, that's a good sign for whatever that thing is, but very few projects rise to that level of centrality in people's lives. There's also no shortage of projects without funding which have terrible or nonexistent communities surrounding them. Usually good communities arise during the long tail of maturity, like years or decades after whatever it is has reached a plateau of collective usefulness. Good software leads to good communities, sometimes, eventually, but it generally doesn't go the other direction. Something has to be great for years before it becomes that critical and that supported of a piece of infrastructure. That's why it's good that open source is only a factor of the license, not who made it, not who maintains it, not why they maintain it, and not how it's funded. That's literally what is special about it and makes open source a useful and good thing.
If the governance is well set up from the get go I think this model is fine. At some point you need money to make quality software.
I wonder if anyone is working on a discord/slack-like app based on janus (the rtc server that powers slack, i think).
I don't get it. What's the need for an open source slack alternative?
Unlimited message retention. Different bells and whistles.
It's because Slack is closed source.
Self hosting
I feel like someone could corner the market just by making tab complete that works as well as IRC did and adding a full dark theme to the desktop client.
I'm using Mattermost for communicating with one team and I absolutely hate it. It feels so completely unfinished, like it's some kind of proof-of-concept? I don't mean to diss on Mattermost, I'm actually very excited to see them getting funding as Slack has like their name implies: slacking. What has Slack done over these past few years? Exactly, nothing! I don't mean that good software needs to keep updating, no not at all. It's just Slack can improve so much and it's just sitting there. I am really looking forward to replacing Slack with something else.
For all of the people going to suggest Matrix or something else to me, hold your breath. The reason I haven't switched is because communities haven't switched and neither have companies.
For all of the people going to suggest Matrix or something else to me, hold your breath. The reason I haven't switched is because communities haven't switched and neither have companies.
Mattermost Licensing
SOFTWARE LICENSING
You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE
- See MIT-COMPILED-LICENSE.md included in compiled versions for details
You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
1. Under the Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy; or
2. Under a commercial license available from Mattermost, Inc. by contacting [email protected]
You are licensed to use the source code in Admin Tools and Configuration Files (templates/, config/default.json, model/, plugin/ and all subdirectories thereof) under the Apache License v2.0.
So that means, only the binary provided by Mattermost is MIT, not its source code, the usage of 'MIT' in their website sounds deceiving.
[0] https://github.com/mattermost/mattermost-server/blob/master/...