I am supportive of this change, but people should try Zulip before agreeing to this. The conversation model is different than Slack. In slack you can respond inline to a message, but in Zulip each message can become a topic. The UI can be confusing at first because of this.
Maybe we should create a basic setup before fully switching to confirm people would be agreeable? 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. >
