Socialtext 2.0 Released

Congratulations to Ross Mayfield, Peter Kaminski, Adina Levin, and all the excellent folks at Socialtext for the release of Socialtext 2.0. Even bigger props for slipping in “Purple Consulting” in the screencast. I’ve been cranking so hard over the past six months, I didn’t have a chance to congratulate them on their Open Source release last July, so now I get to combine my commentary here. (In fact, I’m sitting on a bunch of Wiki-related posts right now that I need to push out; a lot of really cool stuff has been happening.) That’s good, because I have plenty to say.    (L72)

Socialtext 2.0 is an important release for three reasons. First, it doesn’t just look good, it’s highly usable. Adina and Pete deserve big-time credit for this. They’ve spent months painstakingly experimenting and testing the design. More importantly, they haven’t just focused on making it easy to use, but they’ve also agonized over how to accomodate expert usage as well.    (L73)

Have they succeeded? I think the personal home base concept is great. I love the fact that Backlinks are visible on the page and get lots of love. I love their new Recent Changes interface (and I hope to see a Tag Cloud view of the all pages index in the next release). I hate the fact that a Recent Changes link is not on every Wiki page. Both Pete and Adina are well aware of this beef, and I’m also well aware of their reason for not including it. Testing and user observation will tell what’s better.    (L74)

Second, Socialtext 2.0 has a really cool REST interface. Chris Dent has been boasting about it for months, but I didn’t look at it myself until Kirsten Jones walked me through it last week. (Her WikiWednesday presentation from earlier this month is online.) It really is cool, and it’s also useful. Congrats to Chris, Kirsten, Matthew O’Connor, and Matt Liggett for their excellent work!    (L75)

What’s great about this API is that it could very well serve as a standard URI scheme for all Wikis. This would obviate the need for a separate SOAP or Atom API. You just have a regular Web app, and you get the API behavior for free.    (L76)

For example, Alex Schroeder‘s currently going through the same process that Chris went through a year ago with Atom and OddMuse. An easier way around this problem would be to implement these REST APIs.    (L77)

(This is also a great opportunity for me to mention WikiOhana again, which gained great traction at WikiSym last month and which now has a lively Wiki of its own. PBWiki recently announced its own Wiki API, which is a good thing. We are all part of the same Wiki family. Socialtext and PBWiki need to talk about how their two efforts can work together. That’s the WikiOhana Way.)    (L78)

The third important thing about Socialtext 2.0 is that it’s Open Source. (Big props to Jonas Luster and Andy Lester for finally making this happen.) Here’s the thing. I think the announcement a few months back was overblown by a lot of blogosphere hype. The reality of all corporate Open Source releases is that — in and of themselves — they’re mostly meaningless. Mostly, but not completely. The fact that Socialtext 2.0 is Open Source means that other Wiki implementations can benefit from the great work that the Socialtext developers have done, from the APIs to the user interface. That makes for a healthier ecosystem, which is good for everybody.    (L79)

That said, the reason the actual open sourcing of Socialtext 2.0 (and any proprietary software project) is mostly meaningless is that the license is a critical, but tiny part of what makes Open Source software interesting and important. The big part is the community and collaborative process, and a lot of other things besides an open license are required to make that successful.    (L7A)

Before Socialtext went Open Source, I spent many hours talking to a bunch of people there about the impending release. I wanted to know how committed they were to making this a truly open and collaborative software project, because I felt the potential impact on the Wiki community was enormous. The answer I got was complex. The fact that everyone was willing to talk to me with no strings attached, in and of itself, demonstrated a commitment to openness, and I’m still grateful for that. The code itself will be a short-term bottleneck, as it needs a lot of work before outside developers will find it compelling. I also think the licensing terms are weaker than they need to be, although I also understand the outside pressures that make it so.    (L7B)

In short, I think the spirit is strong within Socialtext to fully realize the potential of this Open Source project, but there are also roadblocks. Hopefully, external pressures won’t squash that spirit. If Socialtext ever fulfills its potential as an Open Source company, it will not only help the ecosystem, but it will also tremendously benefit Socialtext as a business.    (L7C)

BAR Camp 2005 Redux

Thoughts on BAR Camp. Yeah, yeah, a little late, I know. Less late than the rest of my Wikimania notes, though.    (JQX)

Many Hats    (JQY)

