What's more disturbing than the bug itself is the Mattermost team's response that this behavior is intentional for the free "team edition" of their software, and that "actually, I think the bug is that we should not be showing Channel Admin as a role in Team Edition" (i.e, users of the free edition don't get any kind of access controls, making it impractical to use outside a small group of trusted users).
Potentially controversial opinion: This isn't really open source. When major features like permissions and access controls are stripped from the "community" version of a software package, it starts looking more like a feature-limited demo.
I think "all team members are admins" is more usable than you think it is; I generally do this for many cloud services on most of my teams even at my day job; it's just not worth spending time dealing with access control, setting it up, and then someone who can't do what they need to do for their job cause you didn't give them enough access, or the only person who can do what needs done is on vacation, etc.
I often say "We don't have (or use the) locks on our doors at our physical individual offices, but that doesn't mean any of us would go into someone elses office when they aren't there and trash everything on their desk. And it's not a problem. What makes electronic resources different?" [I know HN audience will now give me an exhaustive list of what makes electronic resources different; please don't bother; I know this approach doesn't always work. With physical offices either].
But I agree with you that that level of feature-crippling makes me want to all it more like demoware than open source.
"Everyone is an admin" might be usable for some small teams, but it makes the software absolutely unusable for any sort of public project -- like open-source developers, or public communities. It really makes it clear that the primary purpose of the "team edition" is to drive sales of the commercial product, not to be usable in its own right.
It works well for companies where there’s typically recourse in company policy to deal politics and bullying.
For communities, especially those that are open, this model often fails as soon as one bad actor comes along because there’s often no recourse against bad behaviour.
Unfortunately for Mattermost, it’s communities that are less likely to be able to pay, and more likely to be affected by this policy. That just feels like poor policy making.
So, at your workplace, do you put unpickable locks on everyone's individual office door and enforce a policy that all doors are locked when not occupied (or heck even when occupied), so you won't have to "deal with" some insane coworker trashing someone elses office? How about tracking of who is in the bathroom when, with camera monitoring, so you can deal with it in case someone smears their poop on the walls?
Laptops and physical property are one thing. But your digital empire of customer data is another. Encryption, MFA, inactivity based locking, access controls, and the principle of least privilege helps ensure that when something inevitably does happen, the blast radius is contained.
I don't really care if someone were to smash the hell out of the office. Laptops are locked. Data is encrypted. That's why in fact we have insurance.
But a disgruntled or even careless employee could irreversibly damage an enterprise by letting happen (or deliberately causing) a data breach. All because the org didn't want to bother "dealing with" access controls.
Way more likely that someone presses that delete button in a temporary tantrum or by mistake than a coworker randomly trashing someone else's office (there are telling signs after all).
It's also way easier, cheaper and practical to prevent the first example than the second one.
Your employees may not be the problem. But their accounts with brute-forced passwords or shared credentials will be a problem once a 3rd party finds out.
Of course it's more useful, it's more useful to team members and to malicious users alike, but it's not useful for passing security audits and certifications.
> Potentially controversial opinion: This isn't really open source.
I know you were looking for this but I don't agree. Let's remind that Open Source fundamentally means _no expectations_. No expectations of support, no expectations of features, not even expectations of goodwill. Whenever a company complains that this or that open-source software doesn't work as expected and should do this, we all shout in chorus "this is open source, take it or leave it". This is exactly the same case here. I know it's frustrating because the feature exists in a fork that happens to be run by the same people, but that is exactly what is permitted by this license.
Does anyone here complain that SQLite isn't _exactly_ open source because they don't ship their full test suite in the open source package (https://www.sqlite.org/th3.html), even though each release passes it ?
> Let's remind that Open Source fundamentally means _no expectations_.
No. Open Source, as defined, is about what the end user is allowed to do with the code they have. That’s it. What you describe is common, but not inherent. There are plenty of exceptions, like if you get Red Hat, you’ll get to have plenty of expectations, and Red Hat is still Open Source.
Please stop the ancient FUD about Open Source means having no support.
When I say open source means no expectations of support I obviously talk about the license the software comes with, not the overall idea and goals that are common in the open source world.
You want support! Great, it exists and can even provided by multiple different actors, with or without expected quality of service, and that's great! But that is not included in the license, you have to find another arrangement on the side. Maybe you can ask nicely and they will do it for free, maybe they'll ask you to pay them in beers, maybe they'll ask for a specific contract detailing everything. Same goes with features, you can ask for new ones but that is not part of the license. That's it, that's all my message was about.
Right, open source, like all software, has a variety of vectors of usability and suitability. Purposefully leaving out features weakens it along some vectors - especially the "I want to modify software I run in production" vector.
I think you'll find all you need to do is compile with `BUILD_TYPE_NAME=enterprise make`, and suddenly all features appear. Whats peoples moral position on opensourcing the features but not including them in pre-built images unless you pay?
I think it's a clever way to support free and open source projects. Free edition is for everyone, trials, demos, etc. Paid enterprise version is for companies that are happy to pay to get some extra value. Build it yourself enterprise version is for people who don't want to pay, people that get less value from the product than the price, hobbyists, etc.
Caddy (a web server) used to do something similar.
They're doing it wrong. There are many successful, profitable companies making open source products with a subset of the features that their commercial offerings have. These guys are intentionally crippling the open source offering. It's practically a bait and switch.
The right way is to release an open source product that is full-featured and robust, and upsell things like support, managed hosting, and the kind of plugins and addons that primarily appeal to enterprise customers (although increasingly the latter are indistinguishable from advanced small users).
It's worse than that, expectation are different and actually doing disservice to the whole open source ethos. I recently heard a couple of regular users talking and equating Free Software//Open Source with Freeware, I didn't bother correcting them because from their perspective the difference is meaningless. Only us geeks care enough, but not enough to go and fork it.
Thanks for highlighting this. It's a ticket from two years ago and this thread is a good opportunity to share more of the context and intention of how we think about Team Edition vs Enterprise Edition.
Also, I don't know if the ticket title is highly accurate--a non-admin can't delete any channel:
1) There is no "Delete Channel" in the UI only "Archive Channel"
2) A non-admin cannot archive any channel, only channels of which they are a member.
3) A non-admin archiving a channel they created is not really an issue, so this ticket is really about a "Non-admin can archive a channel which they are a member of but didn't create" which we've seen can be more helpful than harmful--when someone leaves a team and their out-of-date channels remains anyone can go and archive them without having to find an admin and make a request.
The current wording sounds like non-admins can delete private channels, channels on different teams, channels they're not part of, etc. and in my mind it's not the case. But perhaps other people have a different read?
I think the concern here is a pre-emptive rage-quit of channels. A team member is aware they are about to be let go, and decide to archive every channel they are a part of on the way out.
What controls are in place to prevent this from happening in the Team Edition?
Archiving a channel in Mattermost just sets a flag in the database. Once the bad actor is removed a simple query can restore the channels they archived. Something like: `UPDATE Channels SET DeleteAt = 0 WHERE DeleteAt > [some timestamp]`
There's also a CLI command to restore the channels. While this won't keep it from happening it should get things back to normal fairly quickly.
Wow this is crazy. So the free edition of Mattermost has even less access control functionality than Facebook Messenger? Disappointing.
It seems to me that "open source" is now being used as a marketing label for what used to be known as "shareware" or "trial". You get a trial version of the software (but where you can see the code) and the big essential features you need to pay for.
Open source no longer means what it used to mean.
And for the CEO to join in that ticket discussion and say "yeah it's a bug - there shouldn't be channel admins at all in the free version" basically confirms this.
Don't complain it's missing features! Make them yourself ... but we'll just steal them if they're better than the paid version because hey, open source!
Not a great comment, in my opinion. He does nothing to address the artificial neutering of the community edition, especially when compared to all the open source products that Mattermost uses - as the blog post author's response sets out.
Why is artificial neutering unethical? What’s wrong with it? Change the code yourself or pay the guy. 99% of software only gives you the second option.
