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

Esther Schindler came home from OSCON with thoughts on growing the size of the pool in open-source development communities. And it's all upbeat news.

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?

The Roles of Women Working in Open Source

That wasn't the only community-centric discussion at OSCON, not by a long shot. A great session extolling the divas of the open source community was given by Pia Waugh from Waugh Partners, in which women were challenged to become more active and visible. As Waugh pointed out, some open-source contributors deliberately do not reveal their gender because, well, who wants to deal with all that harrassment? However, she added, "Every community has morons. Sometimes people say certain things... but that shouldn't dictate our behavior."

To promote female hacker visibility, Waugh cited several dozen prominent open-source women, such as those active in kernel hacking, high availability specialities, Joomla and Debian. A few examples: Dorothy Okello is empowering women in Uganda with open source, especially in the wireless networking arena. And Amy Jiang is active in showing how free software can work in China, Waugh explained. More resources, and notes on Waugh's talk, can be found at GeekFeminism.Wikia.com. (Plus, Alex Russell shared his own opinions on the effect of anonymity on women's open-source particiption which are well worth contemplating.)

In a related talk, during the July 24 keynote address, Danese Cooper, secretary and treasurer of the Open Source Initiative, told the community, "Stop whinging and start doing." Whinging, as she defined it, is "to complain in the repetitive incesant way that make parents buy children things in stores that they really didn't want to buy." (She also introduced us to the complaints choir [YouTube] which may be the first time you're tempted to sing in Finnish. The complaints choir, Cooper explained, began when two women got tired of their own kvetching and decided that hmm, maybe they could use that energy in a better way.)

With open source at an inflection point, Cooper said, she urged everyone to "Focus on going forward, not the problem statement." She said people need to "recalibrate our language," by eliminating words with negative charge; to make a special point of acknowledging those who help, such as insisting on Thank Yous on project websites ("We are nothing if we are not together," Cooper said); and to avoid wasting energy on infighting. Good advice for any community, I think.

Can't We All Just Get Along?

A late afternoon panel session, led by Josh Berkus (from the PostgreSQL Project), Shane Warden (O'Reilly Media), Ben Collins-Sussman (Google), Brian Fitzpatrick (Google) and Karl Fogel (QuestionCopyright.org) focused on "anti-patterns" in community management. Their goal was to identify behaviors in open-source (and, really, in any) online communities that, the panel promised, are "guaranteed to shrink, disrupt, divide, or even destroy the community around your open source project."

One example, labeled, "We don't need no steenking documentation!" had several suggestions of what not-to-have, including installation docs, user docs, contributor docs (more general things you can do for the project other than coding), wikis with peer-to-peer documentation, high level docs that explain how the source code is organized and designed, and code markup in the source that explains everything at detail level. An audience member added: make sure your command line utilities don't respond to -h; make sure documentation isn't available from the command line so they have to go to the Web; make sure the documentation doesn't say which version of the product it references.

It's worth mentioning, as an aside, that a frequent contributor to the open-source Plone content management system, JoAnna Springsteen, wrote Finding the Right Technical Writer for us. In case you care about documentation quality yourself, and I earnestly hope you do.

Other community-killers panelists identified include screwing around with licenses too much; feeding the trolls; and using technology instead of people skills (to which I referred in my earlier post about the open source community needing to learn and develop management skills). In the latter instance, the panelist said, community members try to solve social problems with technological solutions, such as setting up complex authorization controls, to force "which people can commit code when." Path-based access control is a mistake, he said, and a waste of time and energy. "It creates an atmosphere of distrust rather than trust," he added.

I'm afraid that sounds as though the conversations were all cautionary, if not a little on the whinging side itself. Not so. There were all sorts of discussions about how to improve matters, such as Nathan Torkington's keynote session on teaching kids to program. Community leaders, including Joe "Zonker" Brockmeier from OpenSUSE, Ross Turk from SourceForge.net, Jono Bacon from Ubuntu and Jeremy Hogan of Hyperic (previously community manager for Red Hat) spent a whole session discussing their efforts to get a user to become a contributor in some way, while noting how conditions have changed. "Five years ago," said Bacon, "You had to be a programmer [to be involved in an open-source community]. Or you could do doc. But you needed to learn latex for [documentation], which is programming." Today, the software itself encourages users to contribute at least in a minor way, such as Firefox's "just click here" option to report a bug.

One lesson learned? Bacon said they learned (the hard way) not to try to convert a user community into a developer community. It's tempting, when you a have a million users of your open-source software, to imagine the effect of getting "just 1 percent" of them to write code. But it doesn't work. "You're trying to convince a cat to bark," he said. Instead, community leaders need to put their energy into converting users to advocates.

Open Web Foundation to Help Standards Grow Up

That growth isn't all about people matters; technology and standards are part of the growing-up process too. As David Recordon, Open Platforms Tech Lead at Six Apart and vice-chair at The OpenID Foundation explained during a keynote address, for the Internet to become "the" platform, the conversation has to shift from just open source to data. "As more services move into the cloud, it's not just the source code behind it [that matters] but the data as well." That data needs to be accessible everywhere, which means a lot of APIs; "The number of APIs necessary to give you a pulsating blue circle around your location is pretty amazing," he said. Open APIs for data exchange are no longer just a nice-to-have, he said. Venture capitalists are asking new companies how they will work with other companies, rather than looking for lock-in.

The online and open-source community has not been idle. Technical solutions have been designed outside of the formal standards bodies. But OpenID, OAuth and OpenSocial share some problems, according to Recordon: unclear licensing on the specifications, no "social contract," and uncertain definitions for "how you play well" on the open Web. Plenty of folks are working on these issues, he said, including Sam Ruby, Simon Phipps and Danese Cooper. (Remember that part about making a point to thank individual contributors?)

Believing that "Open Data Needs Open Specifications" (you sort of have to say it with Capitals), Recordon announced the formation of the Open Web Foundation, so these communities can work together.

Communities, like people, are either busy growing or they are busy dying. "The real threat to Microsoft," said Shuttleworth, "is the emergence of business models that energize free software."

Join the discussion
Be the first to comment on this article. Our Commenting Policies