Jimmy Wales on Things That Need To Be Free

Thoughts on Jimmy Wales‘s keynote at Wikimania. Read Ross Mayfield‘s post for a more extensive summary:    (JN8)

  • “1. Free the encyclopedia!” Jimbo considers the English and German Wikipedias “done,” and he expects the rest to be complete in about 10 years. His metric is 250,000 pages of content.    (JN9)
  • “3. Free the curriculum!” Jimbo suggested that professors work collectively on free textbooks, which raises the obvious question: Would this be successful? Incentive structures in academia are heavily weighted towards individual achievements, and a group of professors may not have the diverse makeup necessary for a superior collective outcome. Nevertheless, I think there’s some potential there and that it would be a worthwhile experiment, especially for books at the grammar and high school level.    (JNA)
  • “8. Free the product identifiers!” I found this to be the most original of the 10. The so-called Long Tail is creating a market for product identifiers based on open standards. Jimbo calls these LTIN, or “Long Tail Identification Numbers.” This would be a great, achievable, bottoms-up project for someone smart who wants to make a big impact on the world. The timing seems right.    (JNB)
  • “10. Free the communities!” Jimbo’s basic point was that communities need to own their content, even in for-profit spaces (like his current project, WikiCities). This is the Blue Oxen Associates philosophy and our approach with the Blue Oxen Collaboratories. Licensing community content under Creative Commons is not enough, though. You need freely transportable identities, which leads me to a proposed addition to the list: Free identities! I’ll expand on this in a future post.    (JNC)
  • To Jimbo’s credit, the keynote was highly inclusive, even Wiki-like. Folks from the audience freely contributed ideas and critiques (Permission To Participate was rampant throughout the conference), and Jimbo modified his list on the fly. When someone in the audience suggested, “Free research!”, Jimbo responded, “You’re right. I’m going to make that number four.”    (JND)
  • Jimbo on business models and free content: “Everyone tells jokes, but we still have professional comedians.” He also noted that this line isn’t his, saying, “I steal everything, including my jokes.”    (JNE)
  • The most challenging suggestion was, “Free medical information!” In theory, this sounds wonderful. Someone in the audience (Florian) told an anecdote about a project in Austria to create a fully anonymized knowledge repository where doctors could share misdiagnoses. Jimbo suggested that such a resource should be available to everyone. The flip side of the argument to freeing medical information is that the content literally could be the difference between life and death. There’s a tremendous responsibility among the part of the authors and publishers. As Jimbo noted, no one is going to die if there’s an inaccuracy on the Thomas Jefferson Wikipedia page.    (JNF)

WikiMania Hackfest Day 3

