Slashdot Mirror

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Well, maybe it isn't actually an introduction for everyone, but for a lot of us, Lalo Martins has written a nice article to reacquant ourselves with Ox, an Object Model for computers. Check it out if you're interested in learning about it. The following was written by Slashdot reader Lalo Martins. The Ox project

Shortly, Ox is a complete full object model, meaning it wishes to make possible to access anything you expect from a computer in an object-oriented interface. An object-oriented interface means everything you could want to access is an object and, as such, has a class, and benefits from inheritance and polymorphism.

To use my favourite example, in Ox you won't write a "word processor" application; instead you will write a "word-processing-document" class, and objects of this class (documents) would contain all information they need to edit and print themselves, and all other functions you would expect from a word processor, plus others that are made possible by a pure object-oriented environment.

Hovever, Ox does not want to trash all existing software; one of its minor goals is to have hooks to make possible compatibility with anything - and no, I'm not exagerating, the idea is being able to using anything from grep to perl to self (a programing language) to PNG images to old MSX games.

Context

There are many object models. There are many good object-oriented programming languages. There are many object-oriented databases. There are even many good object-oriented tools to make programs cooperate - such as CORBA and ILU. But they are not object-oriented environments.

The very phrase I used to describe CORBA and ILU shows their shortcomings; they're object-oriented tools to make programs cooperate. You still have to write programs, and not classes. Well, I'm tired of writing programs - excuse me sir, I want to write classes. I don't want a tool for cooperation between programs, but a tool for cooperation between persistant objects.

Actually, few people have realized it, but object-oriented databases come far closer to a true, full object-oriented environment than CORBA or ILU. Herectic am I? I would be honoured to be called so :-) people much better than me have. Most of them were not afraid to defenestrate dusty concepts and introduce new ones. I'm a little more of a coward; I'm not introducing a new concept, I'm just trying to explore an old one (OOP) to its full potential.

On the other hand, now I got addicted to my GNU/Linux system and I want to do it "the Unix way" - I want to be able to modify stuff by modifying files by hand, or by moving files around etc. I want to be able to clone an object with "cp" and send it to a friend attached in a MIME mail message. I grew used to knowing which file has what, and I want an object environment where I can keep working this way.

Finally, once the system is working, I don't want to wait for it to reimplement everything from malloc to the X window system before I can use it. And I sure don't want to throw away the zillions lines of working code running around. This ideal system would have to have "hooks" where I could plug compatibility with any existing piece of software. One of the early examples is the hability of writing an "audio-cd" class using the excellent "cdtool" package (cdplay, cdstop, cdpause...) as methods. Alas, instant object-oriented functionality.

These are the major reasons I'm working in Ox, and are the explanations for some of the design decisions. However, these don't say everything about Ox yet; there's another, very important factor:

I'm in the Free Software community (also referred to as Open Source Software).

