Linus Torvalds – Eugene Eric Kim

The Technology Understanding Gap

Published February 28, 2008 by Eugene Eric Kim

Technology is insidious. It has a way of dominating a problem the way nothing else can. If you understand technology, it’s hard not to see everything in that light. If you don’t understand technology, it’s hard not to be overwhelmed by what you don’t know. (MUK)

I’ve known these things for a long time, and I often talk about these things, but I saw the latter phenomenon in a way that really affected me last month at the Packard Foundation gathering on the future of network impact in philanthropy. On the first evening, Clay Shirky gave a preview of his book (available now), Here Comes Everybody: The Power of Organizing Without Organizations (which sounds like it’s a real winner; can’t wait to read it). (MUL)

One of Clay’s contentions was that projects that worked in large-scale networks shared a happy medium between a Promise, a Tool, and a Bargain. In the case of Linux, Linus Torvalds‘s Promise was to build “a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.” (Note how small and concrete the original Promise was, compared to what Linux has become.) The Tool was source code control (specifically diff and patch in the early days). The Bargain was the GPL, which stated that if you contributed your work, others would as well. (MUM)

A lot of my work centers around facilitating collaboration in large-scale networks, so I found this contention particularly interesting. The following day, I co-led a session on this topic with Angus Parker. Two of the participants were dealing with the specific challenge of connecting members of a national network of leaders in reproductive health, so we used that as a case study. We decided to use Clay’s contention to frame the problem, resulting in this whiteboard: (MUN)

(MUO)

What do you notice about this picture? (MUP)

Obviously, the Tools column is completely empty. That’s a dead giveaway that I’m facilitating this discussion. (That and the horrific handwriting.) Figure out the basics first. Don’t let the question about technology drive the discussion. (MUQ)

During the discussion, one of the participants asked, “What tools can we use?” (MUR)

I responded, “Let’s not worry about that now.” So we kept talking and talking, and I noticed the two non-technical participants in the group squirming like crazy. (MUS)

So I stopped, noticed how gaping the Tools column looked, and said, “You’re uncomfortable about not having discussed the tools, aren’t you.” (MUT)

She nodded. (MUU)

“Don’t worry about it,” I responded. “The tools part will be easy, once we figure everything else out.” (MUV)

“Easy for you, maybe,” she said. “You already know what goes there.” (MUW)

That was not quite true, but I got her point, and the force of it struck me so hard, I had to stop for a moment. I looked at the gap, and I saw possibilities. She looked at the gap, and she saw a void. That was upsetting for her. It made it hard for her to think about the other aspects of the problem. (MUX)

It made me realize how much I take my technology literacy for granted. But it also created an opportunity to discuss how easily we are sidetracked by technology. “Tool” does not have to mean software, and making that assumption prevents us from exploring other viable, possibly better solutions. (MUY)

I had two takeaways. First, I had previous explored doing a basic technology literacy workshop as part of Blue Oxen Associates‘ Tools for Catalyzing Collaboration series, but I was not particularly motivated to do it. I’m now rethinking this. Second, if I ever do this exercise again, I’m not going to include the Tools column initially. We can throw that in later. (MUZ)

barx: A Ruby XRI Resolver

Published November 28, 2007 by Eugene Eric Kim

Last month, Victor Grey and Kermit Snelson announced barx, the first full implementation of the XRI 2.0 draft specification (working draft 11, for those of you keeping track). I finally downloaded and started playing with it tonight; it’s very nice. Most OpenID implementations are using a proxy hack to support i-names, but as real XRI implementations start to come out, we’ll start seeing many more interesting applications. (MS5)

I’ve started to port barx over to Perl and will hopefully have it completed by IIW next week. Yes, I’m coding again. I’ve been sitting on a slew of year-old ideas that need to get implemented, and I’m tired of being a preacher instead of a do-er (at least when it comes to code). It’s against my instincts, and I don’t have enough of an audience to leverage the Lazy Web. (MS6)

