“Users”

[T]he problem is that bad writers tend to have the self-confidence, while the good ones tend to have self-doubt. So the bad writers tend to go on and on writing crap and giving as many readings as possible to sparse audiences. These sparse audiences consist mostly of other bad writers waiting their turn to go on, to get up there and let it out in the next hour, the next week, the next month, the next sometime. The feeling at these readings is murderous, airless, anti-life.

– Charles Bukowski on why he encouraged people to not write.

“There’s only one other industry that calls their customers ‘users’.”

– Old information technology proverb.

Poetry Slam

Somewhere in 2009 it hit me that I had been wrong about educational technology. Very wrong.

The year before, I had been working for an organization that dealt with OpenCourseWare, and the rhetoric was (as it still is) that reuse of OCW could lead to education sector efficiency. But as we looked for reuse we found that there wasn’t much evidence of it. Not institutional reuse anyway, or reuse by professors.

And as I pondered this, it became very obvious why this was the case. Every single decision in the OER community at that time seemed to be predicated on glorifying and funding creators, based on a trickle-down theory of impact. Courseware was shipped as PDFs, with school logos burnt into the slides. Hewlett was funding Ivies to the tune of tens of millions to create OCW, and yet none of those projects ever sat down with teachers from state universities and community colleges and asked what they might actually want.

Simple things precluded any reuse. Test questions were published with answer keys, in formats that were not importable into LMS’s. Course videos contained references to resources unavailable to students not in the lecture, or housekeeping about advising periods that would mean nothing to someone watching this video for a class.

The Open Educational Resources community, at least the elite part of it, portrayed itself as a community-minded set of save the world do-gooders. But in reality, much of it was the Poetry Slam from Hell Bukowski talks about above, a bunch of elite schools sitting in Hewlett’s coffee shop, waiting for Yale to step down so they could show their OCW.

Makers, Builders, Producers

People say they want a world of “producers not consumers” or “makers not takers”.  Peel back the assumptions under those statements and you’ll find some disturbing stuff.

And so it was when I returned to instructional design in 2009, fresh off the OCW experience, that I found these phrases, which used to seem so normal, now strange.

There was a time, after all, that we used to call lurkers “readers”. Users were “doers”.  These things had respect.

Now anything short of “making” was devalued. “We’re going to turn our students from passive consumers to producers!” we yelled.

This was presented as revolutionary, but it wasn’t revolutionary at all. The forms might have been revolutionary – video, podcasts, CAD-based fabrication. But the idea that “producers” should be valued at a university is the least subversive idea one could have. It’s the entire basis of the academic enterprise. Everything, from tenure review to pay scale, is based on the notion that it’s not enough to be well-read, or to think good thoughts. One must make something. Academia is one of the few places where your entire career is based on how many important things have your name on them.

And so we showed students how to make things with their name on them.

Edtech-based making in the university was not an attempt to introduce a new value structure. It was (and is) an attempt to give students tools to achieve value in the existing power structure.

That’s valuable, certainly. I repeat, it is valuable. But it hardly makes you Illich.

And of course there’s a possibility that you’re just spreading the “Shut Up or Ship” culture of Silicon Valley that believes participation is only the domain of those-who-code, or the PDFing logo-stamping culture of the Ivies. It’s possible that you’re just reinforcing the same narrative that justifies the massive inequality in our country on the basis that the 1% “contribute”, and that being a “Job Creator” is better than doing a job for someone else well.  It’s possible that you’re enabling the people that went nuts after Obama’s “You didn’t build that” speech, where Obama made the rather mundane observation that success in America is enabled by our entire community.

It’s possible it gets worse. As Audrey Watters,  Debbie Chachra, and Bjork have noted recently, definitions of what constitutes “building” are gendered, and differently applied. A Taylor Swift album is seen (correctly) as co-produced and co-written. A Kanye West album is a Kanye West album, even if it contains a cast of hundreds. Kanye West is seen brilliant where Bjork is seen as making a excellent collaborative album.

And while we’re talking about the Brilliant Mind myth creatorism is based on, we might as well pull in this chart, which plots female PhDs in a field against the emphasis that field places on “brilliance” vs. “hard work”.

The paper in Science the above graph comes from focuses just on the brilliance connection. A focus on hard, sustained work over brilliance appears to predict female representation better than any other general model I know of.

At the same time, I can’t help but see them as interlinked phenomenon. Sociology graduates Bjorks. Philosophy graduates Kanyes. The hierarchy is Kayne > Bjork > Rock Critic > Listener. The fact that it is discerning listeners who produce artistic revolutions is lost on everyone.

To coders, people who don’t code are not makers. But we keep punching all the way down. Published writers kick bloggers. Bloggers see themselves as creating on a level that readers and commenters don’t. It’s not just about your job title, it’s about your internal taxonomy.

The Sources of Innovation

The things I have done since 2009 seem very scattered to people. I ranted on about OER reuse.  I got deep into von Hippel. With Amy Collier and Helen Chen I looked at how classes interact with MOOC materials produced elsewhere. I experimented with the pedagogy of summary. And now I’m involved with a federated wiki project so complex I barely know where to link to to explain it.

