红帽全球峰会红帽博客
This is the third post in our series on open source game development. For posts one and two, I sat down with Red Hat’s Michael Clayton and Jared Sprague to talk about how the second season of Command Line Heroes relates to their work on Command Line Heroes: The Game, and their own efforts as open source game developers.
Today, we’re talking about the trials and tribulations of contributing to open source projects and communities. In episode 3, “Ready to Commit,” we learn how host Saron Yitbarek got her start with open source software, and also how large projects like Fedora maintain a healthy and thriving community. As every command line hero has an origin story (or two), I figured we’d start by asking Jared and Michael about their first “commits.”
Quick note: If you want to jump straight into the code or find out how to contribute to Command Line Heroes: The Game, visit our GitHub repository.
In the beginning
Dan: Today’s episode, “Ready to Commit,” is all about contributing to open source. Contributions are not always just code, right? In fact, at the beginning of the episode, Saron talks about how her own first pull request was actually made to improve documentation. I'd love to start today’s conversation by asking you guys about your first “commit.” Do you remember your first contribution to a project or a community? What was it like?
Michael: You know, I wish I did. I can say that before my first commit, I started out by using a lot of open source software. In fact, I think for most people, even outside of the tech sphere, their first exposure to open source software (whether they know it or not) is a web browser—think Firefox or Chrome.
Dan: This makes a lot of sense. I remember my own early days online, using dial-up modems and Netscape. Netscape was a precursor to the Firefox we know and love today.
Michael: Exactly. I got into open source through Firefox and then became interested in Linux. It was around this time that I began to think about how cool it would be to join an open source community and contribute... but I wasn't sure which community to join or exactly how I wanted to contribute. So instead of joining any one project or community, I just started a bunch of small projects on my own! I found this to be a safe and comfortable way for me to dip my toes in the water. I felt some degree of “total control” over my mini projects and could do whatever I wanted—while still developing out “in the open.” It wasn't until much later that I started making contributions to larger projects.
Dan: It can be intimidating, right? You set off on this journey. You think you know that open source is something you want to work on and you want to contribute to a project or community. But how do you know where to start? That’s a problem in and of itself. Jared, how about yourself? Do you remember your first contributions or pull requests?
Jared:I do. And, I'm kind of in the same boat as Michael in that my first involvement with open source wasn't contributing to an existing project. It was creating my own open source project. In retrospect it’s funny, too, because it actually kind of relates to how this season of Command Line Heroes started off with gaming, as my own first project was an add-on called Auctioneer for World of Warcraft.
Dan: Oh, wow. (Editor’s note: no pun intended.) Tell me more. While I know of World of Warcraft, my own experiences ended with Warcraft 2. Maybe I’m getting old?
Jared: Well, if anyone's played World of Warcraft before, they've probably heard of Auctioneer. I collaborated on the project with a guy named Norganna. And, at first, we were just keeping it to ourselves. We had written this code that would let you scan the game’s auction house and then buy and sell items at a profit. We made a ton of in-game currency doing that. But, at some point, we figured that a lot of people in the game world would really love to use and contribute to something like this, so we open sourced the code and, to our surprise, a robust community formed really, really quickly. People started to add new features… and it took on a life of its own. Eventually, I just let the community take over, and I just faded into the background, moving on to new endeavours.
Michael: That's a good one. Your very first open source project probably had millions, maybe more than 10 million users. That's pretty awesome.
Dan: It is absolutely mind-blowing.
Jared: Oh, and there’s another part to the story. After we released it and made it open source, Blizzard (the company that produces and publishes World of Warcraft) actually had to change their infrastructure, because millions of people were constantly scanning the auction house in the game. They literally had to adapt. I remember a patch note saying something like "...optimizing auction house scanning code for add-ons..." and I knew that was mostly from Auctioneer.
Dan: So, not only did your first project have millions of users, it influenced a really well know gaming company to modify their own code base. Pretty impressive all around. On a related note—also featured in “Ready to Commit”—is Red Hat’s Vincent Batts. Do you guys know Vincent?
Michael: Yeah.
Jared: Yeah.
Dan: Vincent talks about how, when you're trying to find that place to start or a project or community to join, it can be a reciprocal relationship. You might start by trying to solve something for yourself, but ultimately you end up solving something for a larger community. In a way, this is echoed in both of your stories. It's not like you went out and found these projects or communities—it’s more like they almost found you.
Jared: Yeah, exactly.
Maintenance as a luxury problem
Dan: Let's shift gears slightly for a moment and talk about contributing code in a little more detail. In the episode, we learn there are more or less four things that can happen when you make a pull request. There can be silence, right? Like, you might not hear anything back. There could be outright rejection. There could be simple acceptance. Or there could be a request for change.
Michael, as amaintainer, given that you have started a number of your own projects, what does open source look like from the maintainer side of things?
Michael: Oh wow. I think it can span the whole spectrum of human emotions. It can be like the most rewarding thing having complete strangers take an interest in something that you've invested so much of your own time into. It can also be a mixed blessing, because if too many people get interested, you've suddenly created an entirely new job for yourself, and you’re likely no longer personally building the project anymore. Your own time goes to fielding questions and fielding pull requests and trying to more or less organize a group of developers. It can be an amazing and overwhelming experience all at once.
Dan: Yes. At the end of the day, at least from where I stand, that seems like it can be immensely gratifying to see other people take an interest in your own ideas and initiatives. At the same time, I can also imagine that if something really takes off, it can lead to some measure of maintainer burnout, right? In fact, in episode 3, we talk about this. And Matthew Miller, who heads up the Fedora Project, spends some time talking about how, with bigger projects like Fedora, certain measures have been put into place to try and avoid or prevent burnout.
Jared: Yep. Matthew mentions how important it is to have people in the pipeline to take over for you if you need to take a break. That’s really smart.
Michael: Yeah, it's really easy to become a cranky curmudgeon when you're dealing with such an influx of interest. It takes a lot of patience.
Dan: It's a luxury problem of sorts. When your community grows to a certain size or achieves a certain critical mass, you need to have some checks and balances in place to make sure it's also sustainable over time. This reminds me of how control rods are used in some types of nuclear reactors. But, that’s way off topic. Jared, how about yourself? What has your experience been on the maintainer side?
Jared: Well, thankfully, I haven't (yet) had to deal with a situation where I felt overwhelmed by the amount of people submitting pull requests! That said, as a maintainer on Command Line Heroes: The Game I'm super excited for the weeks ahead. Even today, I'm always refreshing GitHub to see if anyone's submitted a pull request. I'm really eager to get more people involved, and I'm happy, super happy, when people want to contribute.
Game on!
Dan: The game! Yes. Let’s talk for a moment about how Command Line Heroes: The Game is coming along. We've been working on the game for almost a month now. Between GitHub and our Discord server, there seems to be a lot of engagement!
Jared:Yeah. We’re actually having a problem right now where people are contributing faster than we can get stuff up for them to work on. Like, we released the first milestone, and it took less than a week and all but one of the issues had been closed out, and most of them have been from contributors. So a big shout-out to those folks. The community that has come together is pretty awesome.
Michael: I totally agree. People seem to be really excited about contributing. And once we get past the initial stages (for example, completing work on hero-engine) and then start building on top of it, there's going to be a lot of stuff for people to work on or add to.
Dan: Speaking of hero-engine, which, as we’ve said before, may be one of the world’s first open source web-based adventure game engines, do you have a vision for how we'll start to build Command Line Heroes: The Game “on top of it?”
Michael: Sure. There are a few types of work that can go on in parallel. As we may have mentioned in one of our last conversations, the hero-engine works to combine a map editor called Tiled and the Phaser 3 HTML5 game engine. In this way, hero-engine will provide a specification—essentially a description for how you can build out an adventure game level within Tiled.
Jared: For example, if you want to put a light switch in your level that turns a light on, the hero-engine will tell you to add a property called “on use” where the value is “turn on light one.” So, you can kind of link “clicking on the light switch” to “turning the light on.” Then, you can generalize that to many other kinds of actions within the game.
Michael: In some sense, once we have the specification pretty close to complete, and I think it's in a really good state now, someone could hypothetically start building a level in Tiled before the hero-engine even had a single line of code written. They, of course, wouldn't be able to play it, but they could build it to the spec and kind of get everything generally laid out. Then, when the hero-engine is ready, they can load the level up and see how well it works.
In addition, some other things can happen in parallel. Let's say one person is designing a level and their concern is where every storyline object is in the game, like how you get to each object. Essentially, what the puzzles are and what you have to find (or do) in the level in order to complete it. They can be working on this at the same time as someone else is working on the art assets, at the same time that someone else is working on sound effects. All it takes is an agreement on, "Hey, we need art for a door and a floor and a wall and a table, and whatever needs to be in the game, and we need a sound effect for the door opening and closing and a sound effect for foot falls on the floor.” Once that's agreed, what needs to go into the level, everyone can go off and do their work in parallel.
Dan: If I'm hearing you correctly, it's like once we get to this point where we're starting to scope and define levels for Command Line Heroes: The Game, this is when it gets really fun and exciting in so far as we’ll need art, sound effects, music, and so much more. This is where we’ll need skill sets that transcend just “coding chops.”
Jared: Definitely. Writing is a big one, too, because in almost every adventure game, it's point and click, and you're clicking on stuff and pretty much everything you click on needs to have a description and needs to be interesting or witty. So, that's a lot of text that needs to be written. So, writing is also going to be a major component. Someone who is not a coder at all, like who has never touched code could totally contribute that. Like here's a bunch of objects in the room. What shows up on the screen when someone clicks on each of them?
We need your skills
Dan: So, this feels like a great way to wrap up today’s discussion… if somebody out there identifies as a writer, or an artist, and they want to get involved with the Command Line Heroes: The Game, but they're not exactly sure how to begin or where to start, what's the best way for them to get involved? Is it to join the Discord server and ask some questions? Is it to check out the our README file on GitHub?
Jared: Yeah, I think the first place to start is to go to the GitHub repo and just do a quick review of it. We keep a current list of the milestones there. Jumping into Discord is the next best step. One of us is nearly always going to be there.
One of the really important things to me in terms of this whole project is building the community and I’ve found that one of the the best ways to build the community is through platforms like Discord, where you can have real time chats with people. Between the GitHub repo itself and Discord, these are the best ways for people to get involved.
Michael: One thing to add onto that is that we were planning to create a few introductory videos, just a quick tutorial of, "Hey, here's how you create ..." the light switch example I gave earlier, or, "Here's how you..." I don't know, "Step on a platform that makes a door open." I think that because the spec I mentioned before is, it's this long document, it's just table after table of property name and possible values, and it's a useful reference, but it's not a good guide. Not a good way to start. So the video series that we hope to make will be a much more accessible starting point.
Dan: That's awesome. In fact, I’ve come to understand that Doug Tidwell from the Red Hat Developer team has already taken a crack at the first of these videos. Folks who are interested in getting started with Command Line Heroes: The Game should definitely check it out.
Open Jam & All Things Open
Dan: A final question for you guys, You just wrapped up Open Jam, right?
Jared: Yeah.
Michael: Yeah. Just yesterday. Judging has now begun!
Dan: Awesome. And here’s my real question… the judging, it’s done by peers? This means the people who participated in the jam now can go and look at each other's work product?
Michael: That’s right.
Dan: And what happens after judging? I know All Things Open is coming up later this month. What's goes on between judging and All Things Open?
Jared:So after judging, when the results are in, we’ll select the top three games and feature them at All Things Open in the Open Jam booth. We’ll have a playable station for the games. And, I can attest, as an open source game developer, one of the most rewarding things is seeing other people play your game and having fun.
Dan: I can’t wait to see how this comes together. For folks who might not be able to travel or make it to Raleigh for All Things Open, I would imagine that some of the games will be available to play online?
Jared: Yeah. Actually, they can be played right now. You can play every single one. In a few days, you'll also be able to see the winners, too.
Dan: That's awesome. I guess I'll close out today by saying that is has been awesome to sit down and talk with you guys again about contributing to open source projects and communities. I enjoyed learning a little bit more about your own roles and history with respect to contributing to and maintaining open source projects. And, for what it’s worth, I’m personally excited to see how (at some point) I can help contribute to Command Line Heroes: The Game myself!
Spoiler alert—whether you’ve contributed to a project or not—join us again in two weeks when Michael and Jared and I discuss how failure can lead to some (really) beneficial outcomes.
Useful links
