Nearly one year ago the German federal government passes an amendment to law on preferential use of open source software.
Now they push projects like OpenDesk[1] to fully replace MS Office (365) and OpenCode[2] where they open-source all software that is build with public money.
In my view, this has led to the German economy having more confidence in open source, and that open source can be used and maintained as a model for software over a period of 5-10 or even more years. Instead of buying licences and hoping that the manufacturers will maintain the software for at least 5 years and provide updates. In addition, there is the realisation, not least as a result of the change in the law and the current global political situation, that sovereignty is a very important factor.
To me the "opendesk" effort looks like a lot of not-open source "licensed" software ("with less than x% closed source") and a handful of wrappers around other people's open source software (diagrams.net wrapped as cryptpad, for example). In fact they recommend the "enterprise edition" which is NOT fully open source, right?
It says all the right words and has a flashy landing page, but doesn't seem very open or impressive; am I wrong in my assessment?
In my understanding it is fully open source and it's source code is available on OpenCode [1].
OpenDesk use nextcloud, Open-Xchange, Element and so on. And it actively contribute to this software.
In my understanding, the enterprise edition, is the non-self-hosted version of [1].
What is the not-open source software used in OpenDesk? Because your example: cryptepad[2] is GNU Affero General Public License. And diagrams.net might look similar, but also LibreOffice looks similar to MS office.
It looks like multiple items in deploying the "enterprise edition" have licenses and are actually a closed-source model.
To me this looks like a flashy web page that makes all the right noises about "data sovereignty", etc, but relies (on the actual back-end) on multiple providers who have in fact cut off access to code; they even take pains to say it is "less than x% of code" or "Admin Console container image: 100% closed source", etc.
In my opinion this project is the best effort so far to have a full Office365 open-source alternative.
And yes, if you want to have the enterprise edition, you have to accept the enterprise licenses, to have then features that contain closed source code. But this is an option, for enterprise.
I think, they can still make the claim: fostering data sovereignty.
> In my opinion this project is the best effort so far to have a full Office365 open-source alternative.
Then the effort sucks.
From my perspective as a German, this almost looks like a scam. It's a bunch of OSS software rebundled as a package by a company which would like to make money off of support for the software. Which inherently sounds great, except that their only original contribution to the software package is a mid tier project management app.
The vibe I've been getting so far, is that they're trying to resell OSS software and accompanied support, except the underlying software already has great community and commercial support (Nextcloud and Collabora for example) and to make up for that, they're getting the german government to slap a "Made in Germany" label onto the package.
I’m an American and thought the effort sucked too - I had the same thoughts (it looks like a thin wrapper around other open source code with closed source “enterprise edition” which allows for providers there to overcharge for functionality that isn’t returned to the open version).
Mercedes Benz is already for example using KWin from KDE as Wayland compositor and likely many other open source components. So this sort of move is not without precedent.
It's a smart move to do so instead of switching to Android Auto and loosing control of one of the most important component of the experience of the car.
Still? It is the best and the most mature cross-platform toolkit. Among both open-source and proprietary ones. It is the default for embedded / industrial UIs and automotive. At least in Europe but I think many US companies like Autodesk also use Qt. Its programming paradigms are a bit outdated. However, it is quite performant and supports many 2D and 3D acceleration drivers / APIs.
Wow: I run KDE with Wayland on my PC, and given the instability I've experienced, I'm surprised it's suitable for a high-reliability environment like a car. I suppose that it being a more controlled environment may help, but even still, I wonder how stable it actually is.
They aren't using KDE for the car, just KWin. And KWin is a robust compositor - it will happily survive a horrible KDE crash and even let you restart the session (unlike Mutter) in many cases.
If you're only using a Wayland compositor to render a webview, you cut out a lot of the surface area that could potentially cause a crash.
Me too - its fine for me. You are probably holding it wrong 8)
My car (Seic MG4 - an EV) clearly has two lots of software. The reliable stuff that runs the "must work" stuff like driving controls and motors etc. and the other stuff that ought to work in an ideal world and I think that lot is on the Android tablet mid dashboard.
The other stuff even includes "lane assist" and other safety features because when I force re-boot the console they report as offline on the display behind the steering wheel, which I think is linked to the first system - the RTOS automotive jobbie.
I think SEIC (and I'm sure this is standard practice) have done a fairly decent job with the divvy up of responsibility between funky features and must work or death will ensure features. I'm an IT consultant and know when Android auto has crashed on my phone or car or both or the radio is on silent or there is dust in a USB port ...
Wayland vs X11 is not an issue in cars - whatever you get will either work always or be a bit of a mild distraction.
Cheers
Jon
PS I went to school in Abingdon, Oxfordshire. My car has nothing in common with the real Morris Garage. The MG marque is merely an affectation and I don't know why Seic really bothers.
They will have to fix their attitude towards the people who build software before they can be successful.
In a typical German corp software developers even in RnD are not seen as an asset but as a mixture of line workers and support staff.
The problem is: The world best assembly line worker will not boost your companies performance in a measurable way, but a better dev will make a heavy impact in his project.
Nice example:
A friend of mine worked in RnD in a German DAX corp. C-Level regularly had them fix bugs in other projects.
Why? RnD is the only department that can adapt its planing fast enough to fit in stupid side tasks.
As a result the best people left, were replaced and the average skill of the department regressed to the mean.
Exactly this. In Germany, the median software developer is treated (and paid) pretty much the same as a blue collar worker, both by their company and by society at large.
From calling it "IT" to paying peanuts, no wonder no one smart and ambitious wants to get into CS here. All the smart kids seems to want to go into consulting and finance. So, of course Germany doesn't see the kind of outsized success in the Tech industry like the US or even the UK.
Volkswagen's (and in general other automaker's) software sucking is simply a fact downstream of that.
There's one area where EU software industry is on the cutting edge: The gaming industry.
Again, the platforms are all American but Europeans know how to make kick ass games that are delightful and awe inspiring. French, Polish, Ukrainians, Bulgarians, so many legendary people are from Europe.
They should hire game developer to guide the user experience and listen to them very carefully.
Not exactly correct. It is just the US studios that are failing because they are captured ideologically, and prioritise other things than making games people want to buy and play.
The EU has good studios, for now, on par with the asian market, but they run the same risk as the US.
Meanwhile, a lot of the higher value work such as in Engines tends to pay pretty high - for example, Epic Games pays SWEs and PMs in the $200-400K TC range, but this is overwhelmingly in the US. Similar story with Unity despite originally being European, but shifting to the US in the 2000s.
The serious move would be centralizing their budgets they have for developing these functions in a new independent company, and until that happens it's likely to get stuck in analysis paralysis.
I saw a video where a mechanic replaced a pack on his Model S with a 100Wh pack. There were some minor issues of fit, which he had all figured out. There was a connector change and some sheet steel around the edges that needed changing out to make it physically fit. The procedure was to keep a table under the vehicle, lower the vehicle so that the pack rested on the table, remove the last retaining bolts on the bottom, and lift the car back up. Reverse for install except he had to align it first. He estimated it would take 2 hours total. This car was designed for fast pack exchange. The coolant connections were self connecting and disconnecting.
Then came the software. The amount of complexity and jargon and issues and roadblocks that come out of nowhere is extraordinary. You have to dive several layers deep in a menu system to do step 1, then get hung up on opening a "gateway", then dive down the same menu to do step 2 of a 2-step process. He had another problem that kept him busy but what impressed me is the amount of time and complexity to do the simplest things. He wasn't performing many steps, but just getting to the step required rebooting, waiting, pressing the brake pedal to see when it was time to move the right turn signal stalk, didn't work, go back, do something else for 10 minutes, try again, it seemed endless.
German automotive companies have historically been terrible at software. Just because Tesla hasn't simplified or integrated their various software components yet, doesn't mean others can't do it nicer. But any company that doesn't value software like the Americans do is going to have a real tough time with the EV software problem.
Everybody just uses QT Auto and they create horrendous interfaces plus they use cheap electronics with not enough resources to power all of that eye candy.
The chinese can create good looking and useful UIs and they can even go deeper in the stack.
I had presumed that car GUI/Infotainment systems were just in sleep or hibernated when the car is off, to shorten the startup time when switched back on.
Some part of it, yes. In the systems I worked on you had the "AC" - Automotive controller that was in a sort of deep sleep. But the "CG" - graphics controller was completely shut down.
They need to boot fast after the battery is replaced. Sleep also needs to not drain the battery. sometimes they will do a full shutdown after a week if sleep can still use power
As always there is a difference between what course of action is widely agreed to make sense for everyone involved, and what course of action is in agreement with the structure of the corporation. The Audi/ Cariad disaster being just one example.
I'd like to see some insight on whether this has a realistic chance of being the winning bet within the companies involved. So far it sounds too obviously useful to win the politics game.
1. Personally, I don't want software in my car, I want physical buttons and switches (then I can control my car without looking at any distractive screens).
2. The German car industry already successfully teamed up on sharing map data (https://www.here.com/).
3. However, while this may work for Libre Office installs in a city administration and (non-critical) car infotainment software, this likely cannot work for the most important automotive control software, due to the legal responsibility of the car manufacturer (they would need to review/audit all changes of open source contributors line by line, patch by patch) - because bugs can cost lives there.
What do you mean, you don't want "software"? Where do you draw the line? A basic digital wristwatch has "software".
You're going to have software for a modern, efficient car, whether you like it or not. For the engine (fuel injection alone needs a bunch of software), ABS, traction control, A/C, and countless other things. And whether your radio has physical buttons or not, unless that physical button is on a radio from the 1980s and directly controls a variable capacitor and a belt to a frequency indicator, it's going to have software.
Of course we had cars entirely without software, about 50 years ago. But they were slow, had many quirks, and absolutely massive relative fuel consumption compared to today.
> What do you mean, you don't want "software"? Where do you draw the line? A basic digital wristwatch has "software".
I think this nomenclature is a result of the post-Jobs software as "app" paradigm + Web as the definitive "application" platform era.
The majority of software written, especially in these circles, is going to be some sort of user interface/CRUD stuff. The "invisible" (and frankly remarkable, when talking of things like ECUs and ABS software) is basically like The Earth (it's just always been there and taken for granted).
"Software" in a vehicle is more than just the UI in the dashboard.
Your engine control, your ABS and your traction control all run software (or "firmware", whatever that word means in this age) and they have been for decades.
What needs to stop is that awful trend tesla started where they replace the entire dashboard with a tablet.
Regarding the need to review and audit all changes, it doesn't matter whether it is open source or closed source. I think the idea is, that various car makers collaborate, not necessarily patches from outside of those organizations.
Do you think they audit line by line every piece of SW in a safety critical ECU? Because if yes, I have a bridge to sell you. They do many many things to insure the SW works, but there are a bunch of corners in the SW very few people poke at.
And anyways, merely auditing I serious doubt would be effective. (LGTM, ship it!)
This doesn't surprise me. Here's my hot take, having worked building these kinds of ecosystems in automotive and related industries (RV), and also working with German automotive/caravan companies in those spaces.
1) They don't want to invest in building vehicle software ecosystems as it's expensive, time consuming, and not exactly in their wheel house. Wireless and cloud connectivity just aren't their language.
2) They don't want to work with existing proprietary off the shelf ecosystem solutions -- they feel that because it's "their vehicles" they should "own" the technology and IP. They don't want vendor lock in, so they avoid existing proprietary solutions they can't "take over". And by "take over" I mean "have the vendor give their proprietary stack to them for free, so they can then share it with their other suppliers".
3) They expect the vendor base to "partner" to develop "open" software stacks for free -- which most vendors aren't keen on doing as there is little upside for the vendor to spend their own internal NRE building a system that their competitors benefit from and can quickly undercut them on. They generally refuse to pay for the development of a stack that they can own and build upon.
The root cause seems to be magical thinking from the higher ups - "Hey connectivity stuff is everywhere, it can't be hard, why should we pay for this?"
They don't want to build it. They don't see the value in paying for it. So of course open source is the obvious solution. Hey, just have the nerds build it! They love doing that kind of work for free.
This is basically AUTOSAR reinvented, by mostly the same companies. That's not a bad thing, AUTOSAR is a flaming pile of trash and this is at least picking a better foundation. It doesn't solve the core issue though, which is that the auto industry struggles to understand software.
AUTOSAR is a spec, this seems to tackle an actual implementation.
As the other commenter said AUTOSAR had some good ideas, but now it has too much cruft and it's hard to decrusity it. If they trimmed 80% of the standard, had an actual open source reference implementation, overhauled the tooling to make it not suck and added solid observability capabilities and did something about the god awful RTE experience, it would be pretty good. The API's are sane, interactions make sense.
AUTOSAR had some good foundations, but consultants who didn't understand anything (as normal) over sold what it did and then sold companies on a lot of bad ideas because management didn't understand the real problems.
If your program is hello world complexity then it isn't worth the cost to make it reusable, just write and maintain 100 different copies - meanwhile elsewhere there are only 5 copies of the transmission controls and since it is only 5 it didn't get to the top of the list to fix redundancy - but those controls are very complex and making one version would be well wroth the effort.
No, AUTOSAR is a flaming pile of shit. What good ideas did AUTOSAR have? Reusable software components? That is the idea every single software engineer or computer scientist had ever, it is completely unusable and I have never, ever seen a MISRA C compliant anything if it is generated by AUTOSAR (well, unless you count a deviation list longer than the ARXML used to generate the crap).
"AUTOSAR is a good idea, it works in theory", nope, much like communism if your theory does not work and continues to fall flat on its face it is a terrible theory. No one would say a theory of gravity that predicted you would turn into a unicorn if your really wanted to and dropped a ball at the same time had merits.
Here is an idea to make the automotive industry slightly better, just an incremental improvement. DBC files are used to specify CAN interfaces, they allow big endian and little endian messages within THE SAME MESSAGE, which is madness. Why not pick an endianess, just one, it does not matter which, do not make things generic (I have nightmares of German mechanical engineers writing software saying the word "generic"). Do that an you have actually achieved something. I am not even suggesting specifying what messages numbers do what, or what signals they contain for a particular ECU (which would make literal components reusable). The automotive industry is riddled with bad, terrible, software.
I do not know how you blame consultants, the German automotive industry sabotaged themselves.
I have no idea how it can be used in safety critical software, because no one understands it. I guess they just test the fuck out of it.
Sorry for the poorly thought out rant...AUTOSAR makes me...emotional.
I feel you, I really do, I've been where you are, but I've seem metastatic automotive code bases that were non-Autosar that would make you tear your eyeballs out. So, trust me, there is _worse_ than Autosar. AUTOSAR is a pain to work with, but, at least, to their credit, once you configure the goddamn' modules they do work. You don't know how, because observability sucks. But the modules work.
I agree with your point about incremental improvements. And I agree that reducing useless options would improve the status quo.
Thanks for the sympathetic reply, but luckily I left the automotive industry a while ago, and I did it because of AUTOSAR. I honestly felt uncomfortable working on AUTOSAR projects, and I mean ethically, they were safety critical components I was working on and no one understood anything, being able to understand a system is a hard prerequisite to being able to sign off on it, and I could not work under those conditions with a clear conscious.
I will have to take your word on seeing projects worse than AUTOSAR ones, I have seen terrible non-AUTOSAR projects, but the only good projects I have ever seen in the automotive industry have been non-AUTOSAR ones.
AUTOSAR had the idea of collecting the common parts used for CARs. Your phone doesn't need a generic library for CAN, but cars do. Reuse isn't a new idea, but the idea of doing it for common car specific code is new - it is an obvious idea whose time has come, but still new for this specific application.
Then consultants got involved and made it into the garbage it is. The ideas themself were sound and obvious. However they over complicated it and made it into garbage even though the idea itself is sound. (over complicated as in I know experienced autosar developers who got fed up and took 1 week to rewrite in C code they had just done in autosar in 3 months!)
You have sort of chosen a bad example, although I appreciate the response - my phone runs a Linux kernel (Android) and the Linux kernel does have software and interfaces for CAN! They will not be compiled in, because the phone doesn't have the requisite hardware, but that bolsters my point even more, the Linux kernel is an example of software flexibility done right and it does a better job of providing software flexibility for cars than AUTOSAR which was designed for cars!
So code reuse for cars, yes, that's a good idea. But that's hardly revolutionary, it's barely even an idea, it's certainly not unique. It's like saying world peace is a great idea, or solving world hunger, okay, so then what? How's that idea actually implemented? Terribly (which we agree on).
To be honest, I don't think we disagree that much, just arguing over very minor points. I happened to chose your comment to reply to instead of another, it should really be viewed as a generic rant against AUTOSAR instead of against anything you've said.
I think I'm taking the view the software is theorem building, it is a bunch of ideas, thus AUTOSAR is a bad idea. Sure, you could argue the core idea is a good idea, but "reusable software", or even "reusable software for industry X" is barely an idea, it's "nice things are nice".
> Here is an idea to make the automotive industry slightly better, just an incremental improvement. DBC files are used to specify CAN interfaces, they allow big endian and little endian messages within THE SAME MESSAGE, which is madness. [...] Do that an you have actually achieved something.
What exactly? Will your proposed change make the cars more reliable? Cheaper to produce? What is the benefit?
It's an example of an incremental improvement that could be made, by itself the change would be lost in the noise, but a series of them would make a difference.
The problem I highlighted, although a seemingly minor one, is actually a symptom of a problem within the automotive industry and their attempts to solve problems around complexity. Even minor things are not locked down, what endianess is used? Why not allow both, What CRC is used? Don't specify, allow some random engineer to decide! Let's make things "generic", because making things generic is good right?
Instead you could specify "This is an X ECU, all X ECUs have the following messages, each message has these signals, we use this CRC, we use this endianess, this is how we handle errors, etcetera". Instead if you get an brake ECU from one vendor or another, they have completely different interfaces and behaviors around error handling. This is just one facet of the software engineering problems in the automotive industry.
It is as if they do not know that other software projects exist. Take for example Linux, they use it but they do not understand it. Here we have something that has been ported to a dozen different CPU architecture, targets god knows many different systems, and can be configured with thousands of different drivers. It works, and it might not be appropriate for a safety critical system, but you can learn by how it does things, what its build system looks like, and so on.
The re-usability that has actually worked is done by reusing Operating Systems, Programming Languages, Libraries / Modules at language ecosystem level, and at a more fine level Objects / Interfaces / Generics. It is also done by locking down the behavior of systems and standardizing them, either by an external body, or preferably by a standard that has won out in the market by virtue of being better. It is not done by making a standard in which everything can happen, nothing is actually agreed upon, and oh, by the way you have to use these incredibly expensive code generation tools that just don't work correctly.
The only thing that slightly irks me is that these are the same companies that were found to have kept innovation back by colluding on synching technology adoption per generation across the brands.
It's always the same story. When I worked in the blockbuster VFX industry, in the early to mid 2000's, whenever anyone suggested we open-source stuff, people would shake their heads.
After all, your craptacular pipeline was surely the secret sauce that made you get jobs and/or be cost effective while everyone else was definitely cooking with water ...
I remember a friend of mine getting openly mocked at a pub in Soho, in 2007, by his co-workers from MPC for suggesting this. DNeg, the company I worked for at the time, wasn't any better.
Mind you, this was after ILM already open-sourced OpenEXR and Alembic formats years ago and they had become industry standards more or less over night, afterwards.
Now there is the Academy Software Foundation and everyone in VFX is using OSS (that came from various big studios, mostly) all over the place.
When I worked in the automotive software industry in Germany, half a decade ago, it was the same. People shook their heads at me and I was mocked for suggesting this.
But I actually made a bet then (just a crate of beers, but hey) with one of the mockers. I guess it will soon be time to cash in on that.
Ok, being the German automotive industry (or rather: BMW & Mercedes, for now, if I read the press release right) -- when it comes to anything software it could still be anywhere between 1--5 years, before the intent "materializes" ...
Most automotive software is targeting real time operating systems from what I understand. Their are some Linux projects built around RTOS that are open source, but current Linux OS is mainly focused on non RTOS systems.
Yes and no. There's a very significant shift underway to move a lot of functionality to Linux. It's very likely that you have at least one kernel somewhere in your car if it was made in the last 5 years. It's essentially guaranteed if your car has ADAS functionality.
Traditional RTOS' are for the most basic, safety critical functionality because the cost of certified (and even QM) code is so high and the tools available are so primitive.
Of course, because after years overpricing for cars nobody needed they've starter to see China is eating their market share.
If you bought a VW, and Audi or a MB in the last 7-8 years you know what I mean.
I'm not sure if there's a substantial dent in existing markets, but I would guess that as the Chinese market (the largest in the world) continues to expand, non-chinese makers will have a lower share of the overall global market. I don't think it has anything to do with open source though.
Not because open source but for not joining forces as a german industry and fighting each other to prevail by themselves meanwhile the chinese were using their technology (mostly sent to China by the german automakers) to produce cheaper and better cars (EVs)
Eh, kind of, but not really. They do have some open source initiatives here and there, but OSS is not the differentiator. They are just better executers, IMO.
Volkswagen absolutely sucks at software. For example, it took me over an hour of infuriating guesswork to add a second user on my car. Then once a new user was added basically nothing actually takes account of who is logged in. I was hoping it would at least remember some settings but nope, it literally just changes the name displayed on the infotainment system when you start the car.
Nearly one year ago the German federal government passes an amendment to law on preferential use of open source software.
Now they push projects like OpenDesk[1] to fully replace MS Office (365) and OpenCode[2] where they open-source all software that is build with public money.
In my view, this has led to the German economy having more confidence in open source, and that open source can be used and maintained as a model for software over a period of 5-10 or even more years. Instead of buying licences and hoping that the manufacturers will maintain the software for at least 5 years and provide updates. In addition, there is the realisation, not least as a result of the change in the law and the current global political situation, that sovereignty is a very important factor.
[1] https://www.opendesk.eu/en
[2] https://opencode.de/en && https://gitlab.opencode.de/explore
To me the "opendesk" effort looks like a lot of not-open source "licensed" software ("with less than x% closed source") and a handful of wrappers around other people's open source software (diagrams.net wrapped as cryptpad, for example). In fact they recommend the "enterprise edition" which is NOT fully open source, right?
It says all the right words and has a flashy landing page, but doesn't seem very open or impressive; am I wrong in my assessment?
In my understanding it is fully open source and it's source code is available on OpenCode [1]. OpenDesk use nextcloud, Open-Xchange, Element and so on. And it actively contribute to this software. In my understanding, the enterprise edition, is the non-self-hosted version of [1].
What is the not-open source software used in OpenDesk? Because your example: cryptepad[2] is GNU Affero General Public License. And diagrams.net might look similar, but also LibreOffice looks similar to MS office.
[1] https://gitlab.opencode.de/bmi/opendesk
[2] https://cryptpad.org/
https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/...
It looks like multiple items in deploying the "enterprise edition" have licenses and are actually a closed-source model.
To me this looks like a flashy web page that makes all the right noises about "data sovereignty", etc, but relies (on the actual back-end) on multiple providers who have in fact cut off access to code; they even take pains to say it is "less than x% of code" or "Admin Console container image: 100% closed source", etc.
There are multiple examples on that page.
In my opinion this project is the best effort so far to have a full Office365 open-source alternative. And yes, if you want to have the enterprise edition, you have to accept the enterprise licenses, to have then features that contain closed source code. But this is an option, for enterprise. I think, they can still make the claim: fostering data sovereignty.
> In my opinion this project is the best effort so far to have a full Office365 open-source alternative.
Then the effort sucks.
From my perspective as a German, this almost looks like a scam. It's a bunch of OSS software rebundled as a package by a company which would like to make money off of support for the software. Which inherently sounds great, except that their only original contribution to the software package is a mid tier project management app.
The vibe I've been getting so far, is that they're trying to resell OSS software and accompanied support, except the underlying software already has great community and commercial support (Nextcloud and Collabora for example) and to make up for that, they're getting the german government to slap a "Made in Germany" label onto the package.
No it does not. And you act very german right now.
ZenDiS is the german goverment.
I’m an American and thought the effort sucked too - I had the same thoughts (it looks like a thin wrapper around other open source code with closed source “enterprise edition” which allows for providers there to overcharge for functionality that isn’t returned to the open version).
> What is the not-open source software used in OpenDesk?
The Calendar is closed source?
And probably also the e-mail client and contacts list?
Mercedes Benz is already for example using KWin from KDE as Wayland compositor and likely many other open source components. So this sort of move is not without precedent.
It's a smart move to do so instead of switching to Android Auto and loosing control of one of the most important component of the experience of the car.
Kia is also using a Linux Wayland system on an x86-64 Intel machine (with an iGPU) with an (excellent) QT5 UI for their infontainment system
They're replacing it with an Android Automotive-based OS in 2026.
[flagged]
Still? It is the best and the most mature cross-platform toolkit. Among both open-source and proprietary ones. It is the default for embedded / industrial UIs and automotive. At least in Europe but I think many US companies like Autodesk also use Qt. Its programming paradigms are a bit outdated. However, it is quite performant and supports many 2D and 3D acceleration drivers / APIs.
I'm not sure I agree the paradigms are outdated. Sometimes the new stuff ends up worse for the problem
https://try.qt.io/projects/outrun-ivi
Qt pretty much owns the automotive market.
Medical also
Wow: I run KDE with Wayland on my PC, and given the instability I've experienced, I'm surprised it's suitable for a high-reliability environment like a car. I suppose that it being a more controlled environment may help, but even still, I wonder how stable it actually is.
They aren't using KDE for the car, just KWin. And KWin is a robust compositor - it will happily survive a horrible KDE crash and even let you restart the session (unlike Mutter) in many cases.
If you're only using a Wayland compositor to render a webview, you cut out a lot of the surface area that could potentially cause a crash.
"Wow: I run KDE with Wayland on my PC"
Me too - its fine for me. You are probably holding it wrong 8)
My car (Seic MG4 - an EV) clearly has two lots of software. The reliable stuff that runs the "must work" stuff like driving controls and motors etc. and the other stuff that ought to work in an ideal world and I think that lot is on the Android tablet mid dashboard.
The other stuff even includes "lane assist" and other safety features because when I force re-boot the console they report as offline on the display behind the steering wheel, which I think is linked to the first system - the RTOS automotive jobbie.
I think SEIC (and I'm sure this is standard practice) have done a fairly decent job with the divvy up of responsibility between funky features and must work or death will ensure features. I'm an IT consultant and know when Android auto has crashed on my phone or car or both or the radio is on silent or there is dust in a USB port ...
Wayland vs X11 is not an issue in cars - whatever you get will either work always or be a bit of a mild distraction.
Cheers Jon
PS I went to school in Abingdon, Oxfordshire. My car has nothing in common with the real Morris Garage. The MG marque is merely an affectation and I don't know why Seic really bothers.
They will have to fix their attitude towards the people who build software before they can be successful.
In a typical German corp software developers even in RnD are not seen as an asset but as a mixture of line workers and support staff.
The problem is: The world best assembly line worker will not boost your companies performance in a measurable way, but a better dev will make a heavy impact in his project.
Nice example:
A friend of mine worked in RnD in a German DAX corp. C-Level regularly had them fix bugs in other projects. Why? RnD is the only department that can adapt its planing fast enough to fit in stupid side tasks. As a result the best people left, were replaced and the average skill of the department regressed to the mean.
Exactly this. In Germany, the median software developer is treated (and paid) pretty much the same as a blue collar worker, both by their company and by society at large.
From calling it "IT" to paying peanuts, no wonder no one smart and ambitious wants to get into CS here. All the smart kids seems to want to go into consulting and finance. So, of course Germany doesn't see the kind of outsized success in the Tech industry like the US or even the UK.
Volkswagen's (and in general other automaker's) software sucking is simply a fact downstream of that.
There's one area where EU software industry is on the cutting edge: The gaming industry.
Again, the platforms are all American but Europeans know how to make kick ass games that are delightful and awe inspiring. French, Polish, Ukrainians, Bulgarians, so many legendary people are from Europe.
They should hire game developer to guide the user experience and listen to them very carefully.
Not exactly correct. It is just the US studios that are failing because they are captured ideologically, and prioritise other things than making games people want to buy and play.
The EU has good studios, for now, on par with the asian market, but they run the same risk as the US.
The salary difference between American and European Game Devs isn't as significant as it is for other segments of SWE.
Was this because the game dev salaries were low in US or high in Europe?
The former.
Meanwhile, a lot of the higher value work such as in Engines tends to pay pretty high - for example, Epic Games pays SWEs and PMs in the $200-400K TC range, but this is overwhelmingly in the US. Similar story with Unity despite originally being European, but shifting to the US in the 2000s.
Low in the US
There's only four things we do better than anyone else:
music
movies
microcode (software)
high-speed pizza delivery
Microcode? Why Microcode, specifically?
It's a quote from Snowcrash: https://profalexreid.com/2014/02/05/music-movies-microcode-a...
Ah, thanks, I missed that reference.
The serious move would be centralizing their budgets they have for developing these functions in a new independent company, and until that happens it's likely to get stuck in analysis paralysis.
If in doubt take a look at what they're referring to: https://eclipse-score.github.io/
I saw a video where a mechanic replaced a pack on his Model S with a 100Wh pack. There were some minor issues of fit, which he had all figured out. There was a connector change and some sheet steel around the edges that needed changing out to make it physically fit. The procedure was to keep a table under the vehicle, lower the vehicle so that the pack rested on the table, remove the last retaining bolts on the bottom, and lift the car back up. Reverse for install except he had to align it first. He estimated it would take 2 hours total. This car was designed for fast pack exchange. The coolant connections were self connecting and disconnecting.
Then came the software. The amount of complexity and jargon and issues and roadblocks that come out of nowhere is extraordinary. You have to dive several layers deep in a menu system to do step 1, then get hung up on opening a "gateway", then dive down the same menu to do step 2 of a 2-step process. He had another problem that kept him busy but what impressed me is the amount of time and complexity to do the simplest things. He wasn't performing many steps, but just getting to the step required rebooting, waiting, pressing the brake pedal to see when it was time to move the right turn signal stalk, didn't work, go back, do something else for 10 minutes, try again, it seemed endless.
German automotive companies have historically been terrible at software. Just because Tesla hasn't simplified or integrated their various software components yet, doesn't mean others can't do it nicer. But any company that doesn't value software like the Americans do is going to have a real tough time with the EV software problem.
All hardware companies are terrible at software except NVidia. It's not just German automakers, US automakers are just as bad.
Everybody just uses QT Auto and they create horrendous interfaces plus they use cheap electronics with not enough resources to power all of that eye candy.
The chinese can create good looking and useful UIs and they can even go deeper in the stack.
in every case I know of moving to qt greatly increased the quality of the ui. Though touchscreens in a car still suck everywhere.
cheap electronics will stand up to use in a car for years - something the fastest computers often fail at. I'm under NDA so I can't give more details.
Those cheap often boot instantly while more powerful ones often need a minute by the time everything is initialized.
I had presumed that car GUI/Infotainment systems were just in sleep or hibernated when the car is off, to shorten the startup time when switched back on.
Some part of it, yes. In the systems I worked on you had the "AC" - Automotive controller that was in a sort of deep sleep. But the "CG" - graphics controller was completely shut down.
They need to boot fast after the battery is replaced. Sleep also needs to not drain the battery. sometimes they will do a full shutdown after a week if sleep can still use power
So? Tesla can do it and they use the same thing like everybody else. Their UI feels apple like and yet they just use QT like everybody else.
The infotainment is just a small part of a car. It's the thing you interact with, sure but it's just the tip of the iceberg.
As always there is a difference between what course of action is widely agreed to make sense for everyone involved, and what course of action is in agreement with the structure of the corporation. The Audi/ Cariad disaster being just one example.
I'd like to see some insight on whether this has a realistic chance of being the winning bet within the companies involved. So far it sounds too obviously useful to win the politics game.
1. Personally, I don't want software in my car, I want physical buttons and switches (then I can control my car without looking at any distractive screens).
2. The German car industry already successfully teamed up on sharing map data (https://www.here.com/).
3. However, while this may work for Libre Office installs in a city administration and (non-critical) car infotainment software, this likely cannot work for the most important automotive control software, due to the legal responsibility of the car manufacturer (they would need to review/audit all changes of open source contributors line by line, patch by patch) - because bugs can cost lives there.
What do you mean, you don't want "software"? Where do you draw the line? A basic digital wristwatch has "software".
You're going to have software for a modern, efficient car, whether you like it or not. For the engine (fuel injection alone needs a bunch of software), ABS, traction control, A/C, and countless other things. And whether your radio has physical buttons or not, unless that physical button is on a radio from the 1980s and directly controls a variable capacitor and a belt to a frequency indicator, it's going to have software.
Of course we had cars entirely without software, about 50 years ago. But they were slow, had many quirks, and absolutely massive relative fuel consumption compared to today.
> What do you mean, you don't want "software"? Where do you draw the line? A basic digital wristwatch has "software".
I think this nomenclature is a result of the post-Jobs software as "app" paradigm + Web as the definitive "application" platform era.
The majority of software written, especially in these circles, is going to be some sort of user interface/CRUD stuff. The "invisible" (and frankly remarkable, when talking of things like ECUs and ABS software) is basically like The Earth (it's just always been there and taken for granted).
"Software" in a vehicle is more than just the UI in the dashboard.
Your engine control, your ABS and your traction control all run software (or "firmware", whatever that word means in this age) and they have been for decades.
What needs to stop is that awful trend tesla started where they replace the entire dashboard with a tablet.
Regarding the need to review and audit all changes, it doesn't matter whether it is open source or closed source. I think the idea is, that various car makers collaborate, not necessarily patches from outside of those organizations.
Do you think they audit line by line every piece of SW in a safety critical ECU? Because if yes, I have a bridge to sell you. They do many many things to insure the SW works, but there are a bunch of corners in the SW very few people poke at.
And anyways, merely auditing I serious doubt would be effective. (LGTM, ship it!)
This doesn't surprise me. Here's my hot take, having worked building these kinds of ecosystems in automotive and related industries (RV), and also working with German automotive/caravan companies in those spaces.
1) They don't want to invest in building vehicle software ecosystems as it's expensive, time consuming, and not exactly in their wheel house. Wireless and cloud connectivity just aren't their language.
2) They don't want to work with existing proprietary off the shelf ecosystem solutions -- they feel that because it's "their vehicles" they should "own" the technology and IP. They don't want vendor lock in, so they avoid existing proprietary solutions they can't "take over". And by "take over" I mean "have the vendor give their proprietary stack to them for free, so they can then share it with their other suppliers".
3) They expect the vendor base to "partner" to develop "open" software stacks for free -- which most vendors aren't keen on doing as there is little upside for the vendor to spend their own internal NRE building a system that their competitors benefit from and can quickly undercut them on. They generally refuse to pay for the development of a stack that they can own and build upon.
The root cause seems to be magical thinking from the higher ups - "Hey connectivity stuff is everywhere, it can't be hard, why should we pay for this?"
They don't want to build it. They don't see the value in paying for it. So of course open source is the obvious solution. Hey, just have the nerds build it! They love doing that kind of work for free.
All three points are valid for every platform provider, and so for car manufactures.
This is basically AUTOSAR reinvented, by mostly the same companies. That's not a bad thing, AUTOSAR is a flaming pile of trash and this is at least picking a better foundation. It doesn't solve the core issue though, which is that the auto industry struggles to understand software.
AUTOSAR is a spec, this seems to tackle an actual implementation.
As the other commenter said AUTOSAR had some good ideas, but now it has too much cruft and it's hard to decrusity it. If they trimmed 80% of the standard, had an actual open source reference implementation, overhauled the tooling to make it not suck and added solid observability capabilities and did something about the god awful RTE experience, it would be pretty good. The API's are sane, interactions make sense.
AUTOSAR had some good foundations, but consultants who didn't understand anything (as normal) over sold what it did and then sold companies on a lot of bad ideas because management didn't understand the real problems.
If your program is hello world complexity then it isn't worth the cost to make it reusable, just write and maintain 100 different copies - meanwhile elsewhere there are only 5 copies of the transmission controls and since it is only 5 it didn't get to the top of the list to fix redundancy - but those controls are very complex and making one version would be well wroth the effort.
No, AUTOSAR is a flaming pile of shit. What good ideas did AUTOSAR have? Reusable software components? That is the idea every single software engineer or computer scientist had ever, it is completely unusable and I have never, ever seen a MISRA C compliant anything if it is generated by AUTOSAR (well, unless you count a deviation list longer than the ARXML used to generate the crap).
"AUTOSAR is a good idea, it works in theory", nope, much like communism if your theory does not work and continues to fall flat on its face it is a terrible theory. No one would say a theory of gravity that predicted you would turn into a unicorn if your really wanted to and dropped a ball at the same time had merits.
Here is an idea to make the automotive industry slightly better, just an incremental improvement. DBC files are used to specify CAN interfaces, they allow big endian and little endian messages within THE SAME MESSAGE, which is madness. Why not pick an endianess, just one, it does not matter which, do not make things generic (I have nightmares of German mechanical engineers writing software saying the word "generic"). Do that an you have actually achieved something. I am not even suggesting specifying what messages numbers do what, or what signals they contain for a particular ECU (which would make literal components reusable). The automotive industry is riddled with bad, terrible, software.
I do not know how you blame consultants, the German automotive industry sabotaged themselves.
I have no idea how it can be used in safety critical software, because no one understands it. I guess they just test the fuck out of it.
Sorry for the poorly thought out rant...AUTOSAR makes me...emotional.
I feel you, I really do, I've been where you are, but I've seem metastatic automotive code bases that were non-Autosar that would make you tear your eyeballs out. So, trust me, there is _worse_ than Autosar. AUTOSAR is a pain to work with, but, at least, to their credit, once you configure the goddamn' modules they do work. You don't know how, because observability sucks. But the modules work.
I agree with your point about incremental improvements. And I agree that reducing useless options would improve the status quo.
Thanks for the sympathetic reply, but luckily I left the automotive industry a while ago, and I did it because of AUTOSAR. I honestly felt uncomfortable working on AUTOSAR projects, and I mean ethically, they were safety critical components I was working on and no one understood anything, being able to understand a system is a hard prerequisite to being able to sign off on it, and I could not work under those conditions with a clear conscious.
I will have to take your word on seeing projects worse than AUTOSAR ones, I have seen terrible non-AUTOSAR projects, but the only good projects I have ever seen in the automotive industry have been non-AUTOSAR ones.
AUTOSAR had the idea of collecting the common parts used for CARs. Your phone doesn't need a generic library for CAN, but cars do. Reuse isn't a new idea, but the idea of doing it for common car specific code is new - it is an obvious idea whose time has come, but still new for this specific application.
Then consultants got involved and made it into the garbage it is. The ideas themself were sound and obvious. However they over complicated it and made it into garbage even though the idea itself is sound. (over complicated as in I know experienced autosar developers who got fed up and took 1 week to rewrite in C code they had just done in autosar in 3 months!)
You have sort of chosen a bad example, although I appreciate the response - my phone runs a Linux kernel (Android) and the Linux kernel does have software and interfaces for CAN! They will not be compiled in, because the phone doesn't have the requisite hardware, but that bolsters my point even more, the Linux kernel is an example of software flexibility done right and it does a better job of providing software flexibility for cars than AUTOSAR which was designed for cars!
So code reuse for cars, yes, that's a good idea. But that's hardly revolutionary, it's barely even an idea, it's certainly not unique. It's like saying world peace is a great idea, or solving world hunger, okay, so then what? How's that idea actually implemented? Terribly (which we agree on).
To be honest, I don't think we disagree that much, just arguing over very minor points. I happened to chose your comment to reply to instead of another, it should really be viewed as a generic rant against AUTOSAR instead of against anything you've said.
I think I'm taking the view the software is theorem building, it is a bunch of ideas, thus AUTOSAR is a bad idea. Sure, you could argue the core idea is a good idea, but "reusable software", or even "reusable software for industry X" is barely an idea, it's "nice things are nice".
> Here is an idea to make the automotive industry slightly better, just an incremental improvement. DBC files are used to specify CAN interfaces, they allow big endian and little endian messages within THE SAME MESSAGE, which is madness. [...] Do that an you have actually achieved something.
What exactly? Will your proposed change make the cars more reliable? Cheaper to produce? What is the benefit?
It's an example of an incremental improvement that could be made, by itself the change would be lost in the noise, but a series of them would make a difference.
The problem I highlighted, although a seemingly minor one, is actually a symptom of a problem within the automotive industry and their attempts to solve problems around complexity. Even minor things are not locked down, what endianess is used? Why not allow both, What CRC is used? Don't specify, allow some random engineer to decide! Let's make things "generic", because making things generic is good right?
Instead you could specify "This is an X ECU, all X ECUs have the following messages, each message has these signals, we use this CRC, we use this endianess, this is how we handle errors, etcetera". Instead if you get an brake ECU from one vendor or another, they have completely different interfaces and behaviors around error handling. This is just one facet of the software engineering problems in the automotive industry.
It is as if they do not know that other software projects exist. Take for example Linux, they use it but they do not understand it. Here we have something that has been ported to a dozen different CPU architecture, targets god knows many different systems, and can be configured with thousands of different drivers. It works, and it might not be appropriate for a safety critical system, but you can learn by how it does things, what its build system looks like, and so on.
The re-usability that has actually worked is done by reusing Operating Systems, Programming Languages, Libraries / Modules at language ecosystem level, and at a more fine level Objects / Interfaces / Generics. It is also done by locking down the behavior of systems and standardizing them, either by an external body, or preferably by a standard that has won out in the market by virtue of being better. It is not done by making a standard in which everything can happen, nothing is actually agreed upon, and oh, by the way you have to use these incredibly expensive code generation tools that just don't work correctly.
"...that accelerates the transition to the software-defined vehicle."
Ew. I want more buttons and less software but better (most car software, visable to the user at least, is junk).
Year of the Linux car!
I'm 100% in favor of the open source approach.
The only thing that slightly irks me is that these are the same companies that were found to have kept innovation back by colluding on synching technology adoption per generation across the brands.
It's always the same story. When I worked in the blockbuster VFX industry, in the early to mid 2000's, whenever anyone suggested we open-source stuff, people would shake their heads.
After all, your craptacular pipeline was surely the secret sauce that made you get jobs and/or be cost effective while everyone else was definitely cooking with water ...
I remember a friend of mine getting openly mocked at a pub in Soho, in 2007, by his co-workers from MPC for suggesting this. DNeg, the company I worked for at the time, wasn't any better.
Mind you, this was after ILM already open-sourced OpenEXR and Alembic formats years ago and they had become industry standards more or less over night, afterwards.
Now there is the Academy Software Foundation and everyone in VFX is using OSS (that came from various big studios, mostly) all over the place.
When I worked in the automotive software industry in Germany, half a decade ago, it was the same. People shook their heads at me and I was mocked for suggesting this.
But I actually made a bet then (just a crate of beers, but hey) with one of the mockers. I guess it will soon be time to cash in on that.
Ok, being the German automotive industry (or rather: BMW & Mercedes, for now, if I read the press release right) -- when it comes to anything software it could still be anywhere between 1--5 years, before the intent "materializes" ...
Most automotive software is targeting real time operating systems from what I understand. Their are some Linux projects built around RTOS that are open source, but current Linux OS is mainly focused on non RTOS systems.
Yes and no. There's a very significant shift underway to move a lot of functionality to Linux. It's very likely that you have at least one kernel somewhere in your car if it was made in the last 5 years. It's essentially guaranteed if your car has ADAS functionality.
Traditional RTOS' are for the most basic, safety critical functionality because the cost of certified (and even QM) code is so high and the tools available are so primitive.
Of course, because after years overpricing for cars nobody needed they've starter to see China is eating their market share. If you bought a VW, and Audi or a MB in the last 7-8 years you know what I mean.
>"overpricing for cars nobody needed"
If the car sells, it is priced at what the customer feels is reasonable. It is not for you to moan as you disagree.
And before the Chinese, there were the Koreans and others who came challenging so it's never been for easy.
I am objectively speaking, I only buy used cars after the major depreciation has happened.
> If the car sells
But it doesn't[1]. And people agree, the main reason is: the cars (esp. the lower price ranges) are too expensive.
[1] https://www.politico.eu/article/brutal-financial-results-vol...
Is China eating their market share with open source?
I'm not sure if there's a substantial dent in existing markets, but I would guess that as the Chinese market (the largest in the world) continues to expand, non-chinese makers will have a lower share of the overall global market. I don't think it has anything to do with open source though.
Not because open source but for not joining forces as a german industry and fighting each other to prevail by themselves meanwhile the chinese were using their technology (mostly sent to China by the german automakers) to produce cheaper and better cars (EVs)
Eh, kind of, but not really. They do have some open source initiatives here and there, but OSS is not the differentiator. They are just better executers, IMO.
Wonder if they will be funding the open source projects they use, and or contributing employee time.
"The enemy of my enemy is my friend"
The Chinese car firms are coming for them, so they are banding together.
Notably Volkswagen is missing
Volkswagen _is_ there as well, just not a quote from them. Source: the MoU PDF
Makes sense as they invested billions into Rivian to get access to their software.
Volkswagen is basically a chinese company. They built more cars in China than in the rest of the world.
Volkswagen is working with Rivian afaik.
Volkswagen absolutely sucks at software. For example, it took me over an hour of infuriating guesswork to add a second user on my car. Then once a new user was added basically nothing actually takes account of who is logged in. I was hoping it would at least remember some settings but nope, it literally just changes the name displayed on the infotainment system when you start the car.
I don’t care what kind of software do they supply with their cars as long as they don’t lock seat heating behind paywall.
[flagged]