Code Fest in Review

I have to admit, I was a bit worried about how the AOSS Code Fest in Guangzhou this last weekend would turn out. I was asked to be one of eight “mentors” with four others from China and three from Japan. When I first heard about the Code Fest, I expected something akin to an ApacheCon Hackathon or a Debian Bug Squashing Party or similar code sprints. These events are fairly self-organizing. Just combine some basic ingredients - active developers, decent venue, good wifi, food and drink - and the magic just happens.

The organizers of this year’s Code Fest decided to take a different approach. Rather than focusing on veteran open source and free software developers (who are admittedly in short supply in China), the planners invited 60 some students to the Guangdong Linux Center (GDLC) with the intention of giving them an “open source experience.” There would be little effort to reach out to other developers. Instead, the mentors were expected to provide activities and lead projects and the students would demo and write up reports on their accomplishments over the Code Fest weekend. The mentors weren’t completely alone in this task, of course. The GDLC staff, a handful of teachers and professors, and staff from the Hong Kong Open Source Center (HKOSSC) made every effort to ensure smooth operations.

The Code Fest Begins

The Code Fest started early Saturday morning. After an hour or so of introductions, the students had till 4:00 PM Sunday to determine a project to work on and get as much done as possible. Chaos dominated the first few hours as first attempts were aborted, missing software was installed, groups formed and reformed, and mentors tried to figure out how to get started. By Saturday afternoon a rhythm had started to emerge and eventually the placed hummed up to its final minutes.

I’m now curious to know more specifically just what the attendees thought about this weekend. If they came away thinking open source is a chaotic place where no one knows what’s going on and work is done in indeterministic spirts, at least they wouldn’t be far from the truth. At least I learned something this last weekend and that’s what I really want to share.

What Went Right (and Wrong)

The list of “what went right” includes facilities with big and small rooms (nice places to break out) including a large computer lab, plenty of snacks and food, mentors with very different backgrounds, a wide range of students (from high school to university seniors), and a laid back “stay as long as you want, make yourself comfortable” attitude. So the basic ingredients for success were all present.

There were a few hiccups though. The internet, while reliable, was a bit slow at times. Now, this comes from someone spoiled on high speed, high bandwidth connections. Even the fastest connections in China come to a screeching halt when they hit the Chinese Firewall, so there may be little we could have done to improve this situation. Another challenge was that, despite the computer lab PCs running Red Hat Enterpise 4, there was a lot of missing software. Some computers didn’t even have gcc installed. None had svn. Now, this could have been used as a great lesson in how to setup a working environment, but with limited time, I rushed through the install steps with some of the students I was helping. In fact, let me delve on this issue a bit more.

The projects I offered to help mentor included RadiantCMS, Apache Tomcat, and Apache Tuscany. To even get started working on any of these projects require subversion, ruby, rubygems, rails, mysql or sqlite, a working JDK, Apache Ant, Apache Maven, Tomcat to run webapps, and perhaps an IDE like Eclipse. To setup a good Ruby or Java development environment is a worthy lesson all to itself. One I didn’t emphasize enough, nor prepare for enough. We could have easily spent half a day just installing and learning these tools (I did end up doing a half-an-hour presentation on subversion Saturday afternoon). I suppose I expected the tools to already be in place. But in retrospect, I should have slowed down, not worried about getting to the bugs and code, and instead spent the time to setup a proper working environment and explain the why’s and how’s of each tool.

This leads to another observation just about each mentor brought up. “Getting Started” documents would have been very useful. A combination of general “about open source” and “basic open source tools” documents along with specific documentation on the proposed projects and bugs would suffice. Having these in place would have helped bring at least some order to the initial chaos, allow students to make more informed decisions on what to work on, and free up the mentors to more easily jump between teams in the crucial first few hours. In fact, this was my biggest frustration—there were a few different student teams who all needed my help getting started. Properly helping each team meant spending at least an hour or two with them introducing the code and the problem. However, doing this left the other teams milling about and stuggling on their own. Some better preparation on my part would have helped ease this resource starvation issue.

