Section 17.4. The Difference Between Doing Legal Research in Public and Writing Software in Public

17.4. 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 projecta summary pageand 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 thatwhile sounding superficially plausiblewere 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.