The German automotive industry wants to develop open-source software together
vda.de
vda.de
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
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?
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.
The Calendar is closed source?
And probably also the e-mail client and contacts list?
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.
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.
ZenDiS is the german goverment.
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.
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.
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.
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.
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.
music
movies
microcode (software)
high-speed pizza delivery
The EU has good studios, for now, on par with the asian market, but they run the same risk as the US.
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.
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.
If in doubt take a look at what they're referring to: https://eclipse-score.github.io/
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.
The chinese can create good looking and useful UIs and they can even go deeper in the stack.
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'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.
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.
And anyways, merely auditing I serious doubt would be effective. (LGTM, ship it!)
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.
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.
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).
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.
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.
"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 agree with your point about incremental improvements. And I agree that reducing useless options would improve the status quo.
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.
What exactly? Will your proposed change make the cars more reliable? Cheaper to produce? What is the benefit?
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.
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!)
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".
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.
Ew. I want more buttons and less software but better (most car software, visable to the user at least, is junk).
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.
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.
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" ...
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.
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...
The Chinese car firms are coming for them, so they are banding together.