Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
In this reprinted <a href="http://altdevblogaday.com/">#altdevblogaday</a> opinion piece, Agora Games' David Czarnecki explains why your studio should highlight its internal and external open source developments.
April 2, 2012
[In this reprinted #altdevblogaday opinion piece, Agora Games' David Czarnecki explains why your studio should highlight its internal and external open source developments.] I recently started a weekly blog series on our company blog called "Game Face". It is "our weekly round-up of our internal and external open source work here at Agora Games." Internal open source refers to our public projects that you can find over at our Agora Games GitHub account. External open source work refers to projects that we contribute to in off-hours and may or may not have anything to do with video games because we're swell folks like that. This is important for our company, and I think it should be for your company. Putting on the game face At the beginning of 2012, I did an assessment of all the projects we open sourced in 2011. Late much? 22 projects wasn't bad, and I want to beat that number in 2012, but it got me thinking that this kind of information is timely and needs more regular attention. So, I started kicking around ideas for a blog series name. After a day, I settled on "Game Face". "Game" obviously referred to the work we do in developing gaming-related libraries and middleware. "Face" would refer to the code-wise public face of the company and the developer(s) working on the individual libraries. It will help you become a better writer If you're a developer and you're scared about writing a weekly blog series, you shouldn't be. The focus of the blog is technical in nature, so you don't need to spend a lot of time on exposition. If you're good with your commit messages or at keeping a CHANGELOG, the blog posts write themselves. For example, from an item in a recent blog post: "This releases addresses the first future idea from the README when the gem was released over a year ago to add a method allowing for bulk insert of data into a leaderboard." Cut and paste for the most part my friends. The intrepid developer might even automate the creation of the initial blog post that can be wordsmithed by someone you deem more fluent in languages other than C++ :) It will help you become a better developer We get feedback on our code each day from our co-workers. By opening up your code to the world, you get peer feedback beyond your immediate peanut gallery. You also get comments, questions and sometimes code where developers are using your code in new and interesting ways that you hadn't thought of yet. Case-and-point: I recently integrated a patch to our leaderboard library with all the code and tests to allow for leaderboards in "reverse" (lowest-to-highest) sorted order. I just hadn't come across that use case in the games we've worked on where I needed a leaderboard appropriate for a racing game. But someone else did. And now our library is better off because of it. Beyond peer feedback, or any feedback, opening up your code and talking about it helps you to think about the ramifications of changes when there are developers other than you or your company using your code. It will help you as a company By highlighting your company's open source work, it may motivate your developers to want to take a stab at open source in the first place or to clean up a library for external publishing. You might also attract developers who put a high value on knowing their contributions will be recognized, whether they are internal or external, and that their contributions may see the light of day outside of your company's hallowed halls. The last "Game Face" blog post I wrote highlighted a new library one of our developers had released that allowed you to parse Beersmith2 (beer brewing software) files in Ruby. I imagine many video game companies rely on open source to some degree, and so by publicly promoting your contributions to open source, it can also help you in the eyes of the open source community. It will help you have awkward conversations I can't tell you what to open source and what not to open source. You'll have to talk as a team, as a company, and possibly with your lawyers to understand what you can and cannot open source. In 2011, there was only one instance where I went to our CEO to get a check on, "Can I open source this?" We walked around the block and our conversation went basically as follows: Me: "I'd like to open source a leaderboard library. Given this is a core thing we do, is that OK?" CEO: "So, someone else could do this before us using a similar method?" Me: "Yes." CEO: "Ship it!" FIN Hopefully I've made some compelling arguments that your company should highlight your internal and external open source development. Our weekly blog post series highlighting our internal and external open source work comes out on Friday, and now I usually get one or two messages throughout the week in our group chat room asking, "What's going in to Game Face this week?" It feels pretty good when I can say back, "Your face." If your company does anything with open source, I'd love to know about it! [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]
Read more about:
2012You May Also Like