Wikimania: Wikipedia and F/OSS – some challenging comparisons

I walked in late to Siobhan O’Mahony’s introduction the panel on “What can Wikipedia learn from F/OSS development?” She offers some useful similarities and some major contrasts between Wikipedia and F/OSS. In Wikipedia, almost anyone can contribute, while in F/OSS, few people make core contributions, while most contributors are offering minot bug fixes. In F/OSS, there’s a large commercial ecosystem that supports production – that’s not yet happened for wikipedia.

F/OSS has offered a number of variations in models, different ways to carry out projects. Of tens of thousands of projects, a small subset have survived and created ecosystems around them. Now, ten years on, some are asking questions like “what else should we be doing”? Like Firefox, is it time to work on marketing?

She offers the intriguing idea that the notion of releases and completed versions is critical to F/OSS success – it’s very unclear what “version” Wikipedia is currently in.

Joel West from San Jose State offers what might be the most provocative talk I’ve heard so far. His basic thesis is that while there are some similarities between Wikipedia and F/OSS, they tend to be overblown – the differences are crucial.

On the similarity side:
– They both create information goods which can be used by an unlimited number of users without reducing the whole
– They use similar infrastructure – the internet
– They’re led by social movements with movement goals
– They’ve had rapid adoption, in part because they’re useful for folks who don’t want to or can’t pay
– Users own their own contributions, licensed under copyleft, with trademarks that protect the brand
– Foundations own and run the project
– Projects are led by “benevolent dictators for life”

Wikipedia has a larger pool of potential contributors than open source software – there are more people who can contribute to an encyclopedia than can program software. The scope is much larger – Wikipedia’s goal appears to be “a one stop repository for everything”. In Wikipedia, there’s a much more ambiguous definition of “done” – software runs or crashes – do we know when there’s a stable version of Wikipedia?

West believes that Wikipedia’s monoculture means it may experience slower evolution than the open source community as a whole. And Wikipedia has weaker feedback loops, which lead to lower quality.

Lessig’s talk yesterday invoked Hayek (Friedrich, not Selma), and the idea that a diverse set of licensing strategies can benefit from market signals. Open Source takes advantage of this diversity – dozens of major projects and hundreds of thousands of minor ones allows more robust projects to win out… not only do the products survive, so do the processes that created them. In Wikipedia, West argues, there’s only one set of processes and no competition.

In Wikipedia, there’s less economy of scale than in F/OSS production – software production has become much more automated than content production. Quality control software now allows F/OSS developers to test whether changes break a build very quickly – there’s nothing similar in Wikiedpia.

West urges people to put down their Benkler and pick up Eric Von Hippel’s “Democratizing Innovation”. Von Hippel observes that innovators – and certainly F/OSS innovators – are scratching their own itches. They’ve got utilitarian motivations to “eat their own dogfood”. This means people have an incentive to fix something someone else has broken. “In Wikipedia, I don’t get utility from my own content – only ego motivates me to monitor it.”

(The low rumble in the room broke into open rebellion at this point, with folks declaring that they most certainly used the content they created.)

Wikipedia has much lower participation barriers than F/OSS – it’s “\easier to twiddle than to create content.” And West believes there’s an emphasis on consistency over accuracy – sometimes facts are “corrected” to make them consistent with non-facts. “Lots of people’s contribution are just twiddling.”

West believes that F/OSS benefits from an economy of scope – Apache is a webserver, not the answer to all software problems. But the scope of Wikipedia is incredibly broad, and this can hurt the quality. “An encyclopedia is only as good as its weakest entries.” Open source can pick and choose battles, but wikipedia doesn’t, and weak content in some errors can hurt overall legitimacy. This is less an issue for bounded sites like IMDB and Wikitravel – Wikipedia appears to be unbounded.

One solution might be to push the Wikipedia community towards the idea of stable releases, though the community appears to push back against it. K-12 librarians aren’t going to accept Wikipedia with the rough edges it currently has – Mark Walker’s “stable” or “validated” Wikipedia proposals would allow Wikipedia to hand librarians a stable, not beta version. There’s decades of quality control experience in F/OSS to learn from.

In offering advice to the Wikipedia community, West suggests that Wikipedia may need to learn from smaller wikiprojects – central authority often lacks control, and Wikipedia has become an enormous project to manage. Smaller wiki projects may add diversity and internal model competition, which West believes that Wikipedia lacks.

