5.2. Hire for the Long Term
If you're managing
programmers on an open source project, keep them there long enough
that they acquire both technical and political expertise�a
couple of years, at a minimum. Of course, no project, whether open or
closed-source, benefits from swapping programmers in and out too
often. The need for a newcomer to learn the ropes each time would be
a deterrent in any environment. But the penalty is even stronger in
open source projects, because outgoing developers take with them not
only their knowledge of the code, but also their status in the
community and the human relationships they have made there.
The credibility a developer has accumulated cannot be transferred. To
pick the most obvious example, an incoming developer
can't inherit commit access from an outgoing one
(see Section 5.5 later in this
chapter), so if the new developer doesn't already
have commit access, he will have to submit patches until he does. But
commit access is only the most measurable manifestation of lost
influence. A long-time developer also knows all the old arguments
that have been hashed and rehashed on the discussion lists. A new
developer, having no memory of those conversations, may try to raise
the topics again, leading to a loss of credibility for your
organization; the others might wonder
"Can't they remember
anything?" A new developer will also have no
political feel for the project's personalities, and
will not be able to influence development directions as quickly or as
smoothly as one who's been around a long time.
Train newcomers through a program of supervised engagement. The new
developer should be in direct contact with the public development
community from the very first day, starting off with bug fixes and
cleanup tasks, so he can learn the code base and acquire a reputation
in the community, yet not spark any long and involved design
discussions. All the while, one or more experienced developers should
be available for questioning, and should be reading every post the
newcomer makes to the development lists, even if
they're in threads that the experienced developers
normally wouldn't pay attention to. This will help
the group spot potential rocks before the newcomer runs aground.
Private, behind-the-scenes encouragement and pointers can also help a
lot, especially if the newcomer is not accustomed to massively
parallel peer review of his code.
When CollabNet hires a new developer to work on Subversion, we sit
down together and pick some open bugs for the new person to cut his
teeth on. We'll discuss the technical outlines of
the solutions, and then assign at least one experienced developer to
(publicly) review the patch that the new developer will (also
publicly) post. We typically don't even look at the
patch before the main development list sees it, although we could if
there were some reason to. The important thing is that the new
developer go through the process of public review, learning the code
base while simultaneously becoming accustomed to receiving critiques
from complete strangers. But we try to coordinate the timing so that
our own review comes immediately after the posting of the patch. That
way the first review the list sees is ours, which can help set the
tone for the others' reviews. It also contributes to
the idea that this new person is to be taken seriously: if others see
that we're putting in the time to give detailed
reviews, with thorough explanations and references into the archives
where appropriate, they'll appreciate that a form of
training is going on, and that it probably signifies a long-term
investment. This can make them more positively disposed toward that
developer, at least to the degree of spending a little extra time
answering questions and reviewing patches.
|
No comments:
Post a Comment