Leadership Lessons: Passion, Smarts and What Open Source Can Learn About Management

Open source is changing the rules about how software is designed, created and distributed. But leadership isn’t always nearly as innovative. Esther Schindler spoke with Ubuntu’s Mark Shuttleworth and two of the dudes who run SourceForge, and discussed some of the lessons the open source community could bear to learn.

Some projects—in IT, open source, or the world at large—become major successes. Others fail or (more painfully) they almost succeed; the projects or products survive, but never reach their potential. Sometimes the difference is luck, sometimes it’s technology… but we all know instinctively that successful endeavors generally are the result of people working together to make the right decisions.

The O’Reilly Open Source Convention has barely started, yet I’ve already had two mind-expanding conversations which have touched on leadership and management skill. One conversation was with Mark Shuttleworth, founder of the Ubuntu Project, and the other was with Jon Sobel, SourceForge group president and Ross Turk, community manager for SourceForge.net. Now that open source is no longer a novelty and isn’t merely the province of techies, these guys (and others) are thinking hard about how to keep the momentum going, how to promote developer involvement and what tools and technologies are necessary to promote innovation and collaboration in the community.

These are not concerns peculiar to open source, as anyone who runs a project knows. What comes next? What people-processes can we put in place to help people on that path, not hinder them? Where can technology improve things? What might screw us up?

One aspect of this issue that fascinates me (and probably can inspire several blog posts) is organizational culture. I’ve long believed that the leadership at the top of any organization defines the culture, for good or ill. I remember early Microsoft employees adopting Gates’ phrases and attitudes (such as, “That’s the stupidest thing I’ve ever heard!” and rocking during meetings… which was a little strange); certainly the ethical decisions that inform employee behavior come from the folks who run the joint. That’s no surprise; when you admire someone, you want to emulate them.

This is as true for volunteer organizations (including open source development communities) as it it for corporate entities. In fact, it’s probably more important when money is not the primary motivation. I haven’t figured out how exactly to measure this, but my non-scientific evaluation is that most successful open source projects have a benevolent dictator who acts as an arbiter and decision-maker. He or she also sets the volunteer version of “corporate culture,” by creating an environment where, say, new members feel welcome, or the community presents itself as a clique. (Hey, isn’t a clique the sound a French camera makes?) Examples, besides the obvious Linus Torvalds and Shuttleworth himself, include Guido von Rossum for Python and Alexander Limi for Plone.

The SourceForge folks gave me some data that fits in here.

I dare say you’re familiar with SourceForge, which hosts some ungodly number of open source projects (the site says 182,599, if you’re in a counting mood). You can download a project’s executable files or source code, find a project to match your need, get in touch with the contributors in its forums, and so on.

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?