I maintain over 200 packages for Alpine Linux across the community and main repositories, with roughly 250 in various stages of completion when you count the draft MRs waiting in the queue. I've been doing this for close to a decade. It started because SBCL was broken; A friend and I relied on it as a build dependency for this crazy lisp powered drive thru timer we tried to build a business around. With the package had been dropped, and the builds were failing on every architecture I cared about, the only thing I could reasonably do was fix it. So I did and took ownership. The project that sparked all of that is long since abandoned, but the packaging kept going.

What I maintain

The breadth is a natural consequence of using Alpine for everything. If I need it and it isn't packaged, I package it. The full listing is the best way to see what I'm responsible for at any given time, but broadly the packages span programming language implementations and their ecosystems, infrastructure and operations tooling, fonts, retro and gaming software, legacy hardware support, and a handful of tools I've written myself. SBCL was the first of many. Everything after that was just the same impulse applied to whatever I happened to need next.

Every additional package became a crash course in how a piece of software is built, what it depends on, and how it fits into a larger ecosystem. Maintaining this many of them means I've read a lot of build systems, tracked a lot of upstream projects, and debugged my share of cross-compilation and musl compatibility issues. That's a form of systems literacy that's hard to get any other way, and it's one of the reasons I keep doing it.

How I manage it

At 200+ packages you need a system or you drown. I wrote maintained.sh, a shell script that reconciles my local aports fork against my package list, queries Repology and upstream RSS feeds for version changes, and stores everything in a recutils plaintext database. It's ugly and I kind of love it because of that. It has been keeping me sane for years. The database it generates lets me quickly check what's outdated, what's missing RSS tracking, and how many packages I'm actually responsible for at any given time. Plus a whole lot of neat automation around handling the MR queue and moving packages between repos. Some day I'll rewrite it as a standalone tool, maybe soon.

The community part

I would not be able to maintain any of this alone. Other Alpine packagers pick up MRs I miss, fix things I wasn't aware were broken, and bump versions when life gets too busy. That's how healthy distribution packaging works. I got into this because someone before me stopped maintaining a package I needed, and the whole reason the ecosystem survives is that people step up. I try to be one of those people as consistently as I can, and I'm grateful for every person who has done the same for the packages I'm responsible for.

None of this work would be possible without the Alpine Linux team who has advised, assisted, and helped maintain these packages tirelessly when life has gotten too busy to handle them alone.