BMW has a subsidiary in Ulm (BMW Car-IT) working on the next head unit. This will be designed and engineered in-house, at least to a large extent. Any opinion on that? The current head unit generation is apparently sourced from a 3rd party. I interviewed there once, it was almost funny how much they stressed that they're a software company, not a car company, kind of like self-hypnosis. (Disclosure: I didn't get the job, neither wanted it after seeing the situation on-site; didn't fit into their culture.) (Fun fact: Company is full of ex-Nokians who they apparently scooped up when the local Nokia subsidiary had layoffs.)
I know that Car IT has a large group there which originates from the Nokia office in Ulm. They also have lots of hiring postings on stackoverflow careers. But I don't really know how much they are doing in house within that group and which parts will still be externally sourced. Even if they are now doing more parts of the headunit themselves there will be still lots of other ECUs which are 100% external developments. For infotainment BMW probably has the most in-house efforts going on. Audi went another route and founded e-solutions as a joint venture together with Elektrobit, which is developing exclusively for Audi. Daimler is still mostly relying on external partners.
A bit off-topic. I recently had to endure an azure evangelist telling me on literally every slide that they are now open (they had a big blue "open"-rectangle on the upper-right edge). A moment later i got very, very frustrated because a feature i had to use didn't work with the java-library (https://github.com/Azure/azure-sdk-for-java/issues/465 open since February!), the node.js library and the Rest interface lacked critical features so i was unable to authenticate programmatically (i think). Since i am working on a Mac and don't have windows, i couldn't use the C# library because it required dlls. In the end I had to code a simple proxy server in C# in a text-editor on my mac and then push it to a azure server running windows, compile it there and run it, just to get the data to my program. It was really a horrible experience. Since then i just assume that somebody that really has to stress something has in reality big problems/deficits in dealing with it.
Huh? But you can use C# on a Mac... I should know, I just came home from doing that all day at work. .NET Core works great on Mac, and imports many dlls just fine.
That being said if it was quite an old dll, and never compiled under PCL or netstandard, maybe not. There's still Mono, but, well, I can definitely understand reluctance in this case, and indeed would choose a different way in a different language myself, if that was my only option left that way.
if i remember correctly the DLL was responsible for the library to not be portable. It might be that i don't remember this correctly, but some crucial part was not available so i could not use it.