Besides, I was starting to miss it. Over the last few years, I’ve built a reputation as someone who knows a bit about collaboration, not just about tools, and that’s been really gratifying. It’s also helped me feel okay about reminding people that I still know a bit about tools as well. Plus, a lot of things have been stoking the fire recently. I was managing the HyperScope project last year and the Grantsfire project this year, both of which are conceptually and technically interesting. I never stopped reading code, and a lot of my friends are developers. What really kicked things into gear for me, though, was stepping in as an emergency developer for Grantsfire and watching Linus Torvalds‘s git talk. (MS7)

I started playing with a bunch of ideas at once, but I’m focusing on Grantsfire and the Digital Identity stuff now. Stay tuned, and if you want to hack with me over the next few weeks, either face-to-face or remotely, ping me. (MS8)

Tools and Culture

Published November 25, 2007 by Eugene Eric Kim

Tools reinforce power relationships. If you want a more emergent power model within a group, you have to make sure your tools support that. Git is a beautiful example of how a tool can support the right power relationships. (MRK)

However, just because a tool has affordances doesn’t mean people will pay any attention to them. Linus Torvalds alluded to an example in a software development context: Giving everyone commit access to a centralized repository. He refers to this happening in companies, but there’s precedent for it happening in Open Source communities as well. For example, TikiWiki gives commit access to anyone who asks. The underlying philosophy behind this policy is very Wiki-like: Empowering everyone to make things better offsets the risk of giving everyone the opportunity to screw things up. By not imposing a power structure, the right model can emerge. (MRL)

In the case of git, the tool explicitly supports an emergent power model. In the case of the TikiWiki community, the tool’s inherent model is overridden by the community’s culture. (MRM)

What can we learn from this? Tools have the potential to transform culture, but transformation never comes easily. In the Wiki community, the classic case of this is when users email an administrator about a typo in a Wiki rather than fixing it themselves. We in the Wiki community use this behavior as a leverage point to explain that they have Permission To Participate and can change the content themselves. Once people start modeling this behavior, transformation becomes a possibility. (MRN)

When I saw Michael Herman last month, we talked about how tools do and don’t encourage emergent models of behavior and how often we need to catalyze this process by other means. Michael brought up the phenomenon of a few people gathering at a circle of movable chairs, then sitting on opposite sides of each other with many chairs between them rather than moving the chairs they needed into a tighter circle. Even though the environment was adaptable, people chose to go with the default rather than optimize it for their needs. (MRO)

I saw a similar phenomenon a few weeks ago at TAG, where I sat in on Eugene Chan, Lucy Bernholz, and Suki O’Kane‘s session on Web 2.0 and philanthropy. They had a very interactive design, which in the context of TAG (a very traditional conference format for a very conservative community), was highly unusual. They kicked things off by doing a spectrogram. (MRP)

(MRQ)

Not only did this establish a sense of self-awareness and Shared Understanding among the participants, it also got people moving (and laughing), which was especially important since the session was right after lunch. Without saying anything, it was clear that this was not going to be your traditional talking heads session. Smart, smart, smart. Then they led a discussion. They gave people Permission To Participate by explicitly setting expectations, catalyzed the discussion by asking broad questions, then held space and exercised self-restraint whenever there were awkward silences. Again, very nice. (MRR)

But they also did something dumb. Look at the space: (MRS)

(MRT)

Whereas the leaders of the session were saying, “Please talk! Participate! Learn from each other!”, the space was saying, “Look at the leaders! Keep quiet! Check your email while pretending to listen!” And the space was really, really loud, much louder than the leaders. (MRU)

In fairness to Eugene, Lucy, and Suki, it would have been a major pain in the rear to rearrange the space, and there were strong disincentives to doing so (specifically, the wrath of Lisa Pool). But space makes a huge difference, and even super smart people don’t account for this as much as they should. Even people who are in the business of collaboration and are constantly preaching about this sort of thing (i.e. me) make these mistakes all the time. Old habits and thinking die hard. (MRV)