Today’s tidbits:    (JLI)

  • Ward Cunningham arrived this morning and gamely participated in the afternoon session, despite the long flight. At one point, he asked the Mediawiki developers what the consequences of a wrong architectural decision would be. The answers were revealing. These guys are faced with a tough problem thanks to scaling issues. By necessity, they have to optimize their architecture based on user behavior. However, this severely restricts their flexibility, because if their predictions about user behavior are wrong, it is extremely expensive to rearchitect, reimplement, and reconfigure. Moreover, Mediawiki really can’t develop agilely, at least not where new user features are concerned, for the same reasons. If they were part of a large company with plentiful IT resources (e.g. Google), then it would be a different story, but they’re not. This also makes Extreme Usability somewhat of a pipe dream.    (JLJ)
  • Funny observation from a Mediawiki developer (Mark) on downtime: They’re the only site that profits from downtime. When Wikipedia goes down, folks assume it’s short on resources and tries to donate stuff.    (JLK)
  • At the FLOSS Usability Sprint last February, we framed the following conflict between Open Source developers and usability practitioners: With usability, the mantra is, “You are not your user.” With Open Source, the mantra is Scratch Your Own Itch. Those two philosophies seem contradictory. However, it’s not so simple. Many new features in Open Source projects are user-driven, although the degree to which this happens largely varies. My impression with Mediawiki from watching the developers work and from talking to various members of the community — developers and users — is that the developers are open to feature suggestions, but are not particularly enthusiastic about user-driven design. Developers will implement suggestions, provided they are posted to Bugzilla. That’s a poor way of doing things, in my opinion. I’m picking on Mediawiki, but it’s a very common attitude in the Open Source world — it came up several times at the usability sprint — and really, in the entire software development community. With Mediawiki, I’m particularly disappointed, because they’ve got this huge, wonderful user community. As I said yesterday, the purely technical problems Mediawiki faces are fascinating in and of themselves. However, the opportunity to evolve some really cool user features should be just as fascinating.    (JLL)
  • Then again, perhaps Mediawiki just isn’t the place for this to happen. As I said above, doing Extreme Usability would be especially hard, because the high overhead imposed by the architecture makes it difficult to develop agilely. Maybe the place to experiment is with smaller communities, and Mediawiki can steal features accordingly. That, after all, is one of the goals behind the Blue Oxen Collaboratories — explore cool ideas in real communities and teams, and then propagate them so they are stolen far and wide. The only problem with this is that it’s almost impossible to duplicate the social effects of scale seen on Wikipedia.    (JLM)
  • I mentioned a “MySQL guy” yesterday. His name is Jan Kneschke, and while he works for MySQL, he’s really here to help Mediawiki with performance issues. One way he’s doing that is by advising them on migrating to his high-performance web server, lighttpd (pronounced “lighty”). lighttpd is a relatively new implementation of an old idea: rather than prefork or thread a web server, as Apache does, use a single event loop, which saves you tons of memory and CPU, especially at scale. It’s got some other cool performance tweaks as well. Jan is very sharp, and lighttpd seems to be taking off. Another high-profile site that uses it is Ruby On Rails. One thing I find amusing is that FastCGI, which has been around forever, seems to be making a big comeback. Ruby On Rails, PHP, Sympa, and many other high-profile tools use it. It’s amazing how old things can fly under the radar forever, then suddenly find new life.    (JLN)
  • Over and over again, I see that proficiency in one area doesn’t necessarily translate into others, even if they seem like they should. Folks in the Wikipedia community are incredibly knowledgable about online, emergent communities. However, judging from the conference design, they know very little about facilitating similar emergent patterns at face-to-face gatherings. Again, I’m picking on them, only because I’m here, but this is a widespread problem, and it further validates what Blue Oxen Associates is trying to achieve. Two things that the organizers here have done very, very right: Bring together great people and establish a wonderful culture of openness.    (JLO)

Blue Oxen and the Commons

There’s a fascinating discussion going on in the GivingSpace collaboratory about the commons, instigated by Phil Cubeta. Since that discussion is really focused on the Omidyar Network, I thought I’d throw in my two cents by describing how I see the Blue Oxen Collaboratories fitting into this discussion.    (2DK)

We currently host 22 alpha collaboratories, some of which are private spaces for organizations. The vast majority of them are public, however, and we encourage all of our groups to have public spaces. In fact, we will probably mandate that all of our organizational members have at least some public space in order to use our infrastructure.    (2DL)

We have not yet explicitly licensed the content of those discussions. It’s not an easy problem, although I suspect one of the Creative Commons licenses will work. However, we do know what principles we want the license to espouse:    (2DM)

  • You own your own words.    (2DN)
  • You’re speaking in public, so react accordingly.    (2DO)

Blue Oxen is interested in open discourse, the free exchange of ideas, and most importantly, collective learning. We’re not interested in demanding royalties from someone else’s idea, just because that idea was formulated in our space. We’re interested in facilitating a better ecosystem, and we’re betting that we will benefit far more from a better ecosystem than we would by making claims on other people’s IP.    (2DP)

“Facilitating the ecosystem” is something people hear me say often. It’s why all of our research is available under a Creative Commons license, and why all of our software is developed as Open Source. It’s why we emphasize interoperability with our tools, and why we’re doing our best to make it easy to export content from our collaboratories over to other sites. Our goal is to improve collaboration, and a policy of openness enables us to do that.    (2DQ)

