Alas, it's taking me much longer to write up my OSCON trip
report than I had planned. Part of that is that I've been busy
with other things, like resurrecting a testbed for the SCM
framework, so that I can start on the workaround for the
mounts" issue. And part of it is that it's
just taking me longer to do the writing, despite
already having an outline. So since I have finished my
comments on a couple talks, I'll go ahead and post those now.
My favorite session at OSCON was "How to Lie Like a Geek" by
Michael Schwern, which was a lively talk about things we can do
to help or hinder communication. Most of us are familiar with
technical lying, particularly bad benchmarking and abuse of statistics. Michael recommended shootout.alioth.debian.org
as a place to get good benchmarks.
Michael also suggested several ways to "lie" that are more
generic. Many of these had to do with getting so caught up in
details that the big picture is lost. For example, there's
lying by information overload: providing too much detail.
There's also lying by pedantry or by being excessively literal:
focusing on the wrong details.
A fascinating way to mislead is to state the obvious. For example,
consider this exchange (which
I've adapted from the example Michael used):
Alice: We should change this code.
Bob: But that could introduce bugs.
Alice: Of course. Why are you arguing against making the
Bob (annoyed): I'm not, I'm just saying we might introduce bugs.
words in my mouth.
I've seen exchanges like this in the past. At best, there's
this unnecessary hiccup in the conversation. At worst, the
conversation goes off into the weeds, with endless rounds of claims and
counter-claims about who said what and what was really meant.
When I mentioned
this example to my wife, she pointed out that people often make
implicit requests in their statements. So if Bob says something
obvious, he's clearly not offering new information, so it's
not surprising for Alice to interpret his comment as a
request. If Bob had a different request in mind, like
"let's defer that until after the code freeze", it'd be more
helpful to say that in the first place.
Another talk that I liked a lot was "Programmer
the Genius Myth", by Ben Collins-Sussman and Brian
Fitzpatrick. I had to chuckle at this quote, which Ben and
Brian said came from the 2008 Google I/O
Can you guys make it possible to create open
source projects that start out hidden to the
world, then get "revealed" when they're
site supports hidden projects. And for
awhile we created new projects as hidden, so that the project
team could get the project page set up before making the
project visible. But hiding the project doesn't provide that much
benefit. After all, the project space is a work area; it's okay
for things to be rough. And we've had a few problems with
projects lingering in hidden mode for a long time. So
we've moved towards making projects visible from the start.
Of course, it's natural for people to want to get things right
them with the outside world. But there are potential
advantages to sharing early. One is that if you're going down the
wrong path, early sharing improves the odds that you'll discover
the problem quickly. And if you have to explore a couple
dead-ends before you come up with something that works, the
information from those explorations is available for others to
And then there's the "bus factor", which refers to the number
of people who would have to all be run over by a bus to stop the
project. Working in the open--with archived discussions,
publicly visible code, any plans and documentation that you've
written down--makes it
easier to recover if a team member is unavailable for whatever
Ben and Brian did point out that it is possible to share too
early. The project needs to be far enough along that it won't
get stalled when outsiders show up and start asking questions and
But since working in the open like this can be challenging,
what are things we can do to encourage it? Ben and Brian
made several suggestions, both social and technical.
On the social side, the first thing to remember is not to let
your ego get tied up in your design or code. You've probably
heard that before, but I think it bears repeating. When someone
points out a problem in my design or code, I try to think of it
as an opportunity to improve something that I care about, and as
an opportunity to learn. But that's often not my initial, automatic
response; it takes some effort.
Even if you don't expect your project to benefit from
outsiders' comments, engaging in a conversation can have benefits.
As Ben and Brian put it, if you want to influence people,
you need to be open to influence.
On the technical side, consider what behavior your tools are
encouraging. For example, the current opensolaris.org portal
doesn't keep page histories, which discourages its use for
collaborative writing and editing. That's one of the things
that will be fixed by the move to XWiki in
Ben and Brian also recommended responding to questions and
arguments on the project web site, rather than by email. With
that approach, they said, the discussion is less likely to
degenerate into pointless argumentation. I don't recall them
saying why they think this works. I suppose one reason is that
from being repeated.