In "The Birth of My Homelab" I mentioned a new project called Mowa, short for MacOS Web API, and said more would come in a follow-up post. That was August 2025. This is the follow-up.

Kairos is at 100% on the OpenSSF Best Practices badge, at the passing level. I checked the project page directly rather than take an internal report's word for it: badge_percentage_0: 100, badge_level: passing. The rest of the week went to supply chain fixes, maintainer lifecycle documentation, and closing out the monorepo consolidation.

Last week ended on 4.2.0 shipped and a reviewer agent reading every change before I do. Both held. riscv64 moved the most this week: it now builds on every push instead of only at release time, and there is a public invitation out asking anyone with real RISC-V hardware to test it.

I was putting Home Assistant OS on a spare Raspberry Pi 4, booting off a USB SSD, with an HDMI capture card plugged into the board so I could watch the boot on my main monitor. I powered it on, console output started scrolling, and about four and a half seconds in the screen went to NO SIGNAL and stayed there. Every boot attempt did the same thing.

Last week ended on a version that had shipped but not released, and a review load I was not keeping up with. Both moved. 4.2.0 is out, reset works again on non-UKI installs, fork pull requests finally get CI, and there is now a reviewer agent reading every change before I do. 34 changes landed against Kairos this week, up from 19.

Last week I wrote that I wanted to get the agents working on actual Kairos tickets, and that the next post would either have results or another pile of postmortems. I'm happy to say it has results. It has a few postmortems too, but the results came first this time.

I picked up Ruby because of how expressive it was. Writing it just felt nice, in a way that other languages did not. Later I found out that was deliberate: Matz designed Ruby so that programmers would enjoy using it. I then spent the better part of a decade writing Ruby and enjoying it.

The email landed on Friday, 17 July 2026, three days before I was due to leave for vacation. The sensible thing would have been to file it away and deal with it when I got back. Instead I spent the next two evenings standing up a system so I could start a small agent factory before I disappeared for a couple of weeks.

Last week I realized I had put myself in front of people 30 times since I started promoting Kairos 3 years ago. That's roughly 10 times per year, which I think is a fantastic number for me.

When I watch teams evaluate open source projects, I notice most of them check two things: the license, and whether the project looks active. Commits in the last month, responsive maintainers, a reasonable release cadence, stars and contributors trending the right way. Both of those signals matter - a project without an OSI-approved license carries a different risk profile than one that has one, and a project that hasn't been committed to in a year is probably not a safe bet.

But those two signals, even taken together, don't tell you much about who actually controls the project, who gets to decide its direction, or what happens if the company behind it changes its mind. That's governance, and it's the signal most evaluations skip - not because people don't care, but because it's harder to check than licensing or commit activity, and nobody has really taught them where to look.

This post focuses on the CNCF and friends - the CNCF specifically, the Linux Foundation umbrellas nearby (LF Edge, NeoNephos), and a couple of LF projects that share governance DNA. That's the neighborhood I'm invested in at the moment. There are plenty of good governance stories in other foundations and in projects outside any foundation at all, but a full tour would make this post much longer than I want it to be. The questions I end up with transfer; apply them wherever you're evaluating.

What governance actually is, and why it matters now more than ever​

Governance is the set of rules determining who makes decisions about a project. Who merges code. Who decides the roadmap. What happens if maintainers disagree, or if the company behind the project is acquired or changes direction. These procedural questions are what determine whether software you depend on will still be serving you in five years.

Distributed governance - multi-vendor, auditable, with decisions made in public - has real benefits. The project outlives any one company's interest. Decisions get made by people with different perspectives, which generally produces better technical outcomes. You get a legible, predictable path for raising issues and having them addressed. And you get something harder to name: the quiet confidence that you're not betting your platform on one CEO's roadmap.

Concentrated governance - typically single-vendor, often implicit, usually fine right now - has its own benefits. Decisions are faster. Direction is clearer. There's no committee. A small team that knows what it's doing can move a project forward quickly, and plenty of excellent software has been built this way. The trade-off is that you're betting on that team's continued interest, alignment, and financial health. When those align with your own interests, it's a great bet. When they don't, you have limited recourse.

Neither are right or wrong. They are just different models that have different pros and cons in this context.

What has changed recently is that the volume of code available is about to increase dramatically. AI-assisted development is going to produce a lot more code - and a lot of that code will be published as open source by individuals or small groups who haven't put any governance structure in place, because there hasn't been time to. At the same time, existing open source projects are going to see more contributions flowing in than their maintainers can realistically review. In both cases, governance is the thing that helps. For new projects, governance is what distinguishes "published as open source" from "maintained as open source." For existing projects, the right governance structures are how you absorb a surge of contributions without losing the quality bar.

That shift is what makes governance checking more load-bearing now than it was a few years ago. "It's open source" used to carry an implicit governance signal - if something was open source, there was probably a person accountable to a community somewhere. As the total pool of open source code grows faster than the pool of accountable maintainers, that implicit signal weakens. Foundations are one of the more reliable ways to tell the difference between "open source with real stewardship" and "open source with whoever is around."

That's the context this post is set in.