Gentoo Linux was a small open source project with about 12 developers when I joined. The community was growing — users were showing up, filing bugs, asking questions — but there was no organizational infrastructure to absorb that growth. Every developer was focused on their own packages and responsibilities. Nobody was looking at the whole system.
There was no authority to claim. No title that would make people listen. Just a project that needed to scale and no one thinking about how.
I took the job nobody wanted. I volunteered to curate the entire Bugzilla bug database. Everyone else was focused on their specific domains. I wanted the panoramic view — what users were experiencing, what they needed, where we had gaps, and where the organization was failing them. Bugzilla was the single best vantage point for all of it.
I built contributor pipelines from the user community. I was on IRC across every timezone, every day — talking with users, understanding what they knew, identifying people with both capability and motivation. The user community was the talent pool; someone just needed to be present enough to spot the right people.
I created low-friction entry points. I wasn’t a Perl user, but I saw through Bugzilla and IRC that users needed better Perl module support. So I created the perl-mod.eclass — a structural template that made it trivially easy for a contributor to own Perl module packages. Then I found the right person in the community and handed it over. Same pattern with the commonbox eclass for window managers (Blackbox, Fluxbox, and others). Same with X. Same with system tools. I built the scaffolding, recruited the person, and moved on to the next gap.
I expanded architecture coverage. PowerPC was handed to me directly, but the model was to groom teams, not accumulate ownership. I recruited and developed maintainers for SPARC, ARM, and other architectures — each one expanding Gentoo’s reach to a new hardware platform and a new user community.
I held the organization together through a crisis. When the Ynot fork happened, it threatened to split the project. Developers were uncertain, demoralized, considering leaving. I was present — literally available across all timezones — to talk with developers individually, hear them out, and keep the remaining team cohesive. The project survived because the relationships held.
Gentoo grew from approximately 12 developers to over 250 during this period. The project expanded from a single-architecture Linux distribution to a multi-architecture platform supporting PowerPC, SPARC, ARM, and more.
The organizational structures I built — the eclasses, the contributor pipeline model, the architecture team pattern — are still in use over 20 years later.
I had no formal authority over any of these people. The scaling happened because I could see the whole system, identify where it was incomplete, create structures that made contribution easy, and find the right people to own each piece.
This is the earliest and clearest example of the pattern that runs through my entire career: take the vantage point no one else wants, use it to see the full system, build the organizational structure to fill the gaps, recruit and develop people to own each piece, then move to the next problem.
The same approach — at different scales and with increasing formal authority — produced the Brontes support org, the Engine Yard turnaround, the Gap stabilization, and the New Relic growth work. The pattern has been consistent for 25 years. Gentoo is where it started.