In the previous post, I described how the media landscape is changing, starting with reader expectations. In this post I'll describe what that might imply for a media organization like ours. If the key word is "participation", how could we encourage that to the fullest? If trust comes come from transparency, how might we open the entire process? What does open source media really mean?
Although I'm not promising we'll do all or even most of these things, here are some first thoughts on what a truly transparent media organization would do. (Some of these are based on my experience in open-sourcing my book research on this site, which worked great. Why not apply the same lessons to a magazine?)
Six tactics of transparent media
1) Show who we are. All staff edit their own personal "about" pages, giving bios, contact details and job functions. Encourage anyone who wants to blog to do so. Have a masthead that actually means something to people who aren't on it. While we're at it, how about a real org chart, revealing the second dimension that's purposely obscured in the linear ranking on a traditional masthead?
Upside: Readers know who to contact. The organization is revealed as a collection of diverse individuals, not just a brand, an editor and some writers.
Risk: Competitors know who to poach; PR people spam us even more than usual.
2) Show what we're working on. We already have internal wikis that are common scratch pads for teams working on projects. And most writers have their own thread-gathering processes, often online. Why no open them to all? Who knows, perhaps other people will have good ideas, too.
Upside: Tap the wisdom of crowds
Risk: Tip off competitors (although I'd argue that this would just as likely freeze them; after all the prior art would be obvious to all); Risks "scooping ourselves", robbing the final product of freshness.
3) "Process as Content"*. Why not share the reporting as it happens, uploading the text of each interview as soon as you can get it processed by your flat-world transcription service in India? (This may sound ridiculous, but it's exactly what wire services such as the AP have long done--they update their stories with each new fragment of information). After you've woven together enough of the threads to have a semi-coherent draft, why not ask your readers to help edit it? (We did it here, and it worked great). And while you're at it, let them write the headlines and subheads, not just for the site but also the punchier ones for the RSS feed and the one that has to work with the art for the magazine.
Upside: Open participation can make stories better--better researched, better thought through and deeper. It also can crowdsource some of the work of the copy desk and editors. And once the story is done and published, the participants have a sense of collective ownership that encourages them to spread the word.
Risk: Curating the process can quickly hit diminishing returns. Writers end up feeling like a cruise director, constantly trying to get people to participate. And all the other risks of the item above.
4) Privilege the crowd. Why not give comments equal status to the story they're commenting on? Why not publish all letters to the editor as they're submitted (we did that here), and let the readers vote on which are the best? We could promise to publish the top five each month, whether we like them or not: "Harness our tools of production! Make us print your words! Voting is Power!"
Upside: Maximizes participation.
Risk: If we don't deploy voting tools or (sigh) a login system, trolls may rule.
5) Let readers decide what's best. We own Reddit, which (among other things) is a terrific way of measuring popularity. Why should we guess at which stories will be most popular and give those preferential treatment? Why not just measure what people really think and let statistics determine the hierarchy of the front page?
Upside: A front page that reflects reader interest better.
Risk: A more predictable and lowbrow front page.
6) Wikifiy everything. The realities of publishing is that at some point you push the publish button. In the traditional world, that's the end of the story. It is a snapshot in time, as good as we could make it but inevitably imperfect. The errors (and all articles have them) are a mix of commission and omission--we hope for the best yet brace ourselves for the worst. But what if we published every story on a wiki platform, so they could evolve over time, just like Wikipedia itself? The original story would be the foundation of what could eventually become a version expanded and updated by readers (our Fortune 500 blogging wiki was an experiment in this). If you want to see the original version, just push the "original" button, or see any changes in-between by looking at the version history.
Upside: Stories live and grow, remaining relevant long after their original publication (at no cost to us!)
Risk: Stories get progressively less coherent as many cooks mess with them. Whatever brand authority the Wired name brings is diminished over time as the stories become less and less our own work.
Needless to say, in all these cases I think the upsides outweigh the downsides. But if I'm wrong the consequences could be serious (Jason Calacanis's crowdsourcing experiment with the Netscape home page, which was something I admired, is nevertheless a cautionary tale. Although that was a portal in decline and clearly needed something radical to get traction again, the short term consequence of his Digg-like experiment was a significant decrease in traffic and a management turnover that included him). My strategy is to try these experiments in a limited way first so that if they don't work they won't take too much of the site down with them. But if they do work, we should be able to deploy them across the site quickly. And that would be very cool indeed.
UPDATE: I've clarified and amplified a few of these points here.
(*Credit goes to Evan Hansen for this term)