Community Messaging

Back in the old days it used to be that IRC was widely used for messaging by communities. Now Slack is widely used mainly because it has kept up with today’s needs (gives the appearance but is deceptive) and covers all major platforms (incl mobile), whereas IRC has seriously lagged behind and is fragmented. What ends up being very odd is the situation where communities use Slack only for messaging when Slack does far more than that as a ”Kitchen Sink” platform. Somewhat surprising that there isn’t a messaging platform around that is community oriented.

One of the communities using Slack is Kotlin which switched over from IRC back in 2015 for the reasons mentioned above, and because of greater numbers of people using Slack over IRC. In general the situation isn’t good with Slack for the Kotlin community when rules need to be put in place to avoid people getting notified too much, and the message threading doesn’t work in a traditional way like people expect for example. Many Slack issues arise from it trying to replace email which is a fool’s game endeavour. Would rather have specialised communication platforms, that provide a significantly better UX (User Experience) than one trying to rule them all like Slack.

For an open source community like Kotlin to use Slack ends up working against them with being locked into a proprietary platform, which doesn’t allow data (messages, code snippets, images etc) to be easily exported/imported, and will often do things that aren’t in the best interest of the community (eg cannot make improvements to the system, examine the source code for security audits, use open standard data formats for interoperability with other programs/platforms). Slack’s pricing is highly problematic with the archiving situation (10,000 message limit) on the Free plan which the Kotlin community uses, where there is no way to easily export messages without deleting them, and the major scalability issues (eg archive system regularly goes offline). Going to a higher level plan would likely cost around $1,000,000 per year (Kotlin’s slack has over 10,000 members) when from a community POV is a ridiculous price to pay just to have a basic messaging service.

Key Slack Issues

• Acts too much like a ”Kitchen Sink” solution (does far more than messaging)
• Not designed with software developers/communities (incl open source) in mind
• Isn’t an open platform (not open source)
• Difficult to access archived messages (has 10,000 message limit with Free plan)
• Messages aren’t properly threaded (cannot easily follow conversations)
• Lack of fine grain control over notifications (eg cannot turn off notifications for certain channels)
• No proper focus on UX (eg some basic UI functionality is only available as typed commands, which isn’t user friendly)

Other Slack Issues

• Cannot use an existing account (eg Google) to register, must create a separate account with the Free plan
• Desktop app provides a bad UX (doesn’t use native technologies, only web ones)
• All apps (web, mobile, desktop) use a cross platform system (doesn’t allow a consistently good UX across the board)
• User documentation isn’t very accessible
• Slack’s platform doesn’t scale properly
• Can’t use a guest account with the Free plan
• Archive system regularly goes offline
• Doesn’t support Markdown for basic formatting
• Cannot do private hosting (have to use their cloud)

Slack Web App Issues

• App is slow to load
• UI isn’t very discoverable
• Not enough emphasis on ensuring the UI is functional (too much focus on aesthetics)
• Text cannot be turned into a link
• Linked images always have to be displayed

Conclusion

Many communities (especially open source ones) are being placed in a bit of a quandary with having to go with Slack for messaging when it isn’t a good solution. There is a real need for a proper yet specialised messaging platform that is community focused (no hidden corporate agenda), which evolves as community needs change over time. Such a system would have to be open source from the very start, and have a proper multi platform approach that allows for a consistently good UX regardless of the platforms that users are on. Also the system would need to easily allow for a proper work/life balance that isn’t in the user’s face.