The most bizarre experience for me at BAR Camp was the number of people I knew from different worlds. My brain was constantly context-switching. It made me painfully aware of the number of different hats I wear, all in the name of Blue Oxen Associates.    (JQZ)

  • Purple Numbers guy.    (JR0)
  • Wiki geek.    (JR1)
  • Identity Commons contributor.    (JR2)
  • Doug Engelbart translator.    (JR3)
  • Usability guy!!! Obviously because of the sprints I’ve organized, but awkward for me, since I have no actual background in usability.    (JR4)
  • Pattern Language hat. I’ve been doing the collaboration Pattern Language dog-and-pony show the past few months, and some folks who’ve heard me speak on the subject were there. I’ll be doing a lot more of it too, so stay tuned. Patterns are damn important, useful, and interesting.    (JR5)
  • Facilitation / event organizer hat.    (JR6)
  • Nonprofit hat. The lack of nonprofit contingent was disappointing, but I had a good conversation with Ho John Lee, who’s done some great work in that space. (We were also both wearing our Korean hats, along with Min Jung Kim, a rarity at events like these.) I also met Phil Klein, a nonprofit guy who also participated in our usability sprint the following week.    (JR7)
  • Ex-DDJ hat. Some fogies, young and old, remembered me from my magazine days.    (JR8)

All this was testament both to my ADD and to the job Chris Messina, Andy Smith, and the other organizers did in only one week. Three hundred people walked through the doors over the weekend. Amazing.    (JR9)

Talks    (JRA)

The best part of the event was strengthening familiar ties and building new ones. I met lots of great people, including folks I’d only known on the ‘net. I wasn’t blown away by the talks for the most part, but some stood out.    (JRB)

  • Ka-Ping Yee did two talks, one on voting methods and another on phishing. Sadly, I only caught the tail end of the latter, but the Wiki page is fairly complete. I’ve never seen Ping do anything that I didn’t find interesting or, in many cases, profound, and these talks were no exception. (I’ll have more to say on Ping’s latest work in a later blog post.)    (JRC)
  • Xiong Changnian presented some interesting quantitative analysis of the Wikipedia community. I didn’t have as much of an opportunity to talk with Xiong as I’d like, but for those of you who have interacted with him, try not to be turned off by his bluster. He’s doing some good work, and he seems to mean well.    (JRD)
  • Rashmi Sinha and I did a roundtable on Open Source usability on the first night. Afterwards, we both agreed that we didn’t learn much new, but simply having the conversation and especially listening to a new audience was valuable. One unintended outcome: A participant (who shall remain nameless, but not unlinked!) complained about Socialtext‘s usability, which I dutifully reported on the Wiki. Adina Levin and Ross Mayfield quickly responded, saying they’re looking to hire a usability person. If you’re in the market, let them know.    (JRE)

I was so busy chatting with people, I also ended up missing a bunch of good talks: Rashmi’s tagging session, Rowan Nairn on structured data for the masses, and Tom Conrad‘s Pandora talk, which seemed to generate the most buzz at the camp.    (JRF)

Throwing Great Events    (JRG)

I toyed with the idea of doing a techie session, but in the end, the talk I should have done was one on patterns and throwing great events. BAR Camp was great, and as with all great collaborative events, there were some common patterns:    (JRH)

  • Food. One of the most critical and, amazingly, most overlooked element in an event. Lots of credit goes to Kitt Hodsden, who made sure there were enough snacks to feed a small country, and the sponsors, who kept the beer flowing and underwrote the party on Saturday night.    (JRI)
  • Introduce Yourself. The organizers borrowed the FOO Camp tradition of saying your name and three words to describe yourself, and they did it each day.    (JRJ)
  • Shared Display and Report Out. Folks did a great job of documenting on the Wiki and on their blogs and Flickr. BAR Camp owned the foobar Flickr fight.    (JRK)
  • Backchannel. I’m not a big fan of IRC at face-to-face events, and there were definitely times when I thought it detracted from the face-to-face interactions. But, it was there, and it was useful. It wasn’t logged, though.    (JRL)
  • Permission To Participate. Lots of Open Space techniques were present — again, borrowed from FOO Camp — like the butcher paper for scheduling sessions. Lots of this was also cultural, though. I think this is the hardest thing for folks who do not live in the Silicon Valley to get — the spirit of sharing that comes so naturally to folks here.    (JRM)

I’d do two things differently at the next event:    (JRN)

  • Incorporate a ritual for new attendees to make them feel welcome and to avoid clique-formation.    (JRO)
  • Add slightly more structure. Now that the organizers have done it once, they can use it as a template for the next event — for example, publishing the time slots ahead of time, and actually enforcing them, at least as far as room usage is concerned. Also, I like scheduled Report Out sessions.    (JRP)