Underneath all of these projects (and many others: Water106, the Mixable MOOC, Design Patterns in ID) is really a single obsession. What would happen if we got over our love affair with creators? What would happen if we collapsed the distinction between maker and taker, consumer and producer, not by “moving people from consumption to production”, but by eliminating the distinction? What if we saw careful curation of material as better than unconsidered personal expression?

What if we stopped calling readers lurkers? What if we stopped caring about who got the credit? What if the OER community saw the creation of materials as a commodity, but the reuse as an art?

I’m not attacking digital storytelling here, personal blogs, or Makey-Makey Boards. I’ve used all of these in my work with faculty, and I’m going to continue to do so. These things get students engaged and excited, and in the process of making things they learn much more deeply than they could ever learn from a textbook. Sometimes a poetry slam is what you need. Sometimes it’s even good.

But the projects that interest me most nowadays are the one where the thing made doesn’t fall into the traditional categories. Federated wiki, the pedagogy of summary, student curation. What interests me most in ds106, for example, is not the making, but the co-making. In these projects I see a chance for an engagement that is less ego-driven, less divisive, and ultimately more useful to society. In the years since Gutenberg I think we’ve managed to get the single brilliant author thing down pretty pat.  It might be time to try something else.

I’ll end here with a story. Back in 2010 I was getting a coffee with Jon Udell, and he said something that has stuck with me. He had been trying to get people involved with community by encouraging production of various things, but it wasn’t working the way he planned.  He said that there was a point he realized that he was trying to make everyone a writer. And everyone’s not a writer.

His obsession with getting people to share calendar feeds seemed odd to some people, but for him it was (I think) about something bigger. Were people to simply share community calendar feeds with a hub, we could solve far more community issues than a roomful of bloggers ever would. A community getting this idea, that the work they don’t even think of as creation could be valuable; that would be much more powerful than than telling people to podcast their town meetings, or asking them to blog their work.

That idea turned out to be difficult for a number of reasons, but I think the concept is right. I imagine classes where writing a good and useful summary of research is seen as being as “brilliant” as writing an original paper, where cleaning up data is seen as valuable as theorizing about it. Where a well curated and quoted set of material is as valuable as research. Where reuse is valued over reinvention. Where replicating experiments is as revered as creating new experimental designs. Where people who connect others and think about how to connect others get credit for the advances those connections bring.

I think students who came out of a program like that would be better suited to solving the sorts of problems the world has right now. It’s just a theory, but I’m hoping we get a chance to prove it.

Rethinking Wiki Lifecycle: Sites as Bounded Conversations

As we plan for our second fedwiki happening the differences between federated wiki and wiki become, well, stranger.

If you’ve been following the story thus far, you know that federated wiki is pretty radical already. As with wiki, people converse through making, linking, and editing documents. But because each person has a seperate wiki, there is a fluidity to this “talking in documents” that is hard to describe.

You write a post referencing Derrida’s concept of “ultimate hospitality”. I get interested in that, do a bit of research. I save a copy of (fork) your post to my site, but link it to a page describing Derrida’s hospitality in more detail. Not because I’m an expert, but because it’s a good excercise to understand your writing. You see that post and fork mine back. The next visitor to your page finds your page plus my article annotating it. Maybe they edit it, creating their own fork. And so it goes.

Carry It Forward or Clean Slate?

As we move into Happening #2 on Teaching Machines, this question comes up: do we pull these documents into the new happening? Use the same site? Do I create one big “Megasite of Mike” which I haul into each event like my persistent twitter feed?

And what we’re thinking is maybe I don’t. Maybe Happening #1 site is done, and I create another site.

So for instance, my wiki farm is at hapgood.net. For Happening #1 on “journaling” I had journal.hapgood.net. Maybe for the Teaching Machines happening I make machines.hapgood.net. And to the extent I want to talk about something from a previous event in this new context, I fork it into the new context.

It’s pretty simple to do this in Federated Wiki after all. I just drag the page from one site and drop it on another, I edit it for the new audience, or maybe even take the opportunity to clean up a few typos. And that’s it, done!

While this may not sound extraordinary, it is in fact an inversion of how we usually think of wiki (and sites in general). And it has some neat ramifications.

The Dreaded Curve of Collaborative Sites

To understand why this is such a departure from traditional collaborative sites, we need to introduce you to the dreaded logistic curve. Here’s the curve of Wikipedia production:

Via Wikimedia Commons.

Until about March 2007 many people thought that Wikipedia’s growth was exponential. Above, we see a log scale graph, where exponential growth would be represented by a straight line (explanation of log scale).

But things go a little wonky in 2007. In that year it begins to become apparent that a logistic model might better predict Wikipedia growth. Currently the site is growing faster than a logistic model would predict, but well under earlier exponential models.

“Enwikipediagrowthcomparison” by HenkvD

If the extended model above fits, Wikipedia will near heat death in about 10 years.

Projection by HenkvD

