What do you get when you bring developers from around the world to the same place for four days of intense coding? In the Plone community, we call this a sprint. I like to think of sprints as jam sessions for coders, an opportunity to work and play side-by-side other talented programmers and try out new ideas among peers.

To get a better sense for what a sprint is like, I invite you to read Jon Stahl’s reflections on the Seattle Sprint, an article Ready, Steady…Sprint! Creating Open-Source ECM, that appeared in CIO magazine about the Boston Plone4Artists sprint, and journalist Esther Schindler’s blog posts about the DocComm sprint at the Googleplex.

At the Plone Science sprint hosted by UCDavis this week we are sprinting on improving the scientific tools and documentation of Plone. It’s a self-organizing activity and we have been planning our work collaboratively in the planning wiki.

As an example, look at the tasks identified for CMFBibliographyAT, a tool that makes it easy to list publications in your Plone site. CMFBibliographyAT is an incredibly useful tool for academics at colleges and universities who want to make a comprehensive list of their published articles. It has some great time-saving features such as importing lists of publications via BibTex and Endnote. Stay tuned for a screencast with the author Raphael Ritz!

In order to better track the issues, prioritize and assign them to owners, we created tasks in the tracker from these issues. Ideally, we would have done this prior to the sprint to save on time, but sometimes it’s necessary to discuss the issues in order to create well-written tasks.

One thing that cannot be underestimated is the knowledge transfer that takes place when programmers meet in the same room and pair program. This is the biggest reason to attend a sprint. You will learn new things, probably a lot more than you would if you paid for lecture style training.

The reason this way is better is because you work very closely but informally with other developers. Working hands-on, there are ample opportunities for asking questions and tap into the brainpower of others in the room. Then in the evening you go out and have a beer with the same people. Sprints are not only great learning experiences, they’re a lot of fun too!

Most of the time, open source software development takes place between highly distributed teams of individuals, who are not working in the same physical space. Linux, the most popular open source operating systems, was created this way. How do they collaborate when they’re spread out all over the world? The communication takes place real-time on IRC or asynchronously on mailing lists.

A sprint gives people the opportunity to meet each other in person. But for those who cannot be present, we invite them to participate as remote sprinters. To give them eyes and ears into what’s happening at the sprint location, we’ve set up a live video stream. That way, they can hear what we’re talking about and still participate even though the conversations aren’t happening on IRC.

One of the overarching tenets of open source is transparency, and broadcasting what we are doing real-time is just one way to share the trials and triumphs of the sprint team. Another way is to post the IRC logs for those who want to see what has been discussed.

Inspired by Jonathan Lewis’ daily podcast reports from the Plone Archipelago sprint in Norway, I decided to make a video each day with highlights from that day. The first video from day 1 is posted and can be found on plone.tv. There wasn’t much coding on the first day, but we had a great time exploring the eateries in Davis and hanging out at Steve’s house in the evening. Thanks Steve!

I’d also like to thank the UCD Center for Mind and Brain who made it possible for me to participate in the sprint. Thanks to the other sponsors we are fortunate to have Raphael Ritz (from Germany/Sweden) and Balazs Ree (from Hungary) participating in the sprint.