In today’s hyper connected world, it has become harder than ever for media networks to ignore fan fiction, fan art and other types of derivative work. They populate social media, pop-culture blogs, mainstream media, forums and dedicated fan art websites.
While most of the time derivative works infringe copyrights and moral rights, they also add new entry points to the original story, drive more engagement and generate ongoing social conversations about it. In this sense, derivative work represents an opportunity for franchise owners on many levels. From casual sources of inspiration to potential sources of monetization, fan art and fan fiction might be key assets for tomorrow’s marketing strategies, and franchise development models.
Today, however, media networks have yet to leverage derivative work in a truly productive way. Marketers can definitely sense the potential that hides behind their fans’ creation. It is social, viral, engaging… everything a online marketing ought to be. To some extent, derivative work is also threatening, chaotic and uneven. Is there way for franchise owners to leverage this valuable content without giving up their authors’ moral and copyrights ?
Drawing inspiration from the software and web industry, this article looks at APIs as a potential model for licensing, franchise development and entertainment marketing.
Regardless of copyrights or intellectual property, fans use original stories to create their own fictional pieces. Fan art takes the shape of simple memes, silly GIFs, sophisticated paintings, lengthy fan fiction pieces, tribute songs and video clips, video games, LEGO reconstruction of scenes, etc. While most of this content is very poor, some of it is quite remarkable, and valuable.
Game of Thrones themed paintings, for instance, contribute to spreading the show’s mythology. They populate forums and social networks with epic representations of legendary kings and battles — not unlike paintings of historical events have populated museums in the real the world. Fans have been building a collective memory, a heritage that brings the Game of Thrones universe to life in the forms of cartoons, rap songs, portraits and interactive maps. In the case of Dexter and Breaking Bad, two hugely popular shows that have ended, derivative work can also act as an extension of the show. It keeps the story alive even when the show is officially over.
This mythology is the result of fans’ collective work — a critical mass of content, which can only be reached by the crowd’s combined skills and intelligence. Fan art represents a constant stream of ideas; each piece inspires the creation of 10 more, and organically fosters creativity and participation. By no means would franchise owners have the internal resource to create such a colossal amount of quality content.
To some extent, this phenomenon is reminiscent of what happened in the software industry, and of the eternal debate over proprietary vs. open source software. There is only so much a single team can build; as innovation keeps going faster, an increasing number of companies decided to open source their software and tap into collective talent and intelligence. Even the most regulated and sensitive industries like healthcare have adopted open source strategies to innovate faster. For instance, open source clinical trial software provider Clinovo has an active community of developers who contribute their skills to improve the company’s star product Clincapture. Another strategy to leverage external talent is to build an API — Application Programming Interface.
API evangelist Kin Lane defines APIs as follow:
An API at its most basic level, allows your product or service to talk to other products or services. In this way, an API allows you to open up data and functionality to other developers, to other businesses or even between departments and locations within your company. It is increasingly the way in which companies exchange data, services and complex resources, both internally, externally with partners, and openly with the public.
While APIs were initially very developer centric, they have become an inherent aspect of business development for many companies:
APIs are launched primarily to give partners that are outside the company firewall, access to internal data and resources. But recently, APIs are also being used by more of the general public, including non-developers. As APIs’ ease-of-use and popularity increases — and as APIs demonstrate their value and deliver efficiencies — many companies have begun to consume their own APIs to build internal systems, websites, and mobile apps using the same APIs that they make available to third-party developers and to the public.
What if stories had APIs?
If APIs have helped businesses innovate, iterate, and collaborate with others, why not use similar methods for media franchises? In other words, what if media networks built APIs for their existing franchises? Could this help them leverage derivative work in a productive way for them and their fans?
Of course, the idea might sound slightly out of touch with reality; big money, big people and a complex legal context. But after all, Amazon is leading the way with its recently launched Kindle Worlds. This fan fiction publishing platform proposes a very elementary form of story API. Each of the licensed “World” comes with a set of content guidelines, and also features the World’s “canon.”
Screenshot from kindleworlds.amazon.com
Drawing from web APIs and Amazon’s Kindle Worlds model, here is a first attempt to define a story API.
Thoughts on how to build a story API
In the context of a media franchise, an API would be generated by the franchise owner, and aimed at anyone willing to create derivative work based on the franchise’s story world. The purpose of a story API is to publish documentation and resources about a specific story world for fans to use. The idea isn’t to open source intellectual property, but to see franchises as platforms that embrace co-creation and derivative work.
Each API will be specific to the needs and vision of the franchise owner. Some will be more open than others. It goes without saying, but there is no universal API. The suggestions that follow are only meant to provide general guidelines and ideas about what a media franchise’s API could look like.
Franchise API documentation may include:
1/ Graphic and narrative “source code”
Graphic or narrative elements of a story world, typically downloadable files of character designs, scripts or bibles that anyone can use to create derivative work.
2/ Story “data sets”
Background documentation on the existing story world. All the available “data” on characters, timelines, events, geography, and other facts.
Note — Fan wikis provide exactly that: large amounts of data about a specific universe. Franchise owners would need to find a way to leverage existing Wikis. The question is: what data do franchise owners have that fans do not? Would it add value to existing Wikis?
Example — A lot of Game of Thrones fans created maps of Westeros. Being able to check facts in order to create an accurate map is crucial.
3/ Story world rules & production guidelines
Guidelines that all derivative work must respect in order to be endorsed by the franchise owner. Those can relate to the story itself, or the production of derivative work (All videos must be in 16:9 and HD for instance.) The goal of these guidelines isn’t to establish universal rules about how fans should use a story universe, or to restrict the community’s creativity. Rather, they are a way for franchise owners to establish standards for derivative work it is to officially endorse.
Example — AMC: Breaking Bad has a specific color code for each character. Mary is purple, Hank is orange, Walt is green, Skyler is blue, etc. AMC could require derivative video work to respect this color code in order to get an official license from AMC.
About how derivative work should interact with the original story world, or with the real world in order to be endorsed by the franchise owner. For instance, protocols on how to place spoiler alerts in mobile apps based on a story world. If a network possesses multiple franchises, they might want to include guidelines on whether those shows can or cannot be mixed together in derivative work.
Example — Amazon Kindle Worlds asks all fan fiction authors not to use elements from 2 different stories in their fan fiction piece. Each fan fiction must be based on 1 world only.
Example — HBO: HBO could require all mobile apps based on Game of Thrones to include a spoiler-free navigation tool. Users must be able to navigate content either based on the Song of Ice and Fire books (by chapter), or on the HBO series (by episode).
5/ Licensing model, royalties and copyrights rules.
APIs must include detailed rights and publishing agreements.
Example — Amazon Kindle Worlds terms.
Pros and cons of building a story API
[Pro] Improve the overall quality of derivative work.
Just as software APIs, publishing a story’s API can help media networks leverage derivative work in a positive way both for them and the authors. Existing licensing models forbids the use of copyrighted materials by fans. As a result, fans that do chose to ignore copyrights end up using low quality content to create their own work. On a pure technical level, if fans had access to some official, quality content, they would be able to improve the quality of their work, which can only benefit the franchise owner — if they can’t prevent the creation of fan fiction and fan art, at least they can try to improve the quality of a content that is organically tied to theirs. Needless to say, this type of cooperation would positively impact the franchise owner’s relationship to their community. Beyond simply sharing fan content, media networks would actively support it.
Adam WarRock case study
Adam Warrock creates Hip Hop songs based on TV shows, movies and other pop culture items. As a Game of Thrones fan, he wrote and recorded a full album dedicated to the HBO show. Each song tells a piece of the GoT mythology in an extremely faithful way. His songs all start by a short excerpt of dialogue from the show, and his videos include pictures and video clips from the show. His music is great, fun, and provides a very creative way to bring the GoT universe to fans. Unfortunately, his YouTube videos are fairly poor quality. They are usually random pictures he probably finds online, and low-resolution clips that were obviously pirated. If Adam had access to official HD video clips, licensed by HBO, the quality of his work would immediately go up. Not that it is absolutely necessary — the videos are good enough as they are. But being the “Apple of entertainment,” HBO is a brand that values excellence, and helping its community create good art can only benefit the brand itself. Publishing a collection of downloadable video clips in multiple formats would allow talented artists like Adam to make great work. Quality video is also key to get more views, and eventually maybe even monetize those videos — a potentially interesting opportunity for artists and HBO itself.
[Pro] Outsource technological innovation.
This might be one of the most promising On a technological level, innovation is also happening too fast for any company to keep up with. Media networks could benefit from encouraging more fans to build second screen experiences or mobile games around their stories.
Story APIs could hence also be useful for developers or game designers wanting to create apps inspired by their favorite TV show. Right now, building an app inspired by Game of Thrones is almost impossible, because of copyrights issues. If HBO published an GoT API, it could provide material for developers and designers to use when building their app.
[Pro] A better allocation of internal resources
Media networks are currently looking for ways to create engaging content online. They dedicate time, human and financial resources to many social marketing projects. In some cases, using these resources to provide “fan support” could generate higher return on investment. By “fan support,” I mean assist fans creative content, help them create quality, meaningful content and build strong relationships with the fan community. Developer support provided by Twitter, or the coaching YouTube provides to its video creators are great examples. This isn’t to say that media networks should open or outsource all of their content or projects. Rather, it is about figuring out which resources will have the highest impact, and why.
Game of Thrones Interactive Map case study
HBO has created a “Viewer’s guide” to its flagship show Game of Thrones. Among other elements, the site features an interactive map of Westeros, the fictional territory where Game of Thrones takes place. Users can explore various locations and territories, and see where major events took place. The map in itself offers interesting resource and is easy to use.
Fans, however, have created another map, which happens to be more complete and provides a better user experience. It gathers much more data and offers additional functionalities. For instance, fans can see characters’ trips and travels, and the evolution of geo-political frontiers in time. The map also features a spoiler-free option. Users can select a book or TV episode, and the map will hide information that may contain spoilers. The tool is an incredibly useful and fun way to visualize the GoT universe and plot. This map was the result of a long work of data collection, fact checking and coding. It is also the result of indirect collaboration between several fans. The creator of the map used open source designs and code created by other fans to build this map.
As it is, the map doesn’t benefit HBO in any way. HBO has no way to leverage the site’s audience or the tool itself. Instead of building its own mediocre map, HBO could have provided additional resources to its community, endorsed the map and maybe used it to drive traffic back to its website. In other words, the resources HBO put into the creation of its own map could have been used to help fans improve their project. The outcomes would have been positive for HBO and its community alike.
[Cons] The danger of authority.
Obviously, an API comes with rules, some form of regulation. Many fans could interpret this as an attempt from franchise owners to gain control of their work. In a way, they wouldn’t be wrong. Publishing a story’s API would reintroduce a sense of hierarchy between canonical content and fan content. Franchise owners would implement a form of validation process for content created, and act as the righteous authority over a storyworld. It is very likely that some franchise owners would build walled gardens like Apple’s and censor some interpretations of their stories.
In a nutshell, building an API could mean:
- Endorsing fan art and other types of derivative works.
- Having more visibility on what is being created.
- Improving the overall quality of derivative work.
- Fostering the creation of innovative content or technology based on a fictional universe.
- To some extent — having more control over what people create.
- Capitalizing on existing fan art to drive more traffic to corporate or official websites.
- Using internal resources to maintain the API and provide “support” to fans instead of creating official resources.
- Outsourcing innovation.
- Monetizing some of the content created.