Editorial:Open Source Isn't Commons

Robert Levin has written a response to Yesterday's editorial on the Tragedy of the Commons. It's an excellent rebuttal.

What follows is an Editorial by Slashdot Reader Robert Levin

When Chris Marsten talks about the "tragedy of the commons", he's missing an important point. Neither the open source community nor the body of code it creates is a "commons."

The "tragedy of the commons" is an old problem in politics and economics. It describes what happens when a limited public resource is overutilized by the public; when even a single user can foul a public waterway or dump toxic waste in a village square. When a limited resource is owned by everyone, it's owned by no one. No one is responsible for preventing its overuse.

The open source community is not a commons. People in the community work on software because doing so meets their personal goals. Maybe they enjoy writing code. Perhaps they need to learn to code better. Quite likely they plan to use the program they are working on in their personal or business life. And many people just enjoy being part of a community, or just want the recognition. For most people, several motivations apply. Certainly there are people who write open source software for altruistic reasons; but I've been part of the community for 5 years, and for most of the developers I talk to, altruism is the icing on the cake.

But what about the product of the community? Is open source software itself a commons? Can users "foul" the product by using it and not giving anything back, or by asking for too many features? Can developers foul the product by providing too many features, or by creating multiple projects working on the "same" ground, or not working on the "right" things? I would argue not.

Developers work on open source because doing so advances their personal goals. They give it away because, at the very least, doing so causes them no harm. If I work on a project because I enjoy coding, I'm not planning on making money by selling it. I can give it away without losing anything. If I need to learn coding better, giving the code away is a clear win. People will comment on how it works for them. If I need the program for home or work, giving it away gives me a source of bug reports and patches.

If I produce a program people want, there'll be a market. People will use the program. They'll want fixes and new features, and they'll send in bug reports and feature requests. Bug reports help me fix problems, which is always a win. Feature requests give me more work to do---but if I have enough users, some will be programmers, and some will be good programmers. There will be people motivated to help me.

If I use my own program (how many developers in the community don't?), I'll want to enlist other people to help me turn out product. If I'm a good manager, the project will prosper; otherwise, someone will take my code and start a new project, with or without my assistance, and the users will flock to their door.

Is there a problem? Not so far. But what if several competing projects have similar goals? Isn't that wasteful, when programmers could be working on so many useful projects no one has yet started?

Who decides what projects are useful? Developers decide, and their decisions are ratified by their user base. This must be so. We've talked about what motivates developers, and the motivations are personal. It's all very well to talk about how "we must allocate the time of open source programmers efficiently," but programmers in our community are not objects. They come with their own motivations. If a developer thinks he should be working on his own project, he's going to work on that or, in most cases, nothing at all.

You can say that we don't need two desktops, so the Gnome people should continue, and the KDE people should pack it up and start working on a Kaliedoscope clone, but who died and made you god? If you want a Kaliedoscope clone, work on it yourself. If there's really a market for it, you'll get plenty of help.

But aren't there just so many programmers to go around? Shouldn't we allocate our programmers' time efficiently? Leaving aside the practicality and ethics of someone telling open source programmers what to work on (you can't do it, and you have no right to do it if you could), I don't buy into the limitation to start with. There are maybe 5-10 million Linux systems installed worldwide. This is a drop in the bucket compared to the number of Windows users, a percentage of whom are quite accomplished coders. And how many of those people could learn to code in the next ten years? Events like the Netscape open sourcing introduce a lot of people to the idea and benefits of open source. Efforts like Gnome will make Linux easier to use, which can only expand the base of users. Not everyone needs to program, but in a larger user population we'll find the people we need. Help's coming.

"Malignant featurism" is not a problem. If enough people use a program to make it worthwhile, there will be people to write the features. Too many applications? Give me a break. People will flock to use the applications they want, and again there will be plenty of help in coding. Thousands of half-coded apps, and too much diversity? Be real. If people used all of those Enlightnment themes, they'd get finished. Half-completed apps are a sign of lack of interest. The community allocates its effort to the projects it finds useful. Draw your own conclusions.

Should we shoot the next person to put out an X toolkit? I don't think so. Everyone who puts one out thinks theirs is the best. Let the users decide. If they like the toolkit, if they like the license, they'll use it. There's plenty of programming support out there for projects someone really wants, and there'll be more. To think otherwise is naive. This is free software, and where you find users you'll find support.

Free software is not a "commons." It is not based on altruism. It is a system whereby people achieve their own personal goals. Recognition is important, but it is not the goal of free software, it is the currency of free software. When someone does good work, they're recognized and people become interested early in their next project. But unless they meet the needs of their community, that next project will founder.

Is the system unstable? Not as long as people understand the motivations of the participants. If you think a project is important, work on it yourself. If you don't get any help, understand it may be because no one is that interested. Don't try to tell people what they should be working on, or what they need. It won't work, and it's not your business. The sum of everyones needs and desires are what keep the system running. If you understand that, you can participate efficiently and effectively in the open source / free software community.



Robert Levin