The paradox of free/open source project management

Leaders from
three separate but related — and incredibly successful —
free/open source projects agree: If you want the project to move to
the next level, let go and let the community take over. We
asked Larry Wall, creator of Perl; Brian Behlendorf, the Apache Project leader; and Linus Torvalds, creator of Linux, for
their thoughts on why this happens and how they and their projects have fared as a result.

All of these projects are tied in some way to the great enabler:
the Internet. They share synergy with it. All have contributed to
the growth of the Internet, and the Internet has provided the
medium that has allowed them to thrive. If the Internet is one
extended machine network, Perl is the baling wire that has held it
together. The Apache Server has come out of nowhere to dominate the
Internet statistically.
And Linux is probably the best-loved kernel of all time, whose
popularity continues to surge.

Larry Wall and Perl

What do you get when you cross sh with awk, sed, and C? That’s
right, Perl, the Practical Extraction and Report Language. Larry
Wall released version 1.0 of Perl in 1987. The rest is history. Perl went on to become the
first of the three Ps represented by the third consonant and final
character in the acronym LAMP. In short, it was a
phenomenal success.

When I spoke to Larry on the phone about “letting go” of the
project, he said in a very matter-of-fact way, “I had to. It got
too big for one person.” He talked about the transition, which
happened at about the same time as Perl 5. “The only
alternative would be to keep Perl as a little text-processing
engine, without any modules or anything like that.”

So what part does Larry play these days? He told me “Since we
announced Perl 6, I specifically asked the community to help me
redesign Perl. They turned around and said, ‘We still want you to
be the language designer.’ So my part these days is architectural
and linguistic.”

It’s clear that two things have happened: Larry has stepped
back, but still plays a critical role. We’re not talking a palace
revolution here, we’re talking about a role change in complete
harmony with the community’s desires.

Brian Behlendorf and Apache

The history of the Apache Server is slightly different. It was
never a one-man project to begin with. It was a band of users who
needed to patch the code themselves when the early-movers more or
less abandoned the project.

Brian Behlendorf was one of that band. I asked Brian by email if
he had less day-to-day control over the Apache Server today than he
once did. He replied:

Oh, on many levels. Even initially, I didn’t control
the process; I think I might have done release management around
one or two releases, but my focus was never on day-to-day control
the way, say, Linus has day-to-day control over work that goes into
the Linux kernel. Within Apache we’ve always had more of a
consensus approach to deciding which patches made it in, what
features were added, when the code was ready for a release, that
sort of thing. As discussions progressed around Apache 2.0 I spent
less day-by-day time on the httpd project alone and more on other
items….

One task I did take hold to and more or less owned until
recently was systems administration duties for apache.org — the Web
site, the mailing lists, the CVS trees and bug databases,
everything. I hosted the boxes at CollabNet and spent probably
10-20 hours a week keeping things running as seamlessly as I could.
The hardware was no problem — it was getting all the other
necessary software to work well that was the pain, and there was
never enough time to properly refactor or re-architect.

In fact it was this activity that drove me to realize that the
state of the art making these tools work together was pretty
abysmal — one of the reasons for starting CollabNet in 1999, and we
now provide such a collaboration infrastructure for companies on a
paid basis. Apache’s setup is customized enough that it’s still
being managed by hand by some very capable and selfless engineers,
and I still help them out from time to time.

In 1998, when the Apache developers decided to form the Apache
Software Foundation, I became its president, and remained for three
years before handing off the torch. I am still active as a director
on the board of directors, but not active (except as an avid user,
fan, and occasional bug reporter) of other projects.

Does Brian think he is better off because of that?

Well, it’s hard to determine if the fact that I’ve had
a very fun last 10 years was helped or hindered by being less
involved in day-to-day development of the Apache Web server. 🙂 I
think it was probably the better thing for me to focus on both the
back-end sysadmin stuff, the promotion and public speaking I’ve
done for the ASF, being on the board, that kind of thing. I
definitely miss being able to work with the server team though,
participating in design discussions, seeing if we can squeeze yet
one more ounce of performance, that kind of thing is definitely
fun. It’s a form of learning that can’t be replicated by a
classroom, a book, or even a job.

What about the project itself, is it better off?

From my departure? If I said yes, would I be admitting
that when I was active, the project was worse off? 🙂

All software projects see developers come and go — it’s a fact
of life. I respect and admire Linus for 14 years now of working on
the same code base, but most developers crave new challenges and
experiences, which makes it important to bring new developers in
and make them feel their participation is valued and makes a
difference. It’s one thing I hope we do well at Apache — bring in
new developers, and gracefully allow current developers to move on
when they’re ready, without disrupting the viability of the
project.

Linus Torvalds and the Linux kernel

Last but not least, we turn to Linus himself. and ask the big
question: Do you feel as if you have more or less control over
kernel development today than you did five years ago? As usual,
Linus pulls no punches.

I certainly think so. And it’s all in a very positive
way.

One of the things I’ve been pretty happy with is how I generally
_have_ been able to fairly gracefully relinquish control. It really
is harder than you’d think, and I think it ends up being one of the
core problems that some open source projects have: people (and
companies) wanting to keep tight reins on a system, because they
have their own “vision” of where they want things to go, or how
things have to be done. And that stifles the project. It doesn’t
allow others to feel like they control their own destiny.

So I have my own issues, and I end up being a control freak too
in some areas, but I think it’s worked out pretty well.

I want to still be involved with Linux, but not as a brake for people who have other
visions and ideals.

Some other projects had to almost fail — or fork — before the
control got wrested from a too-controlling entity. It’s a very fine
balance to walk, I think: you need to still _care_ deeply, but you
can’t believe you know best, and there’s a lot of trust needed when
you decide that somebody else really is fit to make your decisions
for you.

But it’s really not a question you should ask me. The real
question of how successful I’ve been is in whether _others_ feel
like they can control the parts of Linux that they are involved
with and they work on.

I’m not going to say that everybody is happy (and it’s not even
a goal of mine), but I think we’ve been able to maintain a pretty
healthy balance — having people who care (and it’s definitely not
just about me — it’s all the other maintainers too who have to be
able to accept input from the outside), but who don’t control
things to death.

Conclusion

Don’t expect Linus to be going away. I’ve got a feeling he is in
it for the long run, albeit more focused and better supported than
ever before. If you’re planning on creating a hugely successful
free/open source project of your own, include a plan for letting
go when the time is right. If you don’t, it’ll never get bigger
than you are.