The Free Software community has its own way of doing things. We do things to share; sharing is an important part of it. We are opposed to binary-only software (because we want to be able to know how something works, and fix it if it doesn't work right), to interface copyrights, API copyrights, and above all, we absolutely despise NDAs (Non-Disclosure Agreements - contracts where you will gain knowledge of something but you must promise not to tell anyone else, essentially) when applied to software. The Free Software Community believes that software has to be shared to achieve its full potential.

The idea of "open development", more formally known as "bazzar-style" development, is another important concept that was born in the Free Software community. It's about writing the code in the open, making development versions frequently available, so that people can read it, fix it, and even help write it - actually, it's about inviting people to do that. Ox doesn't do anything useful, but it has two mailing lists set up so that anyone who wants to participate may join as soon as desired.

Status

The Ox project was born about two years ago. In this period, it died twice already. In my opinion this happened because I did everything wrong in the point of view of "The Cathedral and the Bazaar" paper. I wanted to first have a good spec, then start coding. Now I want to build the two things together, so that one helps the other - the coders find a missing feature, suggest it to the specwriters, and so on. Also, with no coding going on the interest vanished quickly.

The second time I concentrated in writing a spec alone. This was even worse.

This is the third try. I'm opening up the process and inviting you to participate - either in specbuilding, coding, or both. I would have given up on Ox entirely, but in a partially-related mail RMS said he thinks Ox is a very good idea.

The result of this talk with RMS is that the Ox project is now a GNU project. Don't know if many people care, but I do, a lot. It makes me really proud to stamp in the webpages "Ox: the GNU next generation object model".

Contact

Please by all means give it a try. Help coding, help building the spec. IMHO Ox can give a fantastic advantage to the Free Software world. Draw the icons that are missing in the webpage. If you have a place for hosting lists that you think is better than makelist contact me. Or a ftp site, CVS repository... whatever. But anyway, visit the webpage and see what you think. And if this article isn't enought for an opinion, you may jump straight to the what is Ox page (this article is based on it).

Thanks,
Lalo

Copyright © 1998 Lalo Martins lalo@webcom.com http://www.webcom.com/lalo

For information on permissions to reproduce this document, consult the pertaining section in the Ox website.

Any mention to products, trademarks or copyright material of third parties does not constitute any challenge to these rights.

Bruce Perens has sent us another writeup, and this one hopefully won't cause a flamewar that brings the server to its knees! This one is on Security Through Obscurity, and why it just doesn't work. Specifically, Bruce talks about cryptography and why open source is necessary to produce truly secure internet applications. The following is a feature written by Slashdot Reader Bruce Perens Why Security-Through-Obscurity Won't Work Bruce Perens bruce@opensource.org
With all of the threats of new cryptography export laws, and the copyright bill in congress that would illegalize the circumvention of a copyright-protection system, it's time for us to go over the concept of security through obscurity, and why it's a bad idea. I try to explain the concepts as simply as possible in this article, so that non-programmers can understand them.

The encryption feature of a popular commercial spreadsheet program was broken several years ago, when a programmer realized that the spreadsheet always stored the same character sequences at fixed locations in its encrypted file. Because he knew what those characters were when decoded, and because the spreadsheet used a rather unsophisticated code, he could look at the encoded file and work out the code key. That programmer wrote an application that would automatically work out the code key and decode the entire spreadsheet. At that point, the programmer notified the spreadsheet manufacturer that their encryption function had a security bug, and should not be used. He expected the manufacturer to pass this information on to their customers and issue a revision of the program with a less-easily-broken encryption feature.

The spreadsheet manufacturer tried to solve this problem by security through obscurity. They threatened the programmer with a lawsuit or criminal action if he revealed the method of breaking the code. Because another programmer might figure out the method given only the clue that the code had been broken, the spreadsheet manufacturer also threatened lawsuit or criminal action if the programmer even told anyone else that their encryption function was breakable.

Security through obscurity is always a bad idea. In this case, the manufacturer assumed that nobody as smart as that particular programmer would come along for a while, and thus their customers would be secure if this one programmer could be dealt with. However, they did not consider that someone else might have already broken the spreadsheet code without telling the manufacturer, and might already be using the technique to eavesdrop on some rich corporation's secrets.

Many software manufacturers hide bugs that impair the security of programs, or even entire operating systems, without knowing whether some outsider has already found and exploited these bugs. The only proper course for a software manufacturer is to issue a software update as soon as possible after a problem is found, and to inform all customers that the update must be installed to correct an existing security problem. Until more manufacturers understand that security through obscurity is a fallacy, you should consider that popular computer operating systems, applications, and cryptography programs are presently compromised. Do not rely on the security features of these systems.

One exception to the above are Open Source operating systems such as Linux and FreeBSD, and cryptography programs such as GNU Privacy Guard. Because the developers of these systems publish all of their source code for others to read, they can't rely on security through obscurity. The publication of source code actually improves security because the program or operating system can be peer-reviewed by anyone who cares to read it. Many security bugs that are overlooked in other operating systems have been caught and repaired in Linux, because of its extensive peer-review process.

National governments attempt to use security through obscurity. For example, the United States Government forbids the export of strong encryption software, seemingly under the assumption that people in other nations aren't smart enough to write similar software! A copyright law now in the U.S. congress attempts to legislate security through obscurity by banning code-breaking tools, and placing a half-Million-dollar penalty on the act of code-breaking. This would tremendously cripple computer security, because the only way to tell a good code from a bad one is to attempt to break it.

Here's the test that should be applied to all of your cryptography software, the applications you use for privileged data, and the operating systems on which you run those programs. This test is already used by knowledgeable cryptography manufacturers like RSAData Security. First, publish the source code to your program, or, in the case of a cryptography program, publish complete details of the encryption algorithm so that a programmer can understand exactly how the code works. Encourage programmers to study your system and to attempt to break it. Only when a program has been publicly reviewed this way, and when people have tried to break it and have failed, can you be assured that it's useful for concealing your secrets.

Scientists who review codes will rarely call them unbreakable. There are only a few special circumstances in which an unbreakable code is even theoretically possible. Instead, they will tell you that a good code can't be broken in less than decades using the most powerful computers available today, and that is what makes it practical for you to use. Faster computers are constantly being developed, and we are learning more about computer security every day. To assure the continued integrity of your system, you must continue to encourage people to break it as the process becomes "easier". Eventually, computers become powerful enough to break a particular code, and that code must be retired to make way for a more difficult one.

Some time ago, programmers hit upon the fact that they could couple thousands of momentarily-idle workstations together over the Internet and make them all work on the same problem simultaneously. By doing this, they could create "virtual" supercomputers, at low or no cost, more powerful than the Billion-dollar supercomputers in government code-breaking agencies like the U.S. National Security Agency. These networks, run by thousands of amateurs guided by a few cryptography scientists, are now able to make short work of breaking codes like the old 56-bit DES, once recommended for business use by the U.S. Government. As the news of these codes being broken is made public, their retirement is forced in favor of more difficult-to-break versions. This is exactly the work that the circumvention law would ban, and the result would be that people would continue to use obsolete codes long after they became breakable.

Copyright 1998 Bruce Perens. Contact bruce@opensourcce.org for use permission. Trademarks are the property of their respective owners. This editorial is not Open Source. All of the software I write for Linux is Open Source. With editorials, the contents are mostly opinion and I want to have more control over them. For example, I might say something stupid, and then I'd want to take it back and not have it copied and passed around forever!So don't give me a hard time about my editorials not being Open Source. - Bruce

Bruce Perens has sent us another writeup, and this one hopefully won't cause a flamewar that brings the server to its knees! This one is on Security Through Obscurity, and why it just doesn't work. Specifically, Bruce talks about cryptography and why open source is necessary to produce truly secure internet applications. The following is a feature written by Slashdot Reader Bruce Perens Why Security-Through-Obscurity Won't Work Bruce Perens bruce@opensource.org
With all of the threats of new cryptography export laws, and the copyright bill in congress that would illegalize the circumvention of a copyright-protection system, it's time for us to go over the concept of security through obscurity, and why it's a bad idea. I try to explain the concepts as simply as possible in this article, so that non-programmers can understand them.

The encryption feature of a popular commercial spreadsheet program was broken several years ago, when a programmer realized that the spreadsheet always stored the same character sequences at fixed locations in its encrypted file. Because he knew what those characters were when decoded, and because the spreadsheet used a rather unsophisticated code, he could look at the encoded file and work out the code key. That programmer wrote an application that would automatically work out the code key and decode the entire spreadsheet. At that point, the programmer notified the spreadsheet manufacturer that their encryption function had a security bug, and should not be used. He expected the manufacturer to pass this information on to their customers and issue a revision of the program with a less-easily-broken encryption feature.

The spreadsheet manufacturer tried to solve this problem by security through obscurity. They threatened the programmer with a lawsuit or criminal action if he revealed the method of breaking the code. Because another programmer might figure out the method given only the clue that the code had been broken, the spreadsheet manufacturer also threatened lawsuit or criminal action if the programmer even told anyone else that their encryption function was breakable.

Security through obscurity is always a bad idea. In this case, the manufacturer assumed that nobody as smart as that particular programmer would come along for a while, and thus their customers would be secure if this one programmer could be dealt with. However, they did not consider that someone else might have already broken the spreadsheet code without telling the manufacturer, and might already be using the technique to eavesdrop on some rich corporation's secrets.

Many software manufacturers hide bugs that impair the security of programs, or even entire operating systems, without knowing whether some outsider has already found and exploited these bugs. The only proper course for a software manufacturer is to issue a software update as soon as possible after a problem is found, and to inform all customers that the update must be installed to correct an existing security problem. Until more manufacturers understand that security through obscurity is a fallacy, you should consider that popular computer operating systems, applications, and cryptography programs are presently compromised. Do not rely on the security features of these systems.

One exception to the above are Open Source operating systems such as Linux and FreeBSD, and cryptography programs such as GNU Privacy Guard. Because the developers of these systems publish all of their source code for others to read, they can't rely on security through obscurity. The publication of source code actually improves security because the program or operating system can be peer-reviewed by anyone who cares to read it. Many security bugs that are overlooked in other operating systems have been caught and repaired in Linux, because of its extensive peer-review process.

National governments attempt to use security through obscurity. For example, the United States Government forbids the export of strong encryption software, seemingly under the assumption that people in other nations aren't smart enough to write similar software! A copyright law now in the U.S. congress attempts to legislate security through obscurity by banning code-breaking tools, and placing a half-Million-dollar penalty on the act of code-breaking. This would tremendously cripple computer security, because the only way to tell a good code from a bad one is to attempt to break it.

Here's the test that should be applied to all of your cryptography software, the applications you use for privileged data, and the operating systems on which you run those programs. This test is already used by knowledgeable cryptography manufacturers like RSAData Security. First, publish the source code to your program, or, in the case of a cryptography program, publish complete details of the encryption algorithm so that a programmer can understand exactly how the code works. Encourage programmers to study your system and to attempt to break it. Only when a program has been publicly reviewed this way, and when people have tried to break it and have failed, can you be assured that it's useful for concealing your secrets.

Scientists who review codes will rarely call them unbreakable. There are only a few special circumstances in which an unbreakable code is even theoretically possible. Instead, they will tell you that a good code can't be broken in less than decades using the most powerful computers available today, and that is what makes it practical for you to use. Faster computers are constantly being developed, and we are learning more about computer security every day. To assure the continued integrity of your system, you must continue to encourage people to break it as the process becomes "easier". Eventually, computers become powerful enough to break a particular code, and that code must be retired to make way for a more difficult one.

Some time ago, programmers hit upon the fact that they could couple thousands of momentarily-idle workstations together over the Internet and make them all work on the same problem simultaneously. By doing this, they could create "virtual" supercomputers, at low or no cost, more powerful than the Billion-dollar supercomputers in government code-breaking agencies like the U.S. National Security Agency. These networks, run by thousands of amateurs guided by a few cryptography scientists, are now able to make short work of breaking codes like the old 56-bit DES, once recommended for business use by the U.S. Government. As the news of these codes being broken is made public, their retirement is forced in favor of more difficult-to-break versions. This is exactly the work that the circumvention law would ban, and the result would be that people would continue to use obsolete codes long after they became breakable.

Copyright 1998 Bruce Perens. Contact bruce@opensourcce.org for use permission. Trademarks are the property of their respective owners. This editorial is not Open Source. All of the software I write for Linux is Open Source. With editorials, the contents are mostly opinion and I want to have more control over them. For example, I might say something stupid, and then I'd want to take it back and not have it copied and passed around forever!So don't give me a hard time about my editorials not being Open Source. - Bruce

Allright I know I said no more Gnome/KDE stuff, but Bruce Perens asked me to post this, and its worth reading. Now I'm going to be frank here guys, keep the comments under control. I know this is a hot issue, but think before you post. This issue is a major schism, and we need to solve it, not bicker amongst ourselves about it. Now hit the link below and read Bruce Perens rebuttal to Linus' opinions on the KDE/Gnome debate. Update I had to close the comments. Not because they were bad, but because we had 95% of the httpd processes on this machine serving up that story. 200+ comments in 6 hours was just too much. Anyone wanna swap a boatload a RAM for advertising? If we can get more RAM, this hopefully won't happen again. The following is a feature written by Slashdot Reader Bruce Perens Why KDE is Still a Bad Idea Bruce Perens bruce@opensource.org

Linus Torvalds is a nice guy, and I like him. Some days, though, he really misses the point. One of those Linus-in-space moments happened recently, when Linus allowed himself to be quoted saying:

• My opinion on licenses is that "he who writes the code gets to choose the license, and nobody else gets to complain." Anybody complaining about a copyright license is a whiner. The anti-KDE people are free to write their own code, but they don't have the moral right to complain about other people writing other code. I despise people who do complain, and I won't be sucked into the argument.

Linus is really missing the point here. KDE's authors indeed have a right to choose any license they want. The problem is that they are pushin g KDE as a standard GUI for Linux. And that changes all of the rules. When something's promoted as a Linux standard while a critical component of it has a bad license, every free software developer who has contributed to Linux has a right to complain without being despised by Linus. Their complaints are not whining or flaming. There is a real problem and they sincerely want to see it solved.

I'm pretty familiar with standards. For example, I'm leading the Linux Standard Base development, which is meant to make all Linux distribut ions install and run third-party software compatibly. In that project, we've chosen to avoid the KDE-GNOME controversy by not including either system in the standard. However, we've also chosen for everything in the standard to be 100% Open Source, because the major strength of Linux is the fact that anyone can change it, redistribute it, and use it as they like. So, even though I won't be the person making the decision, I can still tell you why KDE must not become the standard GUI for Linux.

What's the Real Problem with KDE and Qt? The KDE authors chose to use Troll Tech's Qt library, even though its license made it impossible for others to maintain it or port it to other window systems. That's right, you're not allowed to distribute modified versions of Qt, even to fix a bug, no matter how severe the problem is. That's one reason the KDE beta test was so long - they were waiting many months for Troll to accept simple patches into Qt for bugs that broke KDE. Think about how long this sort of thing could delay the next port of Linux to a new computer architecture. The Qt license also doesn't allow free use of Qt except under the X Window System. People are starting to realize that X won't live forever.

Of course, the reason for the license restrictions is that Troll Tech makes most of their money from Qt ports for other platforms, such as their expensive Microsoft Windows developer's package. They don't want the competitio n of an Open Source product in that market.

The Free License That Wasn't All of the Qt license criticism was eventually half-responded-to with something called the KDE Free Qt License. Whenever I think about this, I wonder how well the phrase red herring translates into other languages. A red herring is something that isn't really what you are meant to take it for, something that's meant to distract you from the real problem. That's how I'd describe the KDE Free Qt license. Its license terms do not take effect unless Troll Tech stops maintaining Qt, or is bought, or goes out of business. Until then, you still can't modify Qt or port it away from X. So, should we hope that the Qt people are real nice to us and get bought or go out of business as soon as they can, so that we can have a good license on their software? I won't hold my breath. The Rest of the Free Software World Should Clean Up After Us! The KDE developers dismissed the problems with Qt, saying If people don't like Qt's license, they can just write a free clone of it! I read this as the rest of the free software world should clean up after us! If we want to make full use of Qt on an equal basis with the rest of Linux, we just have to clone about 100,000 lines of code and documentation, which happen to be owned by a company who can tie us up in an expensive lawsuit for copyright infringement the minute we're done. In fact, if we want to try to avoid that lawsuit, we have to do it as a clean room operation, because there is no Qt documentation that is not covered by Qt's license. One team has to document the Qt APIs, and the second "clean-room" team, who must not be allowed even a glance at the copyrighted code, must write the clone from the first team's documentati on. You must also be careful about what country each team of this clean-room operation works in - there are national laws against this kind of thing.

But look at the technical history of other cloning projects. WINE and Willows are both efforts to clone parts of Microsoft Windows. Their task is different from that of a Free Qt project, because they have published documentation on Windows and need not comply with a special license like the one that Troll places on Qt's documentation . Although Willows and WINE have made much progress, neither project shows any sign of being finished after years of effort, in part due to the moving-tar get nature of the software they are attempting to clone. A Free Qt project would suffer the same fate. Even Linux has only succeeded as a clone of Unix because the definition of Unix was stable, and clear written standards were available.

Despite these problems, I proposed for SPI to fund a FreeQt project about a year ago. SPI would have gone ahead with it except for just one thing. I asked the KDE folks to promise that they'd use FreeQt when it was done, and they would not agree.

What's the Next Bad Decision Going to Be? Let's say we do clean up after the KDE team by writing a free Qt, we clear all of the legal hurdles, and we eventually persuade the KDE team to use it. Can we trust them not to make another decision just as bad as the one to use Qt? Would we end up re-implementing another commercial product later on? Perhaps it would be better to direct our efforts toward helping people with a better track record of making good decisions. But Must It Be Open Source? Some people will tell you it isn't really important that Qt is not Open Source. They are ignoring the fact that the major difference between Linux and Microsoft Windows is not a technical one, it's that Linux is Open Source and can be freely modified and redistributed by anyone. It's not important that everything on your favorite Linux distribution be Open Source, but any standard part of Linux must be Open Source. If it isn't, we are discarding the main strength of Linux against proprietary software, the freedom for anyone to change it, redistribute it, and use it as they like. That freedom is the sole reason for all of the innovation in Linux and all of its success. By making the decision to give up that freedom for a critical component like the GUI, we simply substitute a new set of masters for Bill Gates. What about GNOME? The people who are working on GNOME didn't want to see KDE, with its dependency on Qt, become the standard GUI for Linux. They complained about this as soon as the KDE project was started, when KDE's developers had lots of time to change their mind. But nobody on the KDE team listened, and those developers founded the GNOME project.

What kind of people are the GNOME developers? I recently had an opportunity to find out. I spent a day with them at the GNOME summit, at RHAD labs, the day after Linux Expo. What I found out is that they are smart. I'll tell you my benchmark for smart. I work at Pixar Animation Studios, the computer-graphics facility where we wrote and animated Toy Story, and where we're now finishing A Bug's Life. You can imagine that there are lots of smart people there. My day with the GNOME developers convinced me that, as a group, they are at least as smart as my colleagues at Pixar.

But what should convince you that the GNOME folks are smart is the care that they are taking to get the details right that KDE's developers got wrong. For example, they took the trouble to develop the Open Source GTK+ library to the point that it was usable for their project, rather than accept the already-done Qt with its poor license. The chose an Object Request Broker library that was technically OK, with an Open Source license, and then when they felt they could improve it, they started to write their own ORB, also Open Source. They attracted the most brilliant developers, including Alan Cox, the primary architect of Linux networking, and Rasterman, developer of the Enlightenment window manager. They persuaded Red Hat to put six salaried people on GNOME development , so that we are assured that GNOME will be developed quickly and will soon surpass KDE. There are no show-stoppers like the Qt license in GNOME that would prevent it from being accepted as the standard GUI of Linux. The GNOME developers simply would not tolerate that kind of problem. They put the same sort of care into the technical decisions they make about GNOME.

GNOME Will Become The Standard GUI of Linux Because it is 100% Open Source, because it is technically quite good, and because of the wisdom of its development team, GNOME will become the standard GUI for Linux. A large portion of the free software community will simply not accept KDE because of the Qt license. The only chance left for KDE to reach that goal is for them to drop what they are doing and rush to finish the a Free Qt now. However, the KDE developers themselves admit that they are too familiar with the internals of Troll's code for them to write a Free Qt themselves without infringing on Troll Tech's copyright. So, who will write the Free Qt? One of the two main developers of Harvest just got a job (at Red Hat), so I'm not sure it will be him. I'm pretty confident now that before a Free Qt can be done, GNOME will be in 1.0 or some higher release and will have established itself as the standard GUI of Linux. KDEwill stay around as a good desktop with a faithful, though slowly diminishing, user community, but it won't grab the brass ring. He's Linus, and He is Your God Let's get back to Linus, since it was his ill-considered statement that inspired this editorial. Linus recently introduced himself at his Linus Expo this way: Yes, I'm Linus Torvalds, and I am Your God. Having embraced his own god-hood, Linus must now learn that gods must behave more responsibly than the people around them. He could start by thinking a lot harder before he publicly announces that someone is a despicable whiner.

Copyright 1998 Bruce Perens. For use permission, contact bruce@opensource.org . Open Source is a registered trademark of Software in the Public Interest for software that complies with the Open Source Definition. Qt is a trademark of Troll Technology. Other trademarks are the property of their holders.

Allright I know I said no more Gnome/KDE stuff, but Bruce Perens asked me to post this, and its worth reading. Now I'm going to be frank here guys, keep the comments under control. I know this is a hot issue, but think before you post. This issue is a major schism, and we need to solve it, not bicker amongst ourselves about it. Now hit the link below and read Bruce Perens rebuttal to Linus' opinions on the KDE/Gnome debate. Update I had to close the comments. Not because they were bad, but because we had 95% of the httpd processes on this machine serving up that story. 200+ comments in 6 hours was just too much. Anyone wanna swap a boatload a RAM for advertising? If we can get more RAM, this hopefully won't happen again. The following is a feature written by Slashdot Reader Bruce Perens Why KDE is Still a Bad Idea Bruce Perens bruce@opensource.org

Linus Torvalds is a nice guy, and I like him. Some days, though, he really misses the point. One of those Linus-in-space moments happened recently, when Linus allowed himself to be quoted saying:

• My opinion on licenses is that "he who writes the code gets to choose the license, and nobody else gets to complain." Anybody complaining about a copyright license is a whiner. The anti-KDE people are free to write their own code, but they don't have the moral right to complain about other people writing other code. I despise people who do complain, and I won't be sucked into the argument.

Linus is really missing the point here. KDE's authors indeed have a right to choose any license they want. The problem is that they are pushin g KDE as a standard GUI for Linux. And that changes all of the rules. When something's promoted as a Linux standard while a critical component of it has a bad license, every free software developer who has contributed to Linux has a right to complain without being despised by Linus. Their complaints are not whining or flaming. There is a real problem and they sincerely want to see it solved.

I'm pretty familiar with standards. For example, I'm leading the Linux Standard Base development, which is meant to make all Linux distribut ions install and run third-party software compatibly. In that project, we've chosen to avoid the KDE-GNOME controversy by not including either system in the standard. However, we've also chosen for everything in the standard to be 100% Open Source, because the major strength of Linux is the fact that anyone can change it, redistribute it, and use it as they like. So, even though I won't be the person making the decision, I can still tell you why KDE must not become the standard GUI for Linux.

What's the Real Problem with KDE and Qt? The KDE authors chose to use Troll Tech's Qt library, even though its license made it impossible for others to maintain it or port it to other window systems. That's right, you're not allowed to distribute modified versions of Qt, even to fix a bug, no matter how severe the problem is. That's one reason the KDE beta test was so long - they were waiting many months for Troll to accept simple patches into Qt for bugs that broke KDE. Think about how long this sort of thing could delay the next port of Linux to a new computer architecture. The Qt license also doesn't allow free use of Qt except under the X Window System. People are starting to realize that X won't live forever.

Of course, the reason for the license restrictions is that Troll Tech makes most of their money from Qt ports for other platforms, such as their expensive Microsoft Windows developer's package. They don't want the competitio n of an Open Source product in that market.

The Free License That Wasn't All of the Qt license criticism was eventually half-responded-to with something called the KDE Free Qt License. Whenever I think about this, I wonder how well the phrase red herring translates into other languages. A red herring is something that isn't really what you are meant to take it for, something that's meant to distract you from the real problem. That's how I'd describe the KDE Free Qt license. Its license terms do not take effect unless Troll Tech stops maintaining Qt, or is bought, or goes out of business. Until then, you still can't modify Qt or port it away from X. So, should we hope that the Qt people are real nice to us and get bought or go out of business as soon as they can, so that we can have a good license on their software? I won't hold my breath. The Rest of the Free Software World Should Clean Up After Us! The KDE developers dismissed the problems with Qt, saying If people don't like Qt's license, they can just write a free clone of it! I read this as the rest of the free software world should clean up after us! If we want to make full use of Qt on an equal basis with the rest of Linux, we just have to clone about 100,000 lines of code and documentation, which happen to be owned by a company who can tie us up in an expensive lawsuit for copyright infringement the minute we're done. In fact, if we want to try to avoid that lawsuit, we have to do it as a clean room operation, because there is no Qt documentation that is not covered by Qt's license. One team has to document the Qt APIs, and the second "clean-room" team, who must not be allowed even a glance at the copyrighted code, must write the clone from the first team's documentati on. You must also be careful about what country each team of this clean-room operation works in - there are national laws against this kind of thing.

But look at the technical history of other cloning projects. WINE and Willows are both efforts to clone parts of Microsoft Windows. Their task is different from that of a Free Qt project, because they have published documentation on Windows and need not comply with a special license like the one that Troll places on Qt's documentation . Although Willows and WINE have made much progress, neither project shows any sign of being finished after years of effort, in part due to the moving-tar get nature of the software they are attempting to clone. A Free Qt project would suffer the same fate. Even Linux has only succeeded as a clone of Unix because the definition of Unix was stable, and clear written standards were available.

Despite these problems, I proposed for SPI to fund a FreeQt project about a year ago. SPI would have gone ahead with it except for just one thing. I asked the KDE folks to promise that they'd use FreeQt when it was done, and they would not agree.

What's the Next Bad Decision Going to Be? Let's say we do clean up after the KDE team by writing a free Qt, we clear all of the legal hurdles, and we eventually persuade the KDE team to use it. Can we trust them not to make another decision just as bad as the one to use Qt? Would we end up re-implementing another commercial product later on? Perhaps it would be better to direct our efforts toward helping people with a better track record of making good decisions. But Must It Be Open Source? Some people will tell you it isn't really important that Qt is not Open Source. They are ignoring the fact that the major difference between Linux and Microsoft Windows is not a technical one, it's that Linux is Open Source and can be freely modified and redistributed by anyone. It's not important that everything on your favorite Linux distribution be Open Source, but any standard part of Linux must be Open Source. If it isn't, we are discarding the main strength of Linux against proprietary software, the freedom for anyone to change it, redistribute it, and use it as they like. That freedom is the sole reason for all of the innovation in Linux and all of its success. By making the decision to give up that freedom for a critical component like the GUI, we simply substitute a new set of masters for Bill Gates. What about GNOME? The people who are working on GNOME didn't want to see KDE, with its dependency on Qt, become the standard GUI for Linux. They complained about this as soon as the KDE project was started, when KDE's developers had lots of time to change their mind. But nobody on the KDE team listened, and those developers founded the GNOME project.

What kind of people are the GNOME developers? I recently had an opportunity to find out. I spent a day with them at the GNOME summit, at RHAD labs, the day after Linux Expo. What I found out is that they are smart. I'll tell you my benchmark for smart. I work at Pixar Animation Studios, the computer-graphics facility where we wrote and animated Toy Story, and where we're now finishing A Bug's Life. You can imagine that there are lots of smart people there. My day with the GNOME developers convinced me that, as a group, they are at least as smart as my colleagues at Pixar.

But what should convince you that the GNOME folks are smart is the care that they are taking to get the details right that KDE's developers got wrong. For example, they took the trouble to develop the Open Source GTK+ library to the point that it was usable for their project, rather than accept the already-done Qt with its poor license. The chose an Object Request Broker library that was technically OK, with an Open Source license, and then when they felt they could improve it, they started to write their own ORB, also Open Source. They attracted the most brilliant developers, including Alan Cox, the primary architect of Linux networking, and Rasterman, developer of the Enlightenment window manager. They persuaded Red Hat to put six salaried people on GNOME development , so that we are assured that GNOME will be developed quickly and will soon surpass KDE. There are no show-stoppers like the Qt license in GNOME that would prevent it from being accepted as the standard GUI of Linux. The GNOME developers simply would not tolerate that kind of problem. They put the same sort of care into the technical decisions they make about GNOME.

GNOME Will Become The Standard GUI of Linux Because it is 100% Open Source, because it is technically quite good, and because of the wisdom of its development team, GNOME will become the standard GUI for Linux. A large portion of the free software community will simply not accept KDE because of the Qt license. The only chance left for KDE to reach that goal is for them to drop what they are doing and rush to finish the a Free Qt now. However, the KDE developers themselves admit that they are too familiar with the internals of Troll's code for them to write a Free Qt themselves without infringing on Troll Tech's copyright. So, who will write the Free Qt? One of the two main developers of Harvest just got a job (at Red Hat), so I'm not sure it will be him. I'm pretty confident now that before a Free Qt can be done, GNOME will be in 1.0 or some higher release and will have established itself as the standard GUI of Linux. KDEwill stay around as a good desktop with a faithful, though slowly diminishing, user community, but it won't grab the brass ring. He's Linus, and He is Your God Let's get back to Linus, since it was his ill-considered statement that inspired this editorial. Linus recently introduced himself at his Linus Expo this way: Yes, I'm Linus Torvalds, and I am Your God. Having embraced his own god-hood, Linus must now learn that gods must behave more responsibly than the people around them. He could start by thinking a lot harder before he publicly announces that someone is a despicable whiner.

Copyright 1998 Bruce Perens. For use permission, contact bruce@opensource.org . Open Source is a registered trademark of Software in the Public Interest for software that complies with the Open Source Definition. Qt is a trademark of Troll Technology. Other trademarks are the property of their holders.

Brett Watson writes "Opensource.org have updated their web pages. Most of it isn't new to Slashdot readers, except perhaps a link to a White Paper on UNIX vs NT by an MS Certified NT Professional that I haven't seen referred to anywhere else. Sample quote: "Why Windows NT Server 4.0 continues to exist in the enterprise would be a topic appropriate for an investigative report in the field of psychology or marketing, not an article on information technology. Technically, Windows NT Server 4.0 is no match for any UNIX operating system, not even the non-commercial BSDs or Linux." Ouch. "

Ed has written us a little diddy on the various Open Source Licenses with some commentary on each of them. This is important stuff to read, especially for those of us in the audience who aren't crystal clear on the differences between them. This writeup specificly talks about how a business will most likely consider each license for their usage. The following is an Editorial by Slashdot reader Ed

I was recently contacted (along, I'm sure, with many other readers of slashdot.org) by James Glave of Wired Online, who asked me the following:

"Why do you think it's a bad idea to sell free-source libraries to corporations? Doesn't the BSD license give companies total free reign with open source already -- and doesn't this scheme allow companies to at least funnel cash back into the open source community?"

My quick answers were "I don't" and "Yes -- and I don't understand the question."

The questions, I assumed, had come up in the context of the recent formation of the Public Software Institue (PSI for the rest of this screed), a non-profit organization that will attempt to fund open-source software development through the use of a "pay or publish" licence, which would allow companies to sell closed-source software derived from the open-source base, for a fee. It's a neat compromise between the GPL and traditional commercial software licensing(1).

However, I don't think it will encourage as much development as the more familiar open-source licenses.

Indulge in a bit of armchair theory with me:

Let's look at open-source package foo-psi, released under an PSI type of license, open-source package bar-gpl, released under a GPL-style license, and open-source package baz-bsd, released under a BSD or XFree86 type of license. Suppose that all of these packages do essentially the same thing, and that they each have a few core developers who are dedicated to improving the code and releasing source.

Suppose traditional software company A Inc is looking for code to use in a closed, commercial product. Package bar-gpl is not an option, and therefore will not benefit from the efforts of A Inc's remarkably talented development team. A Inc will either choose to use package baz-bsd (for free) or foo-psi (paying the license fee). Again, no source code will be contributed back to packages foo-psi or baz-bsd. If package foo-psi is used, money will go to the licensers of foo-psi, who may do with it as they please. However, company A is more likely to choose package baz-bsd, because there is no fee for doing so.

Now consider university graduate student or computer enthusiast B, who in working on an academic project or hobby wants to modify an existing software package. Any of our three available software packages would be fine, but the industrious programmer might resent the idea of his or her brilliant work being used to benefit the bank accounts of the licensers of foo-psi or to fill the coffers of companies such as A Inc which use package baz-bsd. There would be incentive, albeit somewhat negative, for B to use package bar-gpl. If, on the other hand, B thinks that he or she might in the future want to form his or her own company like A Inc in order to profit from the present project, then there will be incentive to choose package baz-BSD.

Now suppose that the ingenious programmers at company C are looking for some code to use as part of an internal project, which they do not intend to sell. This, incidentally, describes most of the programming done in the world today. If there is a benefit to company C in keeping modifications away from their competitors, then there will be no source code contributed to any of the open-source packages. If there is a greater advantage to be had by making sure that future versions of the open-source package are compatible with company C's project, then code will be released, and whichever open-source project is chosen for the work will benefit from the efforts of the tireless and noble programmers employed by company C. If company C is planning to keep their modifications private, then they may choose code from project bar-gnu (remember that they do not plan to distribute modified code), or from baz-BSD, but they are less likely to use code from project foo-psi if they are required to pay a licensing fee. Thus the license holders of project foo-psi are less likely to earn money from projects of this sort(2).

Eventually, it's likely that one of these packages will attract a few more contributors than the others, and thus more improvements will be made to that package to the others, thereby attracting more developers, resulting in a classic positive feedback cycle. (Well, okay, everyone I know who spends time programming seems to think so. I don't have any great explanation of why this should be the case). Based on the licensing alone, I don't think there is enough evidence to choose a "winner" of this sort, but I think I can see a loser. With all things being equal, there are more motivations for projects to contribute to bar-gpl or baz-bsd than there are for foo-psi. Contributions to foo-psi in the form of money are unlikely when baz-bsd is available, and there is the added difficulty of transmogrifying money received by the license holders of foo-spi into more working code in the foo-psi codebase :) .

This sort of armchair theorizing could get ridiculously extensive (e.g.: Which type of license is likely to generate more bug reports? More importantly, how does the existing body of open-source code influence selection?), but I think I'll take a rest at this point. For the record, I'm a little bit wary of using this sort of argument, because I've encountered so many "evolutionary explanations" for behavior that are in fact rationalizations based only on selected facts. I tend, therefore, not to trust myself with this sort of argument, and I welcome criticism. I apologize in particular if this might be construed as an attack against PSI, who I think are doing Good Things, or as a call for developers to avoid license terms such as those proposed by PSI. That would just be silly.

--Ed Slocomb

(1) Software distributed under such a license might not be able to use the trademark "open-source." (See opensource.org for details) "open-source" is a trademark of Software in the Public Interest.

(2) There is also the possibility that company C might want to turn an internal project into a closed-source product at some time in the future. If the license for foo-spi allowed modification for non-redistributed work without fee, the aforementioned possiblity would favor the use of baz-bsd rather than foo-psi.

Edmund Humenberger writes "I am happy to announce the Open Source Software Fund (F.O.S.S). F.O.S.S is a possibility for USERS to support financially the development and developers of Open Source Software. F.O.S.S is a business model to enable programmers writing Open-Source-Software with free tools and make a living. The goal of F.O.S.S is that all software wanted by users will be written by the best suited programmers in the world and released as Open Source Software. This way users get the best possible software. Please see the Webpages and participate if you like the concept. Productive critics are welcome! All senseless flames will go to /dev/null Ed Humenberger " It's definately an interesting idea... I'm curious to see it in action.

This is the first of a series of articles investigating the interplay between Open Source Software and commercial vendors. The common thread will be to find out how authors have earned a living from writing and servicing GPL/Open Source Software.

The series kicks off with Michael Tiemann, one of the founders of Cygnus Solutions, and author of the C++ component of GCC. Cygnus is one of the pioneers in commercial support for open-source software. It sells support and customization services for the gnu programming tools (gcc, gdb, ld, etc). Initially, the Free Software Foundation applauded this, but more recently, RMS feels that by also selling proprietary software Cygnus has betrayed the principle of free software.

In this interview, Michael discusses what it takes to set up a business based on open source software, what Cygnus hopes to add to GCC, and why they took the decision to sell closed source software.

What is written in red, is what Michael wrote to me in an email
What is written in green, is what I transcribed from my notes of our telephone interview. Any mistakes therein are mine.

• How difficult was it for you to set up Cygnus Solutions?
• • How did the banks cope with Cygnus' non orthodox business model?
  • How difficult was it to find the first customers?
  • What advice could you give someone who has written a GPL'd (or similar) program, and wants to live off it by providing services to commercial users?
  • Can one survive purely on the provision of services?
  • What types of services have you found to be the most important for commercial customers? What sort of guaranties do they want? What should one pay special attention to?

• • The greatest challenge in setting up Cygnus was in finding a name under which we could do business. This is not a joke...for three months we went through a process of finding a name, submitting it to the dept. of corporations, only to learn that the name had already been taken. We were about to give up hope when such an ugly name as "Software Support, Inc." had been registered the same year we tried to get it. When we learned that Cygnus Support (note the embedded GNU in Cygnus) was ours to use, we were overjoyed.

    Cygnus was started with virtually no money. At the time, I wanted John Gilmore (whose userid was gnu@sun.com) to be one of the founders (he was employee #5 at Sun, and was the guy who ported BSD Unix to the 68020), not for his money, but for hus programming skills. I put _my_ money where my mouth was, proposing that all three founders put in the same amount of money at the start. At that time, I had less than $3000 in the bank, so I proposed we each put in $2000 at the start, and raise the ante to $5000 when I could afford it. As you can see, we did _nothing_ to try to get banks interested, so there was nothing to explain to them.

    As for finding the first customers...it was just a matter of knocking enough times on the correct doors. As the author of GNU C++, it was pretty easy for me to talk to high-level technical people, who would then introduce me to mid-level managers. We sold GNU support primarily as a cost-saving measure, so we did not need VP level approval. Nowadays we have a much more strategic sell, but we're also much better established, so we can call on and get VP level approvals.

    I've always advised everybody that if they want to start a free software business, they should not let anything stop them. Of those who did, most managed to break even or make a small profit, leading me to believe that there's more to Cygnus's success than merely addressing a market opportunity. We've always been willing to make tough decisions, and we've always listened to customers, even when they were yelling at the top of their voices. Those who do free software for love, rather than money, are not going to survive what we've been through.

    As far as what customers really want...they want somebody who will listen to their needs, formulate a long-term plan, and then deliver without a lot of hassle or risk. Some customers like to see you work; others like to see the work you do; still others think you are doing a great job if they never see you. In the end, it's not the guarantees you offer that make customers come back..it's what you can deliver. The free software model is unique in that it actually gives an incentive for customers to work with you, not independently from you. In the fast-moving high tech world, that advantage has put us in the #1 spot in our market...no mean feat.

• Cygnus and the FSC (Free Software Community)
• • What exactly are you providing to the FSC?

• • We pour about $10M/year into the development of new free software. We run the servers from which 500,000 people have downloaded our stuff. We promote the concept of free software in articles, conferences, and advertising. We sponsor free software projects and pay free software contractors who do work that's related to our business requirements (though not something we'd directly commercialize). We provide a generous matching fund so that employees and customers who want to donate to the FSF can see their donation multiplied.

• How long does it take for your new code to be released in Egcs, or other freely downloadable source code?

• • The std deviation of this number makes an average number meaningless. If you download EGCS, I'll bet that the ChangeLog entries are no more than 45 days old. Compare that to other FSF-controlled packages where they can be months or years old. It is important to realize that we don't control when the FSF releases code.

• How much do you feel you are getting from the FSC? Would it have been simpler to write you own compiler?

• • Simpler, perhaps. But we would not have been able to distinguish ourselves from the other N proprietary companies. I mentioned earlier that people are now chosing Cygnus not because we are cheaper, but because we are _strategic_. We could not have achieved that strategic positioning in the compiler space in any other way.

• What overhead is there with working with the FSC?

• • It's whatever you want. Some people like to spend hours arguing about indentation styles. Others just decide they are going to do somthing and they do it. I wrote the first native-code C++ compiler in 6 month in 1987. It was hard work, and it was rough, but once I demonstrated the momentum I could sustains, dozens joined to the GCC/G++ team.

    In 1989, when GCC 1.x was getting fairly mature, I wrote an instruction scheduler, re-wrote a branch scheduler that had been abandoned, and wrote several cool new optimizations that could not easily fit with GCC 1.x. I declared that we should start GCC 2, with the goal of integrating this new work, new C++ language features, and an eye towards optimal code generation for RISC machines.

    GCC 2.x is now reaching maturity, and it's just not possible to preserve that kind of stability with the while working on advanced/experimental/cool new stuff we want to do. Hence we created EGCS. I've been amazed at the number and quality of volunteers who are now working on that branch. Thus, for GCC 2, the overhead is high, whereas for EGCS, the overhead is negative.

• What sort of friction is there between immediate customer concerns and the interests of the FSC?

• • No difference to any other scarce-resource problem.

• • The FSF's objective is a free software world. The customer's objective is a solution that satisfies his needs. The problem is that commercial work always pays more, so more people do that, which frustrates the FSF that not more people are on its bandwagon.

• Which strengths do you see in the Bazaar and Cathedral models of free software development?

• • Although Eric Raymond is very good at coming up with beautiful theories, I dispute whether they are a true reflection of reality. I see GNU and Linux as two cathedrals. Both Linux and RMS are benevolent dictators. What sets them apart is that Linus is willing to take more risks, to rewrite more of his software, while RMS is a perfectionist. Overall, I believe that risks win, and the risk of reimplementing things lead to a better result. Eric and I were both at the Foresight institute to discuss Netscape releasing their source code. Eric said that Cygnus's model was to provide service to commercial customers for free software products, while Netscape was going to lead the standards with its Free software strategy. I disagree with this since Cygnus too is leading the standards in the embedded market with free software.

• Why did you decide to sell software without source-code, given that this soured your relation with the FSF?

• • We measure success in $$, not FSF relationship. Free software works great for support, not for products.

    Cygnus has been very successful at its challenge. In 8 years we've become the number one tool supplier for the embedded market. Our growth is limited only by the number of sales and technical people we can find to employ. I expect our business will be eventually worth 100 of millions dollars per year. But this has taken lots of effort, and is only achieved by making life easy for our customers. For instance, we support 17 different host-target combinations for Cisco alone. Their routers' CPUs vary from the very simple basic RISC chip to very complex CISC chips with fancy features, yet they want the same code to work on any host-target combination. Contrast this to Sun or Microsoft where the same code will not work on SunOS 4/Solaris or Windows 95/NT. We support SGI, HP, NT (etc) so that our customers do not have to decide on their platform because of us. In total we support 170 different host-target combinations.

    The proprietary model and the free software model provide two different kinds of simplicity. The free software model provides simplicity of APIs: there is no need to waste time reverse-engineering things if you have source. The proprietary model provides simplicity of control: your software does not go off and have a life of its own, you can control your investment, your price points and focus on command performance rather than spend time on building a consensus. For instance, say we have two customers, one of whom has a bad bug he needs fixed, the other of whom has sent us an enhancement to our product. Say furthermore that we only have enough time to service one of their needs. If we fix the bug, then the customer who sent us the enhancement will be disappointed -- they did what the GPL said to do --, and they will wonder why they need support from us, since the guys on the net included their enhancement while we did not. If we add the enhancement, then one of our customers still has a bug, and if he cares nothing for having the source-code, he will look somewhere else for business. So adopting the proprietary model allows us to control our strategy. If the need for strategic control disappears then the software can become free, but this might never happen. For instance, dejagnu was not planned to be commercial software, so we put on the net to get help from the people out there.

    In my opinion, Sun has done a bad job at being a software leader, as has Microsoft. What GNU and Linux are doing is pushing the envelope back up.

• You provide compilers for the embedded market

• • Yes. The embedded market is very different from the traditional desktop market. For instance, the object files that became popular in the embedded market differ from those used in the desktop/workstation markets. Originally embedded people worked on Sun 3's and cross-compiled 68000 code into a.out executables. But a.out has limitations such as not allowing multiple data sections. New formats were devised to address this and other issues.

    Another difference is the embedded market is extremely cost-conscious. For instance, the money made on cellular telephones is made on the subscription. Thus the bill of materials for a cellular telephone must be extremely low. Similarly, end-product functionality is more of a concern that compatibility. Because RISC processors provide approximately twice the compute-power for half the electric power of a CISC processor, they are being adopted more rapidly than in the PC market. MIPS is now dethroning the previous king of the embedded world, the 68000 family, having sold 44 million units last year versus 68000's 42 million.

    Providing one same set of compilers for a wide variety of chips has made us into the standard for the embedded market. We have close ties with CPU companies, such as Toshiba, so that each new chip is released with a new version of our compiler. This makes it easy for our customers to choose which ever chip will give the best cost/performance ratio, without worrying about high porting costs.

• What features did you have to add for this market?

• • We added many features that improve code performance and code size. We provide a very lean and mean implementation of C++ to allow embedded programmers to use the C++ features they need. Indeed, we were the first to ship C++ for the embedded world, for Nortel in 1990. We've added the ability to control via #pragmas the type of return code the compiler should use, so that interrupt routines can be written in C. Another embedded feature is the ability to specify into which segment each function should go. And to help our customers migrate rapidly from chip architecture to chip architecture, we have a whole series of #pragmas to control the way in which data structures are laid out in memory. This allows them to have binary compatibility of data structures even if the code was originally written to access words at odd boundaries, but the target processor does not allow this.

• Are there any new #pragma like commands to control code size at a lower granularity (e.g.: for single functions)

• Are there any new #pragma like commands to control speed as a lower granularity (e.g.: for single functions)

• • We find generally that programmers want the same level of optimization for a particular module. However some optimizations of that kind are described in the processor specific optimization documentation: these are processor dependent trade-offs. For instance, on an R10000 (MIPS), bigger code is faster in that keeps all 4 pipes full. On the other hand, we had to deal with very high space constraints when we worked with Sega. They used the Gnu compiler for the Sega Saturn. And although the SH (Super Hitachi processor) encodes 32 bit instructions into 16 bits, we had to change the compiler significantly to cope with the fact that loading immediate values (such as 57) is very convoluted: you read the value then jump over it, making immediate value loads very expensive when the compiler assumed they would be cheap.

    Generally, we think code size will become less and less of an issue: at the rate at which chips are shrinking and processes are improving (such as the extreme Ultra Violet process), the average DRAM chip will contain 1.7 Gbits in 2001 and 237 Gbits in 2012. Bandwidth problems will be alleviated by developments such as Mitsubishi's M32R chip, which has a core on a 16 Mbit ram, and has a huge bandwidth.

• Do you have any benchmarks to compare the current GCC levels of compilation (code size, speed) with compilers from Metaware, IBM, Microsoft, Borland, Symantec, Intel's VTUNE, etc?

• • We use the Bench++ benchmark. In contrast to SPEC benchmarks, this uses Stepanov's abstraction benchmark to determine the cost of various C++ features. For instance at the 0th level of abstraction, the code uses an integer, at the 1st it uses a double, then a class with a double member, then a class with a double pointer member... including template iterators until the 12th level is reached. GNU beats Sun and HP's compilers by a factor of 10. Similarly, GNU exception handling is 10 times faster than HP's.

    In terms of the SPEC base benchmarks EGCS attains the same level as SGI's compiler (the best in the business) with -O and -O2 options. Beyond that, SGI allows one to specify tons of options, such as cache size, which generates better code. However no one actually uses these options, so it's not much of an issue.

    As a company, other than the CygWin guys, we don't compare ourselves with the PC guys, so I can't give you a comparison. The DJGPP guys may have some info. Metaware is a non factor for us, since none of our customers complain about our performance.

• Future trends
  • What new features would you like to see in future revisions of GCC?

• • We'd like to see a good implementation bridging the gap between C/C++ and Java. There are good ideas in Java. It provides open standards that are very important to the downloadable world I believe will arise in the future: it provides a simple way to connect to the web, which essential to achieving an information aware infrastructure.

    However Sun's current behaviour is very worrying. Anything that Sun writes becomes a Java API. This is not unlike Microsoft, who redefined C APIs, even though a standard existed (POSIX), to such an extent that even "hello world" will not work (stdout and stderr are not available from winMain()). Sun is playing a similar game with Java, and we fear it will lead to incompatibilities, balkanizing Java, and letting the competition win. Although Sun snipes free versions of Java, all it is doing is replaying the Unix wars. We hope that GCC will be the free standard wedge that keeps the door open.

• What do you think of the idea that programs are JIT compiled to optimize the features being used, to maximize memory efficiency (as Intel's VTUNE does) while minimizing total footprint by leaving most of the code in a compressed bytecode format (as www.tao.co.uk is suggesting).

• • We view the problem rather differently: what do you want to use your CPU power for? Do you want to use it for JIT compilation, or for running the application? We think the latter. So the JIT should be done on the server. There is no reason why your processor could not identify itself to the server and let the server produce whatever native implementation is best for it. Profile information could also be sent to the server in this way. We will be showing in an upcoming Dr Dobbs Journal, that the performance one can achieve in native-compiled Java is comparable to that of C. Speedwise, this is a better solution than a Java chip, because Lisp Machines have already shown us that register based machines present many more opportunities for optimizations than stack machines. Powerwise it is also advantageous as compilation is rather expensive on a battery. Even in terms of code size, gzip compressed 32 bit RISC code is comparable in size to the equivalent byte-code.

• What do you think of IBM's idea of simplifying processor state-machines to increase frequency by moving more of the complexity to software?

• • Like EPIC, the proof will be in the proverbial pudding. Different RISC implementations vary greatly in power, although in principle they should provide similar levels of performance. For instance, a 200 Mhz R10000 provides a similar level of performance to a 600 Mhz Alpha.

• Do you anticipate commercial proprietary source-code will at the end of the day dominate the market-place, or do you feel that free software backed up by a service industry will take over?

• • I think the distinction will be like the difference between public and private life. While we may let all the people on the net look at our source-code we don't let them play with our money. I believe that free software will determine the standards in the world. Proprietary software will exist in niches, where customers don't care for the source code. Instead of spending time building a concensus, proprietary software allows a company to focus on producing a piece of software as quickly as possible to catch a market opportunity. For instance, we use ORACLE's database software. We don't have the source-code, and don't want it because its internal complexity is irrelevant to us: we just want to use it.

Several people have written me with stuff relating Open Source Hardware:The thought is that the Open Source model can be applied to hardware as well. Troy Benjegerdes wrote in and said "Eric S Raymond implies this in this article. I have written a paper for a class dealing with this, and David Freeman has web page on the subject."

After bestowing awards upon Linux, Infoworld (we have a friend in business :-)) has given the NT version of Apache a warm review. That's good news in my book, as the more exposure system admins get to open source software, the more they trust and like it.