James, that’s a really good point about the-asf.slack.com having a paid tier with full history. Moving our Apache Grails committer-level and PMC channels over there makes total sense from an administrative and security standpoint, and we should definitely consider utilizing it for internal discussions.
However, as you noted, the guest restrictions mean it doesn’t solve our primary issue: *our external developer ecosystem*. End-users wouldn't have a self-service signup link, and managing invitations for thousands of community members as "guests" would be an administrative nightmare. If we split the community, putting committers on ASF Slack and the public on another platform, we risk fracturing our communication channels even further. If we transition to Zulip, my preference would be to keep both public support and committer/PMC collaboration in one unified, searchable place. I agree with James D and Walther, that we get the Zulip sandbox up and running first so we can evaluate it firsthand. Should I go ahead and do that? Den tors. 2. jul. 2026 kl. 18.10 skrev James Fredley < [email protected]>: > some additional details for the discussion. > > the-asf.slack.com is not on the free plan like, https://grails.slack.com/. > > We should consider moving Apache Grails Committer level channels over > there to receive full history and other features. > > Also on the-asf.slack.com: > > Non-Apache ID / end users (guests): Yes, they can join, but only as > Guests. An existing full Member must invite them specifically to one or > more channels. Guests have limited access — they can only see and > participate in the channel(s) they were invited to. They cannot freely > browse or join other channels. No public join link or self-service signup > for guests. > Guests are intentionally limited to the channels they are added to. > > James > > On 2026/07/02 11:09:42 Søren Berg Glasius wrote: > > Hi everyone, > > > > Several PMC members (including myself, jdaugherty, jamesfredley, and > > walter) and membmers of the Grails Slack community recently had a > > discussion on Slack regarding the long-term viability of our community > chat > > infrastructure. I want to bring that discussion here to the wider dev > list > > to formalize a proposal. > > The Problem > > > > We are currently hitting the ceiling of what Slack’s free tier can offer > an > > open-source project. The 90-day message retention limit means years of > > critical technical troubleshooting, community onboarding, and > architectural > > context are permanently lost. While archive tools like > > https://www.linen.dev/s/grails help, they are a band-aid solution. > > Upgrading Slack is financially impossible for a community of our size. > > The Proposal: Transition to Zulip > > > > I are proposing that the Grails community migrate its primary chat > > operations to *Zulip*. > > > > *Why Zulip?* > > > > - > > > > *Full Searchable History:* Zulip sponsors open-source communities by > > providing their Standard Plan for free, giving us an unrestricted, > fully > > searchable history. > > - > > > > *Asynchronous-Friendly Threading:* Zulip’s topic-based threading model > > acts like a hybrid between real-time chat and a mailing list, which is > > significantly better suited for deep technical work than Slack's > > chronological noise. > > - > > > > *Hosting Options:* We can utilize Zulip’s hosted OSS plan or look into > > self-hosting options (potentially via ASF infrastructure, which we can > > raise at the roundtable). > > > > Addressing PMC Concerns (Community Retention) > > > > A major point of discussion from James Fredley is the risk of community > > fragmentation. The Grails Slack currently shows ~4,600 members, and a > > migration will inevitably result in a drop in total numbers. > > > > However, our actual *active* core is a fraction of that size. The > thousands > > of inactive accounts shouldn't block us from providing a superior, > > persistent knowledge base for the developers who are actually here and > > contributing. A smaller, highly active, and archived community is vastly > > more valuable than a massive, silent one with a 90-day memory. We have a > > complete list of members, and could send everyone a one-time-mail, > > notifying them of the change. > > Proposed Transition Strategy > > > > To minimize user loss, we would not do a hard cutover. Instead, we > propose: > > > > 1. > > > > *A Phased Migration:* Keep the Slack workspace active for a 90-day > > transition period. > > 2. > > > > *Persistent Guardrails:* Set up automated, recurring pings in all > major > > Slack channels directing users to the new Zulip instance. > > 3. > > > > *Data Import:* Explore importing our existing Slack/Linen history into > > Zulip so we don't lose current context. > > > > Next Steps > > > > I would like to open this up for discussion here on the dev list, with > the > > goal of bringing a formalized plan to the next weekly roundtable meeting. > > > > Please share your thoughts, concerns, or objections. > > > > -- > > > > Best regards > > Søren Berg Glasius > > > > Apache Groovy™ and Apache Grails® PMC > > --- Press ESC once to quit - twice to save the changes. > > > -- Med venlig hilsen, Søren Berg Glasius Hedevej 1, Gl. Rye, 8680 Ry Mobile: +45 40 44 91 88 --- Press ESC once to quit - twice to save the changes.
