RE: [zzdev] Re: :gbg: Flame: User-hostile ethic of the Linux comm un ity

[Joshua Allen <joshuaa@xxxxxxxxxxxxx>]

Just getting this now, maybe my e-mail is messed up?

> It is very different.  Changing source code is feasible.  Being
> compelled to do the job by changing compiled code is extremely hard.
> 

Changing source code is no more feasible for the vast majority of people
than is changing byte code.  Even most tech people are not successful when
they undertake to modify a program's source.  However, I do not disagree
with you about my comparison being exaggerated.  The matter of degrees *is*
arbitrary, however.  For example, yesterday evening I spent a number of
hours working to download still images from my DV-enabled camcorder. The
software that the manufacturer provides works only on Windows 95, but all it
does is communicate through the serial port (JLIP or something), and the
serial communication piece is what breaks on Windows 2000.  So how hard is
it to do serial communications?  Not hard at all, but how successful do you
think I was in finding documentation on the protocol that the serial
interface requires?  I know for a fact that I could write an image
downloader in short order if I had that documentation, but alas it is not to
be found.  If I were really stubborn I might "sniff" the communications on a
Win95 box, but then what's the point?  So my next attempt was to purchase a
firewire card for my PC, and use the firewire connector on the camera.  It
turns out that firewire doesn't abstract out camera-specific details,
though, so I needed drivers specific to the camera, and the ones I found
were no good.  Furthermore, the firewire transfer exacerbated
incompatibilities between NTSC and PAL.  Another example is when I wrote
some code that lets me control my stereo from anywhere in the house from a
web browser on any wireless device.  The tricky part was the functions that
needed infrared.  I was shocked to find that certain devices use one
modulation and others another.  It is very difficult to build a device that
controls infrared devices from a computer; I eventually bought something
from a guy in the U.K.  On the other hand, to tell my computer to play songs
out the stereo took exactly two lines of code:

Set o = CreateObject("MediaPlayer.MediaPlayer")
o.Play "d:\songs\some song.mp3"

Now, I have been using Linux for 8 years and Unix for longer (I have worked
professionally with Irix, HP/UX, Solaris, etc.)  During linux's a.out days,
I was one of the strongest advocates for the community development process
(and I still believe in that).  However, I could not honestly say that the
task of setting up an at-home web-stereo would have been even close to as
easy on Linux.  In fact, even as recently as last week I was attempting to
do some streaming media things with Linux (Redhat 7.0) and find that the
player is not stable or reliable, and good luck finding an SDK.  I have also
been working with web services, Apache/Tomcat/SOAP/Xalan, since I am now a
very strong advocate of XML as a way to assuage inevitable
incompatibilities.  Now, keep in mind that my first web servers were all
versions of CERN-HTTPD that I modified myself, so I should be comfortable
with Apache, but I personally found it very cumbersome, time-consuming and
annoying to get my Linux web services talking to SQL2000 and IIS5.  So even
IF you only look at it from the "geeks" perspective, I think that it is
prohibitive for an open source developer to make changes, while it is easy
for someone developing with closed-source software.  Of course, there are
things you can do with full source that are impossible without, and I do not
deny that.  But those aren't the things that I want to do, and they are not
the things that most people want to do.  And to modify StarOffice to do the
things that are brain-dead to customize in Word *is* so complicated as to be
impossible.  So on the one hand, open-source sacrifices the ability to
*practically* make many desirable changes to a product in order to gain the
ability to *theoretically* make *any* change to the product.  On the other
hand, closed-source sacrifices the ability to use source code to
theoretically make *any* change to the product in exchange for a product
that is ruthlessly focused on being customizable in just the ways that users
want.  I mean, you will never win a wager if you take a survey of the sorts
of customizations that people want to do with their tools, then compare how
many of the people surveyed can actually accomplish those customizations on
Linux vs. some other system -- if you were to bet that Linux wins your
"freedom to change" argument.  Not only will open source lose that wager
with *users* in the sense that Ted originally spoke, but it will lose even
with "geeks" and "programmers".

Honestly, if you look at how *closed* things like hardware specs are, is
that something we organize politically around?  We understand that *most*
people don't want to write their own JLIP interface, and we groan and mutter
when Sony doesn't publish specs, or when we find out that firewire
"compatibility" isn't really that compatible.  But we accept it.  On the
other hand, we have software today that is more customizable, more
adaptable, and more programmable than ever in history.  I used to modify
source code of an ERP (back then it was called MRP) system to tailor to
customer needs.  Why anyone would want to go *back* to those days is a
mystery -- modern systems like SAP and Baan let me write a Java or COM
plugin to customize the stuff I really want to change...


> freedoms listed in the definition of free software, and "allowing" people
> to do this by disassembly is still artificially obstructing it.

It is true that it is artificial to not give source code.  From my
perspective, the people wanting to keep source-code closed have valid
interests that they are trying to protect and the people wanting access have
valid interests.  "Access to source" is a red herring, though -- software
developers want to know that their intellectual investments can be
protected, and developers/users want to know that their customization needs
can be reasonably met.  Access to source may be part of a solution, but it
is not the ultimate end that should be focused on.  There are creative ways
for software vendors and users to both get what they want, and the most
successful negotiations (and the most successful markets) focus on the
interests of the parties involved and attempt to build win-win solutions.
When you focus on making both sides happy, you generate good solutions.
When you focus on something like "source must be open", you often end up
working at odds to the needs of the constituency you claim to represent.
You sacrifice their overall freedom in search of an ideal of freedom.  This
is what prompted the thread -- ever since the software community was
hijacked by the politicians, software developers have been asked to make
development decisions based on religious interpretations of what their best
interests are, rather than what they find works best for them.  And that
ideal of freedom is unnatural, because it requires you to describe vendors
and users in opposition, as if source is "closed" deliberately to rob users
of the right to customize, or as if the only way that users or vendors can
profit is when one of them loses.

> Saving time is not gaining "freedom".  If you stretch the word
> "freedom" to include all possible benefits, the word becomes vacuous,

But you just said it is.  Because you said that it is too much work for
Russians to publish their own newspaper or for developers to modify object
code.  Why are you "free" when you can modify C++ code instead of assembler,
but your are *not* "free" when you can use the language of your choice to
script instead of being forced to adapt yourself to someone's crappy C++
coding style?

> and the distinction between freedom and other values becomes difficult
> to communicate in words--but this does not make it any less important.

Certainly freedom is important, and I do not find my concept of freedom
difficult to communicate.  And I'll admit that I find your definition of
freedom a bit difficult to understand, but likewise is probably true for you
attempting to understand mine!  We apparently are wearing different colored
glasses...