Not playing around: Lessons from indie game developers

There's a lot open source communities can learn from their long-lost cousins in indie games.
440 readers like this.
Open gaming news on Opensource.com

Opensource.com

Imagine, if you will, a culture composed of passion projects and the people who build them; of people scratching their own itch to create the thing they need and want to see in the world. Each project is a complex and innovative technological undertaking requiring multidisciplinary collaborations. The culture has a strong belief in and support for the community, without which it would not exist at all. Project creators help other project creators with free and open sharing of information. Projects and the culture overall foster and value a diversity of skills, backgrounds, lifestyles, and identities.

No, I'm not talking about free and open source software (FOSS). I've just described independent game development.

At the end of February, I was delighted to attend the Community Management Summit and Independent Games Summit at the Game Developers Conference (GDC) in San Francisco. It was truly a fascinating and inspiring experience, about which you'll hear more in the coming weeks as we publish articles from many Summit participants and developers.

What struck me most about the experience was not only the remarkable similarities between indie game development and FOSS (as shown in the description above), but also how much we in FOSS stand to learn from our long-lost cousins in indie games. Cast in the light of our similarities, the differences stand out more starkly and reveal approaches from which we can learn and can adapt to our own situations. Here's some of what we in FOSS might learn from indie game development.

Know your audience

Independent game developers are extremely aware of and in tune with their target audience, whether that audience is small (the developer alone) or large (tens or hundreds of thousands of gamers). Much of the talk I heard during the summit touched on how to communicate with and learn from either potential or current players of a game, and how to incorporate that feedback to improve the either the game or its community.

Indie game developers seem particularly keen on learning from their potential players in the earliest stages of game development, recognizing that as important as the developers' vision of the game may be, it really doesn't matter if no one wants to or can play it.

This focus on usability and end user requirements is an area where many free and open source projects are lacking, with developers preferring instead their "pure" vision of their game. While this may be adequate for some FOSS projects, those that embrace usability and accessibility at the start are more likely to grow robust and active user bases and communities.

Metrics matter, but insights matter more

Few organizations truly know which metrics matter to their community.

The enterprise and startup IT space has caught community fever. Everyone is getting into the community game now, finally having realized that listening to and communicating with users is great for the bottom line. We, in free and open source, are also now focusing a lot more attention on community. This overall evolution toward a community mindset is great. None of us would be here without the people who use and support our projects and our products.

Games—and indie games in particular—have encouraged a community focus for many years. They've made and overcome many of the same sorts of mistakes with which younger community management programs are struggling right now.

One of those struggles is metrics, specifically understanding which to collect and what to do with them afterward. The process of gathering community metrics is relatively easy, so much so that many organizations will gather every metric possible simply because they can. This "just in case" attitude toward metrics collection masks a very real problem—few organizations truly know which metrics matter to their community management programs, or even how to properly analyze those metrics to gain insights from them.

Richard Millington of FeverBee presented a dense and incredibly valuable presentation detailing how game studios can and do use metrics to encourage not only more members to join their community but also to become more engaged both after joining and longer into the future.

The forensic approach to metrics collection and analysis used for these community management efforts in gaming would be dramatically impactful if applied to the issue of open source contributors. For instance, an analysis of metrics shows that even one response to a community member question increased the likelihood that member would participate in the community again to 45%, up from 16% when their question remained unanswered. On a related note, members report a higher satisfaction with the community when their question is answered quickly, regardless of the quality of the information in that response. While a community manager may provide a more detailed and accurate response, the replies of other community members arrive more quickly, are usually deemed "good enough," and improve the chances that member will continue to participate in the community.

It's not difficult to see how free and open source communities can benefit from these lessons from the gaming community management trenches.

Market early, market often

A project shoud think about its marketing and branding from the very beginning.

Unfortunately, "marketing" is a dirty word for software developers of all stripes. While the term often is equated with smarmy and intrusive advertising, the reality of what it represents is less insidious and more critical to project success. Marketing means knowing your market—your users and community—as well as knowing what they want and how to speak to them. It's about taking the time to consider how you wish your project to be viewed by your market (aka your branding) and taking steps to influence that perception. A project that takes the time to consider its market and its brand is more likely to draw the size and type of community for which it's aiming.

Chris Dwyer, a freelance marketing, branding, and PR expert specializing in independent games recommended in his presentation Cost Effective Marketing and PR for Indies that a project thinks about its marketing and branding from the very beginning. While his advice is intended for independent game developers, it applies just as well to open source project developers and maintainers. Once your project is released to the world, it's no longer simply about the core developers. It has users, contributors, community members. It has a market.

Marketing and PR is simply one more piece of the design and architecture problem for your project, another puzzle to be solved. Continually thinking about this market and its needs, much as you'd think about any other part of project design, means you're more likely to develop what that market needs. Addressing market needs leads the project toward success.

Like indie game development, open source projects often are a passion. And like all passions, it often can be difficult to have the perspective necessary to see your project as others do. To help with this, Chris recommends enlisting the help of a friend or family member who isn't in the industry. Ask them to interview you about the project. Their questions can open your eyes to facets of your project you hadn't even considered. Other approaches that can help to gain perspective are to look at other projects in your problem space to see what problems they solve, how their market responds, and how your own project differs.

