Involve kids in free software development through play

Giving up on a position within a free software project when you know you’re no longer managing to do an effective job is a wonderfully liberating experience. Now that I have started to talk with Miriam Ruiz about handing over the Debian Jr. project, I can stop worrying about the leadership task and just have fun with it.

I can always count on Miriam for recommendations for games in Debian my kids may enjoy, as she has a passion for finding good games to package for Debian, and in particular, games for children. Over the past few weeks we’ve had some fun with her picks. At the same time, I always have Debian Jr. in mind. How can we ensure kids can have the most fun with this? How do we equip their guides to help them?

What we’ve done with each new piece of software is to find a quiet time when one or more of the children can start playing with it on their own while we watch, offering such guidance as they need, but for the most part just letting them loose with it. Each wrinkle of the brow, each impetuous thump of the mouse, every illuminated grin and exclamation of delight is noted. We try to see what frustrates or pleases our kids and discuss it both with them and the Debian maintainers and upstream developers. This is an excercise we’ve managed to pull off without being overly intrusive and the results have been well worth the effort.

Using a few of Miriam’s picks we tried this week, we were able to draw their play into the free software development process. Here’s a brief summary of those sessions:

Platinum Arts Sandbox puts into children’s hands the ability to role play in a 3D world and edit that world using simplified controls. The expressions on the faces of our kids as they played were priceless: both the ups and the downs. I wanted to capture this on video and share it. After having established a rapport with upstream, we took a 20 minute clip of one of our play sessions and gave a copy to them to use to help further their work. Here is the edited result. They were very pleased to have that kind of feedback and found the video valuable for determining where the software still needed improvement and to notice which aspects particularly pleased the children.

I happen to know that Hex-a-hop is one of Miriam’s personal favourites. We have a household full of puzzle-lovers so this puzzle game was an instant hit. While on irc on #debian-jr with Miriam we relayed in real-time some of the reactions as they played this and a handful of her other picks. This gave her some confirmation of areas she knew needed work as well as inspiration for upcoming releases of these packages.

During this play session, which also included StegaVorto, kartofel, Anagramarama, Funny Boat and Vodovod, my youngest girl, age 7, plunked down on the couch next to me as her 10-year-old sister played. Then she started to notice I was typing what people in the livingroom were saying and doing on irc. She took a mild affront to me copying her own words and actions, so I decided it would be better to let her participate so she would feel included. At this point, I started playing secretary for her, typing what she dictated to me while she read the responses from the display. Later, I just handed her the keyboard so she could type and read the responses on her own. She was still at it long past bedtime and it was with some reluctance that she finally gave up the keyboard. We all had a lot of fun and look forward to doing this again.

We are particularly careful with privacy, taking care to share pictures, videos, and other personal details only so far as we believe it does not put our children at risk. Also, we need to ensure we observe in a way that is welcome and doesn’t interfere with their enjoyment. But with a little bit of prudence and a practiced eye and ear for what increases or diminishes enjoyment of the software, we can involve our children directly in the free software development process. I commend to anyone who has the privilege to share free software with children to use this method to communicate with maintainers and developers, increasing your own enjoyment of the software in the process and that of children and their guides everywhere.

Update: A quote from this article has made it to Slashdot. Although many of the comments seem to miss my point entirely, it’s nice to get a wider audience.


A pcsx mythgame player using xautomation

Scripting a gui tester for Tuxpaint with xautomation was fun and quite useful too, but really only appeals to developers. Today I found use for xautomation that will appeal to sys admins and users: hacking around a user interface that refuses to work the way it ought to.

I wanted to add another mythgame player, this time for the pcsx-df Playstation emulator. Unfortunately, I couldn’t pass it a CD image from the command line. It seems to know only how to do two things: run a game file, or run a real CD. My best guess is that it doesn’t know its plugins until the GUI starts, so it is unaware that it ought to be able to use the cdrmooby plugin to load the specified image when it is parsing the command line.

After a brief and fruitless grep through the source, it dawned on me that I could put xautomation to work for me to do the job in much less time. Here is the resulting startpcsx script, which sucessfully operates as my pcsx mythgame player.

