4 ms·

Hey! Thanks for sharing your concerns. First, most conversations in Slack or Discord happen as just chats in channels. Not as threads. The thread implementatio

by mrjn 3y ago

Hey! Thanks for sharing your concerns. First, most conversations in Slack or Discord happen as just chats in channels. Not as threads. The thread implementation that they have is actually a "hack" on top of their "chat in channel" design. I'm part of around 50-ish Slack and Discord communities -- to make threads work, the moderators have to manually enforce them -- tell the users continuously to keep things in threads. As a member of the channel, you don't get any notification, or any real-time update about what's going on in a thread, only a number. Discord's "thread-only" channels are a deviation from a chat platform, and a forum of sorts -- it's a hacky design, I for one, I don't like it. You correctly point out that Struct also just shows a number -- but that's the knowledge base product (stage 1) of Struct. The chat platform (stage 2) would have liveness indicators, and threads would be presented in a real-time format. For context, I have put an example in the blog post comparing a Slack thread against what would be the equivalent Struct thread -- the difference in context is stark. Note that these are chat platforms, so not all context is in the first chat message. Chat messages by default are short-form. It's only together that they add valuable context, not alone. The thread based pricing would actually be much cheaper. Take Typsense community, they have thousands of users, but say 100 are active each month. That'd cost them ~$800 per month via Slack. They have ~600 threads right now, which would cost them ~$100 in Struct -- that's about an 8x difference. Also, with Struct -- there's a huge "discoverability" factor -- so every new question doesn't need to be a new thread, it could share existing thread with the same topic. I have no doubt, thread based pricing would be a lot cheaper. In any case, we'd be adapting the pricing model as things become clearer with usage.

alfredm 3y ago
Appreciate the in-depth reply. I get what you're saying about the challenge of getting people to utilise threading well, but my experience (also in tens of communities) does not align quite as strongly as yours on Slack. There are frequent times where a reply goes in the channel as opposed to in a thread, yes, but in my experience that is far from the norm and isn't really a major issue. However, the threading approach on Discord definitely is less ergonomic in terms of starting one and I quite rarely see people utilise them in channels, that's true. I can't say I understand what distinction you see between Discord's forum channels and the proposed behaviour of Struct's upcoming chat platform. > would have liveness indicators, and threads would be presented in a real-time format. I do get frustrated that Slack doesn't give a clear indicator of the last message, but Discord does have various ways of indicating that: "There are no recent messages in this thread." (literally just copied that from a thread on Discord), including having the forum channels be ordered by most recent updates. On the topic of pricing, I could see it being better for large but inactive communities, provisioning a paid Slack workspace for an open-source project is often inviable after all. But for companies and teams that actively use Slack as their main source of communication, I'm not sure I'm convinced by the numbers right now. Typesense seems to have had those ~600 threads in 4mo (the earliest one I can see on the index), which will be an ongoing monotonically increasing cost even if their users stagnate. However, I think those ~600 threads are not at all representative of the average entity that uses Slack for professional purposes; our Slack for example sees thousands of messages a day (a large amount coming from bots that we use to notify about various things) but I appreciate that is unlikely to be a use-case Struct is aiming to support. So if we ignore the bots, there are still tens of threads a day for a team under 10 at the moment, and many companies below 100 people will see hundreds of threads a day. If we assume a conservative 25 threads a day for 50 people, then in 4 months you'd see 3000 threads, which to my understanding of the pricing would be ~$500 in Struct, compared to ~400 via Slack. I'll admit those numbers are actually a lot closer than I initially thought upon looking at your pricing, but that's assuming what I believe to be a very conservative amount for a few people, and giving up a lot of the other benefits of having Slack / Discord (interfacing with bots, getting other kinds of notifications), and after 8 months you'd be paying well over double without starting to "forget" a large amount of your history.
- mrjn 3y ago
  Re: pricing. You might be right, but on the other hand, most conversations might be limited to a few new threads on a daily basis. It's hard to know without actual numbers, which we'd only get after we onboard a bunch of companies. Over the course of a year, an active user would be charged ~$96 by Slack. At 13c per thread, that'd be equivalent of the user adding >700 threads in the year. I'd say that's pretty generous -- but, again hard to know without actual data. Most importantly, if the pricing model doesn't seem to work for companies, we'll adapt. As mentioned in the post, we're exploring new grounds here in terms of pricing, and the ultimate goal is to find a pricing model that works for teams, communities and support. We're motivated by the underlying belief that the charging per user model doesn't work, and we need something better.

by mrjn 3y ago

alfredm 3y ago

Appreciate the in-depth reply. I get what you're saying about the challenge of getting people to utilise threading well, but my experience (also in tens of communities) does not align quite as strongly as yours on Slack. There are frequent times where a reply goes in the channel as opposed to in a thread, yes, but in my experience that is far from the norm and isn't really a major issue. However, the threading approach on Discord definitely is less ergonomic in terms of starting one and I quite rarely see people utilise them in channels, that's true. I can't say I understand what distinction you see between Discord's forum channels and the proposed behaviour of Struct's upcoming chat platform. > would have liveness indicators, and threads would be presented in a real-time format. I do get frustrated that Slack doesn't give a clear indicator of the last message, but Discord does have various ways of indicating that: "There are no recent messages in this thread." (literally just copied that from a thread on Discord), including having the forum channels be ordered by most recent updates. On the topic of pricing, I could see it being better for large but inactive communities, provisioning a paid Slack workspace for an open-source project is often inviable after all. But for companies and teams that actively use Slack as their main source of communication, I'm not sure I'm convinced by the numbers right now. Typesense seems to have had those ~600 threads in 4mo (the earliest one I can see on the index), which will be an ongoing monotonically increasing cost even if their users stagnate. However, I think those ~600 threads are not at all representative of the average entity that uses Slack for professional purposes; our Slack for example sees thousands of messages a day (a large amount coming from bots that we use to notify about various things) but I appreciate that is unlikely to be a use-case Struct is aiming to support. So if we ignore the bots, there are still tens of threads a day for a team under 10 at the moment, and many companies below 100 people will see hundreds of threads a day. If we assume a conservative 25 threads a day for 50 people, then in 4 months you'd see 3000 threads, which to my understanding of the pricing would be ~$500 in Struct, compared to ~400 via Slack. I'll admit those numbers are actually a lot closer than I initially thought upon looking at your pricing, but that's assuming what I believe to be a very conservative amount for a few people, and giving up a lot of the other benefits of having Slack / Discord (interfacing with bots, getting other kinds of notifications), and after 8 months you'd be paying well over double without starting to "forget" a large amount of your history.

mrjn 3y ago
Re: pricing. You might be right, but on the other hand, most conversations might be limited to a few new threads on a daily basis. It's hard to know without actual numbers, which we'd only get after we onboard a bunch of companies. Over the course of a year, an active user would be charged ~$96 by Slack. At 13c per thread, that'd be equivalent of the user adding >700 threads in the year. I'd say that's pretty generous -- but, again hard to know without actual data. Most importantly, if the pricing model doesn't seem to work for companies, we'll adapt. As mentioned in the post, we're exploring new grounds here in terms of pricing, and the ultimate goal is to find a pricing model that works for teams, communities and support. We're motivated by the underlying belief that the charging per user model doesn't work, and we need something better.