On Fri, 27 Aug 1999, Michael Orion Jackson wrote:
> open source is just fundamentally better than proprietary software, on the
> pratical as well as philosophical level[2].
>
> [2]...in most cases (money is a good motivator for getting it done RIGHT
> NOW and DEAD BANG PERFECT (like embedded software in medical devices, as
> was on /. a while ago), and money typically implies closed source,
> for now at least)
Of course, if some people were really interested in embedded software in
medical devices, then they certainly could form a company to produce such
software open source. The medical companies would probably still have to
pay big bucks because they want some company to stand behind the product.
They would never just download it and use it. Other companies would be
taking a huge risk if they redistributed the open source code for a lower
price unless they had reviewed the whole code body first. And to stand
behind such a software product, companies could continue to demand a lot
of money simply because the demand is high. Of course, they could then
each stand behind their own version of some communal software like the
Linux distributers do, and they'd likely drive the cost down some as they
try to compete for the market.
> The entropy of closed systems increases[3], presuming that some
> change is taking place. If you define the system as being a particular
> piece of software, then the entropy would be the increasing disorder of
> the code as the code base grows larger (the change) or is modified in some
> other way (disorder leading to flaws in the overall logical structure of
> the program, aka that most hated insect, the bug :D).
>
> [3]See pg 99-105 so in P.W. Atkins's _Physical Chemistry_ 6th ed. His
> wording is a little different, but can be summed up by saying that the
> total change in entropy for the total (system + surroundings) must be > 0
> for any spontaneous process (spontaneous = will occur without outside
> interference, like gas expanding or hot things cooling). In closed
> systems, because no outside interference is possible, only spontaneous
> processes are 'allowed,' so deltaS must be > 0.
I'm not sure whether you're actually trying to make an argument based on
thermodynamics or whether you're applying a scientific theory by analogy.
For example, in your case the system is the piece of software. If you're
thinking of the software by itself as a closed system, then the code base
doesn't change size (at least my software doesn't). If you include some
agent of change, such as a programmer, in the closed system, then a lot of
the entropy increase occurs through the programmer's work, consumption of
food, etc., right?
So I assume that you're doing the latter and applying the principles of
thermodynamics by analogy. I have generally found such efforts to be more
confusing than helpful. Analogies are sometimes helpful when trying to
wrap my mind around a new concept, but I never actually apply a theory and
its conclusions by analogy. It doesn't actually add any weight to the
argument, and it often leads to some faulty reasoning about the new
problem. I think Feynman says something about this in "Surely You're
Joking, Mr. Feynman"...or perhaps I'm misremembering.:)
I don't see that thermodynamics necessarily states that code becomes more
disordered as it becomes larger. I would agree that flaws become more
likely as the code gets larger, but I don't see how the principles of
thermodynamics help to make that conclusion. To me, it's related more to
the fact that one person can't hold the whole system in his head anymore.
He must add some structure to the code so that he can depend on the
correctness of the overall design and the interfaces between pieces that
are small enough for him to think about. Then he deals with the small
pieces one at a time. Still, there's more code, so there are more bugs.
If he doesn't add structure and design to the code, then things become
disordered as he tries to structure a large code base by working on small
pieces of code. Without some design up front, he is likely to make some
local modification that violates what some other piece of code was
expecting (since he didn't really design an interface between the pieces),
causing more bugs, leading to more local kludges, leading to more bugs and
related disorder.
> Will we ever expand the size of a cooperative group to include
> everyone? Maybe, but probably not anytime soon. Of course, the
> increased globalization of society (internet, fast travel, etc.) seems
> to be expanding the size of our cooperative groups more everyday...
True. But it also unfortunately puts many people into more constant
contact with those of a group they cannot tolerate. I anticipate
continuing friction between expanding the size and diversity of the
cooperative group and defining and honoring the uniqueness of the "local"
group. People want to join and cooperate, but I don't think many want to
join some global "melting pot" yet. They'd like to participate in the
global while mainting the local identity. It's certainly an interesting
time to be alive.
> In open systems, there is _no effective barrier to adding programmers to
> the project_.
Well, most projects have some sort of gatekeeper or gatekeepers who decide
whether to commit a submitted change. The effective barrier is the amount
of work that the gatekeeper can do.
The really nice thing about open software is that bug fixes don't have to
come from a dedicated developer. Someone can make a single contribution
to a project and then not work on it ever again. In the close source
model, only those dedicated to the program ever have a chance of
submitting a bug fix. These "one feature/bug fix" contributors are one of
the striking distinctions between open and closed source models.
> In the commercial market, from what I understand, programming teams
> have quite a lot of comm. overhead tyically: meetings, you have to
> obtain permission to modify the source code, more meetings, you have
> to coordinate your source changes with the other components of the
> programming team, more meetings, etc.
Of course, in a company (open or closed source) that makes embedded
software for medical devices, these meetings may be necessary to ensure
the correctness of the code. In this case, incorrect code could
definitely lead to huge lawsuits. Open sourcers have generally stayed
away from software that *must* be guaranteed to be reliable. Is this area
one of those that Raymond identifies as not very suitable for open source?
> The open source model seems a bit different, though: any interested
> party can get the source code from some (typically at one point or
> another centralized) source
...
> Someone or a team of someones on the other end decides whether or not
> to include the changes. Repeat as many times as desired... The
> communications overhead is still there, but it is much smaller
> compared to what it would be for a traditional programming team of the
> same size
See below for my comments on how most of this isn't really a difference.
The big difference here is "any interested party can get the source code."
One other difference is that the evolution of the code is not guided and
shaped "top down." Of course, few companies are currently willing to let
the code they sell to develop "organically" from the ground up. Linux
moves forward quickly, but it winds and meanders along its way based on
the whims, interests, and energy of the programmers involved. Thus,
meetings aren't really necessary since Linux doesn't really care where
it's going as long as it's forward.
> (can you imagine trying to corral all several million linux developers
> into _one team_? ouch...)
I thought the estimated install base for Linux was only several millions.
Certainly they are not all developers. I would guess that there aren't
more than a couple of hundred doing any significant work on any given
component of GNU/Linux. Of course, add to that the "one time
contributors" that I mentioned above.
I guess I don't see the difference between Linux and closed software
development models in the manner that you do. There is a person or team
who controls whether modifications are added to the code base. There are
teams of developers who work on separate components of the system. Each
team may have it's own "gatekeeper" who sends code up to the higher level
for inclusion. The higher level gatekeeper decides whether the submission
fits with the overall design and forwards it up to the top or returns it
with comments. So far, they sound similar. It sounds like the
development of Linux. It also sounds like the development of Windows. :)
I'll perhaps send a message a little later about the few major differences
I see between open and closed source development. All I have time for at
the moment is a flurry of criticism of what you were kind enough to write.
;)
> Beyond that, my gut feeling that this is so, I think that by drawing
> concepts from formal fields of study and by making appropriate analogies,
> it can be show on a more quantitative level that this is the case.
See above for warnings on the dangers of applying a theory by analogy.
> [10] Typically, open source software depends on folks wanting to
> contribute to it. I don't think anyone really _wants_ to work on boring
> stuff like ERP software, or those that find ERP software non-boring are
> rare... So you have to _make_ people want to do it. How do you do that?
> Money, lots of it, prefereably accompanied by lots of nice secondary
> benefits.
I don't know. People code to solve problems. Of course, programmers
generally have a few favorite application areas or technologies. They'll
work with any technology that helps them with their favorite application.
They'll work on any application that lets them play with their favorite
technologies. Many programmers are willing to work with technology they
don't really like to solve problems that don't interest them if there is
enough money involved.
> If you are a company and you have paid through the nose to develop
> something and your livelyhood depends on it, your tendency to release
> the source code is likely quite low...
True. Like Stallman said, in a free software world, programmers will
still be paid, they just won't be paid as much. No wonder his message
wasn't so popular with the coders. :)
---Tom
P.S. Thanks. That was an interesting read. I'm sorry that I don't have
time for more than a quick attempt to attack your arguments. More to come
later, perhaps. :)
-------------------------------------------
Tom Bryan
Applied Research Laboratories
University of Texas at Austin
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
