Open Source and Console Games

On August 16, 2006 I participated in a panel discussion on Open Source and media as part of Digital Hollywood's Building Blocks 2006 conference.

Here is the description of the panel [from]
The Open Source movement began during the rise with young companies developing great tools to deliver applications and services across multiple platforms. The consumer's appetite for new content driven experiences has expanded to include ways to view, manage, and share content across devices. With the changing landscape around the home, Open Source promises to power a new generation of applications running over today's high-speed networks and the systems used to create, manage, and distribute that content.

Come join key leaders in the global electronics, online, and media communities to discuss Open Source's definition, and learn how companies will create systems, infrastructure, and applications for the next generation of the Consumer Entertainment Experience.

For those of you who did not attend, I would like to take an opportunity to discuss here my personal opinions on these issues.
From the description of the panel, some people might be lead to believe that free and open source software are new phenomenons, somehow linked to the internet bubble. This is definately not true.

Certainly the history of "free software" can be traced back much further than the "dot com rise", and because much of the software we use (for example, GNU/Linux) is a mix of both "open" and "free" software, we should consider the larger context.

By most accounts, this begins with Richard Stallman making announcing his plan to "free unix" on usenet in 1983. But of course, the distribution of source code freely among programmers can be traced back much further than that.

No discussion of "open source" can be complete without distinguishing between the subtle differences of "open source software" and "free software":

See: Definition of "free software"
See: Definition of "open source software"
Here's an article which tries to clarify the differences.

There has been some muddying of the waters by Microsoft's relatively recent "shared source" initiative (but there is general agreement that this is not either really "open" or "free" and so not part of this discussion.)

There are very many open source licenses and one canonical free software license. Many companies (including IBM, SGI, Apple, ...) have also produced their own variants.

I think applicability of license to product merits some discussion here. For example, in my field (console video games), we are restricted by the platform owners (Sony, Nintendo, etc.) by NDA and cannot release specific details to the public. This necessarily limits our choices when using "open source software" and nearly eliminates "free software" as an option, as we often cannot fully reciprocate our modifications to the public.

I do not see this a problem, nor as a challange to be overcome. Authors of free software are often willing to distribute their software without cost so that others make take advantage of the work that they've done and the only ask for one thing in return - that the software remain free. Just as the case when a middleware vendor may charge half a million dollars more than you're willing to pay, if the price for the software is to steep, then something else must be used instead. I wholeheartedly respect the work of the FSF (Free Software Foundation), but I understand that the practical nature of our business makes it very difficult to directly use the products of their hard work, and the work of so many other free software developers, in our own products.

Free software definitely has its place in game development, however. I do most of my work on GNU/Linux desktops and GCC is my compiler of choice. Additionally, many offline tools used directly or indirectly to develop the games themselves are based on free or open software, and I'm grateful that those tools exist.

I think reciprocity is the most important thing we can be discussing in the context of open source software and console games. It cannot be a simply a matter of "how open source benefits us", but we must also discuss "how we can participate in the open source community" and what responsibilities we have for doing so.

The free and open source software which we gladly take advantage of (if not in the games themselves, then certainly in the tools that develop them) can be thought of as the proverbial "shoulder of giants". When we forget what brought us the advantages to get where we are, we do a disservice to ourselves and the health of our industry, and thus ultimately a disservice to our shareholders and customers.

I think Yahoo Search's vision statement applies equally well to the role of open source software:

"Enable people to find, use, share and expand all human knowledge"

To share and contribute not only benefits us now, but will continue to benefit us when our current products are forgotten and dusty.

Cost of Openness
There is an ongoing debate on the cost of sharing your work with the world. Perhaps there will be a higher cost in support when calls and emails arrive from users that have configured the software in some strange environment. Maybe it will give competitors an edge when they see can clearly read the "secrets" of your product in the source code. Most arguments, including these, are never really so much about the costs involved (consider how many millions of dollars are spent developing the typical console title) but rather question the value of sharing, i.e. the return on the investment.

Consider this: The console game industry is a fast-moving industry. Consoles change, methods change and even the developers themselves change rapidly and constantly. Success of a title is usually determined by the quality of the content, not the engine that drives it, although occasionally the field of successful titles is punctuated by technical acheivement. But if competitors need access to the source of a successful product in order to become successful themselves, they are already behind, and no amount of access will allow them to gain on the continued developments of the leaders. And if it does help to make their product a little better, that's a good thing - good games are good for the platform, and what's good for the platform is good for developers wanting to sell their games on that platform.
The value of openness is in the people, not the source code.

  • Invest in the future. The programmers reading, modifying and commenting on the source may belong to the next-generation of coders in the industry. Help them learn by providing examples of real-world challanges and their solutions.
  • Invest in your team. The best way to learn is to teach. Simply by explaining what they've done, programmers will come up with new ideas and find areas that they've missed. This is no minor point - a studio's value is in it's people and since there are very few traditional training courses for the professional developer, a good studio must find different ways of helping make those developers better each day at what they do.
Call to Arms
Electronic Arts made a considerable difference to not only games but to many different industries when they released the EA IFF 85 Standard for Interchange Format Files. And it is in that tradition, almost twenty-two years later that I hope game developers, studios and publishers will re-double their efforts to share what they have created and learned with the community. Id software, the modern poster-child for sharing their technology, certainly hasn't lost anything by releasing some of their older sources.

Start small - a function, a snippet even. But make if we make it a habit, we will all be rewarded.

Has your studio released something into the wild? Tell me about it and I will happily list it here.