Community – Michael Nielsen

One world

So hereâ€™s my pressing question: if the internet gives us new spaces in which to find common ground with very different people, what’s holding us back from becoming vastly more global and cosmopolitan than most of us are? Why, as I’ve argued elsewhere, do we seem to keep sorting ourselves into familiar groups?

The great mathematician Alexander Grothendieck once said “I can only learn what I already almost know” [*]. Entering a new community is difficult. The more unfamiliar the community, the greater the potential gain, but also the harder it is to understand and appreciate the community. There are many communities I’d love to understand and be a witness to, even if I can’t participate in a more active way. But for most of those communities the barrier to entry is high, and it’s easier to stay within the communities I’m already familiar with.

[*] I can’t find the original quote, alas. It is, I believe, a translation from a French original.

Online, there are some special figures that stand out as people who can help broaden our sense of community. They do this, so far as I can see, in two ways. The first group are people who, individually, articulate and exemplify the values of their communities in a way that is extraordinary, and that is also accessible to people outside their community. I love to follow the activities of such people in communities outside my own. I’m thinking of people like Terry Tao, in mathematics. People like Tyler Cowen and Robin Hanson in economics. People like David Byrne in music. People like Paul Graham for startup companies. One doesn’t necessarily follow the details of what is being said – I suspect few people can digest Terry Tao’s posts as quickly as he writes them! But the sense of being engulfed by a community is overwhelming when reading these people. One emerges enlarged.

The second group are the bridge-builders. People like Ethan himself, whose blog postings are frequently marvellous invitations to communities of which I know little, and which thus move me a little closer (a la Grothendieck) to being able to appreciate and understand that community for what it is. Posts like his biography of Paul Simon’s Graceland album, or the story of Matt Harding and the song “Sweet Lullaby”. Those posts both connect with me, and connect me to communities I never knew existed. Another bridge figure is Kevin Kelly, who has a wonderful eye for interesting stories and community, whether it be some of the oldest companies in the world, the story of an attempt to create a completely artificial environment for humans, or his musing on a world without technology.

I don’t know how to answer Ethan’s question from the beginning of this post. I do believe that at least part of the solution is to consciously seek out bridge figures, and to deliberately explore unfamiliar communities online. The architecture of the web – its link structure – makes it tempting to become ever more invested in our existing communities, subscribing to yet another blog closely related to our existing interests, way past the point of diminishing returns. I’m finding it more rewarding to consciously set aside at least some fraction of my time for exploring new communities, for finding new bridge figures, and for finding people who exemplify the communities of which they are a part.

On scaling up the Polymath project

Tim Gowers has an interesting post on the problem of scaling up the Polymath project to involve more contributors. Here are a few comments on the start of Tim’s post. I’ll return to the remainder of the post tomorrow:

As I have already commented, the outcome of the Polymath experiment differed in one important respect from what I had envisaged: though it was larger than most mathematical collaborations, it could not really be described as massive. However, I havenâ€™t given up all hope of a much larger collaboration, and in this post I want to think about ways that that might be achieved.

As discussed in my earlier post, I think part of the reason for the limited size was the short time-frame of the project. The history of open source software suggests that building a large community usually takes considerably more time than Polymath had available – Polymath’s community of contributors likely grew faster than open source projects like Linux and Wikipedia. In that sense, Polymath’s limited scale may have been in part a consequence of its own rapid success.

With that said, it’s not clear that the Polymath community could have scaled up much further, even had it taken much longer for the problem to be solved, without significant changes to the collaborative design. The trouble with scaling conversation is that as the number of people participating goes up, the effort required to track the conversation also goes up. The result is that beyond a certain point, participants are no longer working on the problem at hand, but instead simply trying to follow the conversation (c.f. Brooks’ law). My guess is that Polymath was near that limit, and, crucially, was beyond that limit for some people who would otherwise like to have been involved. The only way to avoid this problem is to introduce new social and technical means for structuring the conversation, limiting the amount of attention participants need to pay to each other, and so increasing the scale at which conversation can take place. The trick is to do this without simultaneously destroying the effectiveness of the medium as a means of problem-solving.

(As an aside, it’s interesting to think about what properties of a technological platform make it easy to rapidly assemble and grow communities. I’ve noticed, for example, that the communities in FriendFeed rooms can grow incredibly rapidly, under the right circumstances, and this growth seems to be a result of some very particular and clever features of the way information is propagated in FriendFeed. But that’s a discussion for another day.)

First, let me say what I think is the main rather general reason for the failure of Polymath1 to be genuinely massive. I had hoped that it would be possible for many people to make small contributions, but what I had not properly thought through was the fact that even to make a small contribution one must understand the big picture. Or so it seems: that is a question I would like to consider here.