People have attributed this to a lot of things, and certainly it’s a phenomenon with many inputs. But the logistic-like nature of it suggests one simple explanation — limited resources. Logistic curves are what you find when you map animal populations, for example, coming up against the resource limits of the environment.

In wiki, as in many other collaborative projects, the limited resource is stuff left to be written. People get together to write articles, and initially each new article leads to two other articles, and you see that growth on the left side of the graph.

Eventually, though, the easier stuff is written. It may not be written the way you’d like it to be, but it’s written. Wikizens move from homesteading new territory to vicious fighting over already cultivated plots of land. The enterprise begins to feel less fresh, and the type of people who find this stage envigorating are often dreadful bureaucrats.

Now, you might think this was just a function of Wikipedia, as it has articles on everything. But you’d be wrong. Smaller wiki communities see this same pattern. Here’s a graph of the first wiki approaching its own heat death:

(Chart by Donald Noyes)

Now these are the tail-end days of that wiki — it started in 1995. And its this observed pattern that led Ward Cunningham to predict, much earlier than most, that Wikipedia would follow the same pattern.

Colony Collapse

We get why Wikipedia would hit a resource limit — there’s an article on fish fingers already, for crying out loud. But why would WikiWikiWeb run out of subjects? There’s only 30,000 pages, after all.

The answer’s simple — people come together for a reason, a shared interest. In the case of WikiWikiWeb it was to share software design patterns and agile programming techniques. As those subjects fill out, the opportunities for new contribution diminish. The community has a choice — expand its charter (which fractures the cohesion of the group) or move into maintenance mode. (Likewise, Wikipedia could expand its charter by loosening notability requirements, for example, but this would radically change the nature of the project people thought they were contributing to).

Very few people want to be on a site that’s all about maintenance. As we mention above, the lack of new ground to cover leads to a claustrophobia manifested in endless arguments about what should and shouldn’t be on the wiki and non-stop edit wars.

This happens in other communities too, by the way. At some point in a political forum if there isn’t new blood people feel like they are just rehashing the same conversation over and over.

And so you get what I call Colony Collapse. One day you reach a tipping point, and suddenly the only people left on your site are the people you actually considered banning at the beginning. (This is what has happened to my old political community). For a while these people maintain the site, but eventually they too get bored and leave, and the site falls into disrepair. It starts to rot.

You can see this at my old site Blue Hampshire, which has reached the final phase of collapse, and now consists primarily of syndicated political press releases and occassional comments about how moronic other commenters are. There’s 8 years of beautiful posts in that site, almost 15,000 posts. Many contain wonderful explanations on how New Hampshire government works, personal reminiscences of New Hampshire political history. There are comments on that site with more political wisdom then you’ll find in a year of the Washington Post (there’s over 100,000 comments).

And it’s all rotting.

It’s heartbreaking, and after you’ve been through it once you get into a feed-the-beast mentality about all future communities. To paraphrase the line from Annie Hall: Online communities are like sharks; they have to keep moving forward or they die. And so, as community leader, you take on the exhausting role of the shark, pushing the site forward, always watching for the dreaded inflection point which presages the site’s collapse. Because once that happens, it’s all over.

A Different View: Wiki Sites as Bounded Conversations

That’s a long digression. But back to federated wiki.

Here’s a possible vision for federated wiki sites that you, the user make.

You’ll make federated sites for conversations on things, the way we are having this happening on Teaching Machines. And during the event, you’ll build it out. And then, at a predetermined point, you’ll call your personal version of that site done and abandon it.

In other words, we bake heat death into the plan. We accept our mortality.

That’s great, but now comes the question — how does the material get maintained? How do we recurse over it?

The answer we’re coming up with is that it gets pulled into new sites belonging to new conversations.

We have an example of this right now. We tried an experiment a while back that was a bit of a flop — a wiki called the “Hidden History of Online Learning”.  It’s got about a hundred pages of this variety in it:

The site flared up into activity for a couple of weeks, then sputtered and died. By all normal metrics it’s a failure, doomed to bit-rot and link-rot, a slow descent into a GeoCities-like hell.

But in this case everyone involved has their copy of the site. As they participate in the Teaching Machines happening, they can pull stuff over into the new teaching machines wiki they have made. They’ll spruce it up, check the links, and maybe even improve it a little.

Ward and I were talking about this, and he said it reminded him of an earlier time when he was first working with Smalltalk. Objects would get better the more systems they were used in, because each time they were reused they would get refactored, optimized, simplified, extended. He and his fellow coders even had a name for this: “Reverse Bit-rot”.

It shouldn’t happen. It defies the entropy we see in all those pretty graphs up-page. But it happened.

Maybe this can happen here too. Sites can end, like conversations end. But we reach back into those previous conversations and say —  you know, we were talking about that a couple months ago, let’s pull this thing in. And that thing gets another spin.

Maybe this doesn’t sound radical to you. Maybe it sounds ordinary. But I am sure every former online community manager out there understands just how radical this idea is. It’s equivalent to the soft-forking solution that was adopted Live Journal that became *the* solution for the non-collaborative communities that followed. But here it is applied to collaborative tasks.

