Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Open Source and Hot Rods

Open Source and Hot Rods

  • Comments 73

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.

  • 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.
  • I think it would have been very hard for people to make win9x any worse.

    Ivan.
  • 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.
  • 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.
  • 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.
  • 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" ;)
  • 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.
  • Having seen some unfortunate results in the comparison of cars and software, I might have been a little more judiciuous in selecting an analogy.
  • 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!
  • 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.
  • 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
  • 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.
  • 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 :)






  • "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...
  • 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.
Page 1 of 5 (73 items) 12345