I wanted to share a few thoughts on maintenance and community development that I think are relevant to this group and that thread.
Having spent 20 years building developer tooling, maintenance has always been a major challenge. Early on, tools like Airflow’s Breeze were heavily dependent on a few individuals, creating a single point of failure (SPOF). While building a dedicated internal team helped, it required contributors to digest extensive documentation just to make basic changes. Since the beginning of the year, however, AI agents have significantly shifted this dynamic. We now receive around 10 high-quality PRs a week for Breeze—adding support for environments like Colima—from first-time contributors. These agents leverage our Architecture Decision Records (ADRs), documentation, and test harness to understand the codebase and generate contributions quickly and with **great** quality. Contributors can then focus on specifying their needs. This shift mirrors the early days of open source, where users directly fixed the issues they encountered, but at a much faster pace. Instead of being the sole maintainers or primary creators, our role has evolved into reviewing contributions and validating high-level assumptions. IMHO Moving forward, the focus for developer tooling (and OSS in general) shouldn't necessarily be expanding central teams that are the only ones developing stuff. Instead, the focus should be on building strong specifications and automated harnesses. This enables a community of custodians to oversee the project's direction while agents handle the heavy lifting of implementation. And those custodians do not even have to be experts in the tooling or language they use - as long as they have the right harnesses in place. The "experts" should rather focus on building and maintaining the harness rather than the tool itself, to ensure quality and production readiness. I believe this approach aligns well with traditional open-source values, making contribution far more accessible and sustainable. I think it's high time we shift our mindset and rethink tooling / OSS creation. Best, Jarek On Mon, Sep 14, 2026 at 5:17 PM Dave Fisher <[email protected]> wrote: > > > > On Sep 14, 2026, at 5:12 AM, Rich Bowen <[email protected]> wrote: > > > > > > > >> On Sep 10, 2026, at 12:00 PM, Rich Bowen <[email protected]> wrote: > >> > >> I’m not at all opposed to this path, but I have not the vaguest idea of > where to get started, as everything I’ve done to date is just the python > scripts in https://github.com/apache/comdev-metrics > > > > So, having thought about this over the weekend, my biggest concern here > is maintenance. I want to be sure we don’t end up in a situation where only > you (Sebb) knows how things work, and then we’re back in the situation that > we are with Whimsy, Projects, Reporter, and so many other tools that have a > single knowledge-holder dependency. So, I guess what I’m saying is, please > document exhaustively, and leave hints on anything that isn’t terribly > obvious. I used to be a software developer, but haven’t really been one for > many, many years. > > The Tooling team is following along. We plan to have much improved project > data based on releases along with release data. I was thinking we could > find some time in Glasgow to discuss and maybe hack on this. > > Best, > Dave > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