In this world, sites like Blue Hampshire die — and maybe even die quicker, more humane deaths. In fact, maybe we say, hey, here’s a site that is going to exist just for the 2008 election. Two years later you spin up a site on 2010. Four years later on 2012. Some material from 2008 flows in. Some doesn’t. If the material is good enough to live on, there is no failure, no Colony Collapse.

Each wiki site is the product of a bounded conversation, expected to die, but also expected to be raided for the next conversation.

Kind of nice, right?

A Fedwiki Happening on Teaching Machines Featuring Audrey Watters

So I’m super excited to announce we’ll be doing a Fedwiki Happening on Teaching Machines with Audrey Watters helping to facilitate.

If you don’t know what federated wiki is yet, the short answer is its a form of wiki where everyone has  personal wiki that magically links to other wikis to form a federation. People find the experience of using it difficult to explain, but I personally thought that Alan Levine’s description of it as communal index cards was a good pass at explaining it.

We ran a Happening in December that was structured around “collaborative journaling” but as people in the Happening pointed out, the exciting stuff was cooperative, not collaborative, and journaling didn’t really capture the weird hypertext mind meld that happens when you get deep into federated wiki. While the first Happening was a great success, we’re interested in exploring the form. So we’re offering this Course that’s not a Course with Audrey’s help in March.

A cMOOC Not Based On Stream

Here’s how it will work. You’ll notice a lot of parallels with Wiley’s proto-MOOCs here as well as with Siemens/Downes/Kop cMOOCs and Cormier Rhizo-experiences. The approach is far from revolutionary, but trying it on federated wiki will add some interesting dimensions.

First, we’ll get all of you set up on federated wiki through two waves on onboarding which demonstrate how to use the tool. The first will start Feb 1. and the second will start March 1. I really recommend getting in the February cohort so you can play around with the tool a bit before the Audrey part of the Happening starts.

The way we think the topical part of The Happening is going to work is this. On Day One, Audrey will publish a concept sheet. It’ll look like this (although this is not from the course, it was just made up as an example).

Each one of those links to nothing initially. As participants come through, they pick topics, click the link and write summaries of these subjects. Or (and this is important) they write something else maybe only tangentially related. Maybe something not related. Or they go to other people’s articles and extend them by linking to new articles of their own creation.

Pushing out from the center, creating through association.

Slowly, however, material gets covered. Over the course of three days as you click these links you’ll see articles that others have written. If you like those articles, you can fork them to your site. If you like them, but would like to extend them, you can do that too. You’re also encouraged to link out from the articles and explore other areas of interest not captured in the list. You’re slowly building a personal wiki site on this subject that represents what you believe to be the best possible view of the subject.

At the end of three days we’ll have a Google Hangout on Air, and we’lll use the articles as prompts for a conversation with Audrey. We’ll look at the articles people have written on her suggested subjects (“Audrey, this article says ‘Augmenting Human Intellect’ is sometimes seen as oppositional to AI — can you talk about that?”). But we’ll also talk about the ones that people have contributed on their own (“Is anyone involved with the article on ‘A/B Testing’ in the Hangout or chatroom? Do they want to say a bit about it?”).

Finally, we’ll look for places where there’s some variation in the versions people have written and forked. Is there an interesting disagreement here, or are things just out of sync?

Then it’s another list of articles for Day 4, and we go through this whole cycle again. We do it seven times for a total of 21 days.

What’s New About It

It sounds a lot like David Wiley’s wiki-based Open Education course, obviously. Or any of a number of open wiki courses. Again, it *is* a lot like that.

Where it gets different however, is that it is a cooperative, not a collaborative class. So each participant will be creating their own wiki out of the works of others, a wiki that captures their view of the subject, their connections, their set of interests. (In this way it’s the fusion of the blog-based approach people have been using with wiki culture).

It’s also meant to be highly associative. One thing I’ve learned with federated wiki is that the distributed ownership of the wiki space frees people up to make the sort of connections and extensions of ideas they would be timid about in a shared space. In a normal wiki, you ask forgiveness, not permission. In a federated wiki you ask for neither, and ultimately this benefits everybody, as people edit and supplement material at levels you just don’t see in a standard wiki based class.

Which bring us to this point — outside of learning about teaching machines, you’ll also get to use federated wiki, which is a bit of a mindbender. It’s sort of what the web might have been if it had been built by the people who produced KMS and the creators of GitHub.

Ward Cunningham calls it “A new kind of browser embedded in an old kind of browser.” And that’s what you’ll see if you have the patience to deal with the weirdness of it — not a new kind of website, but a different kind of web, one that looks far more like what Engelbart, Kay, and Nelson might have built.

I’m not going to lie. It’s not easy software to master, and it is more “developer release” than polished product. But any Happening participant who stuck with it more than a few days will tell you that it was well worth the effort to figure out. (In fact, a few of them told me the course and software changed their lives forever, but we’re being modest here).

Audrey Fucking Watters

Oh, and did I mention Audrey Watters will faciliate it?

Audrey and I talked about the structure of the event earlier this week, and what sort of skeleton she was going to build for it. And it ended up sounding even cooler than I thought it was going to.