One thing that is undeniable is that it was necessary to have a good grasp of the big picture to contribute to Polymath1. But was that an essential aspect of any large mathematical collaboration, or was it just a consequence of the particular way that Polymath1 was organized? To make this question more precise, I would like to make a comparison with the production of open-source software (which was of course one of the inspirations for the Polymath idea). There, it seems, it is possible to have a large-scale collaboration in which many of the collaborators work on very small bits of code that get absorbed into a much larger piece of software. Now it has often struck me that producing an elaborate mathematical proof is rather like producing a complex piece of software (not that I have any experience of the latter): in both cases there is a clearly defined goal (in one case, to prove a theorem, and in the other, to produce a program that will perform a certain task); in both cases this is achieved by means of a sequence of strings written in a formal language (steps of the proof, or lines of code) that have to obey certain rules; in both cases the main product often splits into smaller parts (lemmas, subroutines) that can be treated as black boxes, and so on.

This makes me want to ask what it is that the producers of open software do that we did not manage to do.

Here’s two immediate thoughts inspired by that question, both of which are ways large open-source projects (a) reduce barriers to entry, and (b) limit the amount of attention required from potential contributors.

Clear separation of what is known from how it is known: In some sense, to get involved in an open source project, all you need do is understand the current source code. (In many projects, the code is modular, which means you may only need to understand a small part of the code.) You don’t need to understand all the previous versions of the code, or read through all the previous discussion that led to those versions. By contrast, it was, I think, somewhat difficult to follow the Polymath project without also following a considerable fraction of the discussion along the way.

Bugtracking: One of the common answers to the question “How can I get involved in open source?” is “Submit a bug report to your favourite open source project’s bugtracking system”. The next step up the ladder is: “Fix a bug in the bugtracking system”. Bugtracking systems are a great way of providing an entry point for new contributors, because they narrow the scope of problems down, limiting what a new contributor needs to learn, and how many other contributors they need to pay attention to. Of course, many bugs will be beyond a beginning contributor to fix. But it’s easy to browse through the bug database to find something within your ability to solve. While I don’t think bugtracking is quite the right model for doing mathematics, it’s possible that a similar system for managing problems of limited scope may help in projects like Polymath.

More tomorrow.

Architecture is politics: community building and the success of Wikipedia

I find it surprising, almost shocking, that a system as apparently bottom up as Wikipedia works as well as it does. Anybody really can contribute, even anonymously, and without fear of damaging their reputation; while people can be banned, only a tiny fraction of users ever are; it’s easy and very common for people to vandalize pages. A priori it seems like a recipe for disaster, yet for the most part works quite well in practice.

I used to think the explanation for Wikipedia’s success was excellent leadership focused strongly on building a healthy and vibrant community. This certainly does play a significant role – check out this inspiring podcast from Wikipedia founder Jimmy Wales, who has thought long and hard about building great communities.

But great leadership and community building is only a partial explanation for Wikipedia’s success. It is clearly also the case that the design of the MediaWiki software underlying Wikipedia contributes in a major way to the success of the project.

This thought crystallized out for me in a particularly nice way this morning in the form of two fantastic slogans, Mitch Kapor’s “architecture is politics” and Lawrence Lessig’s “code is law” (book, free online).

Kapor’s observation, in particular, explains and neatly summarizes a great deal about community-building projects like Wikipedia. Tweak the software even a little, and one can cause enormous changes in how community interaction is mediated, and thus in how the community functions. Wikipedia is less bottom up than it appears, for it is a relatively small group of people who are effectively responsible for the design and development of the underlying software. Provided those people are competent and committed (I have no reason to doubt this), they can exert an enormous positive influence over the project as a whole, dwarfing the impact of random vandals.

An interesting consequence of this is that, in my opinion, other large projects like Wikipedia are going to need their own independent forks of the underlying software. Different communities have different needs, even during their own evolution, and the ability to change the underlying architecture of the system, and thus affect the politics, is an enormously powerful lever to have in forming a healthy community. In practice, I think this means that for ambitious projects the code used will need to be forked from an existing codebase (like MediaWiki), and developed alongside the community. Successful projects will require not just a healthy community, but a healthy co-evolution of community and codebase. To date this seems to have happened relatively rarely, and I wonder if this isn’t part of the reason why more Wiki projects haven’t succeeded on a large scale – maybe the architecture is mismatched to the needs of the community?

Related question: Mel Conway has observed that creative artifacts produced by organizations inevitably reflect the channels of communication and control in those organizations. What does this principle imply about Wikipedia?

Related posts: Kevin Kelly has recently written some great posts (here and here) about Wikipedia. Theresa Nielsen Hayden has written a nice post about building online communities. Clay Shirky also has some very interesting thoughts about the dynamics of online groups.