Workflow 4 Eva

Q. The Stet post about the tech/team acquisition focuses quite a bit on workflow and the way that Editorially’s technology and institutional knowledge (can I say that about a startup? whatever) will strengthen not just Chorus, but Vox Media’s workflow. I was intrigued by this bit:

together we hatched a plan for the three Editorially founders to join Vox Media and lead a team that will look hard at the editorial workflow across all of the Vox Media publications.

Can you talk about the relationship between editorial process/culture and editorial tools? If you’re trying to build a workflow that supports better collaboration, are you starting with people or technology?

Mandy Brown: The tech has to serve the people, so I don’t think it’s accurate to say we’re starting with one or the other. A lot of what motivated us to build Editorially was an awareness of the gaps between many CMSs and the actual workflow that writers, editors, designers, and developers undertake. We’ve been putting words into boxes for quite a few years now, and a lot of apparatus has developed to support what happens to those words once they’re out in the world; but often the work that leads up to that point — the editing and revision and collaboration — is neglected. We think enabling that work—by making it more transparent, more efficient, more fun, even—is critical to a publisher’s success.

We anticipate that some of the concepts we built into Editorially—version control, for example—will make their way into Chorus, in some fashion or another. But we’re not wedded to any particular design solution so much as we are focused on helping people work together. Our first order of business is to spend some time with the Vox Media editorial staffs and learn more about how they work.

Open Source Futures

Q. Let’s talk about open source, from a couple of directions. Back in the day when I got a Q&A with some Verge folks, it sounded like the team really thought about Chorus as a competitive advantage that they didn’t want to share. It sounds like things have changed, or maybe that they weren’t quite so anti-open-source to begin with. Can you talk about any of the team’s plans to release code and share out in other ways with the wider news-nerd community? (There’s an interesting thing in there somewhere about older, more culturally conservative news orgs producing so much open source code and newer, zippier outfits struggling with that, but that’s for another day.)

Trei Brundrett: We believe in open source, we always have and we’re eager to find ways to contribute to the community from which we have benefited ourselves. We also understand that open source requires a commitment, level of effort and responsibility that is important to consider.

For the last 7 years our mission has been to create a new, sustainable media company. We had an urgency to build an audience, establish our media brands and work directly on creating revenue. To achieve that, we’ve taken a relatively pragmatic approach as we build our platform including open source, open APIs, documentation and even the architecture of our platform. In the case of open source, we never made a decision not to release code, we just never even discussed it. We have been heads down, focused on shipping and iterating our products to meet our business goals. However, we did make a concerted effort to “show our work” by writing about projects and sharing some code/lessons on our blog. Examples:

• How to set up a private WebPageTest Instance on EC2 to measure front end performance
• From Monolith to Rocketship: Upgrading Chorus to Rails 3.2 and Ruby 2.1
• Web design as troll: how The Verge Fanboys piece taunted the internet
• Polygon feature design: SVG animations for fun and profit
• Using Backbone.js for sanity and stability

In the last year and half, as our team has grown and we’ve generalized our platform for multiple verticals and a broader set of users, we’ve started revisiting a number of things, including open source. Right now at our all-hands hack week, we are actively working on a couple things:

1. preparing several projects to open source them—most of them internal tools, and
2. creating a framework and set of tools to make it easier for us to open source projects in the regular course of development. This will likely lead to more open source from Vox Media.

Q. Now that the Editorially team has landed safely, can you talk briefly about why you-all didn’t open source the Editorially code base immediately as part of your shut-down? I’ve seen a million theories floated on the internet, and I’d love to have the basics on record.

MB: When we made the announcement that Editorially was shutting down, we were already in the middle of several potential acquisition discussions. Some of those discussions centered around the product alone, while others (as with the Vox Media deal we eventually inked) involved the team and the product. We were always keen to find a new home for the product and release some or all of it as open source if we could; but it just wasn’t practical to do so before we explored all of our options. In particular, we had to balance our own desire to release the code with the obligations we had to our investors. We’re very happy to have reached an agreement that satisfies both.

Hacking Inside Vox

Q. I hear you’re doing an internal hack week this week. What’s cooking in there?

TB:This is the third big product team all-hands hack gathering (that we call VAX) we’ve organized. We’ve done many other smaller ones and we’ve participated many times with other organizations, but this is a special event we put together for the whole team to be in the same place and work on whatever they want. Based on the ideas list we assembled, we have about 30 different projects proposed. As folks organize into teams and start hacking, that number may change. We’re blogging about the event on our product blog and you can find some background on past VAX hack weeks here.

Thanks, Mandy and Trei!