Here’s the premise. There’s these teaching machines, and then there’s this idea of augmenting human intellect. There’s Artificial Intelligence. There’s machines that work on you, and then there’s machines that work *with* you. There’s Illich’s hammer, convivial tools, Memex, Pressey’s Machine, PLATO, Logo, Scantron sheets, Speak-and-Spell, and the weird question of how a construction company became the world’s largest educational publisher.

There’s this whole mess of things where you start by talking about Thorndike’s desire for adaptive release textbooks and end up talking about the nature of the Google Car. If you’ve seen Audrey talk recently, you realize how fascinating these paths are, like a James-Burke-in-Connections path from Lascaux Caves to the invention of refrigeration.

You could do this learning event as a standard read-reflect-make sort of thing. But I’m interested to see how it develops in the more associative soil of federated wiki. Maybe you just put up the article on Programmed Learning. But slowly that piece of yours is woven into a larger narratives — or actually woven into many competing narratives, with each person bringing their knowledge into the web.

I had you at Audrey Fucking Watters, right? I’ll just stop here.

Signing Up

So it starts March 1. It ends March 21. There’s maybe seven hours of minimum commitment, up to however much time you want to spend.

I have a sign up form. People who sign up will get an orientation to Federated Wiki in early February and be plugged into the event (via a hub-like thing called “Conversation Clubs”) for March.

It’s here.

We are providing servers for your fedwiki for this event, so please sign up soon so we can estimate server needs.

See you in the Happening!

A Note to Previous Happeners

I know the Happening over Christmas was a very special event for many people, and one or two people had reservations about using the Happening name for something like this that is a bit more structured. The Happening was a neat enough moment that we all feel we own it, and we don’t want to dilute it.

I completely get that. So I just want to say that 1) this is an experiment, we can go back at any time to the more self-directed version at any time, and 2) I think that while this sounds structured that federated wiki has a way of blowing a great big hole in anything hierarchical. So I think we’ll all find in the end that this is just as unpredictable, and just as special as the December event.

And if it isn’t, we’ll blow a hole in it ourselves. ;)

The Fedwiki User Innovation Toolkit

Tim Klapdor has a good explanation of what the FedWiki Happening was and how it went on his site. For those that want to understand what all the fuss is about, that’s maybe a good place to start.

He also has one of the better lines of the week:

There are some idiosyncrasies to learn, some slightly odd concepts and practices but if you’ve ever driven a French car it’s nothing you can’t take in your stride.

Federated wiki, the Peugeot of social software! New tag line I guess.

But he says one thing I want to pick up on:

I’m kind of shocked at the flexility of Fedwiki as a tool. It’s really only limited by your imagination and I’m only just starting to get a sense of how it can be used.

This is the thing. When you first get your first generic Lego set and build the Millennium Falcon, it doesn’t really work as well as just buying the Millennium Falcon Lego set.

Setup is a pain in the butt. Things end up in weird places. It’s a bit funky looking.

But you start to realize after a while that, holy crap, I can build anything with this.

And that’s the case with Federated Wiki. It can be a hub for sensors. A film review application. A navigational database. Interactive fiction. A calorie counting application.

It’s not really a web site at all, or even web software. As Ward Cunningham puts it, it’s a new sort of browser embedded in your old sort of browser. It replaces HTML with JSON. It sees paragraphs/items as the atomic units of the web, not pages. It collapses the read/write distinction of the web, and replaces location-based networking with networking based on named objects. It introduces cross-page refactoring, which turns out to be a much bigger deal than you’d ever guess.

In many ways it resembles HyperCard, the missing link to the Web, a maker set for networked creation.

Mdn Design Interactive – source.

As the Ars Technica article linked above notes, the variety of uses of HyperCard in education were extraordinary:

• a stack of multiple choice test questions
• assembling, storing and delivering teaching materials that included graphs from Excel
• making class KeyNote-like presentations and handouts for students
• a calculator that included a variety of mathematical functions and graphing capabilities
• computer aided instruction in the sciences incorporating animation and sound
• fractals
• oil-spill modelling
• a database front-end to an Oracle database
• a database in toxicology
• selecting and playing tracks on a videodisk
• an interactive educational presentation showing jobs in the wool industry
• educational interactive games ‘Flowers of Crystal’ and ‘Granny’s Garden’

HyperCard even was the original platform the puzzle game Myst was programmed in. Myst remains one of the best selling computer games of all time.

It’s hard to see right now, but underneath the hood of Federated Wiki is some very careful thinking in how a few concepts — JSON, plugin architectures, dynamic neighborhoods, forking, pages as data sources to other pages — can be put together so that you can build applications without programmers.

(In fact, one of the joys of working with Ward has been when presented with a needed capability his question always is “How do we build a solution that gives users more creative power?” He’s iterative , but he rejects the incrementalism of the current age. If you want your users to do amazing things, they need the tools to get out in front of you).

