Open Sources 2.0/Beyond Open Source: Collaboration and Community/Extending Open Source Principles Beyond Software Development

From WikiContent

< Open Sources 2.0 | Beyond Open Source: Collaboration and Community
Revision as of 19:06, 5 May 2008 by Docbook2Wiki (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
Open Sources 2.0

Pamela Jones

It starts with an idea.

Linus, for example, realized that if he put his kernel project online, people all around the world could work on it together, without having to be in the same building. They could quite literally write software in public that way, scattered around the world though they were.

Understanding such simple things changes the world sometimes.

But what about other areas? Is it possible to extend that same process to other kinds of work, or is it suitable only for software development? One thing can now be said for sure: legal research can be done that way. Groklaw is the proof of concept. But as I will explain, you need to tweak things just a bit.

I've done legal research for a living as a paralegal, and now I've done it with the world as a Groklaw volunteer, and I am therefore in a position to make comparisons. I think any company involved in any legal dispute that touches on technology could profit from using the open source method to tap into the community's group knowledge pool.

I'm a good researcher, and I do excellent work, but I know without a doubt that the input from thousands of readers made a huge difference in what Groklaw was able to accomplish in digging up helpful information in the SCO litigation.


How Did It Happen and How Does It Work?

When I began, it was just l'il ol' me. I had read Slashdot enough to know that while there was a high level of technical knowledge in some of the site's readers, the level of legal knowledge was low. I also saw there was a hunger to understand the law. Technical information that could influence the outcome of a lawsuit was available there, but it was not reaching the attorneys. And legal information that could help techies know what to dig up and helpfully provide was not readily available to the FOSS community.

At the beginning, I was trying to learn how to blog, because I had a job interview for a freelance assignment helping an attorney with his legal blog. You have to write something if you are blogging, so I decided to write about what I knew best, which is legal research. It felt private, like a diary, and I didn't think anyone would find what I was writing about or care much if they did.

I wrote to the air, thinking no one would read it anyway, and I horsed around, finding funny graphics for as many of the entries as I could, but it was just for fun, just to learn. I eventually chose to focus on the SCO v. IBM case because it appealed to my sense of humor and stirred my hatred of injustice, and because I knew quite a bit about the GPL, as it happened, and I knew SCO was going to fail on that part of its claims. I was also quite confident that Linus was not going to infringe on anyone's code on purpose. So, every day I'd add a little bit more to the story, as I saw news stories about the case and SCO's claims. I wrote as though I were talking with a good friend over dinner who asked me, "So, what's this SCO case all about? Is there any chance they could win?"

I didn't dumb anything down, because I wasn't thinking about an audience anyway, and I went into the research I was finding as deeply as possible. It did occur to me that I might find some things that would be helpful to Linus and to IBM—I figured IBM might have a service that scours the Net to find IBM-related stories—but that was the extent of my ambition. I knew most attorneys don't know a lot about computers or Linux or the GPL, and I knew a fair amount about them all, so I felt like I was throwing a message in a bottle out into the ocean, just hoping someone would find it and it would be useful.

After a couple of months, I got an email from a stranger, asking if I could please make the graphics smaller, because he was in Europe on dial-up and the blog took forever to resolve. He sent me instructions on how to do it.

Until that email, I had never bothered to read the stats on my site, even though Radio Userland, the software I started blogging with, provides them. I come from a family that has very little interest in computers, and I was used to people being emphatically uninterested in things I find fascinating, I didn't expect even my mother to read my blog. So, when I got the email, I was floored. I wrote back that I didn't know anyone was reading what I was writing, and he told me that lots of people read Groklaw, and that the community appreciated very much what I was doing. I was simply floored. I think I will remember that feeling until the day I die.

I looked at the stats and found out hundreds of people were reading what I was writing, apparently regularly. I turned on comments and, little by little, information began to be offered, particularly when I would ask for it, which I did more and more. Radio Userland also has stats on where your readers come from, what web site they visited before clicking on your site, and what I saw from that was that my readership was consistently growing, it was all word of mouth at that time, and the caliber of reader was very high. It included a high number of lawyers and programmers and professors at universities, from all over the world.

Finally came the idea. I had dug up some information about a Linux kernel author who made contributions to the kernel while an employee at Caldera, and when Slashdot put that article up on its site, the first time that had happened to Groklaw, the number of readers exploded. Even better, they had more information to offer. One would find an old press release, another an article from five years ago, another a speech by an executive, and so on.

When I saw that start to happen, I created a Legal Links page (, with links to legal resources, and started pointing to articles explaining things like copyright and patent law, things readers needed to understand so as to know which article or which press release detail mattered.

I realized then that Groklaw could be a bridge between the tech and the legal worlds, and that if I explained clearly how the court system works and what kind of evidence is valuable in that context, the community would find it, add what they knew, and it could work. The necessary pieces were in place. And I suddenly but totally understood the power inherent in this process of open, group effort. It felt like trying to ride a giant wave, as opposed to trying to turn on and then direct a stream of water in a particular direction. It had a life of its own, and my job was to try to follow the flow, not control it.

We found more and more. The readers built on each other's knowledge, and I learned that way too. My email level shot up also, as readers more and more began sending me tips and links and information. At the time, reporters were faithfully writing down every word the SCO folks spoke and reporting it as if it were all true, so I began reaching out to journalists. As we found information, I sent it to journalists, and some, to their credit, responded; some immediately, others over time.

Working as a Group

The first group project, in the sense of planned action, was to help everyone know how to write to journalists and editors so as to get good results. The FOSS community is not a group of phonies, and they tend to speak their minds. Also, a lot of us geeks are not socially skilled, so sometimes journalists would tell me how offensive the email they got had been. So, I put up on Groklaw examples of good letters, letters that did not offend, and the point was well received, so much so that I had two journalists remark that they never got any flames or nasty email from Groklaw readers.

At one point, we decided that someone should answer Darl McBride, CEO of SCO. He had written an open letter to the open source community. I asked if my readers felt like writing a response, and they did, so we worked on it online together, in the open. After all, his letter was addressed to us. Ideas would be left as comments, and then I'd incorporate them into the letter and post the next version; Then readers would suggest tweaks and more data, which I'd then incorporate and post the next version, until we were all satisfied. It took about two weeks. The Inquirer, which had been watching us create it, offered to post the letter and an accompanying collection of research supporting the points we had written on its web site.

This was very helpful, because by then, so many comments were being placed on Groklaw—hundreds more than any other site on Radio Userland—that the software was struggling, and we were afraid that if we got any more traffic, we'd simply melt off the Internet. That letter led to another growth spurt of Groklaw members, and at around that point, we simply had to move to larger quarters, and ibiblio graciously invited us on board after a Groklaw member wrote them to petition on our behalf.

It was still the early days, back in the fall of 2003, and we hadn't yet attracted many trolls or astroturfers, which is why it all worked so well. We were a group of like-minded people, all striving toward a common goal. No one cared a bit about credit, only results, and it was refreshing, even if it was one of the hardest things I've ever done.

What did I learn? That there truly is wisdom in crowds, and that you can rely on someone in such a group thinking of everything you truly need. Also, that somebody has to be willing to work harder than everyone else and be the final arbiter, or nothing ends up getting done. Later in Groklaw's development, there were other lessons to be learned.

Dealing with the Disrupters

As Groklaw became more popular and began winning recognition, along came the deliberate disrupters. I got my Ph.D. in trolls and astroturfer, you might say, so I'll share with you some things I learned in the University of Trolldom and Astroturfing, because it has a bearing on whether an open legal research project will succeed or fail.

Here's what I know. Trolls are mean. I can't stress that enough. If they see you trying to go to the right, they push to the left. Then they place comments whining that you won't go to the left or insist you ought to be going left but are going right when you shouldn't be. It doesn't matter at all that you are correct in wanting to go to the right. It doesn't matter that it's your decision to make. It doesn't matter that they are interfering with the work you've set out to accomplish. They are spoilers, and the bigger the blotch they leave on your page, the better they like it. There is nothing to do with a troll but delete his comments when you are sure trolling is the purpose. If you are weak in the knees and can't bring yourself to do that, trolls will destroy your open group project. It's that simple and clear. They enjoy destroying what you want to do.

When the open source project is legal research, you also must expect that the side you are working against will show up. They won't be wearing an ID tag. They are essentially spies. Here's how you will know: they work harder than anyone at first, and when they think you are lulled, they try to destroy your reputation and maybe your life, if they have the resources to do so. The interval when they are helping, however, has one purpose only: to gather information to use against you later and to form relationships with your volunteers, so they can undermine from within. It's absolutely essential to identify and either eject or corral such individuals. I can't explain how to do this in great detail until after the SCO wars are over, but it's not impossible to do. Of course, you need a strong stomach and a bit of a tinfoil hat.

I will give just one example. The very first such individual showed up when Groklaw was very new. He began by attacking Linux, then pretended to have an epiphany thanks to Groklaw, and then tried to stir my readers into unhelpful actions. For example, he suggested that everyone send Darl McBride certified letters protesting his actions. Certified letters. Right: SCO would have everyone's address.

Another time, he suggested everyone go to court in Groklaw T-shirts and take PDAs and phones to record the session, which they could stream to Groklaw live. That, of course, would have been a problem. First, the T-shirts would have made participants look undignified, but it would also have made them easily identifiable. This was not helpful. And recording a court session is a violation of court rules. I could just see the headline, so I had to put the kibosh on that fast. I did so by deleting his comments.

I know someone will put up a web site all about this now, but I don't care. You need to know that such things will happen, and you must be ruthless in making sure such individuals don't take over. They will try. Some will be fooled and will criticize you for stomping on the spy's ideas, which he will offer with so much mock sincerity, it isn't hard to comprehend how others accept it at face value. You can't explain publicly that you researched the individual and are reasonably sure they are a spy, and you must just take your lumps. Let them put up web sites. In the end, what matters most is that they are isolated.

Astroturfers are sometimes of that same mind, but usually they just want to steer the conversation their way. They don't want to be kicked off, so they are subtler. We have had a number of astroturfers. I call them the "I used to love Groklaw, but" crowd. Some of them look, at first, like spies. They work harder than anyone, take in all the info they can about you and how you work, and then—diverging from the spy path—they try to steer your project their way. If they fail, at some manufactured moment they publicly find fault with you and your work and loudly make their grievances known to the world, using your own web site and others to try to destroy your reputation. Sometimes they'll put up whole web sites about it. They're mean too, but it's just a job. Nothing personal. They just play-act the emotion.

All three groups will, sad to say, appeal to some of your readers. They deliberately manufacture issues they know will draw followers. If you leave their comments on your site, they will take over the conversation and readers will leave in disgust. If you moderate them away, they will loudly proclaim their love for freedom of speech, and some will join them, not realizing they are being played like violins. The purpose is to destroy your project and make sure it never succeeds. This is something that rarely happens in Linux kernel development, and in my experience it requires tweaking the open source process just enough to keep getting your work done.

Deciding what goes into the Linux kernel is a breeze in comparison to deciding whose ideas can be trusted in doing legal research. You must trust your instincts, and it is one of the most important reasons the majority can never rule when doing research.

The Difference Between Doing Legal Research in Public and Writing Software in Public

I mention all this because if you are doing legal research in public, sometimes you can't say in the open all you might say privately or if doing legal research for a firm. Parties are in litigation really don't want to show the other side their cards until trial, as you may have observed in the protracted discovery wars between IBM and SCO.

You may have an idea for an avenue to research, for example, but you don't know what the result of your research might be. If it is negative, it might not be wise to present the news that you are researching this area until you know what you have found. Sometimes information that seems negative, upon deeper digging, turns out to be helpful, and you very much might want to wait to tell the world all about it. It isn't a matter of hiding information; it's more a question of timing and presentation.

Someone in a legal research project has to know what to keep private and what to make public. There is a great deal at stake, and the outcome can be affected by the decisions you make. That simply never happens in developing the kernel. So as time went on, I built up a feel for whom I could trust in an inner circle of advisers, for both legal and technical research. No one person can do everything, so spreading out the responsibility is vital.

I view the most beneficial structure for such work as a kind of pyramid, where anyone is free to contribute at the bottom of the structure, but as the information moves up the chain, it finally has to go through one or a few at the top of the pyramid. In my experience, that person or persons must be able to say no and mean it, come what may. They must know enough about legal work to intelligently decide what should and should not be published and in which direction to take the work next. And they have to have thick skin, because criticism is sure to come from those who wish to turn the process upside down and have all decisions made by some kind of democratic vote. Linus doesn't even do things that way, but some will be sure he does and will try to make you follow such a setup.

Perhaps that works in other fields, but in my experience it doesn't in legal research.It probably would work beautifully if all the volunteers were lawyers, paralegals, and professors. Or it might work if your geek contingent didn't vote on legal issues, only tech issues. Otherwise, you are doomed, because it is hard for those who aren't legally trained to realize just how complex the law really is, and when they learn a little, they sometimes think they know enough to begin running the process. A little knowledge can actually be worse than none at all, especially when accompanied by a lack of humility. I could write three chapters on this subject, but I'll spare you.

The reverse is true for me with tech decisions. I know I am not the expert there, so I never make those decisions. I trust reliable lieutenants to decide such things, and I listen to my readers very carefully.

It's the same with deciding which stories to mention and which to ignore. Part of Groklaw's purpose is antiFUD, but there is so much of it, what do you cover? I've learned to trust my readers' opinions on this, and if I get a lot of email about a story, I know it matters, even if I didn't think so originally. So, there is a kind of group decision-making.

In many ways, it's not unlike the kernel process, but there are elements of necessary secrecy in legal research that you don't have in programming. No one is likely to sue you for what you post about the kernel, but someone very well may over open legal research.

For example, we tried a second public group project—a summary page—and the troll-astroturf contribution was so high, I was afraid of being sued, because they left outrageous comments that I frantically scurried to get rid of, and they presented ideas that—while sounding superficially plausible—were actually designed to take the work in a direction that would undermine the effectiveness.

Eventually, we had to take the work private, which was not a huge problem, because by then I knew who was skilled at this kind of thing. Groklaw is a meritocracy. I leave the structure loose, so anyone can volunteer to do anything they feel like doing, but over time, I notice whose work is most useful, and others usually agree.

Still, it's an unfortunate thing that we had to do that project behind the scenes, because we had to limit ourselves to only those we already knew, which is not desirable in an open project. The workaround I've found is to do the fundamental work with known and trusted volunteers, and then post the results for comment and tweaking by the public at large. That keeps the door open to some brainiac newcomer, which you want, but it doesn't let spies and disrupters ruin things, which you don't want.

Why and When It Works

I don't think the process would work as well for a less, shall we say, inspiring case.Volunteers responded because they seriously cared about the outcome, not because they found learning to do legal research fascinating. I have gotten a lot of email about enjoying the learning, actually, but I also know that SCO was an inspiration. For some, watching an attack on Linux is like watching someone kick Dorothy's dog, Toto: people get mad and want to do something about it. You don't get the same response in all cases or by paying people. There isn't enough money in the world to pay me for the amount of work I donated to Groklaw, the nights without sleep, the anxiety, or the jerks I had to deal with sometimes, if I may speak plainly.

But it isn't by any means the only case I or my readers care about. Patents and standards also interest the FOSS community and should there eventually be a patent infringement attack on Linux or GNU/Linux, as I believe there will be, I know for sure that the community will react and be available to help. I hope and expect that Groklaw will be ready to be useful again, perhaps in doing prior-art searches, for example, which could definitely be done completely in the open, in contrast to the legal research in the SCO case.

I also know that if a company had a tech issue and needed to tap into the Groklaw group mind, they could simply place the issue as a comment, and readers would tell them whatever they knew. The encouragement on Groklaw is that you provide either a URL or personal experience to back up the thoughts you've expressed, so that anyone can follow the thread and prove or disprove it. That is vital. It lets everyone know that what they comment about is important, that they must stand behind what they write and be responsible to be careful.

The power of applying open source principals to legal research is real. I've lived it, and I feel it. It worked because no one knows as much as all of us together. There is no law firm in the world that can afford to hire the numbers of researchers Groklaw made available. And a small group of trained paralegals would not have been able to find all the technical information that we at Groklaw found together.

So the bottom line is this: as long as there is the heart and the will to do it, the open source process is effective in doing legal research. If you would like to experience it in action, come and join in the fun.

Personal tools