[krater23]

Okay, what is fully open? Do you really think the head unit developer would hand you over a huge developer documentation about every bit in the software?

I'm freelancer and helped to develop some head units. I have a surprize for you: This documentation mostly doesn't exsists. Most of the time there are some chip datasheets and requirement documents, depending on the customer(car manufacturer) they are good or bad and then are some partly outdated wiki pages written down for some important special things. You learn all other stuff out of the code or from your colleagues.

Wait two years and the most knowledge is gone, except of the things that are used for the next head unit.

[ACCount37]

Yeah, that's the status quo.

The biggest advantage actual developers have is access to the NDA'd vendor docs and the official SDKs. And, the vendor docs are bad and the official SDKs are a mess. Internal documentation? You'd be lucky if it's two steps above "nonexistent". It's usually just one step.

[tclancy]

I mean, yes. I would like to know that because it’s an unacceptable state of affairs from my perspective. If the production line relied on just always having someone working who remembered things instead of a proper solution to the Hit By a Bus problem I wouldn’t be buying that brand. It is my anecdata, uninformed opinion much of IT for cars is below average development. I started to wonder about this when I got a hold of two USB images to update a Chevy Camaro in 2010 (open driver’s side door between keys to indicate you were about to install the second USB key) and it feels weird to me this is still so poorly secured. Between the Hyundai/ Kia theft is sue a couple years back and my own experience with multiple long-standing bugs in our Hyundai’s infotainment system, I am suspicious of this ever being fixed.

[krater23]

Oh, don't understand me wrong. I've never seen a better organized embedded development process than in automotive. Review rules, reproducable builds, sometimes good unit tests(not just senseless stupid shit that wastes developer time), a test department in another room that develops test software to automate hardware in the loop tests, huge hardware in the loop test rigs that are running the newest build 24/7. IT in cars is all other than below average. It's not the move fast and break things shit of silicon valley. And it's not the 'we ship it with the next update' shit of the game industry.

BUT, there is no documentation because there is no time to do it. There are SOP-1(Start of Production). This date is carved in stone. When a feature is not done for SOP-1, than it is not delivered in SOP-2. SOP-2 happens normally 6 month later. After that, updates are only done when something bad happens. The complete team moves on to the next head unit.

So, I would expect your bugs will not get fixed in any way, at least when they are not important enough to mobilize a new small team or some people that worked on it to fix them. Normally shortly before SOP-2, all tickets are closed, known bugs too. That feels a little frustrating as customer, but more as developer.

Oh, and don't think that you can run away from that by buing another brand. Normally not your car manufacturer develops the head unit. It's other companies and they work all the same and they work for all car companies.