Open Source Mergers and the Circle of UNIX

Posted on Published by Eugene Eric Kim

Lloyd Budd wrote a post today entitled, “GPL Encourages Collaboration,” that was highly serendipitous and that triggered a flood of thoughts, some of which I’ll try to capture here. Earlier today, I was rereading an interview I did with Sunir Shah a few months back for a paper I’m writing, and I latched onto a point that Sunir made about the proliferation of Wiki communities:    (MHR)

I see so many people start their own Wikis. They go to these other Wikis that are disorganized. They don’t feel like jumping in and learning everything because everything’s in different places, and they are not coherent. So they start their own.    (MHS)

There are now thousands of public Wikis, and they are all balkanized, because no one wants to collaborate. I understand that. It’s human nature. You collaborate within your group, but you don’t collaborate outside of that group.    (MHT)

On the one hand, I encourage the proliferation of Wikis, because if you disagree with someone, you should be able to do your own thing. On the other hand, true collaboration is showing a willingness to actually pull these communities together, a willingness to subsume your immediate need to be a true leader, build relationships, and pull people together.    (MHU)

Sunir’s insight is an important one. The existence of a commons isn’t in itself enough to guarantee collaboration. Ultimately, collaboration is intentional. You have to want to collaborate with others, and you have to be proactive about it. And it only takes two for starters.    (MHV)

That said, if you want to encourage collaboration, you have to start by eliminating as many barriers as possible. The first barriers are Shared Understanding and Shared Language. In the Open Source community, both of these have been indoctrinated in the form of Open Source licenses. The main reason for the effectiveness of these licenses as vehicles for Shared Understanding is Richard Stallman.    (MHW)

When RMS originally wrote the GPL, he embedded the philosophy behind the terms in the license itself. It was not simply a legal document, but an essay on the principles underlying software freedom. Regardless of how you feel about the GPL or RMS, these remain the fundamental principles behind why Open Source works, and more importantly, why collaboration is so rampant in Open Source communities.    (MHX)

However, as Sunir notes, this isn’t enough to guarantee collaboration. We see a lot of redundancy in Open Source, just as we see lots of redundancy in Wiki communities. And that’s okay. There are sometimes good reasons for this redundancy, and it’s healthy to facilitate it. But eventually, you want convergence also.    (MHY)

This is the crux of Lloyd’s post. He writes, “Forking is good, but not as good as merging.”    (MHZ)

Lloyd also cites a few examples (WordPress, gcc) and asks for others. There are tons of good ones, but my favorite is a bit obscure: UNIX.    (MI0)

That’s right, UNIX. Yes, the history of UNIX is fraught with ugliness, some of which still continues today. But it’s also one of the greatest examples of Open Source forking and merging. This is important, because it’s also the birthplace of the modern Open Source movement.    (MI1)

Here’s the quick summary. UNIX came from AT&T labs, and the original license terms were ambiguous (a massive understatement if there ever was one) for a number of reasons, the main one being that most people weren’t thinking about software as IP at the time. Stallman, of course, was one of the exceptions, and in 1984, he started the GNU project, whose goal was to reimplement UNIX under the GPL.    (MI2)

A few years earlier at UC Berkeley, Bill Joy had taken a different approach. He simply forked AT&T UNIX into what is now known as BSD UNIX. The new code eventually was distributed under the BSD license, which essentially allowed anyone to do whatever they wanted with the code, as long as they gave credit to BSD and didn’t sue anybody. This led to many, many new forks, especially proprietary ones from Sun (cofounded by Joy), IBM, DEC, SGI, and many, many others.    (MI3)

With the advent of the 386 in the late 1980s came a number of PC forks, including 386BSD (which begat FreeBSD, NetBSD, and OpenBSD), BSDI, SCO, and MINIX (which begat Linux). At this point, most versions of UNIX were also borrowing heavily from the GNU project.    (MI4)

By the late 1990s, we started seeing massive convergence. IBM, Sun, DEC (now HP), SGI, and SCO (yes, SCO) all switched over to Linux, and started merging some of their proprietary capabilities into the Linux kernel. Apple moved to FreeBSD.    (MI5)

