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.
