Open Source and Hot Rods


I was surfing the web the other day and ran into someone linking to this article by Jack Lanier from Edmunds (the automotive newsletter people).

The article’s entitled “Friends Don’t Let Friends Modify Cars”.

From the article:

Today, it’s difficult to make cars better and extremely easy to make them worse. Or dangerous.

As a journalist driving modified cars, I’ve been sprayed with gasoline, boiling coolant, super-heated transmission fluid and nitrous oxide. (The latter was more entertaining than the former.) Several have burst into flames. Throttles have stuck wide open, brake calipers snapped clean off, suspensions ripped from their mounts and seatbelt mounting hardware has dropped into my lap. All this is on top of the expected thrown connecting rod, blown head gasket, exploded clutch, disintegrated turbocharger and broken timing belt.

The vast majority of these vehicles were built by professionals. Many were from big-name tuners. Most performed as if they were constructed in a shop class at a high school with a lax drug policy. Once, after a suspension component fell off a car from a big-name tuner, the car actually handled better.

For every modified and tuner car that performed better than stock, I’ve driven numerous examples that were slower. If they were quicker, it was often in an area that can’t be used on the street. What’s the use of gaining 0.2 second in the quarter-mile if the car is slower 0-60 mph? And costs $10,000 more?

[…]

Recently, I autocrossed a pair of Subaru WRXs. One was a dead-stock WRX. The other, a tricked-out STi lowered with stiffer springs, shocks and bars and an exhaust kit and air filter. The STi is supposed to have an advantage of some 70 horsepower. Maybe the exhaust and filter moved the power up in the rev band where it couldn’t be used. The lowered, stiffened STi regularly bottomed against its bump stops. When a car hits its bump stops, the spring rate goes to infinity and tire grip drops to near zero. This caused the STi to leap into the worst understeer I’ve experienced with inflated front tires. Meanwhile, in the unmodified WRX, I could be hard in the throttle at the same point. The result: The dead-stock WRX was at least as quick as the STi and far easier to drive. Easy to make worse, harder to make better

I read this article and was struck by the similarities between this and the open source vs COTS model.

COTS (Commercial Off The Shelf) software is equivalent to a stock automobile.  They’re built by professional engineers, and tested as a whole.  But you don’t get to mess with the system.

On the other hand, open source gives you the ability to join the software equivalent of the tuner/modified market – you can tweak the system to your hearts content.  You may make it go faster, but you’re not totally sure what it’s going to do to the overall quality of the system.

In fact, I constantly read that that’s one of the huge benefits of open source – on an open source project, if you don’t like how something works, you can just step in and fix it, while with COTS you don’t have that ability.

Software engineering is software engineering, whether it’s open source or closed source.  Having the ability to tweak code (or an automobile) doesn’t automatically mean that the tweak will be higher quality than what it’s replacing.  It’s entirely possible that it either won’t be better, or that the improvement won’t really matter.  On the IMAP mailing list, I CONSTANTLY see people submitting patches to the U.W. IMAP server proposing tweaks to fix one thing or another (even though it’s the wrong mailing list, the patches still come in).  And Mark Crispin shoots them down all the time, because the person making the patch didn’t really understand the system – their patch might have fixed their problem and their configuration, but it either opened up a security hole, or broke some other configuration, etc.

Btw, the same thing holds true for system modifications.  Just because you can put a window into a hard disk doesn’t mean that the hard disk is going to work as well afterwards as it did before you took it apart.

Just like in the automotive world, simply because you CAN modify something, it doesn’t mean that it’s a good idea to modify it.

