If you shut people in a room for a week with seven other people with the same interests, they have a ball and write a book.
—Adam Hyde, founder of FLOSS Manuals
That’s what happened at the 2013 edition of the Google Summer of Code (GSoC) Doc Camp. A group of 20 open source enthusiasts gathered together in the middle of October and wrote not just one but three books in the span of five days.
I was fortunate enough to attend the event. Here’s a peek at what went down over those five days.
Part unconference, part book sprint, GSoC Doc Camp was organized by Google’s Open Source Programs Office and facilitated by Alan Gunn of Aspiration and Adam Hyde of FLOSS Manuals.
The event drew 20 people from around the globe—from North America, Europe, Africa, India, Sri Lanka, and New Zealand—to Google’s campus in Mountain View, California. Most of the participants were from one of the following projects: Mallard (a markup language used to write online help), OpenMRS (an electronic medical record system platform), and BRL-CAD (a powerful design and modeling tool). The group was rounded out by four free agents (those who weren't, myself included, affiliated with any of the aforementioned projects).
Deciding what book to write
On the first day, Alan Gunn took the group through several exercises that had three main purposes: to get to know each other, to get us to ask questions about what would be going into our books, and to break us out of our comfort zones.
From there, Gunn had us think about three audiences for the books and three outcomes that readers of the book would take away. This exercise was probably the most useful of them all. It helped everyone focus their ideas for the books.
By the end of the day, each project had decided on a topic for their books. BRL-CAD went with writing a guide for potential contributors, Mallard decided to focus on a guide to its markup language, and OpenMRS opted for a developers guide. Myself and the other 'free agents' jumped on board with different projects. I joined the BRL-CAD team. This was an interesting choice because I had no knowledge of or interest in CAD. Talk about moving outside of my comfort zone!
Getting to Work
That started on day two. Each group spent the first half of the day coming up with a table of contents for their books. That was done in a very low-tech way: using sticky notes. Using sticky notes, it’s easier to add, rearrange, edit, and excise sections of a book than it is with a digital tool.
The process of writing
During the process, Adam Hyde admonished us to kill your darlings, meaning don’t be afraid to cut sections or chapters. Even ones that you’re fond of. The idea was for us to focus on what needed to be in our books and not what we wanted or thought should be in the books.
From there, writing began in earnest. A few participants doubted whether or not it was possible to write a book in the time we had. Still, they nudged those doubts aside, grabbed a chapter, and started writing furiously.
It wasn’t just three groups of people typing away in their own little bubbles. There was quite a bit of back and forth among members of all the groups. Questions about structure and style, conversations about approaches to take, and more. Every issue and debate was resolved quickly, efficiently, and bloodlessly. It was refreshing to seethat kind of collaboration and minimal ego-centric behavior.
Still, the trepidation about reaching our goal lingered. Until, that is, Adam Hyde popped in towards the end of the day and told the BRL-CAD team that we’d written close to 8,000 words—this was on par with the work the other teams had done. At that moment, I could feel everyone’s doubts evaporate.
While the pace of writing slowed a bit over the next two days, the focus was expanding on what we’d written on the first day and refining it. The content and structure became firmer and we began adding detail. Again, collaboration came into play. This time, each team exchanged their work with another team. When you’re close to something you’re writing, you need a fresh set of eyes to point out flaws that you have undoubtedly missed. It was then that the admonition to kill our darlings took a life of their own. With the BRL-CAD book, for example, I ruthlessly excised a chapter I’d written that, as someone pointed out, didn’t serve a purpose.
By the end of the fourth day, each team had a book. Adam Hyde then converted the books to PDF, wrapped them in a cover, and sent them to a local print-on-demand service to produce paper copies. The printed books were a nice little reward for a lot of hard work.
How to publize the books
On the first day of the event, Alan Gunn asked us to think about how to publicize the books once they were done. As he said, our efforts could crest like a wave on a beach and then flow out into the ocean, or they could change the world. The goal of every team was to find, at least, that middle ground.
This was the focus of the last day of GSoC Doc Camp. Each team brainstormed and came up with a marketing plan for their books. These included, but went beyond, merely announcing the books on Twitter, in blog posts, and on mailing lists. Several participants wrote articles for publication, and a few planned to distribute books at open source events in the coming months.
I have taken part in book sprints, or write-a-thons, in the past, but I’d never been through the process from end to end. That made for an intense but very satisfying five days. The books that we produced weren’t perfect, but they were darned good. And although they were written by multiple people, the books spoke in one voice.
GSoC Doc Camp demonstrated the power of effective collaboration. And, at its core, isn’t that what open source is all about?
7 Comments