I think they are playing hard ball for a better acquisition deal, but they risk being irrelevant before ever getting a better deal.
Make it free up to 1000 concurrent users, then $x/MAU at plateaus /w reduced rates + $ for extras such as white labeling.
The current in-game Discord overlay is an end-user 'hack' by comparison. Games/applications are notorious for limited/locked-in communication systems and are non-trivial to implement internally. See Star Citizen's 'Spectrum' developed by Turbulent as an example of complex in-house solution.
Heck, Epic provides grants for this exact sort of development. https://www.unrealengine.com/en-US/megagrants
If anyone from Discord is reading this feel free to contact me for bizdev/implementation advice :D
This is just such a bizarre statement. To exclude Unity while including Lumberyard in the condition of "commonly used game engines" makes zero sense. Unity is well known to be one of the most used game engines. Lumberyard in contrast has (according to wikipedia) has a single released game.
Discord has 14x more active users than Slack.
Discord has a technology and feature superset over Slack.
The Discord audience is becoming the professional audience just about right now.
If they can parley this into solid trust over the coming mid-term, without any major security breaches, then they are set.
(plus the other feature options that were mentioned E2E, stickers etc... they have room to grow. There is already some payment duct-tape setup. I am sure that, barring a complete fuckup, discord is going to do very well.)
From what I understand Slack's model is based on selling plans to teams and companies. Within that framework users are actually representing a real monthly recurring dollar value. I don't think Discord is anywhere close to this.
FB rev/yr $90b LinkedIn rev/yr $9b
* Slack threads are an amazing feature and frequently used on the Elm slack. One discussion or one person's question can become a thread and then the channel won't be continuously pinged by the ongoing discussion, plus multiple discussions can happen in tandem. I remember when Slack added this feature lots of people including me were a bit disdainful. It feels like an awfully hard new UI pattern to get used to after so many years of single-threaded conversation on e.g. IRC. But now I would strongly oppose moving to Discord only because of this issue.
* Slack also has a different model for channels on a server. There are probably caveats to these statements, but roughly speaking the default assumption on Slack is you don't belong to any channels in a server but can join what you want or what is configured for you, and on Discord the assumption is that you belong to everything and sometimes a Discord server will configure it so certain things are hidden. For a big organization like a programming language or a company the Slack model is preferable.
(If you like threads, be sure to check out Zulip.)
1. Infinitely-nestable threading, a la Reddit and HN (and probably other sites first, but those are the ones I've used it the most)
2. Single-level nested threading, a la Slack (and maybe Facebook? I forget how much nesting they allow)
3. Discord/IRC-style replies (like you mentioned) where the responding message just quotes the original, possibly with a slight UI indication to make it easier to parse.
I guess you could argue that Zulip-style threading is a fourth option, but IMO that's closer to a bulletin board than a group IM, because you can't have a message that isn't in a thread, so almost no discussion happens at the top level of a given channel.
What's interesting to me is that the split between who prefers which style of threading is pretty close to even.
I suspect, although I'm not sure, that it comes down to two things: the size of the groups in which you normally participate, and how closely-knit they are. A small, closely-knit group would likely prefer Discord/IRC-style threading, because sub-discussions are more likely to be of interest to those not participating, and the added noise isn't too big of a deal if the group is small.
A larger, but still closely-knit group would probably prefer Slack-style threading, because even though sub-discussions might still be interesting to more than the immediate participants, but a single message space starts to become unusable with more than a couple of sub-discussions going on.
A large and loosely-knit group is is likely to prefer Reddit/HN style discussions (and in fact those are two examples of large and loosely-knit communities) because a sub-discussion is less likely to be of interest to a significant portion of the main discussion's participants.
Maybe, at least. It would be interesting to do a poll and see how those factors correlate.
Wait, are we thinking about the same very limited concept of one additional layer down? It feels like they must have intentionally developed it badly, so that you cannot create a thread to reply to a message that is inside a thread. While Discord does not have threads, I would not at all call the Slack solution amazing. It's actually quite a poor solution and an artificial limitation.
We also don't even need to get started on performance. The comparison Slack vs Discord in terms of performance is like comparing 2 completely different things. Switch a channel in Slack? Merely takes a few seconds :D
> For a big organization like a programming language or a company the Slack model is preferable.
And yet communities decide otherwise (examples: Pharo community, general progamming community servers and probably many more). Slack does not handle Markdown well at all, while in Discord it almost always does what you expect, including escaping of special characters and highlighting code blocks properly, which is a must have for programming languages. Basically I would never choose Slack over Discord, because of how crappy they implemented these things. It really shows no attention to the details. In almost any programming language, one can find a markdown parser, that works better than what Slack cobbled together.
Now those are very basic things to get right in any messenger like application, but it is indicative, how bad these things work in Slack.
Dealing with the difference in default channel permissions requires an extra minute or two of work. Adding user-controlled joins means grabbing a bot and spending a few more minutes. For a big organization it's absolutely negligible.
Large organizations are far more likely to buy a solution that works for 80% of the use-cases out of the box, and then live with not fulfilling the other 20% by training their users around it (and constantly complain about the users) - especially if that means you can move accountability to the supplier in the contract. WHICH 80% of functionality is important is decided by what you best can sell to top management.
The sweet spot for quick decisions and technological adaptions are SMBs up to about 500 employees.
> The Discord audience is becoming the professional audience just about right now.
Also, and I don't mean this flippantly - stickers and shit. People want to look different, and selling a sticker or custom emoji pack would bring in money. You see this with Nitro a little, I believe they're experimenting with it
Edit: If you want to confirm this you can use their data export feature and check it. One good thing about that tool is that the data is well formatted and easy to parse
Discord's permission system is one of its killer features, IMO.
Discords roles are really well done and make totally sense in a hirarchical chat system. However i don't see this being sensical in a professional (flatter) environment.
There are certainly bots that automate that on Discord. A bot can open the private channel, add the temporary role, assign the temporary role, then close all that stuff when the chat is done. If it's a voice chat you don't even need a temporary role, the bot can "drag" users to/from other voice chats, so you can have a "public" lobby for the private voice rooms that only the bot can fill. (I've been in game servers built that way.)
> What if you just want to join a channel to drop one line and leave, where did they put that role bot button thingy again to automatically assign roles?
Discord just released a much more comprehensive slash-command system. It will be a while before more bots migrate to it (and away from Reaction "buttons" and weird individual choices for command prefixes), but it supports now some powerful auto-complete/help prompts and argument schema validation.
Maybe Discord could monetize in game integration for its voice network, especially on console games.