What the heck happened? You could attribute this phenomenon to market consolidation, but that would only be telling part of the story. Market forces indeed played a strong role, just as they a play a strong role in anything that involves… well, markets. But the important points are these. The ability to fork UNIX into both proprietary and free versions allowed the market to innovate rapidly, and that innovation was critical to both the success of UNIX and to the growth of the industry as a whole. However, the existence of a free version of UNIX was critical in enabling the consolidation of all of these different UNIXes, even if they weren’t necessarily formal mergers. Why were all of these competing companies willing to throw their hat into the Linux ring? Because of the Open Source license, which protected companies from their competitors hijaacking the commons and using their own code against them.    (MI6)

Ironically, the story of UNIX is also one of the reasons I believe that the GPL’s terms are unnecessary for the proliferation of software freedom. The BSD license enabled proprietary forks, which arguably enabled innovation that wouldn’t have happened otherwise. In fact, it’s still enabling this today; look at Mac OS X. In the end, however, culture won out; these same proprietary companies are all supporting Open Source software, not because they had to (although they do now), but because they wanted to. Empowerment is stronger than enforcement when it comes to communities and collaboration.    (MI7)

I can’t resist one more small rant, a teaser if you will. Most Web 2.0 companies seem to have learned the superficial lessons of Open Source, but they’ve missed the main point. The argument that Open APIs obviate the need for Open Source completely ignores what history has taught us over and over again. One of these days, I’ll blog about this.    (MI8)

Internet Identity Workshop 2007, Day Two

Posted on Published by Eugene Eric Kim

My big takeaway from this rendition of the Internet Identity Workshop (IIW) continues to be the growing maturity of this community as well as the influx of new faces. This manifested itself in interesting ways in Open Space today. As Phil Windley noted in his excellent synopsis of the day, almost half the room stood up to propose sessions, which was quite stunning.    (M9Y)

While there were a number of interesting topics posted, most of the ones I attended were more bull sessions than work sessions. That’s not a bad thing — talk is necessary for building Shared Understanding — but you also want to make sure that the folks who are in a position to work are working. And that’s what happened. There were a lot of ad hoc, project-oriented meetings and plotting happening outside of the sessions.    (M9Z)

This is a good lesson on the nature of Open Space, especially when these gatherings occur repeatedly in a community of practice. Norms emerge and evolve. Communities go through cycles, and the Open Space experience shifts with each cycle.    (MA0)

I managed to eavesdrop on part of a conversation between Lisa Dusseault and Lisa Heft about Open Space and this conference in particular. Lisa Dusseault was bemoaning the lack of Shared Understanding among all the participants, and explained that at IETF and similar gatherings, there was always a baseline of knowledge across participants, because there were papers, and people were expected to read them ahead of time. Pre-work is not anathema to Open Space, and it’s great if you can get folks to do it. In this particular community, I think it’s possible. But you still have to be careful when considering other ways of designing for this challenge.    (MA1)

A few weeks ago, Al Selvin told me about his experiences at CHI conferences. The first time he went, he was new to the field, and it was a wonderful learning experience. The following year, he attended again, and the experience was not as good. Why? Because it was essentially identical to the previous year. People were basically the same things as they had before.    (MA2)

What’s the difference between what happens at Open Space versus most academic conferences? Co-creation — aka collaboration aka real work — is a key part of the process. People, both old and new, get together to evolve their Shared Understanding and something new and wonderful emerges from that. You have both learning and co-creation, which are really two sides of the same coin. Sadly, many conferences are all about one-sided coins.    (MA3)

I think there are ways to make the first day even more effective for new members of the community. We heard some great ideas for this at Kaliya Hamlin‘s session on this topic, and I expect her to do great things with this feedback.    (MA4)

Speaking of community, I held a session on Identity Commons. A lot of folks who have been active in the creation process participated, as did key members of our community. One of the things I wanted to make crystal clear to folks was that ultimately, Identity Commons was simply the name of this community. As it happens, this name represents both the intent and values of this community (or in chaordic speak, the purpose and principles). What’s really unique about our values is how we collaborate with each other. There is in fact a legal entity called Identity Commons, but it is extremely lightweight and open. It’s sole purpose is to manage the shared assets of this community in an open, grassroots way.    (MA5)