Two things left I want to share about the event—my original goal and a list of suggestions for anyone who wants to run a similar event. Thanks for sticking with me on this.

Code is Code

Code is code. The actual code one writes for free software is not substantially different than proprietary code. The critical difference is, of course, the licence and how that license allows a community of developers to form around the code. It’s writing code within a community that makes open source software development different. It’s dealing with bug trackers, mailing lists, revision control, diffs and patches, all with people you may never meet face to face, with whom you are not a coworker or friend at the outset.

The experience I wanted to share with the students was this one—contributing to an open source project. So I asked the Apache community for any ideas on bugs or enhancements the students could work on. Mark Thomas from Tomcat and Luciano Resende from Apache Tuscany both provided great lists of bugs and enhancements (thank you!). I also had some of my own itches to scratch related to RadiantCMS and the ApacheCon websites and banners. The idea was to let students pick from this list (if they didn’t already have their own ideas) and I’d help them set the code up, fix the bug, and submit it back to the project.

At least that was the theory. One team picked up a Tuscany bug, and two other teams wanted to learn Rails and Radiant. One interesting observation was that the Tuscany team got started faster thanks to good project documentation and fewer software prerequisites. However, the Radiant teams ended up further along. The Tuscany team was able to fairly quickly get the software up and running and reliably reproduce the bug. This despite having to deal with ant, maven, Eclipse and deploying a webapp in Tomcat. However, they ended up picking a bug that might have been a little too tricky given the time we had to solve it. We really need to debug everything in Eclipse and that meant setting up a Tomcat plugin and remote debugging and finding DWR source code and … Of course, this is exactly the sort of thing one has to do when working on an open source project. And I think if I had been able to spend my time exclusively with this team, we could have walked away with the bug fixed.

This experience did remind me why I switched from Java to Ruby for web development (not that Tuscany is a typical case). Frameworks can only do so much in helping to eliminate the fundemental costs of the Java development cycle. The debugging and deployment processes are just so much more complicated and so much more time consuming, that it’s almost maddening. I could go on, but I’ll save it for another article.

Code Fest Recommendations

I still believe producing patches should have been the goal of the Code Fest, but in the end, few patches were generated. We did all learn a lot and some code was written and I’m hoping a few students will keep working on it until it is worthy of submitting back to Tuscany or Radiant. With that goal in mind, here are final thoughts on how how organizers can run future events:

• If possible have only one student team per mentor. If not, plan for how the mentors will be able to work with more than one group.
• Mentors should ideally stick with one project during the event (switching between Ruby and Java became a bit complicated for me, at least).
• If you have a large group of students, then have mentors with differing backgrounds. That way students are more likely to find a project they’re interested in.
• Definitely encourage students to come up with their own project ideas.
• Provide that “getting started” documentation I mentioned.
• Either set aside time for setting up the computers or have them completely setup beforehand.
• Carefully select activities which can be done to completion in the time allotted given the skill level of the attendees.
• Enhancements are often easier than bugs because they can require less intimate understanding of the code.
• Contributing to a wiki, writing a tutorial, or running tests for a release are also all good activities.
• Consider setting aside a room for short presentations, demos, lessons, tutorials, etc. Sort of a one room barcamp running simultaneously. This gives a format for teaching important skills, and lets the students have a place to go to take a break while still being actively part of the Code Fest.
• Start planning the activities well in advance by using a wiki and/or mailing list. Get the students involved as soon as possible.
• Consider inviting more local developers or user groups to help out. They can be a good source of mentors or even just add to the buzz of the event.
• Be sure to invite students to participate in the next Google Summer of Code.

All said, I would be interested in running a student-focused event again. It was fun and (I hope) valuable to the students. Done right, there’s a lot of potential to learn practical software engineering skills and be exposed to some non-trivial code. And schools and universities should have everything they need to get started. If anyone does run such an event, I’d love to hear your thoughts about it, so let me know.

Finally, many, many thanks to the staff at GLDC, HKOSSC, the local schools and universities, and the other mentors who made this happen!