So yes, it’s a bit of a Peugeot at the beginning. It’s not the fanciest Millennium Falcon on the lot. But in return you get a user innovation toolkit like no other. We may not talk about that much for the time being (I’ve found people get overwhelmed when I show everything Federated Wiki can do). But I saw Tim’s comment and could’t resist saying — you don’t know the half of it. ;)

Federated Wiki, Slow Cooperation, and a Kindle Parable

There’s a really excellent post over at Frances Bell’s blog talking about problems with forking in fedwiki — and really about the meanings associated with different types of revisions and decisions of people.  And there’s a lot there to comment on, but the piece I take away is that we haven’t reduced the stress of revising work of others as much as we intended.

As Frances points out, sometimes this is because we don’t see the edits we should — and that’s a system issue.  But sometimes it’s that we do have the edits we want, but we’re just feeling pressure to adopt “the latest version” and we’re very worried someone’s contribution might have gotten lost. Sometimes it’s that we’d love to incorporate edits, but we’re newbies, and we go about things in ways that create more confusion.

I started writing a long comment on Frances’s blog, but got routed to a weird WordPress login loop. And I thought rather than go back and reconstruct that comment, I might put out a way of thinking about fedwiki for your critique. This doesn’t quite answer the questions or issues in that post (or the many, many comments), but it deals with the *stress* that misfires might cause newbies in the system. Because the misfires are a problem, but it’s the stress that worries me most.

A Kindle Parable

Imagine a world where everbody has a Kindle, but they are not that sucky, closed system you usually get stuck with. These Kindles allow you to treat your books like a word-processing document. You can add notes, change things, delete passages. And you can forward your annotated & edited version to all of your friends — the license allows you to do that.

So, for instance, I am reading Memory Machines right now, and the chapter I am on is the one on Englebart’s NLS project.

Now I know a bit about Englebart. And so as I’m going through it I’m writing in notes, and linking it up to other books I’ve read and other documents I’ve written. There’s also a bunch of stuff in there that’s not really relevant to what I am reading it for, and I delete it, knowing that when I come back to this to review it I want it to be short and scannable.

I also know I am going to share it with friends, and they won’t read it if it’s super long, so I edit it down to the pieces that really deal with federated wiki, since that’s what we’re talking about.

You (a friend of mine) get my annotated copy on this Kindle book and start making notes, adding some stuff, linking to the books that you have.

Now, here’s the thing — I see your edits. What does it mean if I don’t pull them back?

You can’t make it mean *nothing* — I’m not so naive as that. But I would love it to mean *less*. I’d like it to mean, primarily, that for my own reasons it wasn’t useful to me to pull those edits back.

Underlying that could be a number of things. Maybe I didn’t have the time. Maybe I missed them. Maybe I read them, and enjoyed them, but thought, hey — I can always read this version on your site, no need to fork back. Maybe someone had even better notes, and so I forked theirs and I didn’t want to take the time to integrate your notes in.

Basically I have me, and the people who read my annotated versions of books, and those are my responsibilities. My job is to write the best article I can given the time, but “best” is heavily influenced by what my personal needs are and who I feel I am writing for.

The one thing that best really shouldn’t consider too much is “What article will make my collaborators happy?” because that way madness lies. And that way self-editing lies too — and keep in mind if you’re afraid to say something that you think is useful, it’s likely we all lose.

The Fast Cooperation Problem

So this sort of system is properly called cooperative, not collaborative.

In collaborative systems, people share goals. In Wikipedia, that goal is to write the best and most representative neutral point of view article on a subject, in an encyclopedic style accessible to a general audience. You may have personal goals in addition to that (raising profile of women in science, for example) — but they must remain aligned with the group goal — they can’t supercede it.

In cooperative systems people are allowed to pursue wildly different goals, but are encouraged to do so in ways that can benefit the work of others. Blogging is in some sense cooperative — you pursue your own goals, but you publish in a way that makes your stuff easily quotable by others. The notation system that Kindle currently has, where I can see what Gardner Campbell highlighted is cooperative.

Federated wiki is cooperation dialed up to eleven. Or it’s meant to be.

But looking at the interactions and the confusions and stress that sometimes results, I’m starting to see a failing point.

Here’s the world as I imagined it. I publish an article on NLS. A bunch of people read it and put in their notes. Or just save it. I’m an attention addict, so maybe I immediately read the notes. But I don’t want to pull them back.

Why? Well, I read them, and some were good, But I don’t want to edit this thing every day. I’ll wait for some more notes to accumulate.

Other people fork my article and write their notes, edit their version. Some fork forks of forks. Each one is different. This happens over the space of weeks or months.

At some point I’m writing another article and I link to the NLS article. When I test out that link I see that there are a half dozen twins. I think, I should look at integrating some of this stuff and I browse the twins. and write stuff up.

This is my dream world, but there’s a couple of problems with this. First, we have cross-page item dragging, but it doesn’t create references in the history. So I am pushed to fork a version to get the reference, but all the versions are different, and forking destroys my own history.

This is a big part of the “catch-up” problem. If things get too out of sync it’s hard to put them back together while maintaining attribution. This can be fixed.

