World traveler maple syrup

This is very well traveled maple syrup. 

In November, Shane brought this syrup to Seville for me, from Boston. He forgot to give it to me until I had already left for the airport. So be gave it to Ruth to give me the next time we traveled together. 

Unfortunately, Ruth forgot to take it to LA when we were there last month. So she brought it to Boston to give it to me. And I just had brunch with Shane. 

So the syrup has come back home to Boston, and is now in my suitcase heading home.

Apache Board

This time last year, I was nominated for the Apache Board of Directors, and I wasn’t very keen on it. I was on the down-swing of getting burned out with ASF stuff, which comes every few years of any volunteer effort, no matter how much you believe in the mission of the organization. It does one good to step back from it every few years.

I made a rather half-hearted position statement that basically said: “all of the people on the ballot are great, and any board chosen randomly from this slate will be great.” I wasn’t elected to the board.

However, midway through the term, there were some resignations, and I found myself on the board again.

This time around, I am much more passionate about it and have actually made an attempt to state what I think the board needs. In short, it’s more delegation.

We have arrived at the size where we must delegate, trust those to whom we delegate, and resist the urge to tinker in the minutiae. This is very, very hard, and is especially hard for our current slate of directors, because we are all so deeply passionate about the mission of the Foundation.

Non-profit and volunteer-based organizations have the tendency to rely on heroes – people who take on 90% of the work, rather than delegating. The thing with heroes is that they are awesome as long as they are around. But eventually, they burn out, or retire, or move on to other things, and then suddenly you have a crisis. We need to find a way to identify areas where one person is doing a disproportionate amount of the work, and find a way to delegate that work to several other people, and then be willing to let them do the work, even when we think they’re not doing it exactly the way we’d do it ourselves.

The election of the new board will happen at the ASF members meeting on March 28th. And whether or not I’m elected, I have my work cut out for me in the coming year at Apache. There’s just so much to do.


For St. Patrick’s Day, and for Poetry Friday, here’s Green, perhaps the best poem I ever wrote:

Oh, and here’s me reading it, too, over here:

Dec 5, 2007

My favorite color?
Well, the question lacks context
and therefore meaning.

My favorite sky is
sharp aching blue,
the kind of blue you can
cut your fingers on
until they bleed into
and African Sunset
and plunge into a
deep purple African night,
with the diamonds of
faraway worlds scattered
like the dust thrown up
by the passing herds.

My favorite sea is
gray-green-blue stormy
swirling seaweed churned
from depths beyond imagining,
the sky a reflection of a
reflection of infinity,
winking back at you from
a million million miles down.

My favorite earth is the
dark maroon red brown
of the Maasai clay
brittle and cracked
under the Tsavo sun,
gummy sticky under the
monsoon rains
sweeping up from Victoria,
thundering past on their way
to green the highlands,
glisten on the tea leaves,
pound the coffee flowers
from their branches,
and drench the faces
of the beautiful children
running around in what
God dressed them in,
laughing and shouting
in a language I will never know
but that sings fluently
in the memory of my heart.

So, you see,
the question is unfair.
As well ask a man
to choose one food
to live on forever,
one wine to drink,
one song to sing,
one painting to gaze at
for all my days.

But if I must choose,
I choose the green
of the Kericho fields,
stretching to the horizon,
the beginning and ending
of my world.
The green of a
1952 Ferrari Barchetta,
with its greedy grinning grill
sucking in the wind
of a winding Italian mountain road
tires squealing around the corners,
flashing past a
sleeping countryside
content to be stuck in a simpler time.
The green of
the foothills of Ngong,
acacias and baobabs
clawing at the
dark, angry sky,
promising threatening delivering rain,
the hills singing to my heart,
come and walk our paths,
come and feel the
wind tugging at your hair
come and
lay on your back and
watch the clouds dance
across the sky,
dance from one end of the sky
to the edge of the world,
where the
blue falls back once again
into the red dust
of the far Mara horizon.
The green of my voice,
singing across the years,
telling my stories to
the attentive ears,
the deep green eyes
of the friend of my heart.


Reposting from an email I sent a while back:

As several people have asked about my todo list within the last 2 weeks, I thought I’d share the goodness with everyone.

I’ve been using todo.txt for about a year now.

Don’t let the website fool you. todo.txt isn’t (primarily) a gui app, or a phone app. The todo list is in a plain text file. There’s a dozen different tools that you can use to manage it, but I just use the command line:

