nitro porter

Apparently I channel grief into a pathological need to build.

I took Monday off work. It marked two years since Kyle died and didn’t want to think about work. But what did I want to think about?

It’d been nearly a year since I meaningfully participated in the open source community for Vanilla Forums. Two years since Kyle was killed also marks two years since I did meaningful work at my former employer, so it’s a short leap to checking in there and seeing where things are. I spent some of my morning clicking around the forum and their open source code repositories.

By the time I finished lunch, I realized no one had released a new version of the Vanilla Porter tool since I left. It’s an impressive bit of code: It can take 30 different web apps and convert their data to work with Vanilla or Discourse. It’s essentially a migration tool, but the most impressive one I know to exist. It’s notoriously difficult to migrate a community between platforms, and Vanilla Porter provided a way to make that process much simpler.

Competitors even used it to migrate folks to their platform! Because it funnels 30 apps into one, all they then need to maintain is one import path (Vanilla to their platform). We did all the work, and the entire Internet benefits. Gold-standard of an open source project, really. I co-authored the earliest version back in 2010 and was the primary maintainer for five years, later handing it off to my team.

I likewise noticed there were several open code contributions on the project that no one had bothered to review and incorporate, some dating back a year a half. And really, it’d been five years since any maintenance of significance had been done. It’s wasn’t a modern PHP project by a long shot. Much of what was clever in 2010 looked decrepit in 2021, and it would be a huge amount of work to modernize.

It was about 1pm when I decided that would be fun.

A fairly big part of my job this past year has been modernizing older PHP projects, applying better coding practices, and socializing those changes on their respective teams. Just these last few weeks, I had to do it again from scratch… on an import tool, of all things. Many of the problems I saw in Vanilla Porter suddenly dovetailed with issues I wanted to solve anyway. That, and I was suddenly nostalgic for my old project, and sad about how it was being neglected.

At its core, Vanilla Porter was about data portability for communities. “It’s YOUR data” was a slogan I championed at Vanilla Forums from the day I started until the day I left. The greatest disservice we ever did the project was get a bit salty about other projects using it (ahem, Discourse) rather than embracing opportunities to decouple it from Vanilla specifically. As time went on, it was approached more as a defensive tool than a contribution. Several packages developed against what we deemed “enterprise” competitors remain closed-source and were never included in the public project. As if that was helping us make sales. In retrospect, the logic was bananas. But it took me two years of reflection to realize a lot of things like that. Or rather, to let go of the worst ideas my head got filled with from working in a startup.

Here in the waning months of 2021, I can finally viscerally remember why I started working on Vanilla in the first place: community is important. And a critical piece of a community existing online is the ability of it to change platforms at will. It’s not just freedom of choice, it’s freedom of survival. Platforms fold or change direction without notice all the time. If your community’s history is locked behind a proprietary lock and key, you can’t escape without giving it all up. As someone whose community history was once lost, I cannot abide the idea of it.

By the end of Monday, Nitro Porter was born. I forked the project I’d cleverly named at the pinnacle of my craft beer nerd days and gave it a fitting sequel moniker. I removed all references to Vanilla, added credits for all the original authors, reskinned it from Vanilla’s baby blue to a rich beer brown, and re-positioned it as a community data portability tool. I laid out a complex 12-step maintenance program in a kanban board, and made no commitments about when it’d be finished.

Well, I finished it today, 6 days later. So now it’s time to start improving the documentation and start the real roadmap: proper automated testing, additional app support, and making it more generally useful. Maybe I’ll be tired of it by next week, but I haven’t gotten to code in public like that in many, many years. And it turns out I was right: it was a very fun week.