Open Source and Console Games

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.

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.

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.

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.