t ls – what’s in my list?
t add ITEM – Adds ITEM to my todo list
t pri ## A – Makes item ## priority A
t do ## – Marks item ## as done, moves it to DONE list for later reference
t ls blarg – Lists todo items that match ‘blarg’
t lsp A – Show me all the things that are priority A
done – An alias to ‘cat ~/Dropbox/todo/done.txt’ which shows me what I’ve done most recently

If you happen to store your todo list in your Dropbox directory, you can then also use the free Android app to manage your todo list from your phone. (I’ve heard it also work with google drive, or owncloud, or a variety of other things.)

As someone who has used every possible todo list out there, including a dozen issue trackers, and writing a few different todo list webapps, sticking with a single tool for a whole year is unprecedented. Being able to work from the command line made all the difference for me, since that’s where I always am anyways.

OpenStack PTG, trip report

last week, I attended the OpenStack PTG (Project Teams Gathering) in Atlanta.

Even more in depth: PTG info at


1) This is a hugely productive event, with project teams getting an enormous amount of work done without the distractions that are usually present at a conference.

2) I remain very concerned about how this event will effect the
character of OpenStack Summit – removing the bulk of the engineers from that event, and making it more product/marketing/sales focused. Time will tell

At the gathering, I did 23 interviews with Red Hat engineers about what they did in the Ocata release. You can see some of those interview on the RDO YouTube Channel. I’m not done editing them all yet, but they will appear over the coming weeks as part of various blog posts, as well as all of them appearing in that YouTube playlist.

I am constantly blown away by the passion, expertise, and
professionalism of the folks I get to work with. Wow.

Anyways, more about the PTG.

I was (and, really, still am) very skeptical about this new format.
Splitting OpenStack Summit into four events rather than two has already had significant impact on travel budgets, not just at Red Hat, but also at other companies involved in OpenStack. A lot of companies, for example, didn’t send anyone to FOSDEM, and we had a hard time staffing the OpenStack table there. Usually people work one shift at the table, but this year several of us worked 4 and 5 shifts to cover all the slots.

I am concerned that splitting the engineers off into their own event
will significantly change the character of OpenStack Summit from being a community-centric, tech-centric event, to more of a sales and marketing event, light on technical depth.

But this event, for what was intended, has already been amazing.
Everyone is commenting on how much is getting done, how much less distracted the team meetings are, how much better the teams are gelling than they have at any previous event. This is a working event, and people are here to get work done. They are meeting all day, every day, working on plans and blueprints, and fighting out agreements on things that would take weeks in email, and everyone seems VERY pleased with outcomes.

So, perhaps the trade off will be worth it. Time will tell. Regardless, Erin Disney and her team put on an amazing event that fulfilled, and exceeded, its goals.

On Wednesday  night, everyone that has ever contributed a patch to RDO was invited for drinks and hors d’oeuvres at the SideBar, and while there the RDO Ocata release announcement was sent out.

We had about 50 people in attendance, who ate and drank up all of my budget in about 2 hours.

Here’s some pictures.


Too many beginners

Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.



Project Leader

I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:

A healthy project has a visible lead(s). Who is the project lead(s) for this project?

This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.

Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.

There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:

  • What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
  • What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
  • What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?

A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.

But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.

BAHA 5 Power

Back in December I received my replacement hearing device, the BAHA 5 Power.

The photo shows the last three generations of the BAHA. The one on the left i the one I was replacing – the “Intenso”. The one in the middle is, I think, the BAHA 3, which is what I had as a loaner while waiting for the replacement. The one on the right is the 5.

One of the features of the 5, which makes it practically magical, is that in high noise situations it can make it possible to hear voices. I was a little skeptical, but I had the first opportunity to test this on Friday night when I attended a gathering of Asbury Math department alumni. The room was very noisy, and I turned on the “noisy room” setting. For a moment, everything got a lot louder, and then after a few seconds – I presume it had to calculate ambient noise of whatever – the roar  of the crowd lowered, and I could clearly hear the person next to me – professor Ron Welling, who taught me Abstract Algebra back in 1991 or so – and understand his words.

I’m reminded of meeting Vint Cerf, and his wife, in 1996 or 1997. Someone asked him to think back over the technology advances in his lifetime, and say which one was the most amazing. Rather than talking about the Internet, he said that the most amazing, almost magical, was his wife’s cochlear implant, which let her hear and understand speech, after decades of hearing nothing. At the time I had a Xomed Audiant, which was a very early generation of what I have now.

Each generation of this technology gets more amazing. The new one even does Bluetooth! But the voice enhancement and noise reduction is truly amazing. I expect it to make attending conferences much more bearable.


The Margin Is Too Narrow