Tesla made a name for itself, not only by pushing for electric vehicles much harder than other manufacturers at the time, but upending the traditional processes around car ownership: bypassing the dealership model to sell directly to customers; no price negotiations; no annual model refreshes1; over-the-air software updates. Now that the company has sold its mass-market cars for a decade and proven itself successful, we’re seeing the rest of the industry shift their own operating models to catch up.
Being a software guy, I’m most intrigued by the implications of treating the car like any other modern computing device—where the malleability of software adds heretofore unseen dynamics to what was previously a static purchase. Sure, even my 2004 Honda Accord could update its navigation system every year, but that required buying a DVD of updated map data and going to the dealership to perform the install. 12 years later, and a 2016 Volvo XC90 that wanted to update its cruise control system…also required paying a local dealership to spend 2 hours having their service center tech flash the firmware.
By contrast, Tesla cars generally just want to make sure you’re using WiFi to download their updates.
In the early days of the Model S and especially the Model 3, the cars received substantial improvements with each major update; there were even firmware upgrades that tweaked the performance curve of the engine and increased cars’ range. Over time, the scope and magnitude of the changes have been less dramatic, as most of the core functionality have been added and the operating system matures for this generation of vehicles. Tesla also decoupled the infotainment hardware2 from the car, so that owners could upgrade just the unit—similar to swapping out PC components—to enable more computing-intensive apps and autopilot-related visualizations.
On the flip side, treating cars like SaaS products has the downside that it can and does change rapidly, sometimes in ways detrimental to the consumer, sometimes by playing too fast-and-loose with additional functionality that doesn’t adhere to the slower cadence of automotive regulations. The recent v11 updates are an example of the former, where the developers moved around a bunch of features and made a number of common actions3 harder to access from the main screen. The full self-driving recall would be an instance of the latter, a misstep where a product manager’s decision to implicitly endorse rolling stops turned out to be too aggressive for regulators.
Modern cars have dual software systems: the user interface in center consoles analogous to phones and tablets and PCs, and the core firmware that govern driving mechanisms like traction and steering control, braking and acceleration systems, etc. The SaaS issues above are mostly a concern for the user interface; there’s little evidence that Tesla or any other automaker is being frivolous and careless in maintaining the software that actually drives their cars. But, the introduction of full self-driving, car autonomy levels 3 and above does start blurring the lines between the 2 separated systems.
Core driving software has to be developed like firmware—the code, operating system, testing procedures are closely and tightly integrated with the mechanical parts it’s controlling. Autonomous functionality looks a lot like pure software development: computer vision, machine learning, maps data, with an interface back to the user communicating its calculations and decision-making. To be fair, most firms pursuing autonomous vehicles are iterating on their product with a cadence and care closer to the former style of development; Tesla is really the outlier here, in pushing their Full Self-Driving (FSD) updates in rapid fashion and slapping a beta on the program4. And it is this convergence of what some would consider a cavalier attitude towards software development, coupled with real-world, life-and-death consequences of controlling a 5000 lb. vehicle, that fuels the opposition to self-driving adoption. It has raised the bar to what feels like an acceptable level of error for machine-controlled driving to be orders of magnitude higher than existing human error.
One of the reasons that commercial software moved en masse to the subscription service model is that the business model ultimately increased the lifetime value of its users, by being able to count on an ongoing stream of revenue month-after-month and year-after-year. To keep users satisfied, however, required continuous updates to the product, something that software is well-equipped to handle. Hardware—and in this case, cars—don’t have quite the same distribution characteristics that allow it to mimic the lifecycle of code5, and the software within cars…well, at least one company’s pushing to SaaS-ify it.
I’d argue that one hurts more than helps.↩
Known as the Media Center Unit, or the MCU.↩
E.g., setting cabin temperatures.↩
It’s also a paid beta that keeps on raising the price of entry.↩
For a while manufacturers tried building a subscription service around vehicles themselves; it looks like most of them didn’t work out.↩