The organizational elements of this entity are fascinating in and of themselves. The challenge that most organizations like Identity Commons face is, how do you embrace an identity (which implies creating a boundary between you and others) while remaining open (keeping that boundary permeable and malleable). (Boundaries and identity as they pertain to leadership were major themes at the Leadership Learning Community Evaluation Learning Circle last January, yet another instance of all my different worlds colliding.) Complicating all of this is the challenge of sustainability.    (MA6)

In order to make decisions, a community must define who its members are. Most organizations define membership as some combination of vetting, voting, and payment. I believe that a pay-to-play membership model is the main source of problems most organizations like these face. It’s simply a lazy approach to sustainability. There are other ways to be sustainable without destroying the integrity of your community.    (MA7)

I could go on and on about this, and I eventually will, but not right now. The challenge we currently face is that the growth of the community outpaced the reformation of the new Identity Commons. While we were busy gaining a collective understanding of what we were trying to do, a process that took well over a year, the overall community grew on us. Now, we’re faced with the challenge of getting folks to think of this community as Identity Commons, rather than as some entity that a bunch of folks are working on. I like to call this going from “they” to “we.”    (MA8)

Conversations with folks about this today made me realize that I was overthinking the problem. (Shocker!) The problem is as challenging as it was before, but I think the solution is relatively straightforward: good ol’ fashion community-building, starting with the existing social network. As complex and multilayered as all this stuff is, I think we can keep the message simple, which will greatly aid our cause.    (MA9)

Miscellaneous thoughts from day two:    (MAA)

  • I chatted with Larry Drebes of JanRain about Pibb, and he assured me that they would be adding Permalinks soon, as well as other cool features such as export. Call me a convert. Now I’ve got to remember to talk to them about the perplog vision, and how those ideas could be integrated into Pibb to make it seriously kick butt. I’m also going to evangelize at RoCoCo (RecentChangesCamp Montreal) later this week.    (MAB)
  • I am really impressed with how much OSIS has accomplished over the past six months. Kudos to Dale Olds and Johannes Ernst for their leadership on this project, and kudos to Dale and Pamela Dingle for a really cool interop code session this afternoon. Despite some difficulties with the wireless, it looked like they got a lot of stuff done.    (MAC)
  • Brilliant move on Kaliya’s part to invite Open Space facilitator Lisa Heft to participate. She’s an outsider to this community, but she’s a wonderful observer of people, and it’s been great hearing her take on things. She’s also performing a nifty experiment which will be unleashed on everybody tomorrow afternoon.    (MAD)
  • I chatted a bit with Kevin Marks this evening about microformats and his experience as a new Googler. When I think of Kevin, I don’t immediately think Google, but he does work there now, so technically, Google was represented at the workshop. Ben Laurie, another Googler, has also been an active participant in this community. However, as much as I generally love Google, I have been extremely disappointed in its overall participation and presence in the identity community. The Google identity experience is one of the worst on the Internet, which is all the more notable when compared to its consistent track record of superior web experiences. It’s also using its own proprietary identity protocols, which is a travesty. There are good solutions to all of this, and yet, Google has thus far ignored the quality work in this community. I’d love to see Google adopt OpenID, but I’ll settle for more folks involved with identity at Google simply participating in this community.    (MAE)

The Fractal Nature of Large-Scale Collaboration

Posted on Published by Eugene Eric Kim

Collaboration is a meta-discipline. It is usually the means, not the end. You don’t collaborate for collaboration’s sake; you collaborate to accomplish some bounded goal. Making the means the end is tricky business. When you eliminate the context, it’s easy to shift from thoughtful practice to ivory tower jibber jabber and suffer the consequences of Professionalization. All communities and networks centered around meta-disciplines are vulnerable to this, including Blue Oxen Associates. It would not be an exaggeration to say that this is my foremost challenge as a social entrepreneur and as a scholar-practitioner.    (M65)

Being meta also has its benefits, however. Over the past few years, I have been helping more and more groups with the conundrum of being a top-down, command-and-control organization in a heavily network-centric world. Sometimes, this takes the form of coaching, where I talk the organization through principles and provide encouragement through what can be a painful and frustrating process. My approach is to tap into the existing organizational instinct and experience as much as possible while challenging assumptions by identifying and asking deep, underlying questions.    (M66)