slowtype () {
   echo "$@" | sed -re 's/(.)/\"str \1\"\n\"usleep 15\"\n/g'

pcsx &
xte "sleep 2" "keydown Control_R" "key o" "keyup Control_R" "sleep 1"
slowtype "$@" | xargs xte
xte "key Return"

The hard part was that pcsx is afflicted by one of my pet peeves, a typeahead find that cannot be disabled. As a result, if you make xte type at full speed into the open file dialog, the filepath comes out all jumbled up. This happens because the filepath is constantly being redrawn as xte types characters, so the cursor isn’t always at the end of the line. The usleep 15 allows the cursor to reach the end of the line before typing the next character.

Of course, this is truly a hack, subject to variations in timing between systems, so if you use it, you may have to tweak the sleep and usleep values. But it works well enough as a workaround until pcsx-df is fixed to accept a CD image on the command line.


Mythgame player to run native Linux games

I recently started to be aware of a problem in our family. Ever since we configured Mythgame to run Xmame games, we started to ignore native Linux games. This is a shame, because often the quality of such games is much higher, and besides, they are open source, which I strongly believe in.

I looked around for help configuring Mythgame to run Linux games, and was unable to find a way to make a game player that would play any Linux game. So I devised the following solution:

Step 1: Set up directories for pseudo-roms, command switches and snapshots

mkdir /usr/share/games/roms
mkdir /usr/share/games/switches
mkdir /usr/share/games/snaps

Step 2: Define a player in Mythgame

Player name: Linux
Command: %s `cat \`dirname %s\`/../switches/\`basename %s\``
Rom Path: /usr/share/games/roms
ScreenShots: /usr/share/games/snaps

Step 3: Populate the directories with data

cd /usr/share/games/roms
ln -s /usr/games/oolite
ln -s /usr/games/starvoyager
cd /usr/share/games/snaps
cp ~synrg/snaps/oolite.png .
cp ~synrg/snaps/starvoyager.png .
cd /usr/share/games/switches
touch oolite
echo "-f" >starvoyager

Step 4: In Mythgame, “Scan for Games”

Step 5: Play!


XPilot change of upstream growing pains

XPilot development has changed hands over the past several years. While the
original website at continues to be run by the original
developers, XPilot-NG ( is where all of the new development has
been happening. But still performs an important function for the user
community: they run the meta servers1 that list all public xpilot servers around
the world.

Recently, we (the XPilot-NG developers on #xpilot at noticed
quite a number of uncontactable servers popping up on the meta servers. This is
annoying, to say the least. Users don’t know they can’t connect until they’ve
tried (unless they’ve bothered to try pinging the server first) and besides
which, having all those “junk” servers in the list makes it harder to locate
contactable servers.

Now, naturally, we wanted to know where all of those servers were coming
from, and why now, at this particular time? I knew my Debian package (and
presumably any derivatives) do not report to the metaserver by default. Any
admin starting an XPilot server would have to explicitly configure it to do so,
so the incidence of uncontactable Debian XPilot-NG servers should remain
relatively low and have a constant growth rate. Then I found the Fedora
package, and started poking around inside. After a shallow review of the
package, I concluded there was a good chance it was the culprit2, especially
since it recently (FC5) had an init script added. Such a bug, coupled with the
relatively recent release of FC5, would account for the sudden spike in number
of permanently running non-contactable XPilot-NG servers.

Bingo! I found some helpful folks at #fedora-games at, including the XPilot NG maintainer, which
led to filing this
. I subsequently invited the maintainer over to #xpilot and had a nice time introducing him to the other upstream devs and chatting about our current issues.

Ultimately, we know we need to fix the problem at the metas, but in the meantime, I am pleased to have established contact with my counterpart in the
Fedora project, expanding the diminishingly
small XPilot developer community by one.

1 They deliberately never released any source code for those metas
to try to keep the user community unified at the centralized servers. While I
see the reasoning behind the decision, given the problems we’re facing now,
it’s clear the XPilot community would be better off with meta server source that
is actively being maintained.

2 Admittedly two problems with the +reportMeta option upstream set us up for this problem. First, counterintuitively, +reportMeta disables reporting to the metaserver (following the rule ”+” negates the meaning of an option starting with ”-”). Second, -reportMeta is a stupid default. Most people starting servers are behind firewalls these days, so unless they consciously decide to make their server public, making the corresponding adjustments to their firewall, the option should not be set (not to mention the security implications of making a server public by default).