B
> As a developer I do see value in access to source code. But I wonder
> how many users have the time, temperament, skills, and ability to
> "customize, fix bugs, and truly understand in detail" any complex
> application
presented
> in Open Source. Sure, you can get the source code for Netscape
> Navigator
-
> but who wants to work in that rats nest? Open Source does not
> necessarily equate to well documented, clean, elegant, reliable, or
> maintainable.
I'm going to weigh in on this point with a little story.
Years ago when first learning about analog data acquisition I bought a cheap, 8 bit board from Omega. It included QuickBasic programming examples that talked to the board through a TSR driver that was written in assembler.
Problem was, I couldn't connect to the board, and (having a copy of Borland's assembler) single-stepped through the driver to find out why.
Now, let it be known I am never going to be a top notch assembler programmer, although at that particular point in time I'd just had an extension course in 6502 machine language programming, and was playing around with such things. Thus, I had a general knowledge of how the CPU operates on this low level, but never a great desire to live "down there".
Anyway, I was successful in finding out what was wrong, fixed the problem, and everything worked jake after the assembly language source was recompiled.
My point is, if the need is great enough, and the source is available, then I (and, I would suspect, others with similar or better backgrounds) have a chance to make broken software work, and learn something along the way. If the source *isn't* available then there are a lot more hoops to jump through, and the knowledge level to jump through them is so much greater that the chances of success are go closer to zero.
It isn't necessary to understand the entire application to fix such problems, any more than it is necessary to know all the nuances of how a particular machine operates in order to find and replace, for instance, a relay with an intermittent contact. Having the schematic comes in darn handy, though, if the control system is of any complexity!
Without a schematic it's usually necessary to pull on wires, and go nuts with a VOM tracing out what gets connected where, then scratching it out into the trusty dirt-stained and gloop contaminated notepad to create a field drawing of what appear to be the relevant circuits. This can be (and usually is) a slow and painstaking process that costs a lot of money in machine downtime, and what you end up with is only a portion of what you should have had to start with - a circuit diagram.
Same goes for the next steps up on the evolutionary ladder - discrete circuit boards using transistors, op amps, and logic gates - except the details of how the system is traced out are different, and the difficulty and knowledge levels goes up a bit.
I think the analogy holds with software as well. Source code is the circuit schematic of computer programs, and, if I find a need to understand what's going on, having it is much preferable to not having it. If it's well-commented and written so much the better (although I'd argue it's more important to have source when the program *is* a plumber's nightmare; reverse-engineering an abomination is much harder than if the program is sound to begin with).
Bob
> how many users have the time, temperament, skills, and ability to
> "customize, fix bugs, and truly understand in detail" any complex
> application
presented
> in Open Source. Sure, you can get the source code for Netscape
> Navigator
-
> but who wants to work in that rats nest? Open Source does not
> necessarily equate to well documented, clean, elegant, reliable, or
> maintainable.
I'm going to weigh in on this point with a little story.
Years ago when first learning about analog data acquisition I bought a cheap, 8 bit board from Omega. It included QuickBasic programming examples that talked to the board through a TSR driver that was written in assembler.
Problem was, I couldn't connect to the board, and (having a copy of Borland's assembler) single-stepped through the driver to find out why.
Now, let it be known I am never going to be a top notch assembler programmer, although at that particular point in time I'd just had an extension course in 6502 machine language programming, and was playing around with such things. Thus, I had a general knowledge of how the CPU operates on this low level, but never a great desire to live "down there".
Anyway, I was successful in finding out what was wrong, fixed the problem, and everything worked jake after the assembly language source was recompiled.
My point is, if the need is great enough, and the source is available, then I (and, I would suspect, others with similar or better backgrounds) have a chance to make broken software work, and learn something along the way. If the source *isn't* available then there are a lot more hoops to jump through, and the knowledge level to jump through them is so much greater that the chances of success are go closer to zero.
It isn't necessary to understand the entire application to fix such problems, any more than it is necessary to know all the nuances of how a particular machine operates in order to find and replace, for instance, a relay with an intermittent contact. Having the schematic comes in darn handy, though, if the control system is of any complexity!
Without a schematic it's usually necessary to pull on wires, and go nuts with a VOM tracing out what gets connected where, then scratching it out into the trusty dirt-stained and gloop contaminated notepad to create a field drawing of what appear to be the relevant circuits. This can be (and usually is) a slow and painstaking process that costs a lot of money in machine downtime, and what you end up with is only a portion of what you should have had to start with - a circuit diagram.
Same goes for the next steps up on the evolutionary ladder - discrete circuit boards using transistors, op amps, and logic gates - except the details of how the system is traced out are different, and the difficulty and knowledge levels goes up a bit.
I think the analogy holds with software as well. Source code is the circuit schematic of computer programs, and, if I find a need to understand what's going on, having it is much preferable to not having it. If it's well-commented and written so much the better (although I'd argue it's more important to have source when the program *is* a plumber's nightmare; reverse-engineering an abomination is much harder than if the program is sound to begin with).
Bob