In the postmortem, we talked a bit about what BAR Camp is supposed to be, and I really liked how Chris positioned it: As a model for organizing grassroots, free (or very cheap) alternatives to more expensive gatherings. I’m toying with the idea of incorporating BAR Camp-style alternatives to complement some non-free events I’m organizing.    (JRQ)

Purple Numbers: Optimized for Synthesis

Chris Dent has been having some good exchanges about Purple Numbers with Adina Levin and Phil Jones. I don’t have much to add, as I think Chris is spot on. Two comments struck me, though.    (IQV)

First, Phil claims that Purple Numbers are optimized for reading at the expense of writing. His point is that Purple Numbers, as currently implemented, add overhead to the writing process, whereas the pay-off comes for the reader. I emphasize as currently implemented, because we just haven’t gotten around to making them mostly transparent in the writing process. Hacking one of the WYSIWYG JavaScript text editors to support Purple Numbers should do the trick.    (IQW)

However, I really liked Chris’s response:    (IQX)

Yes, purple numbers do try to favor the reader and the act of reading, but not just for reading. They favor the reader so the reader may more easily do more writing. The whole point is for purple numbers and tools like it to be a generative force in the synthesis of new understandings.    (IQY)

Phil can write all he wants, and I can read all I want, but until I write down something that builds on what Phil says, while making chains of reference back through the many layers of context, there’s been no synthesis, at least not any that is available outside the confines of my own mind.    (IQZ)

Granular Addressability enables synthesis. Wanna know what makes blogs conversational? Permalinks, which are a form of Granular Addressability.    (IR0)

A lot of people don’t get this. I read The Sports Guy over at ESPN.com all the time (despite the fact that I hate all Boston sports teams with a passion), and at the past two Super Bowls, he wrote what ESPN.com called a “blog.” It sure looked like a blog, but in reality, it was just one-way publishing. Folks couldn’t comment on his entries, because they couldn’t link to any of them. I see this all the time with other major media outlets trying to jump on the blog bandwagon.    (IR1)

Which brings me to the second comment that jumped out at me. In his response to Adina, Chris wrote:    (IR2)

Clearly I am in far too deep with purple stuff: I need a translator. The above can be so much meaningless noise and I find little time to make things cogent.    (IR3)

I’m not the best proselytizer of Purple Numbers, not because I’m not proud of them (I am), not because I don’t value them (I do), and not because I can’t explain their value clearly (I can). There’s a tremendous amount of deep thinking underlying these little purple critters, and the implications are fascinating. But before you can understand any of this, you’ve got to care. And unless you’re one of those strange individuals who just gets it, you’ve got to try them before you’ll buy them.    (IR4)

A lot of folks think I invented Purple Numbers. Not true at all. I was one of those folks who didn’t care, one of the first in fact. Purple Numbers are an HTML manifestation of Augment’s granular addressability scheme, invented by Doug Engelbart and made purple years later by his daughter, Christina Engelbart. When I first started working with Doug, he kept insisting that all of our knowledge products on the Web have Purple Numbers. I didn’t think it was a priority, but I knew I could easily whip up a tool to generate them, so I wrote Purple to humor him. Then a funny thing happened. Once I had them, I used them, simply because they were there. Then I started missing them when they weren’t there. Then it dawned on me: These little purple thingies sure were darn useful. And I started thinking about why.    (IR5)

The point of my story is this: I’m perfectly happy to have a deep, convoluted discussion about some esoteric aspect of Purple Numbers. If you don’t believe me, try me. Or read my blog entries on the matter. But if you really want to understand why they’re so important, just give them a try for a month, then try living without them.    (IR6)

People Time

Adina Levin quotes Peter Kaminski:    (21Y)

“Time together in person is too important to spend working.”    (21Z)

Reminds me of something Paul Visscher and Jason Cook told me when I had dinner with them a few weeks ago. I was asking about the hacker community in Dayton and whether folks ever got together to do code sprints. Paul responded, “When I get the chance to see these people in person, I’d rather just hang out with them.” Jason told a story of how he went to one local hacker gathering, where everyone was in a circle, staring at their laptops, something he found rather unappealing.    (220)

To some degree, it shows how spoiled techies are in the Silicon Valley. There are so many of us here, doing code sprints doesn’t necessarily interfere with socializing. When Seb Paquet met up with me in December, he had just come from Marc Canter‘s party and was in awe of how easy it was to run into cool and interesting folks — not just techies — around here. (Hey Marc, where was my invitation?!)    (221)