Other times, it takes the form of designing a convening. These convenings play the same role as my coaching does, except it accelerates Shared Understanding among the stakeholders and it leverages Wisdom of Crowds.    (M67)

Here’s where the meta-ness of the collaboration business becomes useful. The act of co-designing a highly interactive convening, then experiencing it first-hand is a smaller-scale representation of the steps an organization would go through to transform itself into something more network-oriented and collaborative. Even though these convenings are smaller than the large-scale challenges that these organizations face, the principles are the same, whether you’re dealing with 20 or 20,000 people.    (M68)

These convenings are never meta. They are always about something concrete that is directly relevant to the organization.    (M69)

They start with the principle that everyone has different worldviews, but shares strong values. They facilitate interactivity, artifact generation, and continuous resynthesis of knowledge.    (M6A)

They don’t try to control participants. Instead, they let the right path emerge. They allow subgroups to form, to be creative, and to explore their own ideas and interests, without losing The Red Thread of the network as a whole.    (M6B)

By helping organizations design, then experience these convenings, I am indirectly helping them understand how to transform their organization in an experiential way. That’s a direct result of both the fractal nature of large-scale collaboration and the meta-ness of being in the collaboration business.    (M6C)

Voting, Collective Leadership, and Identity Commons

Posted on Published by Eugene Eric Kim

Thanks to next week’s Creating Space, Collective Leadership has been on my mind a lot recently. It’s also been a key element of the new Identity Commons. One of the issues we’ve been grappling with is decision-making. To understand why this is a challenge, you have to understand the underlying structure and philosophy of the organization.    (M5R)

Ultimately, Identity Commons is a Community Mark that represents a set of values concerning Digital Identity. It’s a name bestowed on the community of folks who care about User-Centric Identity. If you care about this stuff, then you are part of Identity Commons. There is nothing to join, and you are free to use the name and logo as a way of demonstrating your support of these values.    (M5S)

Why this is such a powerful and important construct is a topic for another day. What’s interesting about this particular community is that there’s also a corresponding legal structure, a nonprofit organization that is in the process of being incorporated. This organization consists of community “Stewards” — people appointed by the community to represent the interests of particular sub-communities (“Working Groups”) and who are responsible for managing the tangible assets of the commons. There are rules for becoming Working Groups and Stewards, but they are extremely lightweight.    (M5T)

All of the Stewards comprise a Stewards Council. Each Steward has an equal vote on all matters. There is a Chair, but that position is mostly facilitative. There is also a Chief Catalyst, someone (not necessarily a Steward) who is responsible for handling the operational duties of the organization and catalyzing action in the community.    (M5U)

It’s a fascinating, but delicate structure. The Stewards Council has an important leadership responsibility, but that role is distributed equally among all of the Stewards. How do Stewards exercise leadership effectively given this structure? Decision-making via voting is clumsy in many contexts, and yet that’s the only process that we’ve actually defined.    (M5V)

We’ve had a number of interesting conversations on the topic, and the latest discussion recently surfaced a lurker, Martien Van Steenbergen, who cited an interesting reference on holacracy. Martien quotes the following excerpt (emphasis his):    (M5W)

Another common question is about the “possible votes” in integrative decision making. At first it can sound like there are two possible votes on a proposed decision — “consent” or “object” — though that’s missing a key point. Consent isn’t about “votes” at all; the idea of a vote doesn’t make sense in the context of consent. There are no votes, and people do not vote.    (M5X)

People do say whether they know of a reason why the proposed decision is outside the limits of tolerance of any aspect of the system, and then decision making continues to integrate that new information. This isn’t the same as most consensus-based processes — either in theory or in practice — although it does sound similar at first, especially before an actual meeting that seeks consent is witnessed.    (M5Y)

This quote is keying on the difference between Collective Leadership and consensus leadership. They are not the same thing. With Collective Leadership, you are acknowledging the multi-faceted requirements of leadership, and you are empowering those best suited to meet those requirements to fulfill that leadership role. You are not voting on every decision, which would be a sure path to disaster.    (M5Z)

