Hello everyone, My name is Yongjun Hong, and I’m a software developer based in Korea. I’m also a committer on the Seata (incubating) project. Above all, I’m a developer who loves open source and is deeply interested in the health and growth of the open source ecosystem.
Lately, I’ve been thinking a lot about a problem I’m sure many of us have felt: the slow drain of knowledge and context from our projects. I have an idea to tackle this, tentatively called Apache Compass, and I’m looking for the first few people to help me shape it. Once we have a core team and a clearer vision, the ultimate goal is to propose this formally to the Apache Incubator and grow it with the community's guidance 🚀 Here’s the problem I’m hoping to solve : So many of our projects run on the passion of just a handful of key maintainers, right? The real problem is that so much of the *"why" *the history behind a big decision, the design philosophy lives only in their heads. When they (inevitably) have less time or step back, that crucial knowledge is often gone for good. It creates an information imbalance, makes it incredibly hard for new people to step up, and puts the long-term health of our projects at risk. The core idea: The heart of my idea is an AI assistant I'm calling the "Maintainer's Co-Pilot" (MCP). But instead of trying to automatically scrape decades of data (which sounds impossibly hard), my proposed approach is to start by *teaching* it. The idea is that we, as maintainers, would feed it the important stuff: PMC meeting minutes, design documents, and architectural decision records (ADRs). (This is getting easier now that tools like Google Meet can automatically generate meeting transcripts). The process would be like curating the project's 'brain'. With that foundation, imagine if we could: - Have the MCP draft a new ADR after being fed the notes from a few different design meetings. - Let a new contributor ask, "Hey, what's the history behind the new auth module?" and get a real, sourced answer like, "Based on the PMC minutes from last September, the team chose option A because..." - Connect the dots between scattered discussions on a single topic that happened months apart. Why start this at Apache? I honestly think the ASF is the only place this could work. This isn't just another tool; it's a strategic asset to help us preserve our own collective intelligence. The wealth of knowledge in our project archives is the perfect ground to build and prove this model. And way down the road, I dream of the framework we build here being adopted by companies to manage their own critical internal knowledge, all built on a foundation proven at the ASF. This is just the start of a conversation. I truly believe an idea like this could help reduce maintainer burnout and make our entire ecosystem stronger. Long term, I also believe that Apache Compass could be valuable even in companies that have been running for many years, helping them preserve and manage critical knowledge over time. 👍🏻 Just to be clear, the features I mentioned above are really just examples to get the ball rolling. The very first step for anyone who joins would be to figure out what we should actually build together. So at this stage, I’m much more interested in feedback on the general vision. Is this a problem worth solving? than on the nitty-gritty details of any single feature. I’d love to hear what you all think, the good, the bad, and the crazy ideas. 😀😀 Most of all, I'm hoping to find a few mentors and collaborators who feel this is a problem worth solving with me. If you’re interested, you can reply to the mailing list or reach out to me directly via email. Thanks for your time, Yongjun Hong / YongGoose <https://github.com/YongGoose>