He also warns that technology fixes may help, but not solve problems. Some possible tech fixes might involve better systems to escalate problems, ways to use tools to validate checked facts, rate contributor quality and mark pages as validated. But West worries that the real problems to Wikipedia are social ones, not just technological ones.

Kevin Crowston from Syracuse is interested in what people working on Wikipedia and F/OSS actually do, day to day, in the course of their projects. He’s interested in the user model for both communities, which he sees as expressed in the project changelogs or history files.

He points to an “onionskin” structure common in F/OSS communities – core developers control access to the CVS. They’re surrounded by a larger set of contributors who can offer patches, but need those patches accepted and verified by the core members. And they’re surrounded by an “outer layer” of active users, who test and report bugs.

Crowston argues that there’s no active user role in Wikipedia. (I believe this is what he said – seems like a very controversial statement.) There’s a big co-developer layer, a much smaller core proportionally to F/OSS projects, but the active user role is missing. In part, no one is helping people figure out how to use Wikipedia in the same way that people in the F/OSS world are helping people figure out how to use F/OSS systems.

Communication on projects is different as well, Crowston believes. Software projects tend to use email and threaded discussions, not IRC. This gives the project a track record, a history of issues and resolution, which allows new developers to watch on the edge of a project and learn how to participate. (He notes that the Linux kernel page has 6,000 posts a month – it’s so much to follow that there’s an abstracting service that publishes summaries of discussion on the page.)

Talk pages on Wikipedia aren’t threaded, and it’s harder to see where discussions go. Structured communications, like bug tracking, are critical to the success of F/OSS projects.

Decisionmaking in F/OSS often requires core team participation – accepting a new core member, making a release and accepting a patch all require that core team approval. Decisionmaking on that project is generally dominated by that core. Part of this may happen because F/OSS works through dependencies – if you break a module, you break lots of other people’s code. Are there similar dependencies in Wikipedia? Screwing up one page doesn’t affect the rest in the same way.

An interesting final observation from Crowston – there aren’t too many societal norms in F/OSS projects, he argues – don’t fork, don’t appropriate code. But Wikipedia seems to have lots more norms, some of them very complex. Is this a result of trying to pull everyone into the same project, rather than having many different projects with different norms?

Siobhan O’Mahony approaches the Wikipedia and F/OSS conversation from a sociology perspective, looking closely at the foundation structure of F/OSS projects. She argues that the F/OSS model has now matured, with formalized governance structures, and that it’s very useful to look at the non-profit foundations that have helped these projects deal with firms and a commercial ecosystem.

Her interest comes in part from the “myth” of F/OSS – that we’re hackers, we don’t need marketing, we’re a meritocracy – that’s not what really happens, as most serious F/OSS contributors will tell you.

From 1993-2000, many F/OSS projects were self-governing, accepting volunteer contributions with most participants motivated by the cause, ideology and idealism. From 2000 – 2006, the majority of volunteers are sponsored by vendors, well-supported by in-kind donations of hardware, marketing and legal services. Most commercial-grade projects have incorporated as nonprofit foundations with formal governance structures. The foundations hold assets, protect projects from liability, and present project to the outside world, including brokering agreements with commercial firms, Underlying the whole structure are other foundations, defining what is Free Software or Open Source software.

There’s diversity in these models – Debian has resisted the Apache model of putting release decisions into the hands of the foundation – the foundation for Debian is purely an asset-holding organization, keeping governance within the project.

She observes that the Wikimedia Foundation is not-membership based. Free Software Foundation began the same way, as Richard Stallman was worried about being accountable to a membership base – he recently changed his mind. (Will Jimmy want to change his at some point in the future?)

The observation of O’Mahony that I found most helpful – there are (at least) two types of openness influencing the wider business ecosystem: transparency which lets everyone observe community production, and permeability, which allows members to shape community production, with some level of decision rights.

Wikipedia seems to be much more permeable than any other project – but it may be less transparent, harder to see what’s going on with the whole project. Is wikipedia popular, she asks, because it’s open, or because it’s free?

This was a fascinating session – lots of fun, challenging ideas, lots of skeptical questions designed to challenge the success of Wikipedia so far. I offered two observations in the session: some of the objections the academics are offering may well be answered by the arrow of time – comparing Wikipedia a few years in to the mature FOSS ecosystem may be unfair simply because Wikipedia is developing some of the features FOSS has developed. Also, I wonder if the atom of comparison is wrong – individual wikipedia articles sometimes develop communities, and project certainly do – is Wikipedia too big and too broad to compare to an open source project?