Open Source – Page 2 – Eugene Eric Kim

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)

FLOSS Usability Sprint Seeking Great Usability Practitioners

Published October 24, 2007 by Eugene Eric Kim

FLOSS Usability Sprint V is happening November 2-4, 2007 at Google in Mountain View. This one is special for a number of reasons. First, it’s the fifth one. Second, our project list is once again superb, including Firefox, Chandler, Socialtext, and WiserEarth. Third, it’s the first sprint being primarily organized by members of this burgeoning community: Daniel Schwartz and Jon Slenk. (MO7)

The goal of these sprints is simple: Make Open Source software more usable, focusing especially on software for social benefit. Our approach is to bring catalyze collaboration between the usability and open source communities. The sprint takes place over three full days (November 2-4). It’s fun, it’s intense, and it’s gratifying. It’s a fantastic way to meet and work with an amazing group of people. (MO8)

This sprint is shaping up to be really outstanding. We’re still looking for a few great usability practitioners to participate, so if you’d like to help some socially-oriented Open Source projects in a concrete way, please sign up. And please spread the word! (MO9)

MySQL, Open Source, and Trust

Published August 10, 2007 by Eugene Eric Kim

When Jonathan Cheyer wasn’t working with me and Brad Neuberg on HyperScope, he was scrapping away at his day job as Solid Information Technology‘s Open Source community manager. Despite having to deflect my endless teasing about revoking his hacker membership card for becoming a “marketing guy,” he’s been an excellent source of stories and insights about the nature of Open Source communities and collaboration. (I’m less concerned about his hacker cred than I am about him being a die-hard Celtics fan. Sad, very sad.) (MII)

Jonathan recently blogged about some controversy surrounding MySQL AB‘s decision not to distribute source tarballs of its Enterprise Edition. Why is this seemingly minor move such a big deal? He explains: (MIJ)

It’s about the importance of being earnest in what you do. Being an open source company is about a lot more than just slapping a GPL license on your software and handing it out. It’s about building a relationship with the community that is using, playing, testing, and improving your software. As anyone who is married knows well, this can only be done through ongoing, continual trust and transparency between the two parties. Trust is built by being dependable, and by telling the other person things that sound honest and real. Trust is improved by transparency, which is opening yourself to the other person. Adding an artificial means of inconvenience to the community in obtaining bits does nothing to help customers and only reduces transparency as seen by the community. (MIK)

I’m amazed at how often good companies with a strong understanding of Open Source forget this. I think it’s indicative of the ongoing tensions that businesses must balance, and it speaks even more favorably of companies that manage to consistently uphold their Open Source values even in the face of these difficult tensions. (MIL)

I don’t have any first-hand insights into MySQL as an Open Source project. I do know that it’s been a model in the community for doing commercial Open Source for a long time, and I know a bunch of great folks who are involved in that community, Jonathan included. Jonathan sums it up best when he writes: (MIM)

MySQL AB has been working with the open source community for a long time and a lot of good things have been accomplished as a result of that. There is much to applaud. Along the way, there have been occasional mistakes, and this is one of those times. MySQL risks alienating a community that has been very supportive of them by a misguided move in in their quest to “get more customers”. Make money, make as much as you can, but while you do, don’t forget the lesson of being earnest in your endeavors and staying true to your community. (MIN)

Open Source Mergers and the Circle of UNIX

Published August 7, 2007 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)