As Sobel and Turk explained to me, the long tail applies to SourceForge as it does to anything else online; some "name brand" projects represent a major percentage of site traffic, but just about every project, no matter how obscure, has at least a few downloads and contributions.

When SourceForge took a close look at open source projects' activity, they noticed that the key contributors (the "Guido" of any given project) didn't really submit that much of the new functionality once a project grew past a set of core people. Most new features are added by the inner circle of contributors and committers around the project leaders; the leaders refine the new feature, encourage discussion, and find ways to incorporate it. But they no longer write that much new code.

Well, yeah. They're called managers-a word that techies have a tendency to reject because so many corporate managers are inept. And-here's a point, finally-while open source developers can train each other in technology skills (sometimes by example, when another programmers corrects or optimizes your code), there's nothing in place to train a developer to lead a project or to be a manager. Sometimes those training resources exist in corporate America (with debateable usefulness), but they sure don't exist in in open source circles. How does one learn to motivate and inspire others?

And for sure, that's a necessary skill for a project's success. When I discussed the SourceForge evalution with Shuttleworth this morning, he described the role of the rock stars in an open source project as "holding the culture of the project in their hands." Like VCs, he said, they're the arbiters of what's possible. I like that phrase.

Some people have a natural talent for leadership. They can cajole the most reluctant person to contribute, and to get great joy from it. They can cope with difficult team situations, such as the geographic dispersion of most open source communities. They can smooth feathers, get ducks lined up in a row, and probably achieve a third bird-related analogy in a single sentence. Other people... well, they have passion for what they're doing, but somehow they never learn how to lead. Even when they want to.

Obviously, not every community works exactly the same way. Sobel pointed out that Apache doesn't have any one Head at the top; it's a differently structured society. And before you do, I'll add that a lot of successful organizations have two heads (easy example: Wozniak and Jobs); usually one is inward-facing (develop the technology) and the other disseminates the technology to the world. I can't think of major open source projects in the dual-headed category, though perhaps you can.

Shuttleworth, like many open source proponents, is watching the community change as it evolves from geeky hobby to new-business-model-as-usual. This week, Canonical is releasing Launchpad 2.0, with features to improve collaborative development; Shuttleworth will also run a session about Agile methodologies in open source communities. And OSCON has a lot of sessions on people-meets-tech. If I'm lucky, I'll find a few minutes in the next few days to write about some of these technical explorations, if only so I can find an opportunity to use "hackcessibility," a word Shuttleworth coined on-the-fly this morning.

But for now: I think that part of the open source evolution has to be in training people to lead teams. Nothing says that such training has to use an old proprietary model; the free software community can be innovative in this area, too.

Anybody ready to get started?