Open Source Content: The next wave in content creation

Over the last few weeks, I've read Dan Ariely's "The Upside of Irrationality," Daniel K. Pink's "Drive", and I'm finishing Clay Shirky's "Cognitive Surplus." The three books cover much of the same ground and refer to much of the same research in behavioral economics, and I'll be referring to them quite a bit in future posts, as their concepts impact a variety of fields.

One by one, old media industries have been reshaped by technological changes: When music could be copied perfectly and shared at no cost with anyone around the world, the ability of record companies to control the pricing and distribution of their products collapsed. The music industry is still trying to find viable new business models.

The business of printing words on paper and distributing them daily or weekly to consumers is also collapsing. Note that I didn't say that the newspaper or magazine businesses are collapsing, only the business of distributing ephemeral content on paper. There's tremendous demand for news, analysis and opinion, but it's being fulfilled by websites, blogs and Twitter, all of which can respond instantly to events. Newspapers and magazines will survive if they can develop business models that will enable them to get out of the "words on paper" business and make money online.

The movie and television businesses see the digital steamroller coming and want to defend against it with their own technology: 3D. The cost of producing videos, and now movies, has probably dropped by two orders of magnitude in a decade. 3D, on the other hand, is still (comparatively) expensive and difficult to produce, so only "professionals" need apply. Also, the only commercially viable outlets for 3D are movie theaters; only a relative handful of 3D HDTVs have shipped, and very little programming is available for in-home viewing.

However, 3D won't stop the penetration of online digital media into the home, and it won't prevent the marginalization of "big media." People have made their own independent films for years, but they were limited by two constraints:

1. Filmmaking was expensive, especially if you wanted to make a film that looked good enough to come from a major studio.
2. Distribution was controlled by a handful of distributors owned by the major studios. If you couldn't get one of them to distribute your film, you'd never reach a big audience.

Today, filmmaking isn't free, but it's much less expensive than it used to be. DSLRs and their lenses have dramatically decreased the cost and size of cameras. Desktop editing, special effects, color correction and audio mixing systems can handle all the post-production work. Netflix, Amazon, YouTube and countless other vendors can distribute the production to viewers around the world.

One component can't be eliminated, however, and that's people. The best equipment and software can't produce a movie or television show by itself. That requires talented people. People like (and expect) to get paid, so no matter how much you can reduce the other costs and bypass the big media gatekeepers, you still have human costs. Or do you?

The computer software business has been turned on its head by the open source movement. With open source software, a group of developers comes together to write software, and the resulting software is made available to be used (under specified rules) at no cost. The developers aren't paid, but they get satisfaction from solving a problem for users, recognition from the developer community for their efforts, and experience that they can use to increase their income from their "day job."

Blog writers like myself do this all the time, but it's less common in audio, video and motion pictures. Call it "open source content". The key is that a like-minded group of people come together to produce a musical recording, podcast, video or movie. They don't get paid for it, and their creation will be distributed (under specified rules, such as a Creative Commons license) at no cost.

Open source content can be distributed for revenue, of course. For example, Sony Pictures could agree to distribute a particularly compelling movie made using the open source method. For that reason, before work even begins, the team needs to agree on how any revenues earned from the content will be distributed: Will the funds be distributed equally to every team member? Will the team put a percentage of the funds into a reserve for future productions? Will they contribute all or a portion of the funds to a cause or charity? I can easily see pre-made disbursement agreements along the lines of the Apache License or GNU GPL that become widely accepted, and that everyone on the team can agree to before work begins.

One important distinction here is that these open source content projects aren't intended to replace "day jobs." They provide participants with satisfaction, challenges, experience and recognition, but (in most cases) no financial compensation. If and when the project makes some money, it comes after the project is complete and is a nice bonus for the participants.

People want to make their own videos and movies, but the "old media" environment shuts them out. The DIY (do it yourself) content movement is alive and well--just look at YouTube, which gets 24 hours of video posted every minute of the day, if you have any doubts. By formally applying the concepts of open source software to content, the rules and expectations for participants can be standardized. The big software companies have been unable to stop the open source movement; the big media companies are unlikely to have any more success with open source content.

Capstan Channel Syndication: A format for syndicating time-based video

A few months ago, when I had an unexpected amount of time to myself, I began looking at what it would take to put video content on the set-top boxes from companies like Boxee, Roku and Popbox. It became clear very quickly that it would take a lot more than simply posting a bunch of videos to the web. Each one of these platforms has its own API, its own content description format and its own developer program. Some platforms give the set-top box vendor the power to control which content is made available to its customers. It presents a Tower of Babel for content suppliers.