Harder to deal with is the different sort of environment our Happenings present.  In the Happenings we’re on the time-scale of hours, not days. It’s a sort of a “wikiswarm”, and it has the benefits and drawbacks of swarm behavior. So people all pounce on the same article at the same time.

That changes the dynamic dramatically. And I’d argue that it dials up the meaning of whether you get forked or not forked, or have your edits included or excluded. It certainly creates an environment where I feel I must stay on top of new edits, for the good of the tribe.

Possible Solutions

Some upcoming software upgrades (particularly a “history for paragraphs” upgrade) will make this much better. But the social issues remain.

It may be we need to encourage certain behaviors in Happenings that we don’t need to encourage in slow-cooperation environments. I’ve noticed that linking small articles out tends to work better than doing larger pages. When you create a small article with your additional idea, example, or data that idea stays visible even if the main article gets slammed with edits.

It maybe that we need to encourage “random article” behavior, to push people into editing the things that are not where the buzz is. We definitely need to get people to attribute less meaning to inclusion and exclusion of edits. The key is the long view.

At the same time, the “buzz” is part of what is addictive about the Happening. I have talked to so many people who describe just *dying* to get back to their computer to see what the Happening had pushed to the top of Recent Changes. That excitement is a powerful tool, and we want to preserve it in some fashion.

Hmmmmm.

Anyway, lot’s to think about. Thanks to Frances for starting the conversation.

Fedwiki Happening: I Don’t Know How to Start, So Let’s Just Type

I don’t know how to start talking about the Fedwiki Happening publicly, to people who have not been a part of it. I’m worried that to people who haven’t experienced it it will be about as exciting and comprehensible as hearing someone narrate a dream, or an acid trip.

Which, I suppose, makes it very Happening-like. Take it away, Pixies:

The short version is, after talking about this hypothesis for several months that you could build a distributed community with the vibrancy of Twitter,  the independence of blogging, and the timelessness of wiki 20 insanely great people volunteered to test that hypothesis out.

Even that undersells it, because the hypothesis wasn’t just that you could tweak a recipe, or get a balance right. We were asking people to blog, essentially, but remove ideas of authorship, rhetoric, ownership. We were looking in many ways to turn the web on its head.

Could it work?

Short answer: Yes. In much less than fourteen days we proved that social media software is profoundly underestimating what people are capable of, and the models on which you could base a community. The chorus of voices that says that people won’t be able to understand this sort of mode of communication is, in fact, dead wrong. People not only understand it, they have profound experiences with it. I have had people write me that the fedwiki paradigm flows much more naturally with their way of thinking than anything currently on offer on the web; that federated wiki feels less like publishing and more like an extension of their mind, a tool for deep thinking on an increasingly shallow web.

Weirdly, I’d thought we wouldn’t have gotten much further than that in fourteen days. And that was the surprise for me. People went from stressing out about attribution to not caring about it, by like Day 4, and to embracing the tool on Day 5. But then they started to really prod at the edges of what the form was, what it could be, and how to steer it.

(This really is like a dream narration, isn’t it?)

Over the next six or seven days we got deeper into the issues of social media, power, feminism, ownership, voice, group dynamics, knowledge, and cooperation than most 15 week classes do. And we did it in this weird style we had developed — trading terms, stories, resources, ideas instead of rhetoric (although one could argue, I suppose, that this is a new kind of rhetoric).

And it makes sense, I suppose. As we discussed under what circumstances we should use comments we had to grapple, in a very real way, with what comments are, and what they do to the online experience. As we forked articles referencing personal stories, we had to deal with issues of attribution and credit, and the question of why and when the “I” matters.

The tension between the Recent Changes feed and the more topical approach to engagement drove further conversation about the way that feed driven architectures create cliques that are impenetrable to outsiders. What the reverse chronology approach does to conversation became apparent — and it’s not all good. (Ward refers to wiki’s Recent Changes — a feed he created a couple years before RSS, and one of the first community feeds of the internet as “pouring gasoline on wiki”, which perfectly captures the ambiguity of feed effects on the web).

Authorship, power, gender differences, connection, consensus, lack of consensus, ownership…

There have been other classes about the web and social media. I’m not sure I’ve ever seen a class where we disassembled the web put it back together in an entirely different way, and asked participants to reflect on the difference.

So we ended up proving the hypothesis that this could work, but also ended up with something much bigger — a set of people who, I think, are coming away from the experience not as fedwiki cheerleaders, but as incredibly thoughtful critics of the assumptions of the web and the ways in which fedwiki addresses and does not address them.

And as for me, I’ve come to see that more than anything, THAT is the point. Tim Owens joked a while back that I talked about fedwiki like Morpheus in The Matrix offering the blue pill and the red pill. Do you want to go back to your boring, but safe life? Or do you actually want to understand the machine you are living in?

I denied that back then, but I’m not sure now. I think a lot of people in the happening feel a bit like they just took the red pill. And while I think fedwiki has a bright future as a product, it’s this process of getting people to re-examine 20 years of assumptions about what the web is that excites me the most. And if I can speak for the participants in The Happening, I think that’s what has excited them as well.

