A Penguin with an Egg: Growing the Open-Source Community

CIO — The open-source community is no longer the sole province of technology geeks. The mood is shifting. As the mistress of ceremonies at OSCON (the Open Source Convention) commented: instead of open source trying to figure out its place in the enterprise, today the enterprise is seeking its place in open source. And that, among other trends, is causing changes in the community.

Which is not to say that open source isn't still remarkably geeky and willing to celebrate that personality attribute. SourceForge did offer free tattoos to the first 10 people willing to sport an open-source themed design, an offer that we're unlikely to see at a Gartner conference. Nor can I imagine most IT conferences offering session titles like Damian Conway's "Temporally Quaquaversal Virtual Nanomachine Programming in Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces... Made Easy!" And I saw plenty of purple hair and outfits that would make my mother breathe softly, "Oh, my."

Yet, several OSCON sessions and one-on-one conversations addressed the community's self-conscious awareness of who and what it is, and how it might get better, bigger and more helpful to its members.

That was marvelous, and not just because a common theme was people working together in order to better work together. The open-source community has suffered from flame wars and (in a day-to-day way) political infighting, of the "My distro/project/framework can beat up your distro/project/framework" variety. This isn't unusual for communities dedicated to "alternate" solutions, whether it was IBM's OS/2 or Macintosh.

In battling the "enemy" (which in all these cases has been Microsoft) and with all the variations on the alternative certain that they see as the correct path (because once you start making choices you sometimes get lost in making more choices), the community wastes energy that should be used in moving forward. Since I've historically always been on the "alternate" side myself, it makes me think of a statement Rick Steves made in passing in Europe 101: History and Art for the Traveler: that the early German Protestants made no great Art. Resisting and responding to the Catholic church left them no energy or time for creating awesome edifices.

So I was particularly heartened to see a lot of attention going to streamlining and improving people and community issues. Individuals and open-source organizations are doing their darndest to ease the friction between wetware modules, and creating platforms that bring related projects together. Among them are attention to gender issues, training the next generation of programmers and attitude adjustments. I thought it might be appropriate to share a few verbal snapshots from that learning experience, especially since several are relevant even outside open-source circles.

Mark Shuttleworth Tries to Open the Inner Circle

My conversation with Mark Shuttleworth, founder of the Ubuntu Project, was all about building more viable and inclusive communities. His attention was particularly on making it easier for someone on the outskirts of a community to become part of the central core. Shuttleworth scribbled a drawing on the back of the press release for Launchpad 2.0, a hosting platform intended to bring projects together. At the core of any project are the "rock stars" who spearhead the effort, we agreed (a bunch of little circles were drawn in the middle of the page), and a group of active participants surround them who are committers or contributors in some way—the people whose names you see again and again in the discussion forums.

But (here Shuttleworth drew a circle around the clustered dots in the middle of the page, and the spread-out dots near them) most of the people who use the software are outside that inner circle. To bring them inside, or to expand the radius of the circle, the circle itself has to be permeable; it can't be a moat around a castle which others must scale to get inside. (By this time, the drawing looked like an amoeba with acne on a bad hair day.) It has to be easy for someone who merely thinks this is something "cool" to get involved and become part of the core team.

It isn't just about getting a single project to attract participants. Most open-source communities also have to interact and integrate their software with others (the forks of Linux itself, for example, or a content management system that needs to support an AJAX framework). People working on another project have to find it easy to work with this one. That's true on an interpersonal level, obviously, but it's also true of the code. A developer should be able to try out a modification with the full version of his or another's project; Shuttleworth called this "hackcessibility." And, he pointed out, it's necessary for a healthy ecosystem that encourages people to build on what others have done.

All that is interesting in open-source terms, but step back a moment. Is it any less true of the IT projects in your own company? We call them silos, don't we? The big difference between open-source development and enterprise development is that, as Shuttleworth said, "We attract people to the domain based on interest." How many business developers get to work on what they want to? And how many businesses are willing to allow their people to fail? Due to fear of failure (and your job being on the line), corporations buy innovation. Instead, the open source community encourages people to try new things by branching from the core project; if you can deliver something good, we'll merge it back in. That's a different way of creating innovation (not to mention leadership); is there a way for enterprise IT to adopt any part of this attitude?

Continue Reading