I second that. Creae a Grails Zulip Group and we test it out. Regardless a messaging searchable application takes us into the 21st century.
Walter > On Jul 2, 2026, at 7:07 AM, James Daugherty <[email protected]> wrote: > > 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. >>
