Unlike a rusting highway bridge, digital infrastructure does not betray the effects of age. And, unlike roads and bridges, large portions of the software infrastructure of the Internet are built and maintained by volunteers, who get little reward when their code works well but are blamed, and sometimes savagely derided, when it fails.


It’s easy to take open-source software for granted, and to forget that the Internet we use every day depends in part on the freely donated work of thousands of programmers.

The Internet’s Telltale HeartbleedThe New Yorker

#AANDigital: WordPress in the Newsroom

Since I’ve been involved in the news industry, I’ve been a huge proponent of open source software. In particular, this selling point: open source makes for much easier cross-institution collaboration. Open source software provides a legal framework for companies to pool development resources, and build mutually-beneficial products. However, as I learned the hard way, news organizations need to get to the point where they’re comfortable managing their own open source software before any collaboration can ever happen. We’ve made some strides, but we still have a ways to go.

Today, I was honored to speak about WordPress in the newsroom to the AAN Digital Conference. The alt-weeklies industry is in a situation very similar to what I saw in college media a few years back: one proprietary CMS dominates, editorial workflow is MS Word to InDesign to web, and most of the focus is on print. It was a bit of déjà vu. Fortunately, everyone is also super enthusiastic about the web — no curmudgeons in the audience.

The WordPress-powered sites I highlighted: Quartz, Metro, CBS New York, Rolling Stones, Online News Association, and DigBoston. Quartz is near and dear to my heart because I think they’re really at the forefront of innovation with an app-like product and responsive design. I can’t wait until they roll out their commenting system.

Features and plugins I pointed out include: distraction-free writing, drag and drop media uploader, Edit Flow and WP Frontend Uploader. If you’re looking for more publishing-related plugins, we’re slowly profiling our recommendations in the VIP Plugins Directory.

One parting note: this conference was the first time I’ve heard “dry humping” as a recommended way to show your appreciation to the organizers. Keep on rockin’, alt-weeklies.

How you might “open source (almost) everything”

I’d like to identify ways in which Automattic can release more code as open source by default.

In the WordPress.com repository, there’s a fair amount of code in use that’s never seen the light of day. Bits and pieces of this code would probably be useful to other people, and subsequently be improved as more developers read, implemented, and found new uses for it.

Open source is a unique and tremendously important phenomenon because it enables people to create more economic value than they could with previous collaborative frameworks. It’s “one of the most important ideas of our generation.” Automattic as a company believes this too; on the first page of our internal company documentation, Matt Mullenweg says, “I’m fine with releasing basically any code on WordPress.com that isn’t our password files.”

However, we don’t release as much code as we could be releasing, nor do we go about many our projects in the open source way we admire. I get the sense others in the community may agree.

Part of the challenge, as I perceive it, is that we (Automattic) build new functionality for WordPress.com, are lazy in our implementation, and it then becomes extra work at the end to “release” the functionality as a plugin. People have limited time in the day, understandably, and the last step doesn’t get done.

Last month, I wrote an internal blog post identifying four ways I’d like to see Automattic improve:

  • Releasing (or mirroring) as much of the WordPress.com codebase as possible.
  • Building community around parts of WordPress.com infrastructure, both in terms of people who use it and people who develop for it.
  • Incorporating more third-party code into our codebase, and actively contribute back to it.
  • Modeling best practices for open source projects, including support and documentation.

There was good conversation in the comments and, in somewhat typical fashion, not a lot of clarity on the takeaways.

Personally, I’d like to get as much WordPress.com code into a repository that VIP developers can check out and use in their development environments. Hell, it even means they can submit patches for fixes, coincidentally as Erick Hitter just did while I’m writing this post. I’d like to move our existing, private shared plugins repository into a WordPress.com public plugins repository which would also contain code like the shortcodes we’ve implemented on WordPress.com.

Communication is the lifeblood to open source, and the only remedy to poor communication is over-communication. For an open source project, discussion should be public, ticketing should be public, and the changelog should be public. This obviously isn’t to say that everyone should have an equal voice — rather, everyone should have an equal opportunity to participate. Making public WordPress.com’s internal code would be a start, but that would just be the start.

What other approaches do you think we could take?

If you haven’t already, I’d highly encourage you to read Tom Preston-Warner’s “Open Source (Almost) Everything“. It’s legit.