Tuesday, March 09, 2004
Even More Conversations with Eric Raymond, Part 9
> Again, you're posing the wrong criterion. Recipes
> are less
> complicated, but *reconstructing them from the
> finished food* is often
> much more difficult than decompiling binaries. The
> problem is that
> the chemicals in food mix and combine in much more
> complicated ways
> than the bits in object code -- the information from
> the "source"
> (recipe) can turn into very subtle effects like the
> degree of
> caramelization of the sugars in a fruit.
You're thinking like an engineer, not a chef. Chefs
do strange things, like try a dish at a nice
restaurant, then go home and recreate it themselves.
It doesn't HAVE to be the exact same chemical
composition.
Programs require higher degrees of similarity, though,
simply because there are so many things that can cause
the performance characteristics to change.
> In the relevant sense, "free" software isn't free
> either, and never
> will be. It doesn't install itself, or maintain
> itself, or know when
> it needs an upgrade. So the right comparison would
> be between
> low-cost food and high-cost food.
Granted. But then again, the average consumer doesn't
tend to upgrade all htat often, or need maintenance.
I know people who still use DOS versions of
WordPerfect. If they got that product for free
originally, they would get one HELL of a lot of
mileage out of it.
As for products that need maintenance (custom software
in corporations), fine...but that applies to
proprietary software AND open source software. In the
latter case, though, you've ensured that people who
MAKE software can't get paid just for that. You've
excised a revenue model, and as I said, there are
advantages to the incentives created by a strong
source of revenue for software as such.
> So: what is it that makes it possible for expensive
> restaurants to
> compete against cheap food? And can you explain why
> they don't
> need to keep secrets to do so? Now apply this model
> to code.
Like I said, the fact that ALL restaurants charge.
Your recasting of the argument doesn't really apply to
software. GPLed software is REALLY and TRULY free for
most consumers. For businesses, they would have to
pay for maintenance, anyway, irrespective of whether
the code was open source or proprietary. In the open
source case, they just run more risk that code will
end up being made incompatible due to in-house
changes, and furthermore, if EVERYBODY is open source,
ensured that no incentive exists to orient programmers
towards the needs of non-technical users.
> > As the cost of automobiles goes down, the price of
> > auto mechanics goes up. The reason is that lower
> > priced automobiles results in higher demand for
> > automobiles, leading to more autos on the road,
> and
> > hence, more demand for mechanics.
>
> The full explanation is that automobiles and
> mechanics are part of a
> "bundled good" which is the ability of the consumer
> to get from point
> A to point B. Now a characteristic of such bundled
> goods is that when
> demand for the bundle is elastic (increases as price
> falls) then a
> fall in the price of one of the factors of
> production stimulates
> demand for the bundle, *and consumers spend more on
> the other factors
> of production*.
>
> Now, consider the bundled good that is the ability
> to handle
> information on computers. This good has numerous
> factors:
> hardware, programmer time, software licenses,
> electricity to
> run machines, etc. The above model predicts that
> cost reducers like
> commodity hardware and open-source development will
> pull programmer
> salaries *up*, not down -- and this is consistent
> with the real-world
> evidence.
But that doesn't deal with ANY of the examples I gave,
such as SAP, Oracle and Photoshop. Real world
evidence DOES show that salaries CAN go up as prices
go down IN CERTAIN CASES. It also shows that in other
cases (SAP, Oracle, etc.), high prices give cover to
high salaries.
I think you're vastly simplifying the data to suit
your point.
> You believe the opposite because you're fixated on
> sale value.
> But,
> in fact, very few programmers are paid from sale
> value.
I'm NOT only talking about sale value. I'm talking
about the manner in which software acquires value.
People convinced that software should cost money will
pay more for developers, just as people convinced that
coats should cost $1000 will pay more for tailors.
> Rather,
> they're paid a portion of the productivity increment
> that they deliver
> to employers who *use* what they write. The effect
> of open source is
> to increase their capacity to deliver use value to
> their employers
> (because, among other things, they can spend less
> time reinventing
> infrastructure and more time on business logic).
But that applies as much to closed source as open
source. If I REUSE components in Windows (HTML
Rendering, Media Handling), I'm not "reinventing the
wheel," as it were. With open source, however, you
run the risk that someone will create an incompatible
variant, which is VERY common.
> > Spoken like a true high priest of the open source
> > movement. Bravo.
> Um, two of those sources are texts on neoclassical
> economics.
No, I was talking about the "away, ye infidel, until
you accept the fullness of the truth" tone you were
taking with me.
> Again, you're posing the wrong criterion. Recipes
> are less
> complicated, but *reconstructing them from the
> finished food* is often
> much more difficult than decompiling binaries. The
> problem is that
> the chemicals in food mix and combine in much more
> complicated ways
> than the bits in object code -- the information from
> the "source"
> (recipe) can turn into very subtle effects like the
> degree of
> caramelization of the sugars in a fruit.
You're thinking like an engineer, not a chef. Chefs
do strange things, like try a dish at a nice
restaurant, then go home and recreate it themselves.
It doesn't HAVE to be the exact same chemical
composition.
Programs require higher degrees of similarity, though,
simply because there are so many things that can cause
the performance characteristics to change.
> In the relevant sense, "free" software isn't free
> either, and never
> will be. It doesn't install itself, or maintain
> itself, or know when
> it needs an upgrade. So the right comparison would
> be between
> low-cost food and high-cost food.
Granted. But then again, the average consumer doesn't
tend to upgrade all htat often, or need maintenance.
I know people who still use DOS versions of
WordPerfect. If they got that product for free
originally, they would get one HELL of a lot of
mileage out of it.
As for products that need maintenance (custom software
in corporations), fine...but that applies to
proprietary software AND open source software. In the
latter case, though, you've ensured that people who
MAKE software can't get paid just for that. You've
excised a revenue model, and as I said, there are
advantages to the incentives created by a strong
source of revenue for software as such.
> So: what is it that makes it possible for expensive
> restaurants to
> compete against cheap food? And can you explain why
> they don't
> need to keep secrets to do so? Now apply this model
> to code.
Like I said, the fact that ALL restaurants charge.
Your recasting of the argument doesn't really apply to
software. GPLed software is REALLY and TRULY free for
most consumers. For businesses, they would have to
pay for maintenance, anyway, irrespective of whether
the code was open source or proprietary. In the open
source case, they just run more risk that code will
end up being made incompatible due to in-house
changes, and furthermore, if EVERYBODY is open source,
ensured that no incentive exists to orient programmers
towards the needs of non-technical users.
> > As the cost of automobiles goes down, the price of
> > auto mechanics goes up. The reason is that lower
> > priced automobiles results in higher demand for
> > automobiles, leading to more autos on the road,
> and
> > hence, more demand for mechanics.
>
> The full explanation is that automobiles and
> mechanics are part of a
> "bundled good" which is the ability of the consumer
> to get from point
> A to point B. Now a characteristic of such bundled
> goods is that when
> demand for the bundle is elastic (increases as price
> falls) then a
> fall in the price of one of the factors of
> production stimulates
> demand for the bundle, *and consumers spend more on
> the other factors
> of production*.
>
> Now, consider the bundled good that is the ability
> to handle
> information on computers. This good has numerous
> factors:
> hardware, programmer time, software licenses,
> electricity to
> run machines, etc. The above model predicts that
> cost reducers like
> commodity hardware and open-source development will
> pull programmer
> salaries *up*, not down -- and this is consistent
> with the real-world
> evidence.
But that doesn't deal with ANY of the examples I gave,
such as SAP, Oracle and Photoshop. Real world
evidence DOES show that salaries CAN go up as prices
go down IN CERTAIN CASES. It also shows that in other
cases (SAP, Oracle, etc.), high prices give cover to
high salaries.
I think you're vastly simplifying the data to suit
your point.
> You believe the opposite because you're fixated on
> sale value.
> But,
> in fact, very few programmers are paid from sale
> value.
I'm NOT only talking about sale value. I'm talking
about the manner in which software acquires value.
People convinced that software should cost money will
pay more for developers, just as people convinced that
coats should cost $1000 will pay more for tailors.
> Rather,
> they're paid a portion of the productivity increment
> that they deliver
> to employers who *use* what they write. The effect
> of open source is
> to increase their capacity to deliver use value to
> their employers
> (because, among other things, they can spend less
> time reinventing
> infrastructure and more time on business logic).
But that applies as much to closed source as open
source. If I REUSE components in Windows (HTML
Rendering, Media Handling), I'm not "reinventing the
wheel," as it were. With open source, however, you
run the risk that someone will create an incompatible
variant, which is VERY common.
> > Spoken like a true high priest of the open source
> > movement. Bravo.
> Um, two of those sources are texts on neoclassical
> economics.
No, I was talking about the "away, ye infidel, until
you accept the fullness of the truth" tone you were
taking with me.
