March 7, 2020

The Curse of Sustainability learning to learn from game development

License Zero came about by looking outside software to other fields and industries, and accepting that no problems are unique to software alone. Public-private licensing, the path License Zero paves, remains common and accepted in photography, B-roll, and other creative media, even while it’s ignored and aggressively downplayed in software. Rather than snuffing out the vitality of other art forms, public-private licensing has helped open very closed fields online.

Most recently, I’ve been reading up on fairness, funding, and opportunity in game development, especially computer game development. It’s an interesting meeting point for older media, like art, music, and film, and software development, often quite sophisticated at that. If the music and film industries orbit Los Angeles, and software calls the Bay Area home, computer gaming is a dual citizen, drawing opportunistically from both, as well as abroad. As usual, monocultures can learn a lot from their hybrids.

This line of research recently led me to Alex Jaffe’s talk “Cursed Problems in Game Design” at the Game Developers Conference in 2019. The crux of Alex’ talk is the notion of the cursed problem: an unsolvable design problem rooted in conflict among the expectations gamers bring to a game.

To illustrate, Alex develops an extended example of a multiplayer video game mixing beat ‘em up and competitive fighting elements, with many combatants on-screen, but each controlled by a human player. Players love roughing up throngs of on-screen baddies, and eventually beating a game. They also love mastering the complex movements, strategies, and combinations of competitive fighting games. What’s not to love?

Unfortunately, mashing the two together yields less than the sum of the parts. Mastering fighting mechanics makes players more effective individually. But in practice, teaming up on stronger players, rather than maximizing individual skills, yields the most victories. So the game becomes an exercise in group politics, rather than solo virtuosity. Outstanding displays of skill bring swift collective punishment, not victory and acclaim, under the dominant strategy. Tall poppies get chopped, not put on podiums.

Alex encourages designers facing cursed problems to accept that they stem from player wants, not quirks of design or concrete game mechanics. Cursed problems therefore cannot be solved without compromising one or more kinds of value the game promises to players. But rather than simply hobbling a game, such compromises often markedly improve a game overall.

Nearly every week, I find a new reason to be grateful that software knows and says it has a “sustainability” problem. Our new, shared vocabulary of that problem—ecology, infrastructure, common pool resources—enables recognition and discussion in new and urgent ways. Having found a way to talk about the problem, we can see and express it more fluently.

But nearly as often as I’m grateful, I’m frustrated by how the metaphors of sustainability welcomed by users both implicitly and explicitly dehumanize the producers under strain. Software developers aren’t forests, highways, fisheries, or water canals. They’re people, not trees, roads, bridges, fish, or fluid running downhill. But we don’t tend to think of ecological, infrastructure maintenance, or man-versus-nature problems first and foremost as people problems. God’s-eye-view vocabularies for dispassionate, technocratic management don’t lend to solutions that dehumanized subjects want to get behind. They inspire resistance.

The category error that makes it so easy for users to join the new “sustainability” conversation also reinforces bad thinking, bad behavior, and bad answers. In the corporate environment, dubbing coworkers “human resources” endorses a managerial disconnect that reduces people to the level of durable equipment and consumable goods, greasing a downward spiral of detached decision making and rank and file resentment. Likewise, equating programmers to creatures of the forest, or merely the work they leave behind, raises key problems while simultaneously pointing in exactly the wrong direction.

There follow myriad schemes to count, measure, grade, triage, qualify, and generally speaking surveil the bejesus out of open software projects and open software people, all for the sake of meting out shares of allotted sums of cash or attention. The result, if developers prove desperate enough to accept it, will better resemble picking and packing at an Amazon warehouse, driving cars for a ridesharing app, or receiving shares of a centrally planned budget, than professional engineering. The alternative, of course, is to beg.

Better metaphors stand readily available. Framing open software as a game recognizes the humanity of players on all sides. But seen as a game, does open software sustainability represent a cursed problem?

It’s easy to identify broadly held expectations on both sides at fundamental odds. Open source consumers want ample code, maintenance, and support for nothing. Producers want advancement, opportunity, and compensation for their work. Consumers want friction-free discovery, distribution, and integration. Producers want credit, recognition, and reputation. Consumers want state-of-the-art code under open terms. Producers need lax and stable work environments to do their best. And so on.

Some of these conflicts can be theorized away by dismissing any distinction between producer and consumer, assuming that producers losing in one round will be consumers winning in the next, the game self-balancing over successive plays. But that short-circuit approach burns too much wire in practice. Chains of supply from low level to high level to application to end user remain fundamentally unidirectional, not circular. Going one step further, presupposing that every player is or ought to be part of an enterprise commercializing free work at a price helps to avoid theory problems, but only by mounting still more assumptions. It still fails to account for enterprises whose customers are also software enterprises, like the database companies stirring up so much controversy of late. Meanwhile, specialization continues to grow, even while need for broad-ranging generalists and “glue programmers” persists.

As a whole, the corporate-adjunct theory of open equity conflicts insolubly with the idealism of non-coder software freedom, and therefore saps the motivation of idealists to contribute more code for nil. If open source requires closed-source applications to do right by open source programmers, open source isn’t a liberation movement, but a conspiracy against the laity.

Long story short, I think whether open software sustainability represents a cursed problem depends largely on how we frame the game. But many ways to frame that game to avoid cursed problems—such as relegating open to a means of corporate cost reduction—fall well short of what we think and hope open source to be. They sacrifice goals, expectations, and promises that many signed up for, and won’t play without. This gets recognized far more often than it gets expressed, in large part because it’s no fun winning when others quit in droves. Eventually the word will get out, but while the winning is good, why rush it?

No metaphor’s perfect. Neither is open software as game of many players. After all, there’s no such thing as a designated designer or a designated player. Everyone participating in open software also participates in negotiating the rules of that game, if only by choosing whether or how to play under the current rules on offer. If the results are unfun or unfair, we have only ourselves to blame. If we can do better—the game designers certainly can—it’s time to get working.