Comments (73)

  1. jmayeur says:

    he-he,

    Okay so I read this I think well lets look at a COTS IDE, VS.Net 7.1, which runs relatively fast most of the time [although it does grind to halt occasionally ], but has this nice feature, of Chucking up a Null Pointer Exception Dialog box, to which you can click OK and watch VS disappear with your last few minutes of work. Versus, a open Source IDE like Eclipse, which albeit a little less "packaged" and a little slower, and much more "hobbyist" does not have the nice feature of disappearing…

    But I should prefer the COTS IDE? because its ? better ?…

    I see your point, but raise you that the IDEAL solution is a pairing of OS Dev, with COTS finishing. Ideas that involve large collective contributing bodies do tend to slip towards incoherence, but on the other hand, they avoid the stagnation inherent in projects where the same 10 engineers keep looking at the same 10 problems. Just a thought, but this post seemed a little to β€œnarrow” in its view.

  2. Ivan says:

    I think it would have been very hard for people to make win9x any worse.

    Ivan.

  3. To extend that analogy, if cars were closed source software you wouldn’t be able to get an oil change without visiting an authorized dealer and forget looking under the hood; you’d be arrested for breaking the law.

  4. Ivan,

    You have no idea πŸ™‚ You have REALLY no idea how much worse Win9x could have been πŸ™‚

    JMayeur. I was not making a comment about the relative quality of OSS vs COTS. There are many high quality OSS solutions out there, just like there are high quality COTS solutions out there. And there are low quality examples of both as well. But the ability to tweak the code isn’t a benefit of OSS.

    Kristoffer: That’s scheduled maintenance. A better example for cars: If cars were closed source software, you wouldn’t be able to go to a 3rd party to buy a replacement door without voiding any and all warrenties.

    Oh wait, you can’t go and buy a 3rd party door for your car without voiding the warrenty.

  5. Chris T says:

    This isn’t limited to open source. It frequently happens with commercial software as well. If you don’t fully understand the totality of the system you’re working on, you can’t know every last effect of the change you’re making. Saw this at Apple all the time.

    In the extreme cases, what happens is this: the original programmers of a large complicated system moves on, and nobody else knows how the system works, at least in detail, and so new changes, even minor ones, cause major regressions, until the new guys figure it out. Typically, there isn’t time (because of schedule pressure) for the new guys to learn every last nook and cranny.

    I’ve been on both sides of this; I’ve had to come in and learn new large complicated systems under time pressure (causing regressions in the progress) _and_ I’ve had to reject changes from members of _my own team_ on occasion. System software is not as hard as it is sometimes made out to be, but you really have to understand the binary compatibility, performance, and security implications of your changes.

  6. Ryan says:

    The last line in the entry reminded me of one of my favorite Chris Rock bits that ends with him saying "just beause you CAN do something doesn’t mean you SHOULD. I mean you probably COULD steer your car using your feet, that doesn’t make it a good fu*&ing idea" πŸ˜‰

  7. bramster, I’m not sure.

    On the other hand, after feasting on an unending diet of hot rod and modder shows on the Discovery channel (all custom build, all the time), I thought it was interesting to see an alternative view.

  8. bramster says:

    Having seen some unfortunate results in the comparison of cars and software, I might have been a little more judiciuous in selecting an analogy.

  9. Chris says:

    I think the best Car/SW comparison is this:

    Open source, you buy the car, you are entitled to open the hood and see what is going on.

    Closed source, you buy car, if you dare open the hood, you are breaking the law!

  10. How about:

    Closed source, if you buy car, if you start looking at the chips that run the timing, you are breaking the law.

    Oh wait, if you start looking at the software on the chips that run the car, you ARE breaking the law.

  11. JD says:

    I will not be surprised if you get slashdotted and get all the OSS zealots coming in to shout at you.

    To come to the main topic, I couldn’t agree more with what you said. For any non trivial software, it’s surprisingly difficult to do code enhancement/fixes if you don’t know the big picture. To give my own example, I use WordPress as my blog tool and I created a hack to modify the admin login URL. Matt, the person who started WordPress, found in a split second what I was doing was totally pointless. [See our discussion here, http://jdk.phpkid.org/index.php?p=1131#comments ] And he was absolutely right! My hack was completely useless. This was only because I didn’t know how the overall software worked and how the different pieces were fitting with each other. And for any software project of decent size, expect to spend hell lot of time to really understand what’s going under the hood. If you know how it works inside/out, then only dare to modify it. And even after that, you will never be sure how good job you did. So I agree with you 100%.

    JD

  12. The thing is, if software was like cars, I’d agree with you.

    But it isn’t – even in Microsoft, where you spend ages testing and preparing, software (and hardware) is poorly made and poorly designed.

    Now, space shuttle software – you’d have a point, and I’m sure a good case could be made for software BEING built like that. When it is, then OSS will not compete unless it is built in a similar way. But at the moment we’re still at the stage where the factory bought stuff isn’t much better than the modified stuff.

  13. bramster says:

    Larry:

    I went back and looked at your source. . . removed from your citation was

    "Long ago β€” when your grandparents were kids and the president was Dwight Eisenhower β€” it was easy to improve cars. Back then, carmakers designed vehicles largely for production convenience. It’s not difficult to improve the handling of a car that had one steering idler arm a little longer than a man’s shoe and the other more than the length of his arm: Stiffen the suspension to the point that it doesn’t move. Also, in the olden days, cars were so simple virtually anybody could work on them. Replacing the stock two-barrel carburetor (ask your grandfather) with a four-barrel reaped easy power: There were no sensors or computers to confuse, as often happens if you tinker with today’s engines."

    Hmmmmmm. . . What if one were to consider the relative maturity of the auto industry and the software industry?

    and, re: Discovery Channel. . . It strikes me that a lot of not-very-complicated modding/building/rebuilding jobs are of the "We’re going to do an eight-week job in three weeks", and watch the participants self destruct. These shows have about the same educational value as Pro Wrestling.

    Off the main topic — I follow this and Raymond’s blog with the goal of learning. Mostly I feel like I’ve been stuck into the cockpit of a Boeing 747 before having soloed in a Cessna. . . but I treat the experience as a big hologram. With each session, with all the excellent input of the blogger and the commenters, more pixels get turned on, and the picture is slowly emerging. Now, THERE’s a murky analog πŸ™‚

  14. JMayeur says:

    "JMayeur. I was not making a comment about the relative quality of OSS vs COTS. There are many high quality OSS solutions out there, just like there are high quality COTS solutions out there. And there are low quality examples of both as well. But the ability to tweak the code isn’t a benefit of OSS. "

    Okay I got that, but I disagree. The was I see it, is that the ability to tweak code is a benefit of OSS. Not beacuse an indivual tweak will neccessarily be the holy grail for an OSS project, but because the collective effect of these tweaks is a net benefit. Think Ocean/ Ebb and Flow… OSS allows both for the good and bad to naturally occur, when and OSS project is mature [or close to it], then I think closing the doors for the final set of refinements will end with a better COTS, than software that is COTS its whole life-cycle. Again, I don’t disagree that tweaks are bad, I’ve paid that price a few times, but looking at a project like Hibernate, without tweaks it wouldn’t be have as good as it is now… tweaks=exploration ~ evolution…

  15. Larry, the Magnuson-Moss Warranty Act says that you cannot have your warranty voided just for installing a 3rd-party part. Also, there is also no law preventing you from merely looking at the software that runs your car.

  16. <quote>

    Oh wait, if you start looking at the software on the chips that run the car, you ARE breaking the law.

    </quote>

    Not if you do it for compatibility. If you’re designing a satellite navigator that has to connect to some chip in the car, you can reverse engineer it. Microsoft itself does that all the time to keep backwards compatibility, just look at how the sims was kept working on new versions of windows…

    <quote>

    You have no idea πŸ™‚ You have REALLY no idea how much worse Win9x could have been πŸ™‚

    </quote>

    oh yes, it could not boot at all πŸ™‚

    Still a friend of mine says he prefers win98 to xp.

    <quote>

    Oh wait, you can’t go and buy a 3rd party door for your car without voiding the warrenty.

    </quote>

    BTW I beleive you meant warranty, not warrenty

    Ivan.

  17. Nicholas,

    I was unaware of that. I wonder how Ford would feel if someone came in for warranty service on an engine and they found a 3rd party fuel injector on it though.

    According to this site: http://www.zo6vette.com/forums/showthread.php?t=74875 the MR Warranty act has no teeth – it doesn’t mean you can’t have your warranty voided, it just means that you can sue to get the warranty enforced.

    This modding site says similar things: http://www.awe-tuning.com/pages/faq/awefaq_main.cfm?FAQ=27

    I’m not a lawyer, but I suspect that the automotive companies protect the IP in your car rather furiously.

    Andrew: I’d challenge your comment about poorly made and poorly tested.

  18. Allrighty, how about some mundane part in your car breaks. Say the break light. Easy enough to fix if you are allowed to. With a closed source car you’re stuck waiting until somebody gets around to changing your bulb. With an open source car you go switch it out and continue on your way.

    We can do silly metaphors all day and you won’t convince anyone that closed source is better than open source.

    I think the most overlooked value of open source is the learning that can take place from it. If you give a beginning programmer access to good source code they can learn from it and in turn produce even better code; on the shoulders of giants and so forth.

  19. Kristoffer, good points.

    And you’re right about the ability to see the source. Jason Matusow (director of shared source at MS) has some related thoughts here:http://blogs.msdn.com/jasonmatusow/archive/2005/03/10/394009.aspx

    It’s worth reading.

  20. James says:

    How many custom cars make it to the mainstream market? Most of the mods mentioned seem to have failed terribly on the first try, so it’s unlikely it will be done again.

    It’s certainly true most patches, like car mods, are poorly designed or implemented or just plain unnecessary. But just like that journalist, the open-source community are the test-drivers who evaluate or try the patch. They report just how bad of an idea it is – or maybe they pick up on a really neat idea or fix.

    Hopefully the person who used an undersized bolt on the brake calipers would learn from experience and not repeat his mistake. We can hope for the same in the open-source community.

    Is trial-and-error the best way to learn good engineering practices? Perhaps not.

    But with closed-source software, that is not even an option.

    -James

    P.S. Whether software developers are improving their trade is another debate. I have been less than impressed with this industry – and I am in the industry.

  21. Kristoffer, good points.

    And you’re right about the ability to see the source. Jason Matusow (director of shared source at MS) has some related thoughts here:http://blogs.msdn.com/jasonmatusow/archive/2005/03/10/394009.aspx

    It’s worth reading.

  22. Jerry Pisk says:

    The problem with the analogy is that a lot of open source is built by software professionals, not by some hobbyist users. They do get paid for it (a lot of the time with taxes collected from all of us) and they do create code that’s at least on par with COTS software. Also most users do not modify their open source, that’s just not sustainable as you would either be stuck with your version or would have to port your changes to every new release but rather they submit their changes/fixes to the original developers to put it in.

    And another point in the car/open source software analogy that doesn’t hold up – open source software is not modified commercial code. It’s code started from scratch. Even projects that od start with commercial code eventually realize that it doesn’t work (wink wink). Comparing it to patched up commecrial cars doesn’t work.

  23. Larry,

    You’re right that Ford may have an argument that your fuel injector damaged the engine. But they’d have a burden to explain why that’s the case. And it would certainly be difficult to explain why your new door panels caused the engine to fail.

    I’m not sure what that argument about "no teeth" is about. Every law is like that! Laws provide a means of relief not prevention.

    Car companies certainly do protect their IP. Looking is not restricted by copyrights, patents, or other common IP protections though. You can sign a contract promising not to look and that would stop you (from above, it wouldn’t actually stop you but they could sue for relief if you did look). You can sell your car to whoever you please and they’ve never signed a contract with the manufacturer. That makes it tougher to restrict what you can do.

  24. For all those patches you see that mess things up, there are a few — 1 or 2 percent, perhaps — that help things. (If you don’t see any, it probably has something to do with looking on the wrong list.) That’s one difference between the quality of open source and closed source software — in the closed source world, that 2% doesn’t exist.

    Not only that, but perhaps the patch that fixes their config, but breaks somebody else’s, is good enough for them. My father’s car used to have stiffer back suspension springs — a mod. It was good for him, because he had a couple tons of stuff in his trunk all the time. It would probably have been very bad for the average user of that make & model of car, but that wasn’t a concern for him.

    Open source, when it works, is taking the best parts from millions of shop students with lax drug policies, and putting them together. If you have a good person putting them together, you can get a pretty impressive machine out of it… assuming a few of the kids in shop class actually have decent skills.

  25. Ivan, that’s off-topic. The issue under discussion is solely the ability to tinker and tweak your open source distribution.

    Protection from vendor failure is off-topic.

  26. Scott says:

    Yeah, but Larry there’s a big difference between wanting to change out the gearbox and wanting to be able to put a new steering wheel on the car. I can’t even change the seats easily in Windows. The best I can do is buy aloha print seatcovers and put them over the seats.

  27. Ivan says:

    Another problem with closed source is that if the vendor goes bust, in most cases you’re f%&*$d up, end of story. With open source, even if all developers find something better to do and abandon the app, you can always hire someone to maintain/improve the app for you, and that may be a very good thing if your business depends on it.

    Ivan.

  28. Bryan says:

    There was an interesting article that was published a couple of months ago that had a similar theme:

    http://www.infoworld.com/article/05/01/14/03OPconnection_1.html

  29. Stuart,

    So you’re saying that the open source model requires a single gate-keeper to ensure the quality of the product?

    What happened to the bazaar if only one person (or one set of persons) decides what gets contributed?

  30. Your UW IMAP example demonstrates not a weakness of the Open Source model, but a strength.

    If 100 bad patches come in and are ignored, nothing is lost for anyone (and the people who wanted the tweak can use it, or not if they come to an understanding of why it’s a bad idea). If one good patch comes in and is accepted, something is gained for *everyone* who uses the software.

    The open source software gains one improvement out of 101 submissions.

    The closed source software never gets any submissions and never gains anything.

    Which is better off? The open source one.

  31. The project described as "the bazaar" in "The Cathedral and the Bazaar" had all contributions going through a single person…

    I think the bazaar model is about transparency of development more than anything else.

  32. Larry: I’m not saying "Microsoft software is crap compared to open-source/Novell/IBM" – I’m saying that modern day software is generally poorly produced and has nowhere near as much discipline as say, software for the space shuttle (and they still get that wrong from time to time, depressingly).

    Now, I don’t think the development environments are there to make all of this practical to do now – and I think Microsoft are doing a lot more than people think to make things better, but can you honestly say that you don’t think that software will be radically better in, say, 10 years? Testing is only one part of it (and I didn’t criticise Microsoft’s testing, as I know they make Herculanean (sp?) efforts to perform lots of testing – but comparatively the design of large elements of modern software spends forever trying to make it fast rather than trying to make it robust.

    Modern software is written at far too low a level, has almost no real static checks for correctness, is rarely backed by statically checkable models, and is far too unreliable in general.

    How much software really needs to be written in C/C++? Why does neither C# nor Java have statically checked non-null values (the Microsoft Research guys were investigating this, and Nice – an extension to Java has it). What about bounded range types? (value between 0 and 255, statically checked). Why do we use integers directly – if it can fit into a smaller set then that should be done by a static checker/optimiser. Otherwise it should be able to automatically extend.

    We still persist in doing manual storage management when we could use region inference and region checking instead and use lifetime hints where necessary if garbage collection is too non-deterministic. At the very least we could use these to back storage hints up.

    We persist in writing complex multithreaded code rather than learning from Erlang and similar systems which hide these complexities behind message passing. There are checkable models for deadlocks and livelocks and fairness available.

    I think Microsoft spend a lot more time on software quality than many people give them credit for – but my attack is not aimed at them, it’s aimed more at the quality of software in general. I think that modern software is very much more like the badly hacked up cars that you allude to than the nicely perfected heavily tested, heavily simulated (remember, windtunnel simulators and so on are used to design these things) cars that you and I might buy.

    Of course, this doesn’t stop our 4 year old Peugeot refusing to stop wiping the windscreen if you make the mistake of putting windscreen wash on it (and this being a fairly common problem), but overall I’d say that the motor industry is significantly more advanced than the computing industry in terms of quality.

    Sorry, this was a bit long, feel free to trim it down πŸ˜‰

  33. nil4 says:

    The worst that could happen is that the person who contributed the modification forks off his own, private version of the code, that he can distribute to anyone else interested.

    IMHO, that’s sometimes better than getting the "wontfix (by design)" stamp for a bug that’s really annoying, from everyone’s favourite COTS vendor πŸ˜‰

  34. Anonymous says:

    Techie life – Phillip Renouf’s blog &raquo; Open source is like Hotrodding?

  35. Heh. I was thinking about something similar to this a while ago and I blogged this:

    http://www.vbbox.com/blog/2004/09/transmission-tax.html

    I’ve never really liked car analogies but this one quite works.

  36. Drwe says:

    Oh, my. Trying for Slashdot again, Larry?

    Software is like cars? I’m not so sure this analogy makes COTS look so good, actually. Not only will somone post the obligatory OS/automobile jokes, but you’ll have to try to defend against arguments like these:

    – But Windows doesn’t even make it easy for users to change their oil. (People will target Windows even if you keep using "COTS". "Change their oil" will be any number of things that are non-trivial tasks on Windows.)

    – Someone drives a car through a bad part of town and notices later that the car has lots of extra parts bolted together under the hood. Unfortunately, the car is Windows, so the user can’t determine very easily which parts were supposed to be there. Time to take the car to the garage (PSS). Oh, if only it were a FOSS car and the Chilton’s manual were available! Oh if only I didn’t need a special wrench that I can only buy from Microsoft! (Etc.)

    – There’s also the ever-present bickering abotu whether or not software engineering is *real* engineering (IMHO for the most part it’s not).

    – Probably more. I think I’ve probably written too much here already. If I’m a Microsoftie and I work on Windows and I actually like my COTS what can you expect from the anti-Drews out there?

    Stop the torture! Save the analogies!

    Please tell us more about concurrency or something. Somehow when the topic is more technical the comments are both fewer and more insightful.

  37. Drew says:

    Oops. Not trying to hide my identity. Just after I hit "submit" I noticed that I had mistyped "Drew" as something like "Drwe".

  38. Ivan says:

    <quote>

    The issue under discussion is solely the ability to tinker and tweak your open source distribution.

    </quote>

    Sure, and that is one of the conditions where the ability to tinker with the source can be very useful.

  39. Ok Klaus, you did this MUCH better than I could ever have done it.

    That was absolutely brilliant.

  40. Ivan says:

    I agree cars are a very bad analogy for computers, have you ever googled for "if Microsoft built cars"?

    Ivan (Hoping that commenting on the analogy in the post isn’t off topic)

  41. > COTS (Commercial Off The Shelf) software is

    > equivalent to a stock automobile. They’re

    > built by professional engineers,

    So is a lot of open source software. Tied on this point.

    > and tested as a whole.

    Liar. You should have known better than to post something like that after being reminded of stuff like Windows 95’s FDISK command. If Microsoft were dogfooding during Windows 95 development, Windows 95 would never have been completed because when people needed to restore backups from external SCSI disks the backups would be unusable. When that kind of bug happens in open source it gets fixed within days if not hours, and you don’t see vendors years later still denying the bug’s existence.

    The most recent benefit I’m experiencing in closed source is from the VB6 compiler. An order from a customer was to modify a program of theirs and we have to deliver the results next Monday. Some preexisting bugs in the program itself we could fix (besides doing the contracted modifications). But how to get calls to DLLs working when we can’t fix the executable code that VB6 generates and we can’t fix what Access 97’s VBA stuff does, I can’t imagine. Well luckily it "mostly" works. In Microsoft’s vb.bugs newsgroup no one else has confirmed it yet but you know how to do it if you want to talk about how closed source stuff gets tested.

    One of your colleagues even admitted privately that most Microsoft products don’t get the kind of testing that Microsoft US products get. But the case of Windows 95 FDISK is language-independent and 100% reproducible. The VB6 case happens overall less often in the US version than in Japanese but it’s still reproducible.

  42. Matt says:

    Larry,

    You’re being far too generous to the clowns that are suggesting that changing a globe or oil or even seats and doors is the equivalent to writing a well written patch to an Open Source Project.

    Someone with absolutely no background could be taught those basic tasks on a car in a matter of minutes, hours at worst.

    OTOH it would take months at best to learn the language, OS and project in enough detail to write even the most basic patch

  43. Anonymous says:

    Virtual Dave &raquo; Hot Rodding Programmers?

  44. mschaef says:

    " But the ability to tweak the code isn’t a benefit of OSS. "

    I’ve said it before, and I’ll say it again: if that tweak is the only way to get your business done, and you can’t get your commercial vendor to do it for you, than the ability to tweak the code is a HUGE benefit to open source.

    If VB6 was open source, VB6 developers wouldn’t be abandoned: somebody else would take up development. If Windows NT had been open source, I wouldn’t have had to spend five years of my life working around a bug involving the way it ran Borland C++ 4.5 from makefiles/commmand line.

    People call open source the scourge of the market economy, since it lowers software purchase costs to zero. Personally, I think it creates a new market economy. Rather than letting Microsoft dictate what gets fixed in Windows NT and VB6, let the market decide where they want to put their support dollars. If anything, that’ll let software consumers spend their money where they see the value: support and integration. Open source makes this possible for the very reason that it allows anybody to tweak the code.

    (Of course, I can see how this would be a threating point of view to companies dependant on license fees for revenue πŸ™‚

  45. Charlie T. says:

    With power comes responsibility, my son.

    If you’re a structural engineer, you’re not likely to knock down a load-bearing wall in your own house. But any clown with a sledgehammer can knock down a wall.

    Modifying source code is no different. Of course it’s easy to do something stupid, but if there’s a highly talented software engineer who spots a bug, he can fix it.

    But 99% of programmers aren’t highly talented software engineers.

    So you’re 99% right. The ability to modify source code isn’t a valid reason for most people to choose OSS, but if they’re in that 1%, it’s an excellent reason to choose OSS.

  46. Larry,

    A very bad point indeed! The logic is flawed. You sound like "if you have the power to shoot yourself, you probably would, so that’s not an advantage… COTS will deprive you from that posibility and…"

    Well, guess what, most serious and large OSS projects (take Mozilla as an example) have drivers and maintainers that do the check-ins and make sure that the quality of the patch is at least of the set standard. Some vendors have adopted similar practices through different methodologies or simply though internal policy.

    On the otherhand, if I knew that Win2k Sp4 would NOT EVEN WARN ME about the 128GB HDD limitation of the atapi driver and would allow me to partition and format (part of) my already loaded 160GB drive, overriting ITSELF and all other data, because the internal address pointer is 28-bits ONLY and is overflowing beyond the 128GB point… well… had it been OSS, somebody would have added a simple message box to warn me of the limitation… not to mention a simple patch that would have simply resolved the problem altogether. Well the professionals who wrote the atapi driver didn’t know enough to at least recognize the drive as 128GB where their code could work and address it without overflowing. And you don’t want to know what it took to replace about 128GB of lost data and how I found out about the problem and how long it took…

    Is the problem resolved? NO! You MUST manually edit the registry to ENABLE the driver to access larger-than 128GB drives. WHYYYYYY? WHY??? I don’t comprehend. Still, if I enable it, the KB hints that smaller (than 128GB) drives might not work as expected (otherwise why not enable it by default). There goes the $$$ you pay for COTS in lost data, worry and lack of professional solutions to critical issues and support and time. There goes COTS and the product that is built by "professional engineers, and tested as a whole"

    I’m not a die-heart Linux fan, and I do program on Windows (as well as Linux) but your argument doesn’t hold in the practical world. And CTOS stinks in a lot of cases, even if it’s Win2k!

    Cheers,

    Ash

    P.S. I enjoy you blog heaps. Keep it up.

  47. AndyC says:

    Changing the oil is analogous to hacking the registry.

    I’ve yet to see a car manufacturer who provides full blueprints of their latest model to anyone interested in building their own.

  48. Few people would argue that the Linux Kernel isn’t developed as a bazaar – in fact, ESR coined the term bazaar after watching the kernel development process in action.

    Similarly, few people would argue that Linus doesn’t act as a single gatekeeper for changes going into it.

    A bazaar and a single gatekeeper are in no way contradictory – they’re necessary, and complimentary.

    The third necessary factor is that if the single gatekeeper is doing his job poorly, an alternative gatekeeper has every right to step up and do the same job – and it’s then up to the free market to decide which is the better gatekeeper. This is why forking, so often argued to be a downside of open source, is actually a necessary good thing.

    In recent months, dissatisfaction with the leadership of the XFree86 project reached a breaking point, and within a few months every major Linux distribution (except Debian, which is in a perpetual state of trying to freeze for a release) has switched to the new Xorg server. Which is the *exact same code* but with a new group of gatekeepers.

    XFree86 served the community well for many many years, but eventually stagnated. If it had been a COTS product, users would have been screwed until someone could clean-room those decades worth of functionality to a similar level. Since it was Open Source, all they had to do was pick up the code and do a better job of maintaining it.

    This is the essence of Open Source. It’s also why all VB6 developers should be wishing that VB6 was open source right about now… (which isn’t to say that *I* don’t think VB6 should die a fast and painful death, but in an ideal world the market should decide that, not me, or you, or even Microsoft).

  49. Roger Binns says:

    The thing that is actually missed is that this is all about management and FOSS vs commercial only affects who is eligible to contribute and view the code.

    I can’t just get a line of code added to the Linux kernel or to the NT kernel. These projects have managers and processes that they follow. In either case if the manager accepts rubbish from others, doesn’t do testing etc then you will get junk. If they rarely accept anything then progress will be slow although probably higher quality.

    Proprietary stuff also (usually) has one set of goals in a trade off of time to market, performance, "quality", portability, feature set etc. With FOSS if there are groups with different goals, they can make a fork of the code. In either case these are goals of the developers not the users.

    Open source does the have the benefit that anyone can participate, but has the drawback that you can’t make people participate (unless you hire them such as Redhat does).

    Consequently there has been a far stronger focus in the open source world on reducing the barriers of entry, and improving developer productivity and communication. SourceForge is one example of this which then gets fed back into the proprietary world as a product.

  50. Klaus,

    How exactly does asking a manufacturer to sell a computer before the installation of an OS equal asking a dealership to remove a transmission from a car? No additional work needs to be done to sell a computer without an OS. Assemble, pack, ship. Including a transmission is much more integral to the process of car assembly than installing software is to PC assembly.

    It seems like a pretty weak analogy to me… Am I missing something?

  51. Scotch Moose says:

    And just because you had better not modify it doesn’t mean that no one should be able too.

  52. Rob says:

    Your analogy is flawed. Sure there maybe "hot-rodders" that tweak things here and there without knowing what they are doing, but in the open-source world you have access to the engineers. You can suggest modifications to them and they can give you feedback on them so you can improve it further. They might even want to include your tweak in the next generation car so that everyone can take corners faster, or have a smoother ride.

  53. Brooks Moses says:

    It occurs to me that, while the analogy is fine as far as it goes, it’s a bit incomplete — because the way people use software is very different from the way they use cars.

    In my own life, I can think of three different categories of how I use software, and the car analogy — in the form you’ve given it — only works for one of them.

    First, there’s the sort of "daily transportation" software, where the analogy works. My desktop operating system,my programming IDE and compiler, my browser, my email program — all of these are things that I use every day, and will have significant troubles if they cease working. These, I use off-the-shelf software for (often FOSS off-the-shelf, but still mature software that I’m not modifying), for all the reasons in the analogy: mature, well-engineered software is more reliable, and is (in general) reliably good at what it does — and the designers’ objectives for the software are a reasonably good match for the end users’ objectives.

    Second, though, there’s stuff like the ’65 Mustang I used to play with. When I used on that car for basic transportation, I did it knowing that there was a fair chance of getting stranded. That wasn’t the point; the point was that it was simply fun, and that I enjoyed working with it and trying to make it better. Similarly, there’s software that I use when I’m "playing" with things, where it doesn’t really matter if it breaks. (And, unlike with cars, one doesn’t have to worry about losing brakes on mountainsides or the like, so there’s even less risk involved.) Here, modification is a perfectly valid choice.

    Third, there are things like the Corvette over in the vehicle dynamics lab — software that I’m actually working on for research. That stuff — be it car or software — gets modified, because the requirements that we have of it are different from what it was designed for, and are different from what any car/software is designed for. It gets modified by people who know what they’re doing, and who are taking proper precautions with regard to the risks involved. And the result is, reliably, something better than off-the-shelf solutions would be, because the off-the-shelf solutions don’t fit these needs at all.

    The point there being that, while it’s really hard to change a car to make it a better car, it is not difficult to make it a better suspension-dynamics test apparatus. And it’s not difficult to make it into a better suspension-dynamics test apparatus than anyone currently sells, because nobody sells purpose-built suspension-dynamics test apparatuses.

    So, what’s the conclusion? First, yes, it’s unwise to go mucking about with the internals of something that you depend on for "basic transportation" needs. But — and this is an important caveat — there are lots of software uses that aren’t "basic transportation"; there are cases where one is simply playing with things for the fun of it, and (in a situation more relevant to the outside world) there are cases where there is an unusual design requirement for which there is no existing mature product, or for which existing mature products are ill-suited because they were designed for something different. And, in the latter cases, modifying the code is a very reasonable thing to do.

  54. 3/25/2005 9:49 AM Roger Binns

    > The thing that is actually missed is that

    > this is all about management and FOSS vs

    > commercial only affects who is eligible to

    > contribute and view the code.

    > I can’t just get a line of code added to the

    > Linux kernel or to the NT kernel.

    Partly true and partly false. You and I can’t get a line of code added to the base Linux kernel, but I can get a line added to my copy of it and you can get a line added to your copy of it.

    For a few months I was probably the only person in the world with a USB Japanese keyboard working properly in Linux 2.2.around18or20 and 2.4.earlyversions. I couldn’t get a 2-line patch into the distribution. Eventually the maintainers did a more complex solution (and for 2.6 they eventually did a different more complex solution). Meanwhile my copy worked.

    I sure wish I could fix my copies of certain other kernels. I sure wish I could fix my copy of the VB6 compiler the same way, and that’s not for me, that’s for a customer’s industrial control system that they’ve been working on for 8 years.

  55. 3/25/2005 6:02 AM AndyC

    > I’ve yet to see a car manufacturer who provides full blueprints of their latest model to anyone interested in building their own.

    Actually, it’s funny you mention that. I don’t know about other makes, but Toyota will sell you a very detailed repair manual which, among other things, includes detailed schematics of every circuit in the car, and explains clearly what happens for every expected input to each control box, most importantly the ECM (e.g., "When voltage on pin 3 of connector G6 (brake lights) goes to 12V, pin 7 of connector G4 (cruise control computer) shorts to GND). For purposes of illustration, the fat red, white, and gray book in <a href="http://binrock.net/photos/index.php?pid=209">this photo</a> is volume one of three for a 1990 Toyota Supra. A full set of manuals for a given car costs about $100. It’s not quite the full blueprints you mentioned, but it’s far more detailed than the Haynes or Chiltons manuals available at Pep Boys, and I specifically remember thinking, "it’s amazing that the manufacturers make such detailed information available to the average consumer."

    I don’t really have a point with respect to the discussion; just throwing more fuel on the fire. πŸ™‚

  56. James Risto says:

    Here is my 2 cents. I have struggled with the core concept of this … in the bigger picture. My view is that freedom allows this debate to thrive. Luxurious freedom. But all freedom has its limits … there are laws that one must follow. You can debate the laws … and may change them; but usually not. Examples from my world; I want to be able to drive a home-made <$5000 car, and be legal and safe. I want a portable desktop-priced computer. I want

    to be able to play xbox games on my 17" LCD monitor without the vendor saying "no". List goes on; all segments of the market. BUT I CAN’T GET EVERYTHING. So I experiment "on the edges". I play with a surprising large amount of free MS software like .Net compilers and MSDE. And I run apache and mysql on Windows from time to time. I extend bash and cmd.exe to get close to what I want. I always wanted to write a Notepad replacement and damn, that is not easy. At work, I am better off buying supported software … I need to call vendors occasionally, and have someone paid to answer

    the phone; not much at work can be "free".

  57. mschaef says:

    "Actually, it’s funny you mention that. I don’t know about other makes, but Toyota will sell you a very detailed repair manual which, among other things, includes detailed schematics of every circuit in the car, and explains clearly what happens for every expected input to each control box…"

    This is standard practice: I had a similar set for a 97 Cherokee. While interesting, it’s not even remotely close to a set of blueprints. The difference in size must be three or four orders of magnitude.

  58. Andrew Shuttlewood:

    Seems like you’re describing the Ada language there :).

    One of the most defensive languages available. Need to have a type with only integeres 34-95 available?

    type MyRange is new Integer with range 34…95

    (Sorry if I got the syntax wrong, but something like that). It is based on creating a new type/subtype for most of what you need.

  59. Paul says:

    (This is a bit long; sorry about that.)

    Larry:

    Other people have already commented on the "100 bad patches, 1 good one" thing, so I won’t bother.

    I will correct the guy who said it takes months to learn the OS/language/project – for almost all projects, that’s just plain wrong.

    The point is not so much that everyone is expected to dive in and start patching the code; more that everyone has the freedom to do so. Some of the improvements in the Linux kernel have come from people who read an interesting paper and produced a new IO scheduler. One of the people maintaining 2.6 simply started fixing bugs that he saw. It does work. (In general. πŸ™‚

    The other point I’d like to touch on is this:

    >In fact, I constantly read that that’s one of the

    >huge benefits of open source – on an open source

    >project, if you don’t like how something works, you

    >can just step in and fix it, while with COTS you

    >don’t have that ability.

    And this is, I think, correct (as in a benefit). To take a real-world example which is causing me grief at the moment (if you’ll excuse the small amount of explanation required):

    I have a wireless network at home. I have Samba on the desktop sharing things, and a laptop which I want to use them from. Because it’s wireless, I want to share over a secure link. So I set up a VPN over the wireless link.

    Until XP SP2, this worked perfectly. When SP2 came along, the wireless link started behaving oddly. It took some doing, but eventually I found that Windows appears to react quite oddly to the VPN interface and the ‘real’ interface being on the same device – it seems to think it’s sending packets out from one, and receiving them on the other.

    If this was free software, then I could start at least trying to narrow down the fault – debugging things, effectively. Because the things involved are binary blobs – Windows and the network drivers – I can’t, particularly. I also have basically no support trying to fix this, unless I want to pay MS a large-ish lump of cash.

    So yes, there is a certain amount of hot-rodding involved. But there’s also much greater transparency when it comes to finding the source of problems and fixing them, and just the code in general. For example, when working inside the Linux kernel, if I want to see what a function *actually* does, I go and look. Easy. πŸ˜‰

    As for the patches sent to the UW IMAP list – do the ones which are rejected ever spawn an "that is a problem, but the wrong fix, here’s the right one" patch? That’s an improvement. It’s a benefit I don’t think you get with COTS. (I don’t like that acronym…)

    Sorry, that kind of ran on a bit.

  60. suwan says:

    <a href="http://www.cheap-car-online.com/cars_e/2005-car-in-montreal-show.html">2005 car in montreal show</a>: "2005 car in montreal show To People Who Want To 2005 car in montreal show – But Can’t Get Started" <a href="http://www.cheap-car-online.com/cars_e/">car directory</a>