The online tool space is rampant with these examples. How often do you see Wikis where the “Edit this page” button is impossible to find? (MRW)

Tools can encourage or discourage certain types of behavior, and it is in our best interest to choose and adapt our tools to encourage the behavior that we want. That’s not always enough, but it’s generally a good start. Eliminating obstacles can be as much of a catalyst as a good kick in the pants, but a combination of both is even more effective. (MRX)

Imposed Stupidity, Emergent Intelligence

Published November 25, 2007 by Eugene Eric Kim

In The Restaurant at the End of the Universe, Douglas Adams wrote: (MR5)

The major problem — one of the major problems, for there are several — one of the many major problems with governing people is that of whom you get to do it; or rather of who manages to get people to let them do it to them. (MR6)

To summarize: it is a well-known fact that those people who must want to rule people are, ipso facto, those least suited to do it. To summarize the summary: anyone who is capable of getting themselves made President should on no account be allowed to do the job. To summarize the summary of the summary: people are a problem. (278) (MR7)

I recently watched Linus Torvalds‘s talk at Google on git, the distributed version control system he wrote a few years ago. There are a bunch of gems in his talk, and it’s well worth watching. My favorite had to do with git’s views on decision-making in Open Source communities: (MR8)

Maybe you don’t have this issue inside a company, but we certainly have it in every single Open Source community I’ve ever seen that uses CVS or Subversion or something like that. You have this notion of commit access. Because you have a central repository, it means that everybody who’s working on that project needs to write to the central repository. Which means that, since you don’t want everybody to write to the central repository because most people are morons, you create this class of people who are ostensibly not morons. And most of the time, what happens is, you make that class too small, because it’s really hard to know if a person is smart or not, and even when you make it too small, you will have problems. So this whole commit access issue, which some companies are able to ignore by just giving everybody commit access, is a huge psychological barrier, and it causes endless hours of politics in most open source projects.    (MR9)

If you have a distributed model, it goes away. Everybody has commit access. You can do whatever you want to your project. You just get your own branch. You do great work or you do stupid work. Nobody cares. It’s your copy. It’s your branch. And later on, if it turns out you did a good job, you can tell people, “Hey, here’s my branch, and by the way, it performs ten times faster than anybody else’s branch. So nyah nyah nyah. How about pulling from me?” And people do.    (MRA)

And that’s actually how it works, and we never have any politics. That’s not quite true, but we have other politics. We don’t have to worry about the commit access thing. I think this is a huge issue, and that alone should mean that every single Open Source system should never use anything but a distributed model. You get rid of a lot of issues. (18:12-20:13)    (MRB)

Someone in the audience asked Torvalds whether the distributed model simply shifted the political questions of access rather than eliminated them, to which Torvalds replied: (MRC)

What happens is, the way merging is done is the way real security is done: by a network of trust. If you have done any security work, and it did not involve the concept of network of trust, it wasn’t security work, it was masturbation. I don’t know what you were doing, but trust me, it’s the only way you can do security, it’s the only way you can do development. (MRD)

The way I work, I don’t trust everybody. In fact, I’m a very cynical and untrusting person. I think most of you are completely incompetent. The whole point of being distributed is, I don’t have to trust you, I don’t have to give you commit access, but I know that among the multitude of average people, there are some people that just stand out, that I trust, because I’ve been working with them. I only need to trust five, ten, 15 people. If I have a network of trust that covers those five, ten, 15 people that are outstanding, and I know they’re outstanding, I can pull from them. I don’t have to spend a lot of brainpower on that question. (27:37-29:00) (MRE)

Power relationships exist everywhere there are groups of people. And if you don’t believe they should, you’re kidding yourself. Collective Intelligence, Collective Leadership, and more specifically, emergent self-organization are not about eliminating power relationships. They’re about empowering the right people at the right time. (MRF)