| Date: | March 18, 2004 / year-entry #105 |
| Tags: | non-computer |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040318-00/?p=40183 |
| Comments: | 68 |
| Summary: | For the first time, a team of women is challenged to develop a car, and the car they come up with requires an oil change only every 50,000 kilometers and doesn't even have a hood, so you can't poke around the engine. To me, a car has no user-serviceable parts inside. The only times I... |
For the first time, a team of women is challenged to develop a car, and the car they come up with requires an oil change only every 50,000 kilometers and doesn't even have a hood, so you can't poke around the engine. To me, a car has no user-serviceable parts inside. The only times I have opened the hood is when somebody else said, "Hey, let me take a look at the engine of your car." (I have a Toyota Prius.) On my previous car, the only time I opened the hood was to check the oil. Sometimes the open-source folks ask, "Would you buy a car whose hood can't be opened?" It looks like that a lot of people (including me) would respond, "Yes." |
Comments (68)
Comments are closed. |
I don’t think you get it. The point is not only you can’t open it – nobody you know can. You can’t stop in the local garage for checkup on the way back from work. You probably can’t even change a tire without entering some codes in the computer.
Would you buy a car whose media player couldn’t be changed?
It was certainly unpopular with the /. crowd, and although I don’t even OWN a car, let alone know how to service one, the idea that only a certified Volvo dealer can even LOOK at the engine is slightly disconcerting. How do you know there’s even one in there? It might be powered by golblins or something! I also find it a bit strange that a team of women designed a car that reinforces the stereotype of women being mechanically inept…
Just curious, how many folks on Redmond campus have a Prius? You wouldn’t happen to have a tan Prius, would you? I think I saw it last October, on a Sunday night.
I wish MS would make a car. I’d buy several!
Where is the inlet to the windshield wiper fluid container on a Prius?
Interesting analogy. I think 10 years ago I would have agreed with some of the others that even if I myself didn’t want to open the hood I would still want the local mechanic do so. But things have changed greatly, and while that still "sounds" like a charming idea, the reality is that the local mechanics are already unable to do any real work on our newer cars. I still have to go to oil change shops, but they are all so shady and ignorant that I would gladly always go to a dealer if I didn’t have to go so often — and the dealer is already competing decently on prices since they still compete among each other for the opportunity to service my car. So after initially thinking I wouldn’t buy such a car, I think I’m leaning the other way now.
What a sexist concept! Only women want a low maintenence, easy to keep clean car.
From what I see in my neighborhood, women want big honking beasts that they can use to see over/run over other cars.
Raymond, are you really saying that you take your car into the dealer every time you want to fill up with wiper fluid?
I take your point in general. I have no interest in doing repairs to my car either. But trivial basic care like refilling wiper fluid reservoirs is something that’s an order of magnitude more convenient for me to do myself (couple of minutes, versus at least an hour out of my day if I actually have to go somewhere else to have something done).
Yes. I have never filled my own wiper fluid but that’s because I’ve never run out either. The dealer always gives me enough when I take the car in for servicing.
But the issue isn’t about consumables. It’s about maintenance – replacing spark plugs, changing a timing belt, tinkering with the choke…
Even when I lived in New Jersey I never ran out of wiper fluid…
Could it be because you live in the Redmond area (I assume), where it hardly ever snows? Here in eastern mass, I use up about a gallon of wiper fluid a week! Ok I’m exaggerating, but you really tend to use a lot here.
or has this blog’s comments deteriorated into "Let’s flog every teeny-tiny-itsy-bitsy little comment Raymond makes"?
Because if you let people open the hood then people who think they know what they’re doing will start screwing around and breaking stuff.
I don’t think that trying to use a car that isn’t even near production to pull apart an open-source analogy is an itsy-bitsy comment; I think it’s intentionally provocative.
The thing is, a lot of people <i>haven’t</i> said yes, since no-one is actually manufacturing this car yet. Let’s see if it even reaches production before we see how much people want to rush to have their options taken away from them. (Besides, the hood of the car is removable; it’s just harder to remove.)
On top of that, the whole thing reeks of sexism — being designed by a team of women doesn’t mean you get a get-out-of-stereotypes free card. (The idea that women cannot manipulate a gas cap struck me as particularly absurd.) Or maybe the whole thing is just a sign of what happens when you design by committee.
Raymond:
>Because if you let people open the hood then people who think they know what they’re doing will start screwing around and breaking stuff.
You mean people like mechanics? Consider that any repair on this car requires removal of the front end (even to check stuff) and that you have to take it to a $80/hr dealer, and you’d better hope it’s low maintenance.
Incidentally, that seems to be the rationale behind a lot of the nanny state stuff that I really hate – I prefer the ability to make my own mistakes and suffer the consequences.
> tinkering with the choke…
That’s a joke, right?
I had my last car for 4 years and only ever opened the hood to change the wiper fluid (and that wasn’t even because I had run out – it started smelling funky, so I flushed it and replaced it). I’ve opened the hood on my new car one time, to show someone the engine (it’s an RX-8 with a rotary). Turned out there wasn’t anything to see – it’s all covered up (though I’ve since read how to remove the cover). I don’t intend to open it again.
The point is, while some people like to make a lot of noise about this, there are a lot of people who really don’t care. There is a market for these cars.
From the point of view of a consumer, who just wants to drive the car, i can get your point. He has no need to look under the hood. when i use a piece of software, i don’t have a use for the source code.
But now imagime that you have to develop a car stereo that has to work with a car, but the car constructor refuses to tell you how the interface works. You will have a very hard time doing this.
As a developer who has to write software that works on windows, having the source code would be a huge help.
I want to point out that Microsoft has a long tradition of open source for some products, even since the time that the name open source had not been invented yet. I’m thinking about MFC for example, or most of the resource kit tools. Having the source code for MFC has greatly helped many developers, i think you agree with that. I would love to see more of that.
And then when the car is taken in for a safety recall repair and your custom radio stops working, whom do you blame?
Do you mean to say only the car constructor should be able to develop car radios that can work in it?
Because they’re the ones who will be stuck supporting all radios (even custom radios), they can decide which radios can be installed.
But the more radios they support, the better for the car constructgor. It’s a sales argument. You might lose sales if you don’t support a specific barnd.
same for Windows: windows has become so strong exactly because of all the ISV software that exists for it. If it would just have been windows and Office, Microsoft would have been a dwarf by now.
You have to draw the line where you want third parties to plug in (and therefore have to support forever) and where you want to reserve the right to redesign radically. Maybe car companies say that third party tires are okay but third party timing belts are no good.
Obviously the majority writing here rarely drive cars and have more money than they can spend so they can afford to listen blindly to dealer. With such car you have no other option but go to the dealer – you can’t even verify their claims that something need to be replaced. And if you refuse – guess what any problem after that we’ll be miracullously because you missed that maintenance.
The point about not driving much is what happens when you have a problem on the road – say 100 or more miles from a special Volvo dealer. You toll the car all the way there for a spark plug or somehting similarly simple?
A VCR is less than $50 – you can compare it to a car seat cushion, not the whole car.
I think this Volvo has a wiper fluid access close to the gas one.
Raymond,
I think you maybe had an extra glass of that Kool-Aid.
When Volvo sells a car, it’s not their car anymore. It belongs to the buyer, to play the buyer’s tunes and go to the buyer’s destinations carrying the buyer’s payload.
When you sell me an OS, it is meant to run on a computer that I own to do tasks that I want to do in the manner that I trust.
And, what Henk Devos said.
I think you have it backwards here Henk. Honda doesn’t provide their proprietary design information to every car radio mfgr who wants it. Instead they provide support for a standard mounting format and beyond that it’s up to the custom radios guys to make their radio fit in a variety of cars.
The radio mfgrs response to this is to build a generic radio that supports a standard mount and and has a generic plug that supports the outputs from the car (power, ground, speakers) and has inputs that support other radio component mfgrs standard outputs (RCA, optical,etc…).
In other words, the radio mfgr doesn’t worry about how power is generated in the car, only that it meets the standards for radio input and output in a car.
And then if the radio manufacturer decides, "That standard mount isn’t good enough. I want to be able to access the onboard video screen too" and starts going outside the standard mount, then things get really interesting.
ATZ: If you feel that way, consider this: When you find that a program you installed isn’t compatible with the next security patch (because it was doing something undocumented, say), who (1) should get the blame, (2) actually does get the blame.
Does Volvo give you the design specs, blueprints, molds, etc. for the car? I thought not.
But the notion of support for software and hardware (a car) is different. If I buy a third-party timing belt, and it doesn’t work, you can’t go whining to the car constructor about it. Essentially there’s no support for it. Part of this is because its trivial to reverse-engineer the timing belt, how many teeth, how long, etc. and also that the car company can’t do anything about it if it doesn’t work. Also, theres no notion of backwards compatibility–if the design of the timing belt changed next year, it wouldn’t affect owners of the previous model. If I buy a new car, it comes with a new, compatible belt.
Compare this to software: somebody does something stupid, and Microsoft has to work around it or release a patch. And the next version of Windows doesn’t come with every program I use.
Remember those sealed legacy-free PCs that were hyped up several years ago? Same hardware situation.
I’ve been writing software that runs on Windows for years and I have never needed the source code. In fact, thousands upon thousands of developers have written thousands upons thousands of programs and <they’ve> never needed the source code. I have also written some code for Linux, and the fact that the source code is available is of zero importance to me.
How can this be? How can I, standard issue brain guy, write programs on an OS without the almighty source code? Gee, I guess I just write code to the PUBLISHED API’S regardless of the platform. How hard is that? To the various Linux folks who talk about "needing" the source code, how many of them have ever opened up the source code to Linux to fix bugs or figure out an API while writing a program? I imagine it’s a very small percentage indeed.
Thanks,
PeterM
I strongly dislike this idea as well. All this does is give you an inferior product with <B>ZERO</B> benefits over a competing product which is not limited in this fashion.
Raymond:
>Because they’re the ones who will be stuck
> supporting all radios (even custom radios),
> they can decide which radios can be installed.
Methinks you’re taking this all too personally. Cars aren’t like windows – if you do something foolish like install a stereo that shorts out the electrical system, GM isn’t going to fix it for free – they’re going to charge you. If you then monkey with your drivetrain, GM will happily cancel your warranty. In no event is GM required to support a car past the end of the warranty (recalls excluded), and there is no requirement that ski racks from your last car fit on your current car.
Drive. Be happy. Don’t be so bitter about cars.
Steve:
In other words, the radio mfgr doesn’t worry about how power is generated in the car, only that it meets the standards for radio input and output in a car.
True, but you can be sure that the power will be there, and will always work, and will always work the same. There have however been times when i needed to work around a bug in MFC, and i could just override a virtual function that had the bug, copied the whole function in my derived class, and fix the bug there. No need to do this for cars.
Furthermore, interface of the car is well documented, and usually DOES come with diagrams, data books etc. explaining how it works (the equivalent of source code). In Windows, the situation is very different. There are huge portions with lacking documentation or documentation that is just wrong. Figuring these out is very hard.
Raymond:
ATZ: If you feel that way, consider this: When you find that a program you installed isn’t compatible with the next security patch (because it was doing something undocumented, say), who (1) should get the blame, (2) actually does get the blame.
Well, in reality (and you know i’m speaking from experience) there’s as much chance something documented and supported will break the app as something undocumented and unsupported. I have been using undocumented functions that were around since Windows 95 and haven’t changed since. Yet when my software didn’t work anymore, this was because of documented and supported things that had changed. I didn’t need to make any changes related to the undocumented parts.
I don’t currently own a car, either, but I do have the ability to hear a car with a problem (and sometimes just hear *about* the problem) and can usually diagnose (debug) the problem. In many cases, I can also fix the problem for "pennies on the dollar". Some times this isn’t worth the time (changing oil, for instance), but sometimes this can mean not only saving $100/hour or more, but can also mean that the work is done correctly.
I don’t like unknown people working on my car any more than I like them working on my computer.
A car with no user servicable parts would only be acceptable to me if it never needed service. Otherwise, it’s too much like WebTV or something.
I have no idea.
I didn’t say that *you* would buy it. But I would. I already own a TV with no user-serviceable parts inside, a VCR with no user-serviceable parts inside, a washing machine with no user-serviceable parts inside, a car with no user-serviceable parts inside…
And just how long do you think it’ll take before someone opens up their hoodless car? And how long after that before people start screwing around with it? The harder it is to tweak, the more people will wan’t to do it.
Henk Devos: "I have been using undocumented functions that were around since Windows 95 and haven’t changed since. Yet when my software didn’t work anymore, this was because of documented and supported things that had changed."
Looks like you are missing an obvious difference: changes to undocumented features can be altered without prior or further notice, hence, those changes will never be documented. Quite in contrary to the published API.
In addition to Peter Montgomery’s points, which I can all agree on, source code availability is in fact dangerous for 2 reasons. The obvious one being that developers (aka hackers) will rely on internals instead of committing themselves to an interface. A more subtle problem, yet very common one, is lack of documentation. I mean, how many times have you had an argument with an open-source-crusader who finally throws in source-code-availability to cover up for crappy documentation?
.f
Henk Devos: "Furthermore, interface of the car is well documented, and usually DOES come with diagrams, data books etc. explaining how it works (the equivalent of source code)"
Again, you are mixing up things in an attempt to make a point. Documentation of an interface, with diagrams, data books, etc. is generally referred to as API documentation. Carrying this back to the original topic, would you actually need to know what sorts of laws govern the recombination of molecules in the combustion chamber during ignition (which would be truely the equivalent to source code) to operate a car? I’m happy with it’s documented interface actually.
.f
floyd: Looks like you are missing an obvious difference: changes to undocumented features can be altered without prior or further notice, hence, those changes will never be documented. Quite in contrary to the published API.
Taking Henk’s example, that would mean that the undocumented stuff will never change, but the documented stuff varies with each release.
Kevin Schaffer: And just how long do you think it’ll take before someone opens up their hoodless car?
As long as it takes to find a repair manual? It’s designed so that the whole front end is removable.
Of course, if you buy a car which is built to only be serviceable by one company, then that one company is free to charge you whatever they feel like charging.
Even if you always take your car to the dealer (as do I, and there are lots of other places that’ll work on a late-90s Saab), the *possibility* that the dealer will have competition keeps his prices competitive.
Another way of looking at it is that it’s not about user-servicability but about convenience: the hood means that if someone needs to get in there, they can. I’d hate to have to get my car towed to the dealer (easily a hundred bucks) when all I really wanted was to have the Automobile Association send out a truck to jump-start my battery (free with a membership, usually about $20 otherwise).
Mostly, though, I just fail to see the disadvantage of having the ability to open the hood if you desire. Why is this innovative?
For the largest majority of people, a computer is something that ‘just works’, but how many of us would buy a computer with ‘no user-serviceable parts inside’?
"It looks like that a lot of people (including me) would respond, ‘Yes.’"
I’ll second that!
I really couldn’t be bothered wasting my time looking at the internals of a car, or a computer. I’ll take it to someone who has the time and inclination to look at it.
My time is worth more to me than the few extra bucks from understanding how it works. If the dealer (car -or- computer) overcharges me, who cares – its only a few dollars.
Okay I think I figured out the difference between installing an aftermarket radio and installing thirdparty software: When an aftermarket radio does something unsupported (like try to hook into the onboard LCD panel) it’s pretty obvious to you (the person who installed it) that you’re doing something pretty dodgy, and if the LCD panel starts acting weird you know that the aftermarket radio is likely to be the reason. But when you install software, you don’t know what sort of dodgy things the software is doing. Maybe it installed a driver? Maybe it grovels into undocumented data structures? You can’t tell; it’s not obvious whether a program is doing this or not. So when the computer acts up, you don’t know whom to blame. (And therefore you blame Microsoft.)
"Sometimes the open-source folks ask, "Would you buy a car whose hood can’t be opened?" It looks like that a lot of people (including me) would respond, "Yes." "
The exact same "lot of people" also included a "stunning shoulder bag in soft rose leather . . . fitted with compact, lighter, lipstick and cigarette case" on the back of one of the seats.
Not trying to be sexist, but that "lot of people" was 5 managers, 20 or so others and the occassional opinion of the 400 female Volvo employees. Not exactly the most accurate cross-section.
Also, note that it says "Volvo officials say they have no immediate plans to mass-produce the new prototype".
So, I guess the answer to the opensource question is "about 30 people and an unknown percent of the 400 women at Volvo would say yes".
> I don’t think that trying to use a car that
> isn’t even near production to pull apart an
> open-source analogy is an itsy-bitsy comment;
> I think it’s intentionally provocative.
*Nod*. Thus the media player nudge.
…and what’s a blog without the periodic annoying Slashdot conversation?
Floyd:
Looks like you are missing an obvious difference: changes to undocumented features can be altered without prior or further notice, hence, those changes will never be documented. Quite in contrary to the published API.
Believe me, the difference is really not so big.
As an example:
When we went to a client and looked at their source code, we noticed that they were deleting an object and still using it after that. It worked because the object happened to still be around and they never noticed. It is typically this kind of applications that gets broken when small undocumented changes are made to a memory manager.
I am selling libraries that come with source code for n extra price. So far, i have sold 1 (one) copy withot source code. This in itself is a very clear indication.
The library is well documented, so it’s no excuse for bad documentation.
But this way, the users can debug through the library and identify their problems more easily.
Furthermore, this greatly improves the quality of the library. I have had many users sending me bug fixes. Without giving them the source code, this would never have happened and the libraries would not have the same quality.
I am extramely happy that i have chosen an open source model.
There is also the issue of "how can i do this?".
Suppose we would have the source code of Windows. Instead of running to Microsoft Support every day to ask them how i can do something, i would just look in the source code how the same (or something similar) is done in Windows. Would make my life so much easier.
Floyd:
Carrying this back to the original topic, would you actually need to know what sorts of laws govern the recombination of molecules in the combustion chamber during ignition (which would be truely the equivalent to source code) to operate a car?
I also don’t want to know which laws govern the transistors in a processor.
To me, a car does what I want to do. That includes taking all the user add-ons I want to apply to it, subject to its structural limits and documented electical and mechanical interfaces.
Once I buy it, it’s mine. I’ve as much right to sell it or its parts or change parts for those the manufacturer dislikes as I have to resell bundled software unbundled – which is my legal right.
Someone replacing the engine or NTDLL might be causing problems but I do expect them to say that they are replacing the engine, not installing go-faster stripes on the bodywork. That misleading lack of disclosure has been a significant issue on the software side. Also onthe car side, at some service places. If someone doesn’t comply with the documented interface standards, that someone is the guilty party. There haven’t been enough legal cases against companies which break things in the software area.
If I spend $20,000 on custom add-ons for a $500 car I don’t expect the maufacturer to stop supplying spare parts or routine servicing for the car after five years. That undermines my investment in my custom parts. Better an open source car where I can still take the car to third parties for servicing and can run it as long as the custom parts and car combination makes sense to me. That may look worse for the car maker but those custom parts makers are far bettter off when I’m willing to invest lots of money in their products, as am I when I get a tool which better meets my needs than the stock product. If I buy a closed source car, I’d be placing my future use of the vehicle under the control of a third party and the business interests of that third partry. That car had better have a steep discount to compensate for the lock-in and forced upgrade potential which make it otherwise significantly more costly and less dependable in the long term than an open source alternative doing the same job.
well put james.
And what happens if the owners of TNT decide to rearchitect their program so your patches don’t work any more?
floyd wrote:
> In addition to Peter Montgomery’s points, which I can all agree on, source code availability is in fact dangerous for 2 reasons. The obvious one being that developers (aka hackers) will rely on internals instead of committing themselves to an interface.
Oh, come on. That’s not really the point of open source. The point of open source is that:
(a) if I want to customize a piece of software so it does something I want (say, I want MS Word to play morse code as I type), I can do that. This happens *all the time* in the open source world. Users end up changing the software, "scratching an itch". Yeah, those users are often geeks without a lot of UI skill who are writing features for themselves, but just like modding my car to drop a supercharger in, if I want to do that, why shouldn’t I? Nobody else *has* to use my version.
(b) if software is broken/obsolete I don’t necessarily have to rely on the author to fix it.
I’m not saying there’s no room for commercial software, just saying that your impression of open source (and its users as "crusaders" or whatever) is ill-informed.
How often are contributions to things like KDE accepted? Suppose, say, somebody who wrote a music editing program also modified Konqueror so if you hovered over a file created by their editor, a tiny little play/stop/rewind control popped up. Is that likely to be accepted?
If you wrote a music editing program (RCmusik?) and submitted a patch for KDE to play your .rcm files using Konqueror’s preview feature, it’d probably be rejected.
However, if you submitted a "sound previewer" plugin for Konqueror which would allow any sound format to be registered (wav/mp3 through standard libs, .rcm through -lrcmusik), it’d probably be embraced-and-extended rather quickly.
Permanent solutions are more readily adopted than quick hacks, even in open-source projects.
Ashley Winters: "Permanent solutions are more readily adopted than quick hacks, even in open-source projects."
I’d say ESPECIALLY in open-source projects, generally more so than in proprietary ones.
And who does the usability testing to ensure that users find the new popup player feature easy to use and consistent with the rest of the UI?
If the Konqueror owners decide, "Sorry, that doesn’t fit how we think Konqueror should work, especially since it would conflict with what we’re trying to do in the next version," do you just have to smile and say, "Okay, well thanks anyway"? Do you ship your custom Konqueror with RCMusic? Even if they accept your changes, who is responsible for maintaining it? You? The Konqueror developers?
In the Windows world, vendors typically come up with specific features for their product, not "permanent solutions" – what incentive is there for Intel to design their video driver Explorer plug-in so it supports ATI video cards?
An interseting counter point to yours, Mr. Chen
http://andykessler.com/wsj_hack_this_please.html
But people are not making the distinction between an end user hacking their system (in which case they know what they’re hacking) and a third party program hacking the system (in which case the end user has no idea what sort of hacking is going on).
Third-party hacking is a common occurance with KDE/Gnome. I know the KDE development team isn’t very fond of having users (RedHat, Debian, whatever, not Joe End-User) hacking the system to meet their "vision" of the desktop.
One the one hand, you have Gnome, with the classic free-software laissez faire attitude toward "users" changing anything they want using the source-code freely provided under a liberal license. On the other, you have KDE trying to maintain a unified environment, and trying to shoe-horn any necessary enhancements into the greater reusable framework.
If you write something which doesn’t "fit" into the KDE framework, they will simply reject it. If it’s needed and/or successful, they will write a competing implementation using their own tools and methodology, and bundle it with the base system to strangle yours out. It’s a…. familiar strategy. :)
Suppose the car manufacturer reneged on warranties and said that you had to buy a new car in order to get fixes? You would still buy cars from that manufacturer instead of from others that make mechanic-serviceable parts? (Well sure, yours is also mechanic-serviceable in a way, since your vendor’s mechanics have the capability, but your vendor has refused to service it.)
Suppose that every time you bought a house you also had to buy a car from that manufacturer? Sure you’re also free to buy cars from other manufacturers, and you’re free to throw away the unwanted one that you still had to pay for.
Let non-user-serviceable products compete in an open market. Then they’ll sell to customers who really want them.
It’s like having a computer with non-removable case. I wouldn’t want a computer that I can’t even change the fan (which I blew quite a few)
Why would I want to bring the whole thing to dealer if all i want is change the fan (a few bucks)… or may be change timing belt in the car..
Interesting discussion wrapped up in another interesting discussion… towards the end, the open source discussion broke free from the thin cover of automotive manufacturing though.
I wonder what kind of cars we would get if it were easier to exchange parts (AMG Mercedes… or more souped-up Opel Mantas?).
As one who works in the automotive industry, FYI there are basically two types of component interfaces there. (1) standardised – for example, radio slots and connectors. These are agreed upon across the industry and "are what they are" – there is very little change over time. Backwards compatibility reigns – it has got to work in the "installed base" of umpteen million cars. Interfaces are tightly specified and very reliable. (2) engineered – for example, a brake. These are very precisely specified in individual engineering drawings, with notes outlining individual requirements like your parking brake cable comes in exactly here or the required brake force is exactly that. Then they are tested and tested and tested again until we’re sure that everything works. Since someone is selling the whole car as a system, they’re taking responsibility (and being paid) for integrating the whole lot into a working whole.
Another area are aftermarket parts. These are sometimes still very specifically engineered (this rotor will go on this car model… only) or sometimes very generic. The vendor is responsible (and paid for) certifying that it works and is safe with all cars that he sells it for. On a per unit basis, aftermarket parts are a lot more expensive than what goes into the car in the factory, and you only get them for where demand (volume) and supply (engineering and manufacturing cost) are in the right relation (rotors are a consumable and relatively easy to do, while entire engines aren’t required very often and do require a certain investment, so you can’t buy them at Pit Stop).
Automotive manufacturers are making quite an effort to reduce the amount of user-serviceable parts in cars (ideally, there shouldn’t be any – most people just want the damn thing to work and not spend time mucking about with it, and some people will get anything wrong no matter how trivial), and to tie the mechanic-serviceable parts to specific equipment that is only economical for dedicated garages (i.e. their dealer network).
It should by now be quite obvious that we are really talking about two quite different environments here. The ability and cost of making and selling changes makes any comparison pretty moot.