Skip to main content
A cartoon depiction of the author, wearing a hoodie and smiling

Chorus: The Modern Media Stack

I was joking, as a defense mechanism, that I had just told an intern I've been working with this summer (with a great deal of self-consciousness for being preachy, but continuing nevertheless) that something I found challenging about being a professional software developer was feeling okay—even good—about code I've written being removed from a codebase, features being turned off after I had agonized over the lines of code required. I meant it. I had watched open source projects develop over my high school years, seen people receive acclaim and job safety from their contributions to CVS repos and kernel mailing lists and whatever else. When I finished college and some QA work that I did, I was proud to be taking problems from product managers and implementing fixes and additions that would make software more valuable, more capable. So of course your measure of success is based on you using your brain and fingers to accomplish something, and then have that manifestation continue accomplishing good things forever.

When I worked at a small ecommerce startup in 2011, the week I arrived I was invited to a funeral. It was a meeting, actually, one held in the open-plan office, for everyone in engineering, design, and product to attend. The funeral was for all the features and experiments that had been discontinued in the past year—the greatest of all a huge Facebook integration that lots of people had worked hard on, and that had brought them so much frustration, and they were proud that it ever worked, but so, so happy to be free of the consequences of all of it. It was mind-blowing! I stood next to the VP of Engineering as a coworker sang "Danny Boy", an honestly startlingly good rendition. Afterwards, another person did an interpretive dance. We all laughed. I realized that these features, these lines of code, these product specs were just as well sent off into the sea if we took a look at what we had and realized we were better off without the things we had piled up around us.

Working on and around Chorus was what taught me the difference between a product and a piece of software. I met people who broadened my perspective on... well, pretty much everything, really, but in the most focused way on what it means to build software "products". I had worked places where we actually published periodic updates, some of which got burned to CDs and shipped to important clients with high-level security requirements, and still thought of my job as writing code. With the help of the people I learned from, people who worked across a lot of disciplines, I came to understand why you would refer to a team made up of many different skillsets and job requirements as a "product team". I still kind of bristle that we had to rebrand as a "Product, Design, and Technology team" while I was there. We were part of a team, with all the good and bad that can contain, and not a bunch of different departments somehow finding a way to work together.

Chorus was a complicated set of interrelated parts. It had a monolith at its core, one built in Ruby on Rails like many web servers deployed in the late 2000s. Over time it picked up some other components; a separate Rails app that stored "structured data", a realtime multiplayer rich text editor and a companion database/all-in-one API, a federated GraphQL API, a video asset management tool and probably half a dozen other components that I'm forgetting or that were spawned after I left. In teams that I worked on that were outside of the Chorus umbrella there were solutions for deploying works-in-progress of the entire software suite so you could run QA and demonstrations, there were ad authoring tools and ad marketplace header-bidding gizmos and any number of other things that I'm sure have evolved into all kinds of dizzying forms; some of which will survive this transition, others which won't.

So thinking back to the comparison that I had made, to the point I had so heavy-handedly laid in front of this intern in an attempt to explain why there was value in building something that felt temporary but would inform a lot of decisions that my team at Glitch will be making over the next year: I don't think it's actually the same at all to grieve Chorus and what it is and has been. Because I'm not actually grieving the individual lines of code I wrote, or even the ones that other people wrote that probably worked much better. I'm grieving the product, grieving the loss of jobs for people who found value in working on something that I also found value in, and grieving the loss of a time when the type of people who work in management (and VC and whatever other roles are involved in this kind of decision-making) understood and valued the kind of work that I found so fulfilling, that I witnessed bring happiness to the people who used it, that gave me the opportunity to be around people who made me a better engineer, a better product thinker, and a better person.

When Buzzfeed News shut down recently, I was pretty sad. It felt like a notable moment among a lot of signs over the past few years that digital media, much like many other areas where tech investors happily deposited piles of money, though maybe to not quite as wild of a degree, was evolving; and generally not in a way that favored readers, writers, or anyone who built "platforms". I was happy to see that on its way out the door the editorial folks managed to write and publish an "oral history" of Buzzfeed News. I guess I had been out of the game just long enough to be surprised, and a little hurt, when I realized the story was being told entirely from the editorial perspective. It's a perspective I value, but I can't help but feel a little bit sad that a product came and went, one that based on my experience as an "audience member" worked pretty well, and I still have no idea who was involved in making that, what difficulties they had, what successes they celebrated. Did they have funerals for features that they removed? Did they ever have to scramble to build a feature for some momentous story that was on the platform? I hope I get to ask someone from that team some day, but until then, their side of that story remains untold.

Today I've seen a lot of weird takes from people who don't actually understand anything about what "digital media" has done, or what value Chorus provided to the people who worked at Vox Media or any of the websites that licensed Chorus during its SaaS period. A couple reactions seemed to indicate a confidence in a simple idea: that leadership retiring it in favor of Wordpress means that the platform was a failure. This is the most bizarre idea to me, that only a platform that survives until the heat-death of the universe can be considered a success. The fact that many of them were saying it on social media sites and Mastodon instances, neither of which have exactly been a paragon of durability on the Internet, was not lost on me.

I'm sure there were lots of people from Vox or newsrooms who licensed Chorus who had negative experiences. Maybe some of them even know and prefer Wordpress. Chorus wasn't always perfect. It didn't always do what they wanted. We had outages and data loss and features that we should have been able to prioritize but never did. It's an unfortunate truth that the team didn't always have the shared vision, the focus, the teamwork and the energy to solve every problem they wanted to. And it may even be true, in the sense that Vox Media as a corporate entity has to make decisions that preserve some abstract sense of success that cannot be perfectly calculated by any one person, that retiring Chorus as the CMS at Vox Media is the "correct choice". But one thing I'm fairly sure of is that none of the people who have already been laid off, or will be laid off next month, or whenever the Wordpress migration is "complete", are to blame for Chorus not succeeding in a way that may have made it look more appealing to the kinds of people who decided that it's time to end it. And that just feels really shitty to me.