The Perl community is not new to hackathons; the Pugs hackathon in Toronto in 2005 before YAPC::NA is one of the best known. However, most of these sprints took place before or after conferences: OSCON, YAPC, et cetera.

I went to the Chicago Perl Hackathon this past weekend. Barring some troubles during the trip, it went flawlessly.

The organizers, Andy Lester and Pete Krawczyk, found a small hotel in a little town outside of the Chicago suburbs. It was accessible from public transportation, had a small conference room for us, and was within walking distance of a handful of restaurants.

Better yet, we had tables, chairs, wifi, electricity, and snacks.

Though there were a few out of towners (a couple of us from Portland, two from Seattle, a couple of people from California, two from New York City, and one from the UK), most of the attendees were from the midwest. This was a goal, and it was a great help. The total attendance was somewhere around thirty people.

Two projects dominated the event. One was the Perl::Critic project. Several attendeed squashed bugs, refined policies, and improved one of the most useful software development tools I’ve used in years.

The biggest success may have been for the Parrot project, however. Six of the attendees were Parrot contributors before the weekend started (including your author) and by the end of Saturday night, we had added eight more contributors.

I spent the weekend fixing broken tests in Parrot, and had the time to add a couple of new features. (My big goal — fixing Parrot::Embed on non-Unix platforms — didn’t quite happen, but Jerry Gay and I did track down some of the problems.) This cleaning was necessary for Chip Salzenberg (also in attendance) to release Parrot 0.4.7, codename “Caique”. We also took advantage of being in person to discuss some weighty design issues related to our object system. Unfortunately, three of the core Parrot developers couldn’t be there, but we caught up on IRC with Leo Toetsch and Patrick Michaud.

Was it a success? By all means! The best part was sitting down with people who’d never touched Parrot before and walking through adding a new feature or fixing a bug. For example, Jerry and I helped Jim Keenan compile Parrot for the first time. He’d found a bug in our configuration process. Though Jerry and I both recognized the error (being very much too familiar with compiling Parrot), walking Jim through the fix on his own virtually would have taken a lot of time. It went much faster in person, and now Jim is providing patches to related build files.

If you ask any of the other attendees, you’ll hear similar stories – especially, I hope, from people new to a project. A few people dropped by for a few hours without any particular plans, just hoping that they could contribute to something.

To me, that’s the real goal of a hackathon. I’m very proud of the work we’ve done on the Parrot release, but I’m even prouder that we helped eight more people contribute to Parrot. Maybe some of them will never contribute again, and that’s okay. Maybe some of them will continue to produce good patches and even become committers. I’d like that a lot.

However, each of them tried something new and contributed to a project that’s bigger than any single person. All of the developers of the project are better for their work, and all of the current and future users of the project benefit too. You can, of course, start to contribute to almost any free software project without ever leaving your house, but if it takes flying halfway across the country in wild weather and giving up a weekend every now and then to help someone else make that jump, I think it’s well worth it.

TPF, how about a west coast hackathon sometime early next year? Portland’s nice.