All that said, it’s not as simple or as easy as it sounds. For example, what do you do about requests to remove content from a Wiki or one of our mailing list archives? (We discussed this issue a few months ago at the Collaboration Collaboratory.) Also, what about governance? Our collaboratories are not the commons. Although we try to be as open as possible, I’m not inclined (as of yet) to make the space entirely self-governing. That said, because our tools are Open Source and because we share our knowledge openly, people have the flexibility to create a self-governing commons using our tools and knowledge. In this way, we’re supporting the creation of commons. Again, it’s all about the ecosystem.    (2DR)

There’s also the question of sustainability. We’ve obviously closed off potential sources of revenue by being as open as we have. I strongly believe that we can not only sustain ourselves. We haven’t proven that yet, but I’m confident that we will soon enough.    (2DS)

Battling Group Think

Geoff Cohen asked:    (PM)

As we build different kinds of groupware/social software, what’s the role of consensus, and how powerful is it? Does software make reaching consensus easier or harder? For purely message-driven systems like email lists or USENET, consensus is much harder to reach than it would be in a real-life meeting. But once consensus is reached, breaking that consensus often brings down the flames of wrath. All of this is somehow invisibly coded in the interstices of the software architecture and human nature.    (PN)

…    (PO)

Could we architect social software that fought groupthink? Or does it just make the gravitational attraction of consensus, even flawed consensus, ever so much more irresistable?    (PP)

Seb Paquet responded:    (PQ)

I think the key to avoiding unhealthy levels of groupthink has to do with designing spaces that consistently exert pull upon outsiders (or social hackers or community straddlers), so as to keep the air fresh.    (PR)

…    (PS)

I think the blogosphere exhibits this kind of “outsider pull” much more than topic-focused forums.    (PT)

…    (PU)

But what about action? A diverse group has fewer blind spots, but on the other hand, agreement in such a group can be harder to establish, so there is a real possibility that the group will go nowhere beyond conversation. Is a core of agreed-upon ideas necessary for group action to take place? I think so. Does this mean that group action requires groupthink? Not necessarily, because some people are able to act upon ideas without believing in them so strongly they can no longer challenge them.    (PV)

Ross Mayfield added:    (PW)

He [Seb] is right that groupthink is avoided by a social network structure that allows a dynamic and diverse periphery to provide new ideas, but the core of the network needs to be tightly bound to be able to take action.    (PX)

That’s the main point of Building Sustainable Communities through Network Building by Valdis Krebs and June Holley.    (PY)

…    (PZ)

The ideal core/periphery structure affords a densely linked core and a dynamic periphery. One pattern for social software that supports this is an intimacy gradient (privacy/openness), to allow the core some privacy for backchanneling. But this requires ridiculously easy group forming, as the more hardened the space the more hard-nosed its occupants become.    (Q0)

Finally, Bill Seitz commented:    (Q1)

I think a shared mission is necessary. Whether that amounts to groupthink is a fair question.    (Q2)

There are a goldmine of ideas here, and the discussion is highly relevant to issues currently faced by the Collaboration Collaboratory. I’ll address them one at a time.    (Q3)

Group Think Versus Group Action    (Q4)

Bill’s comment points to the crux of the matter. What qualifies as Group Think or Group Action? We’ve discussed this question a lot at Blue Oxen Associates. In our upcoming research report, we draw a distinction between bounded and unbounded goals, and individual and collective goals. Generally, having shared unbounded goals is enough to constitute group alignment, but having shared bounded goals is required before you can call an effort “collaboration.”    (Q5)

The larger the group, the harder it is to define a shared, bounded goal that every group member will endorse. A good example of where this happens are elections. In the case of Howard Dean supporters, for example, the community is defined by a universally shared, bounded goal — voting Dean for president in 2004. As we’ve seen in the Dean case, having that universally shared, bounded goal was a galvanizing force for a previously unseen community of progressives in this country.    (Q6)

For large groups, I don’t think it’s necessary to have universally shared, bounded goals, although it’s nice when it happens. It’s enough to have small subgroups sharing different bounded goals, as long as they do not conflict with the unbounded goals, which must be universally shared.    (Q7)

The Intimacy Gradient Pattern    (Q8)

An aside on terminology: Intimacy Gradient is an excellent name for the phenomenon I first tried to describe in a previous blog entry, where I introduced the Think Out Loud and Whine In Private patterns. The problem I had in describing the Whine In Private pattern was that some spaces — blogs being the best example — felt like private forums, but were actually public. So people whining on their blogs are not actually Whining In Private; they just feel like they are.    (Q9)

Ross also used the term Backchannel, which I had also recently noted in my Wiki as a good name to describe this mostly private, but partially public space.    (QA)

Community Boundaries    (QB)

One of the founding principles of the Blue Oxen Collaboratories is that the products of the discussion and interaction should all be freely available to everyone. This is why the mailing list archives are publically available, even if participation is restricted to members.    (QC)

There is an Intimacy Gradient pattern involved here. There is a small barrier to entry to participate in tight-knit discussions, which makes the environment more conducive to parlor-style conversations. On the other hand, anyone can benefit from the resulting knowledge, which is our ultimate goal. Our hope is that the collaboratories act as a substrate for a much larger conversation.    (QD)

This has already begun to happen, and blogs play a key role. Bill Seitz, Chris Dent, Danny Ayers, and I have all blogged about discussions on the Collaboration Collaboratory, which expands the conversation to a larger group. The side effects include countering Group Think, as Seb suggests, and also attracting new members who want to participate more directly in the lower-level interactions. Similarly, we mention these blogs on the mailing lists, so the collaboratory members are aware of the larger conversation, thus completing the circle.    (QE)

Are there hidden costs to these Intimacy Gradients? Absolutely. Examples of blogs being read by the “wrong” audiences abound. Gregory Rawlins became a victim when he made some choice comments about another programmer’s software on a private, but publically archived list. (Sorry, Greg, but I always get a good laugh when I reread this.)    (QF)

Nevertheless, I think the benefits outweigh the downsides. I recently joined Howard Rheingold‘s Brainstorms community, and have wanted to link to some of the discussions there, but couldn’t. It’s unfortunate, because those linkages are lost, but it’s a tradeoff I understand. Finding the right balance is tricky.    (QG)

How Open Should Wikis Be?    (QH)

Our original intention with the Wikis on the Blue Oxen Collaboratories was to treat them the same as the mailing lists — restrict writing to members, but allow anyone to read the content. However, we did not configure our Wikis that way, mainly because we couldn’t — UseModWiki doesn’t have this feature — and it was low on list of things to hack. (See PurpleWiki:RoadMap.)    (QI)

Based on our experiences with this configuration and further examination of other Wikis, I’m reluctant to change this model now. One potential compromise is to require registration to write to the Wikis, but to make registration free. The difference between this and simply allowing anyone to click on “Edit This” is subtle, but significant. I’m still a bit undecided on this issue, although I seem to be leaning in favor of extreme openness. The reason for this is simply that we’ve had some interesting contributions and comments to the Wikis that probably would not have been made if there were even the slightest barriers to entry. Again, it’s a good safeguard against Group Think.    (QJ)

This issue recently cropped up again, because both the PurpleWiki and Collaboration Collaboratory Wikis were vandalized for the first time. Chris Dent discovered the act first and quickly fixed it, noting, “In a way this is sort of a good sign. Infamy is almost as good as fame….” My reaction was, “Good catch, by the way. A good sign of a healthy Wiki is how quickly the community fixes vandalism.” Notable in both of our reactions was that we simply fixed the problem and moved on, instead of rushing to implement access control.    (QK)

John Sechrest, however, suggested that access control was exactly what the Wikis needed, which led to some interesting philosophical debate about the openness of Wikis. My response to John wasn’t very deep, but it does sum up my feelings on the matter: “Wikis are successful because the cost to contribute are zero. There are downsides, but there are also upsides. Get rid of one, you also lose the other.”    (QL)

Mailing List Etiquette and Experimentation

I’ve been an e-mail user for over 10 years, and a mailing list and USENET user for just about as long, so I have strong beliefs about proper mailing list etiquette. That puts me in an interesting position as a participant in the Blue Oxen Collaboratories. On the one hand, these collaboratories are supposed to be shining examples of high-performance collaboration. On the other hand, they’re also supposed to be testbeds for experimentation and coevolution.    (8K)

Sometimes, people use the lists in ways that conflict with my inner sense of etiquette. However, etiquette is a form of social constraint, and if we forget why we find these constraints valuable, our sense of etiquette can impede collaboration.    (8L)

The collaboratories are a perfect place to have metadiscussions about this sort of behavior as it happens, but unfortunately, it’s hard for me to participate or initiate those discussions. Because of my position at Blue Oxen Associates, my commentary can be perceived as law rather than opinion, and I don’t want that to be the case.    (8M)

That, of course, is the reason for this blog — for me to WhineInPrivate in public. Which leads me to today’s topic.    (8N)

Cross-Posting    (8O)

The impetus for this entry was a discussion this morning with Andrius Kulikauskas, who called me all the way from Lithuania. Andrius founded the Minciu Sodas laboratory, which is similar in spirit to Blue Oxen Associates, and he actively participates in our collaboratories.    (8P)

One thing that Andrius does often is cross-post across different forums and mailing lists. I’m not a big fan of cross-posting, but I think there are times when it’s appropriate. The problems are:    (8Q)

  • List participation is often restricted to participants, largely as a way to avoid spam. As a result, people will not necessarily see responses to cross-posts, and it can result in stilted and confusing discussion.    (8R)
  • There is a force at work within effective communities: Know Your Audience. People behave differently depending on their audience, as well they should. You may know the audiences of the lists to which you are cross-posting, but the different members of each list may not, and that will affect how or whether they respond.    (8S)

Andrius and I discussed this a bit over the phone. One of his rationales for cross-posting is that it builds awareness of other communities, and that it encourages interconnectedness. I definitely believe in the former, but I’m not so sure about the latter. Simply knowing that a community exists certainly enables interconnectedness at some level, but cross-posting could also discourage interconnectedness. If there is no Shared Language on the different lists, cross-posts can unintentionally lead to further balkanization of communities.    (8T)

I’m not a big fan of cross-posting, but I tolerate it, and for good reason. When Andrius did it, it forced me to think very hard about why I disliked it. That helped me understand the reason for my feelings, and it also helped me think through some half-baked ideas. For example, when you consider the benefits of cross-posting, it’s clear that the technical balkanization of mailing lists caused by restricting participation to subscribers can be a very bad thing. One advantage with USENET newsgroups or web-based forums is that you don’t have this balkanization. On the other hand, these forums are susceptible to spam. I’m certain there is a technical solution to this problem, although I don’t know what it is yet.    (8U)

Off-Topic Postings    (8V)

A great example of where etiquette can be overly enforced is off-topic postings. I’ve noticed that on some lists, moderators are tyrannical about keeping discussion on-topic. While I understand the reasoning, being too extreme about this can do more harm than good. The nature of online spaces is different from face-to-face spaces, and the former is a more tolerant space for divergent ramblings than the latter. I wrote some thoughts on this in an earlier entry.    (8W)

Another reason for tolerating some off-topic discussions is the Water Cooler pattern. Communities are more effective when people have shared experiences, and informal socializing is a great way for identifying or creating these experiences. Several months ago, there was a discussion about local restaurants on the San Francisco Perl User Group mailing list. This clearly had no relevance to Perl, but it was very interesting, and no one complained. In fact, the original poster asked for recommendations off-list, and several people e-mailed him asking to post the responses on-list instead.    (8X)