[FM Discuss] Writing a posting for Google blog on recent sprint

Andy Oram andyo at oreilly.com
Fri Nov 4 00:29:08 PDT 2011


Stephanie from Google read my postings ( 
https://bitly.com/bundles/praxagora/4 ) and like them, and asked me to 
do a write-up of the sprint for their Open Source blog. I'm not sure how 
to frame it, but I threw together the following draft and thought other 
people on this list could help write it.

Andy

---

For a long time, there was talk around Google's <a
href="http://code.google.com/opensource/">Open Source Programs
Office</a> of doing a "Google Winter of Documentation" to complement
their long-running <a href="http://code.google.com/soc/">Google Summer
of Code</a>. This past month, Google took a big step toward giving
documentation its due with a five-day <a
href="http://google-opensource.blogspot.com/2011/09/sprinting-for-open-source.html">Google
Summer of Code Doc Summit</a>. The event was inspired and driven by <a
href="http://booki.flossmanuals.net/groups/gsoc-doc-summit/">FLOSS
Manuals</a>, an organization of volunteers (of which I'm one) that has
received increasing recognition for its documentation projects and the
related community-building they stimulate.

<p>

The summit did not exactly take place in the summer (in fact, I have
pictures from the site of a sukkah [which I will provide], a
distinctly harvest-related religious symbol. But it returned projects
and many people who had participated in GSoC. It was predicated on the
realization at Google (and at least among pockets of open source
developers) that free software needed more than good coders to be
successful. It needs communities of people caring for each other and
guiding each other through the best use of the software, and part of
this community effort is good documentation.

<p>

Google's willingness to provide a hotel, work space, and food for some
thirty participants, along with staff support all week long,
demonstrates their commitment to nurturing open source. Google is one
of several companies for which I'll coin the term "closed core." They
code on which they build their business and make their money is
secret. (And given the enormous infrastructure it takes to provide a
search service, opening the source code wouldn't do much to stimulate
competition, as I point out in a <a
href="http://radar.oreilly.com/2010/12/what-are-the-chances-for-a-fre-3.html">posting
on O'Reilly's radar blog</a>. But they depend on a huge range of free
software, ranging from Linux running on their racks to numerous
programming languages and libraries that they've drawn on to develop
their services.

<p>

So Google contributes a lot back to the free software community. The
release code for many non-essential functions. They promote the
adoption of standards such as HTML 5. They have been among the first
companies to offer APIs for important functions, including their
popular Google Maps. They have opened the source code to Android
(although its development remains under their control), which has been
the determining factor in making Android devices compete with the
arguably more highly-functioning iOS products. They even created a
whole new programming language (<a
href="http://code.google.com/p/go/">Go</a>) and working on another.

<p>

Google is not only "closed core" company (for instance, Facebook has
also built their service around APIs and released their <a
href="http://cassandra.apache.org/">Cassandra</a> project). The
movement represents a fertile collaboration between communities and
companies with businesses in specific areas. The closed core model may
prove more robust and lasting than open core, which attracts companies
occupying minor positions in their industries and is in danger of
losing its shining example, MySQL.

<p>

To understand the five-day conference itself (which I <a
href="https://bitly.com/bundles/praxagora/4">wrote about extensively
on Radar</a>), you have to know something about FLOSS Manual and its
intense "book sprint" process. FLOSS Manuals was started by artist
Adam Hyde several years ago to fill the gap in free software's
documentation. From the start it focused not on small articles or
wikis but on full manuals. Adam developed the book sprint as a way to
pull together a community and get something done quickly that
everybody could point to as an achievement for their community.

<p>

Five to ten developers, power users, and core supporters meet in a
workplace for three to five days and write, sharing their work. Remote
contributions are encouraged, and outsiders often weigh in with key
points. It's a chaotic process that converges suddenly on the last
day into a 80-page to 150-page book, and it leaves a high-endorphin
sensation among the participants that propels them toward other
community-related activities. Books are frequently translated into
other languages, are available both on web sites running FLOSS Manuals
software and in print, and are kept "live" so that people can
contribute to them later.

<p>

My Radar articles contain my own lessons from the Google/FLOSS Manuals
sprint. The four projects that participated took back not only a book
but guidelines for keeping it alive and capitalizing on the
educational and promotional activities that a book permits. And
Google? Presumably their staff also derived valuable insights from
the sprint, such as the relationship between code development and
documentation, and the potential for documentation efforts to marshal and
motivate a community..



More information about the Discuss mailing list