Shamelessly self-promote

Without self-promotion, your project may languish.

Marketing—the concern for the needs of and communication with your market—is an ongoing process through the entirely of your project. According to Chris Dwyer, public relations—the outreach for and promotion of your project—often makes sense to delay until you're ready to release it out to the world and is entirely vital after that. With indie games as with open source, if you build it they will not come. You cannot rely on a community beating a path to your door if you do not take the opportunity to let them know that it exists. Without self-promotion, your project may languish.

Once you're ready to start talking about your project, you have many different ways you can self-promote it to your potential community. Screenshots, GIFs, developer blogs, and social network postings are among some of the avenues you can take to reach those who would be interested in using and contributing to your project. If you've been paying attention to your market, you probably are already aware of what sorts of outreach methods it prefers. Use those to communicate with them. Not only will this keep up the interest of those who are already engaged, but it will draw in new members to your community.

It takes all kinds

Walking into the Independent Games Summit felt like stepping into a butterfly house in the middle of winter.

There is no avoiding the fact that the gaming community has had very public issues with diversity. It's unfortunate but true that the mindsets that underlie those issues are found infesting a lot of the technology industry, including our own open source communities. The community has to make a lot of progress yet, but thankfully folks have become aware of the problem and are working diligently to fix it.

One of the side-effects of the lack of diversity in our industry is an equal lack of diversity in our industry events. It's the sort of thing that is difficult not to see the moment you walk into a tech conference: very few women, fewer people of color, fewer yet gender nonconforming, and nearly no one with visible accessibility concerns.

For me, walking into the Independent Games Summit felt like stepping into a butterfly house in the middle of winter. The colors, genders, lifestyles, abilities, and perspectives in attendance at a tech summit was unfamiliar to someone like me, who has spent their professional life attending primarily free and open source technology events. Granted, the independent games industry undoubtedly has strides it can continue to make on this front, but the diversity I saw beggars anything we have yet accomplished in most free and open source communities. How did they achieve this?

The games industry long ago embraced what we in open source have yet to tackle in our culture: A successful project requires so much more than simply code—it needs math, physics, art, music, sound design, story design, puzzle building, production, direction, QA, community management, marketing, and much more. The creation of a project that delights and meets the needs of its users and community requires a multidisciplinary approach, which encourages the participation of a diverse set of people in the creation process. That diversity and the abundance of viewpoints it supports enables innovation and a beauty of a kind that most FOSS projects can only dream.

If we in free and open source wish to improve the diversity in our communities and our industry, we can learn a lot from the multidisciplinary nature of game development. Our projects and our communities will benefit greatly if we remove our focus on code and instead put the focus on what we're creating and the needs of those whom it is intended to serve. Accepting and encouraging the participation of roles such as designers, QA testers, marketers, technical writers, and others will open the door to a diversity of participants and opinions. Embracing the multidisciplinary nature of successful open source software development not only creates a more welcoming environment and a better product, but it also helps to spread the philosophy of free and open source beyond the relatively small world of coders into the larger world of creatives of all kinds.

Some suggested independent games

An article about GDC and the Independent Games Summit wouldn't be complete without highlighting some of the exceptional indie games that were featured at this year's event. None of them are open source, but all of them are playable on Linux with Steam. Check them out and help support some of your passionate and talented cousins in that faraway land of game development.

Tags
VM Brasseur profile photo
VM (aka Vicky) spent most of her 20 years in the tech industry leading software development departments and teams, and providing technical management and leadership consulting for small and medium businesses.

3 Comments

Hi Vicky,
thanks a lot for your post and sharing your insights. It's very enjoyable to read.

You write about a lot of thoughts we had in our community about 18 months ago when we friendly-forked from ADempiere ERP https://github.com/adempiere and started our own project metasfresh ERP https://github.com/metasfresh .

One of the reasons for us to fork was our plan to change the software architecture to be able to focus on the end-users/ user experience. After nearly 10 years of business functionality and backend development, the wishes of our users got more and more intense about wanting a User Interface that puts them at the center of our thoughts.

We moved from a Java Swing Client to a modern ReactJS/ HTML5 Web Interface. "Love" is normally not the word our users said when talking about ERP Software, but we've heard this word more often in the last time when presenting the new Interface. :-)

I still remember a lot of talks we had about promotion/ self-promotion of our project. As Free & Open Source People it felt awkward for us in the beginning, most of us thought "if we are good enough people somewhere outside there will recognize and then talk about us". We have improved, nowadays we still do promotion only if it "feels good" for us. So thanks also for your encouraging words and invitation to do so. ;-)

Hi Vicky,
thanks a lot.
I had a very inspiring talk with Bryan Behrenshausen a few weeks ago about #TheOpenOrg topics and I'm currently preparing some outlines for articles about these in our community/ company.
I'll give it a try and proceed with an outline about the user focus in our project too. ;-)

In reply to by vmbrasseur

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.