Federated wiki is not hard like setting up a Jekyll instance hard, or the ten steps to embed a YouTube video hard. It’s not hard like “I have to learn to edit video” hard.

It’s hard like Red Pill Hard.

I’m incredibly grateful to have worked with a bunch of people who embraced that sort of hard, and pushed the experiment past my wildest imaginings. Thank you!

Helping the Right Ideas Find One Another (FEDWIKI HAPPENING)

I’ve talked a bunch about Federated Wiki, and the idea a system like it could reinvent the way we talk on the we talk on the web, replacing our Twitter streams of reaction porn with something more substantive, connected, and iterative.

So, imposing on people I knew across the intertubes, I decided to put together an experiment called Fedwiki Happening #1. Initially I tried to only invite 15 people (making sure to pull from a worldwide group — I really do take the U.S.-centric critique seriously). The idea was a 14 day uncourse (Dec 17 to Jan 1) that would set very small open assignments (Connect two articles! Fork an article you like!) around a task of “idea-mining”, a cycle of daily discovery and connection I’ve become convinced is a core application of the technology. It ended up ballooning to about 36 people as a number of people asked to be involved.

We started on Wednesday. And already I have the sense of something big here. Here’s a segment of the Recent Changes, about a quarter of a day’s activity:

Each separate icon (whether color or photo) represents a person forking a page and making an edit; joined icons indicate a fork without an edit (which is halfway between a “like” and a bookmarking action.

Participant Alan probably captures the process a number of us are following as well any anyone in Federated Index Cards, and it’s well worth reading his take.  (There are of course other approaches, from writing collaborative fiction to co-authoring more formal academic pieces, all of which I watch with intense interest).

It’s a process I followed for a number of months while experimenting with the form, and then invited Ward to try with me in a six week experiment. You go about your day, read what you normally read, think what you normally think. But rather than posting links to these things on Twitter or Diigo, you drill down to what the connectable *idea* of the thing is.

Why? Because the problem I am trying to solve is I want to help “the right ideas find each other”. Those ideas could be two of my own ideas that I don’t realize are connected. The could also be an idea I have and one someone else in Bangalore has. Or my idea and your examples. Etc.

But what’s really cool, and what I’ve gotten to experience firsthand, is the joy of connecting *other* people’s ideas, of being what is called a “broker” in social network analysis.

Here’s an example of that.  First Kate puts up an article on Small Public Spaces.

As Alan notes, it’s like filling out an index card. And it’s not that it’s an *idea* exactly — it’s that this thing here, this thought about how Whyte approached the design of public spaces — it’s “a good tool to think with”.  You can see throwing that idea (or example, or data, or whatnot) into the mix of a future discussion, and it helping to deepen that discussion.

I’ve read about Whyte before, but this prompts me to search YouTube for a video of some of Whyte’s observations. I find one on movable chairs, and watch it. It’s super cool, showing how people reposition movable chairs in plazas to deal with needs of the moment, and sometimes move them just to feel empowered.

Looking at Kate’s article, I link the term Movable Furniture to to a new page I’ll create with that video on it:

But as I’m writing up the page Movable Furniture, I’m reminded of something else I recently read in the federation — David Jones had written two pieces, one on the idea of needing students to be Digital Renovators — people who feel empowered to alter their digital environments, and a related idea of the Concrete Lounge — the digital environment that is impossible to customize. Watching the video and seeing how much people rearrange chairs when they get the chance, I just can’t help but see this as related.

So I link it up:

And now, if you click that Concrete Lounge link you get what I think is a very relevant connection to Whyte’s work:

Now, did Kate already know about David Jones’s Concrete Lounge analogy? Had David already put together how his Concrete Lounge related to these late 1970s ethnographic films of people moving patio chairs?

Maybe. I’d be curious to know. But even in the case they had both known about these connections, these connections are now there for *anyone* to follow. The next person who ends up on the Small Public Spaces side of the equation can follow it to the Concrete Lounge, and vice versa.

You could connect other things — data to theories, examples to patterns. Data to data. If you imagine a universe of people doing this rather than forwarding article and video links around, you start, I think, to get to a vision of the web more in line with early conceptions of what the web might be.

And of course, it’s very like wiki, but it’s not in this one, super-important way: there is no permanent community. The wiki is implemented as a network, where the people Alan follows will overlap with some of the people I follow, but never so much that the community is self-contained. As federated wiki expands, the network might start to look more like Twitter in terms of how information flows fluidly through through multiple sub-networks, but more like wiki terms of how that information is treated. Ideas could flow through log chains of people unaware of each other’s existence, reaching unpredictable yet fitting destinations.

Of course, there are other models of use as well, some of them emerging on the site as we speak, and we watch this closely. After playing with (and thinking about) the software for eight months, it’s really this piece that most excites me at the moment, the possibility of a new culture of connection, where we solve one of the most pressing problems of today — how to get the right ideas, data, and examples to meet.

For now, the software may be buggy, the users may be new to the environment, the learning curve may be difficult. But we’re starting to see the outline of something strange and new. And I like it.

(Edited to fix misattribution of Whyte article)