I had no real concerns with Slack from a development perspective. If Teams wasn't such garbage at basic things like markup and pasting screenshots, we might still be using it for everything. We went Skype => Slack => MS Teams => Mattermost for our developers. But perhaps other people have a different read? The current wording sounds like non-admins can delete private channels, channels on different teams, channels they're not part of, etc. #Mattermost features archive#Īlso, I don't know if the ticket title is highly accurate-a non-admin can't delete any channel:ġ) There is no "Delete Channel" in the UI only "Archive Channel"Ģ) A non-admin cannot archive any channel, only channels of which they are a member.ģ) 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. 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. īut I agree with you that that level of feature-crippling makes me want to all it more like demoware than open source. What makes electronic resources different?". 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. 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 don't think that would have happened had we taken Mattermost's aggressively Open Core approach. On the flipside, Zulip has been very successful in building a large community of volunteer major contributors (some handy stats are in our release blog posts, e.g. It's commercially more difficult because it means right now we have users at governments and Fortune 500 companies and whatnot who've reached out to tell us they how much they love Zulip, but nonetheless aren't paying us anything. Even obviously enterprise features developed entirely by our paid team, like SAML authentication are FOSS, and our plan is for it to remain that way forever. But it isn't really FOSS, and I think the difference is important, which is why Zulip is following the commercially more difficult path of 100% FOSS. It's definitely a lot better from a freedom perspective than proprietary software, so I don't want to be too down on it. #Mattermost features software#You get all the marketing benefits of being "open source", but few IT departments will use your software in production without buying the enterprise license, so you get most of the revenue you'd have had if you were closed source.įolks have different perspectives on Open Core. This is, fundamentally, the Open Core business plan, which Mattermost is executing quite successfully.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |