BAR Camp this Weekend

Chris Messina and others are organizing BAR Camp this weekend at Socialtext‘s offices in Palo Alto. It’s a grassroots gathering of techies doing cool stuff that’s open to all, an open alternative to O’Reilly’s invitation-only FOO Camp, which is happening the same weekend in Sebastopol. Even though it was literally organized this week, a lot of cool folks have already signed up, and it looks like it’s going to be a blast. Hope to see you there!    (JOC)

Ross Mayfield on Social Software, Social Networks

Last Friday, I finally got a chance to meet Ross Mayfield, who was speaking at the November meeting of the Bay Area Futurist Salon, held at SAP Labs in Palo Alto. Ross is CEO and founder of Socialtext, a company that is selling social software to companies. Some people have compared Blue Oxen Associates to Socialtext, which is apt in some ways, but is not quite right, as I’ll discuss below. Christine Peterson (one of our advisors) had said great things about Ross and Peter Kaminski (Socialtext‘s CTO), and Ross and I had exchanged some pleasant e-mails. The meeting confirmed Chris’s judgement. Not only is Ross a good guy, he had some interesting things to say about Social Software and Social Networks.    (D8)

Social Software    (D9)

I mostly agreed with what Ross had to say about social software, and I especially liked his overall philosophy about what makes a good tool. I did have a few nitpicks, though. Ross defined Social Software as follows:    (DA)

  • Software that supports group communication    (DB)
  • Software that adapts to its environment, rather than requiring its environment to adapt to it    (DC)

I asked him to clarify the latter statement, and he explained that most collaborative software tries to enforce too much structure. These tools force users to figure out how to fit the data into the tool, whereas the tools should fit the data. In this vein, Ross spoke highly of Wikis and blogs, and also of human filtering (such as Google’s technique of measuring backlinks) as a way of organizing information.    (DD)

I strongly agree with Ross’s philosophy, although I don’t like how he worded it in his slide. His statement is equivalent to the first part of Doug Engelbart‘s philosophy of coevolution of tools and processes; however, it leaves out the second part, which is equally important.    (DE)

Doug says that tools ought to augment human processes. However, as we learn more about the tool, we also must evolve the processes to adapt to the tool. An example that Doug often cites is the bicycle. Riding a bike is not intuitive, but it offers significant performance advantages over a tricycle. (To illustrate this point, Doug likes to show this picture.) “User-friendly” tools can be useful, but they should not be the end-goal.    (DF)

One “semistructured” tool that Ross does not like is e-mail. In predicting its demise, he cited several statistics regarding the amount of time required to deal with e-mail, especially but not exclusively due to spam. Ross introduced a cute term that I had not previously heard: “occupational spam” — e-mails from “legitimate” sources that have no bearing on your life or work whatsoever. This often manifests itself as being cc’d on threads of little or no relevance. Ross claimed that 30 percent of our inboxes consist of occupational spam. I should have asked for a citation on that stat, because it’s an interesting one.    (DG)

One of his main arguments against e-mail as a collaborative tool was that it encourages discursive discourse, and that it’s hard to make any sense of the sum product. I agree entirely with this argument, but would use it as an argument for how to use e-mail effectively rather than against e-mail entirely. Internally at Blue Oxen, our e-mail and Wiki usage complement each other quite nicely. We kick off the discussion using e-mail, and we synthesize the resulting thoughts into the Wiki, with links back to archived e-mail.    (DH)

Social Networks    (DI)

Ross’s presentation on Social Networks was outstanding. He’s obviously thought deeply about these issues, and he’s collected quite a bit of interesting research. He first described his and Valdis Kreb’s Blogmap Project, which mapped relationships between members of Ryze‘s Blog Tribe.    (DJ)

He then discussed the power law of blog space, which states that the distribution of links to a blog is inversely proportional to the blog’s rank. In other words, the number of links to the most popular blog is exponentially greater than links to the next-most popular blog.    (DK)

Ross then proposed three types of collaboration: the publishing model (one-to-many, where the power law applies), the individual’s social network, and small teams. He cited the primatologist Robin Dunbar’s work to suggest that social networks generally numbered about 150, and said that people’s interactions with their social networks generally followed a normal distribution. (Interestingly, he showed his RSS aggregator, which had 146 subscriptions.) Finally, he suggested that the optimal size of teams is about 10, and that the number of interactions between team members tends to be about equal.    (DL)

Socialtext Versus Blue Oxen    (DM)

Socialtext and Blue Oxen are similar in that we both are interested in collaborative tools, and that we both share similar philosophies about tools. Socialtext sells these tools as enterprise applications, however, whereas Blue Oxen is focused on understanding how best to use and improve these tools and on disseminating that understanding widely.    (DN)

In that vein, we both have embarked on similar projects, but with different goals. Ross talked about Socialtext‘s experiences with Social Software supporting face-to-face events, and those tools were available during his talk. We did a similar project with the PlaNetwork 2003 Conference, for which we set up a Wiki, RSS aggregators, and an IRC channel.    (DO)

We host collaboratories, and plan on charging for membership to those collaboratories once our infrastructure is up to snuff. However, we’re not an ASP, although we will make (and already have made) ASP-like services available to communities. Our infrastructure is meant to be cutting-edge and rough around the edges. It’s a way for people to experience first-hand what it’s like to use those tools, an opportunity to learn (and share) how best to use them, and a platform for coevolution. Despite our intentions, we’ve already discovered that even with promises of little/no “official” support, people enjoy using our tools for their real-world collaborative needs. As members, they’ll have free access to these tools for their groups. When they start needing better support and enterprise-level features, we will happily point them towards Socialtext and similar companies.    (DP)

Response to Marc Canter

I meet a lot of interesting people in this business, but a few stand out more than others. Anyone who’s met Marc Canter knows what I’m talking about. Marc is a big, boisterous fellow, mostly good-natured, and very outspoken. The guy is sharp and passionate, and has a proven track record of getting things done in the Valley, including cofounding MacroMind (which became Macromedia). He’s also got an incredibly cute baby daughter, which is a bit unfair, because it makes it difficult for me to get mad at him.    (B5)

Marc recently complained about Blue Oxen Associates. Among his complaints were:    (B6)

Now I have nothing againist Eugene Kim and his stalwarts, but what they created and what they do is pretty lame – compared to what’s going on out there – for free, everyday. What was it about Blue Oxen that Socialtext, Phil Pearson, Dave Winer, Paolo Valdemarin, Clay Shirky, Cory Doctorow, Danny Ayers, Dan Brickley, Lisa Rein, Mitch Kapor, Mark Pilgrim, Aaron Swartz, and hundreds more aren’t doing everyday?    (B7)

Why did we need a white paper on why open source is a good thing? Why do we need yet another Wiki – ever if it is purple?    (B8)

I just really think that Pierre’s money could be put to better use.    (B9)

There are lots of problems with what Marc says, the biggest being that he’s got most of his facts wrong.    (BA)

First, Omidyar Foundation has not invested in us. They funded our first research report on the open source software community. We are completely self-funded (by me), surviving on my initial investment and on clients.    (BB)

Second, we are not in the business of open source software development. As a company that uses, evangelizes, and works to better understand collaborative tools, we naturally do some development. Our policy is that everything we produce is open source, be it software or research. PurpleWiki happens to be the first of those tools, and so we make it available.    (BC)

Is PurpleWiki the Wiki to end all Wikis? That’s not our intent. Our intent is to understand and explore ideas that will help us improve collaboration, and then to disseminate those ideas as widely as possible. PurpleWiki is more than a bunch of purple hash marks spread out on a page. There is a lot of deep thinking behind its architecture, much of which was inspired by Doug Engelbart‘s earlier work. The Purple Numbers are the most visible manifestation, but there are others that will become more apparent eventually. The point is, we want to make those ideas accessible, and if they are useful, we want to help spread those ideas. That goes for all collaborative tools, not just Wikis.    (BD)

We’ve done this. For example, we worked closely with Mike Mell who worked closely with Simon Michael to implement Purple Numbers in ZWiki. We host an active community of tool developers who are working together to make their tools more useful and interoperable. We’re always exploring new ways to make a difference.    (BE)

Third, our research report was not about why open source software is a good thing. It was a preliminary exploration into why open source communities work. We’re not the first to explore this question, but I think we are especially qualified to explore it for a number of reasons. More importantly, our target audience is not open source developers. These folks don’t need persuading. Our audience is people who know nothing about open source software, except perhaps that it exists. There is an enormous language and experience barrier that prevents these folks from understanding what makes open source communities tick. Our thesis is that all communities — independent of their domain — could benefit from understanding and emulating open source communities. In order to test this thesis, we first have to overcome the language barrier.    (BF)

Fourth, Marc listed a bunch of people doing great work in this space as if they were our competitors. They are not. I know several of these folks, have worked with some of them, and hope to work with many more. Our goal at Blue Oxen Associates is to better understand collaboration, so we can help improve it. In order to do that, we need to put our money where our mouths are and collaborate with others working towards the same goal.    (BG)

When I founded Blue Oxen Associates, I consciously avoided seeking seed money and going for the big splash up-front. Some of the things we’re trying to accomplish are not obvious, and require further thinking and development. Starting small and growing slowly means we have to focus, sometimes at the expense of interesting projects and work, often at the expense of attention.    (BH)

Nevertheless, I’m surprised and flattered by the attention we’ve received thus far. The participants in the communities that we host are incredibly supportive. We have an amazing advisory board. I constantly run into people who know about us and compliment us on our work. And, the blogging community has said some great things about us as well. I’m even flattered that Marc thought enough of us to devote some space on his blog to call us “lame.” Like I said, it’s hard to get mad at a guy who means well and has a cute baby daughter. I hope he’ll continue to follow our work; perhaps “lame” will evolve into something better once he actually understands what we do.    (BI)