One of the ways this manifests itself is by making decisions “without objection.” This is a technique from Roberts Rules Of Order that Joaquin Miller brought to our attention. Essentially, you empower people to act, unless someone in the group objects, at which point an alternative process kicks in. Everyone still has a voice in the decisions, but it is a proactive rather than a reactive style, and it encourages action rather than stagnation.    (M60)

I believe that when you have great collaborative process, voting is a rubber stamping process, even when the topic is controversial. In other words, the actual decision-making process starts well before any vote happens. Healthy deliberation results in Shared Understanding, which in turn helps to surface clear courses of action that navigate through the obstacles of contradictory ideologies. When there is pressure for movement (another pattern of high-performance collaboration), then people will rally around those courses of action.    (M61)

Being Ambushed by Terrell Russell

Posted on Published by Eugene Eric Kim

Gail Taylor told me an excellent story last Saturday that reminded me of an incident at the Internet Identity Workshop this past December. I was doing something that I am deeply opposed to — participating in a face-to-face conference without being fully present. Basically, I was sitting in the middle of the space doing work on my laptop while everyone else was participating in the conference. I felt guilty about it, but I wanted to talk to some people while they were in town, and I had a ton of work to do at the same time.    (LWP)

So I gave a talk on Identity Commons, attended a few presentations, talked to a few people, and spent the rest of my time doing my work and ignoring everyone else. It was actually quite nice. I was sitting in the middle of the large conference room at the Computer History Museum, visible to everyone, with people constantly milling around me. People who knew me stopped by to chat for a few minutes; people who didn’t just ignored me.    (LWQ)

Towards the end of the second day, I was basking in my productive anti-socialness, when a fellow who was sitting at my table started making small talk. It was harmless chatter, stuff that I could respond to while remaining focused on my work, but at some point, it felt wrong continuing to talk without introducing myself. Turns out the guy was Terrell Russell of claimID fame. I knew about claimID, but I knew nothing about Terrell. The same could not be said of him, who had known all along who I was, and who apparently follows this blog. (Hi, Terrell!)    (LWR)

That bastard must have used that knowledge against me, sharing ideas that he must have known would suck me into conversation. Either that, or he was just a nice guy who was passionate about his work. Either way, it worked. I ended up closing my laptop and having a great conversation with him.    (LWS)

What was he doing that I found so compelling? It was his Ph.D. research on Contextual Authority Tagging. The basis of the idea is simple: The best way to identify an authority on a topic is not to ask people to self-identify themselves as such, but to ask others to identify the people they consider to be the authorities. We can leverage this principle to locate expertise by building tagging systems where users tag other users with information about their expertise.    (LWT)

Terrell has thought really deeply about this, and several of his ideas are documented at his website and on his blog. Phil Windley and David Weinberger have also commented on his work.    (LWU)

I heard more original ideas about tagging in that 20 minutes of conversation than I’ve ever heard from anyone else. The one that really struck me was the notion of tag disparities: comparing what people say about you to what you say about yourself as a way of measuring reputation. Sound familiar? It’s a real-life instantiation of the Squirm Test!    (LWV)

I think there are some interesting tools that can be built on these ideas, and I have no doubt that Terrell will build them. There are also some face-to-face group exercises based on these same principles, and I’ve actually done one of them before (described below). You could also apply these ideas towards group evaluation.    (LWW)

I’ve been vividly reminded of our conversation on two occasions. The first happened later that week at the Blue Oxen Associates anniversary party. Peter Kaminski decided to do some social engineering of his own, and instead of asking people what they did, he asked them to tell him about someone else attending the party. Real-life, face-to-face, Contextual Authority Tagging! We actually did this for real at the 2005 anniversary party, where we had people literally stick name tags on other people’s back. It was an idea I stole from Chris Messina, who in turn had stolen it from a previous SuperHappyDevHouse gathering.    (LWX)

The second occasion happened this past Saturday. Gail recounted a story about a group exercise with five people, where each person was asked to write ten words that have to do with “love.” Out of the 50 total words, only three were the same! It was a stark lesson on how challenging it is to achieve Shared Understanding and how critically important Shared Language is.    (LWY)