Book review: Open Advice

The recently released Open Advice has much to offer those who are new to free software and its communities, but there is plenty of interest to veterans as well. It is a collection of essays from an auspicious number of contributors (42) to free and open source software (FOSS) that centers around the idea of "what we wish we had known when we started". As might be guessed, the book encompasses more than that—it ranges all over the FOSS map—including recollections, war stories, philosophical musings, academic research, and good advice.

The book was the brainchild of KDE contributor Lydia Pintscher, who served as the editor as well as contributing one of the essays, "Being Allowed to Do Awesome". The book was released at the recent FOSDEM conference in Brussels and is available in a variety of formats (PDF, EPUB, Mobi). But the book is licensed under the CC-BY-SA license, which means that the LaTeX source is also available. In addition, printed versions of the book can be ordered from Lulu and, soon, Amazon.

The material is spread out over 16 chapters after a foreword by Free Software Foundation Europe founder Georg Greve. He sets the tone for the book by introducing the ideas of free software and communities, specifically connecting the rise of the internet and free software as "co-dependent" developments. Not only does free software run much of the internet, but many of the internet giants that are popular today (Google, Facebook, and Twitter are specifically mentioned) could not have gotten so far so fast without depending on free software.

What follows is a bit of a wander through the different facets of our communities, with an eye toward passing on some of the hard-won knowledge that these contributors have gained. Armijn Hemel notes that projects need to coalesce around code, so that there is something to work with and improve. All the design documents and ideas in the world will not actually build into a community. Evan Prodromou furthers that idea by noting that once there is code, the founder needs to step back and let others contribute. It is, he says, sometimes hard to do, but is essential:

Markus Krötzsch and Felipe Ortega talk about the connection between academia and FOSS, but come at it from different angles. Krötzsch looks at the challenges that researchers face when opening their code, many of which are applicable to anyone trying to form a community of users and contributors. He likens the effort to gardening. Ortega looks at how different FOSS communities evolve as project members come and go. He notes several studies of different kinds of projects and how they have overcome the "generational relay" problem—handing off the project to new leadership over time.

But in order to increase a project's contributors, some recruitment and mentoring are needed. That's the subject of one of the chapters. In it, Leslie Hawthorn points out that contrary to their belief, people new to the project have something unique to offer:

Hawthorn's point crosses into the realm of documentation, which is the subject of a later chapter, but that just highlights one of the strengths of the book. Few of the essays neatly fit into the categories of the chapter they appear in. They largely represent a personal view of the experiences of the author, which often range across various parts of the FOSS world. They are also uniformly encouraging to those who may know little or nothing about how to participate and why they might want to.

Pintscher's entry notes that the biggest enemy of free software is "not who most people on the Internet think it is", but is, instead, a lack of participation. She notes that it takes active effort from existing project members to get new contributors involved, but that it's worth the effort. It's also important to recruit from outside the existing contributor base:

Henri Bergius writes about cross-project collaboration and notes that creating libraries, rather than frameworks, better fosters that collaboration. In addition, he says, meeting in person can go a long way toward helping projects work more closely together:

That sentiment is echoed by others, including Nóirín Plunkett in the chapter on "Conferences and Sprints":

But, all is not "sweetness and light" in the free software world as Máirín Duffy Strode describes in her look at the interaction between designers and developers. Her essay, "Don't Be Shy", suggests that designers (and, by extension, all new contributors) make their needs known so that they can "help the project help you help them", which can't happen without making it clear what's needed to get the job done. She also notes a bit of cautionary tale about being chased away from a project and suggests that new contributors be persistent:

There are several essays on various aspects of documentation. From Atul Jha's reflection on how Eric S. Raymond's writings (in particular the jargon file and "How To Ask Questions The Smart Way") inspired him, to Shaun McCance's look at how to use the "crowd" to generate project documentation, there is a wealth of interesting information. Rich Bowen plays off Larry Wall's famous "virtues of a good programmer" (laziness, impatience, and hubris) and notes that those virtues unfortunately give some programmers a "license to be jerks". He goes on to describe virtues for another group:

Anne Gentle introduces an interesting idea about how a new contributor can "take the pulse" of a project to get a feeling for how hard or easy it will be to get involved:

In the realm of usability, Guillaume Paumier offers up some things he's learned working with the Wikimedia Foundation. He suggests that developers sit down and passively watch users interact with their application. It is "truly an eye-opening experience". Furthermore, he offers up an important point that sometimes gets lost in the development process: "Users are an unpredictable species. But they are on your side. Learn from them."

Federico Mena Quintero has a lengthy essay on "Software that Has the Quality Without A Name". In it he takes concepts from the architectural (i.e. buildings, not software) studies done by Christopher Alexander and others and applies them to software design. The "quality without a name" is embodied in buildings and spaces that are eminently livable. Alexander has come up with a number of properties that govern such spaces and Quintero (by way of Richard Gabriel's Patterns of Software) applies those ideas to software. It is one of the more philosophical essays in the book, and well worth reading in its entirety.

There is also some real "nuts and bolts" advice on things like conference planning (from Dave Neary) and a nice explanation of "How to Ask for Money" (for conferences) by Selena Deckelmann. Beyond that, there is advice on community management and the role of a community manager from Jono Bacon, thoughts on the intersection of law and FOSS from Till Jaeger, ideas about testing from Ara Pulido (and others), and on and on. Not mentioning one of the essays in this review is in no way an indictment of the essay or author, there is more there than one could hope to cover. In addition, each reader will undoubtedly have their own slant on the most interesting and useful essays in the book.

Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about. It is, in short, a great book for a variety of audiences and the (mostly) two or three page essays make it easy to read, while the anecdotes and recollections personalize it. The authors, editor, and everyone else who helped should be very pleased with the result. Readers will be too.