On the other hand, you've got RSS, which is as close to a universal content syndication format on the Internet as you can find. RSS works extremely well for static content; what I mean by static in this context is that everything in an RSS feed is available right now, not at some point in the future. Video on demand (VOD) works fine with RSS; when you upload a new video, you update your RSS feed and either push the information to clients or let them pull the information from your server.

Broadcast and cable television work in a different way. They use schedules: Certain episodes of certain series are scheduled at specific times on specific days. Those episodes (and the program segments that comprise them) may or may not be made available on a VOD basis at a future time. RSS isn't designed for that--an RSS feed can tell you what's available right now, but not what's going to be available a week from Tuesday at 0800 UTC. It doesn't give client developers enough information to build a unified interface to live, scheduled and on-demand programming, all at the same time.

There are several other issues: The same episode of a program can shift from scheduled, to live, to on demand, over time. Content providers may want to make video available on a pay-per-view or subscription basis, so they need ways of authenticating viewers, protecting their content and processing transactions, and they would much rather not support different systems for every set-top box and client vendor.

I looked hard at making RSS do all of this, and yes, it can be done with Namespaces, but it would be like cutting the back end off of a sedan, welding on a truck bed and calling it a pickup truck. It's much better to develop a new XML Schema that's purpose-built for the application. And so, that's what I did.

I call the result Capstan Channel Syndication, or CCS. Why Capstan? Capstans are the metal spindles that guide magnetic tape through audio and video tape recorders, and I thought that "capstan" would give a retro feel to a format that's designed specifically for Internet video in the 21st Century. Rather than go into the details of CCS, there's a more detailed description of what it's for here, and a downloadable copy of the specification here.

I've made CCS available as open source under Apache License 2.0, the least restrictive widely used open source license I could find. Neither I nor my consulting firm have a horse in this race--I'm not working on, promoting or investing in any video client, set-top box or Online Video Provider companies. If you want to participate in the process of defining CCS, I invite you to do so at the ccs-format Google Code site.

I'm hoping that CCS will be adopted by client and set-top box developers to enable them to get access to much more content without having to write and market their own APIs, and by content providers who will be able to write one CCS specification instead of a different application for every client and set-top box. Adopting CCS doesn't preclude anyone from writing and promoting their own APIs, so client and set-top box developers can still encourage content providers to take advantage of special capabilities of their platforms. However, my hope is that CCS will become the "baseline" for making time-based video available on the web.

H.264 now comprises 66% of encoding.com's videos

In response to Steve Jobs' open letter about Flash last week, TechCrunch contacted encoding.com, a video encoding service, to get their statistics on what formats their clients are requesting. In Q1 2010, 66% of all videos that encoding.com processed were encoded into H.264, while On2 VP6 and .FLV (which could be any codec supported by Flash, but in this case probably means Sorenson) together add up to 26%. (Ogg Theora is barely 2%.) Here's the chart:

Keep in mind that encoding.com has encoded 5 million videos over the past year for a variety of clients, but it in no way represents the majority of video sites or content. Also, these numbers represent new or transcoded files, not the huge number of legacy video files that still exist on the web. Nevertheless, encoding.com's numbers suggest that H.264 has got major adoption momentum. However, that could change.

Google's rumored announcement later this month that it will make On2's VP8 format available as open source may change the balance, especially if YouTube starts encoding its videos in VP8. According to ComScore's traffic numbers for March, YouTube had more video viewing traffic than then next ten sites put together, so as YouTube goes, so goes a large part of the market.

Google to open source VP8?

NewTeeVee is reporting that Google will announce plans to make On2's VP8 codec open source as early as next month's Google I/O developers' conference. The move is no big surprise, and it's likely to dramatically increase adoption of VP8, which On2 claims is significantly more bandwidth-efficient than H.264. Adobe Flash currently doesn't support VP8, although given Adobe and Google's closer partnership, future support is likely. NewTeeVee reports that both Google's Chrome and Mozilla's Firefox will add VP8 support once Google makes its announcement.

VP8 could provide an alternative to H.264 for developers and content providers who are concerned about future changes in MPEG LA's licensing policies, and to Ogg Theora for those who believe that Theora requires significantly more bandwidth than H.264 for the same level of quality. (Google is also helping to fund an implementation of Ogg Theora for ARM processors.)

The bottom line is that VP8 and Ogg Theora would provide a solid base of royalty-free alternative video codecs, in much the same way as PNG served as a royalty-free alternative to GIF.