The case for open source software in automotive is not for the developers. It's not even for the companies. The greatest benefits go to the very industry as a whole and automotive needs the leg up. Let's talk about it.

Open source for individuals: maximize agency

I love the individual case for open source software; the Stallman-esque free software movement tickles the techno-utopian nerve centers of an idealistic nerd brain. It feels so lofty and pure of intent. I'm no open source historian but it seems the free software movement was initially consumer-focused; these new piles of beige boxes called "personal computers" were sitting in more and more living rooms and schools throughout the world and it was a great way to make them useful.

Modern open source software predominately focuses on the building blocks of software; frameworks, developer tools, and programming languages. My non-technological family members don't use a single piece of open source themselves, yet every single piece of commercial software they touch is built on open source building blocks. That infrastructure layer is where open source has dominated. It has allowed a motivated developer to spend a weekend cloning repositories, reading open documentation, scouring source code, and have an interesting and unique working application by the end of the weekend. Developers love this; the feeling of agency and capability to build software for free is addictive. One can spend a career chasing the rush of that initial "hello world" tutorial program when you first coerce the machine into enacting your will.

The individual agency afforded by open source tools has a meta benefit; by creating a system that maximally empowers the smallest possible unit of work (a single developer) software effectively casts the widest net. Like a joule thief circuit, open source development allows the software industry to capture and harness the efforts of large corporate-funded teams all the way down to an individual developer halfway across the world with only a few hours per week. The advantages of this system compound when those individual developers do sometimes develop the next hot programming language, UI framework, or even an amazing app idea that will grow into a unicorn-sized tech company. Let me be explicit in my foreshadowing; even when speaking to the individual open source experience the benefits are quickly skewing towards the industry-scale.

Open source for companies: minimize costs

When most companies outside of the tech industry champion open-source adoption the motivation is transparently financial. Even when the initiative was driven by individual open source developer evangelists motivated by idealism, agency, and technical jurisprudence by the time an executive-level director or VP is explaining the open source strategy you can almost see the dollar signs in their eyes like a Looney Tunes cartoon. Open source software is free software and that is the lion's share of the motivation for a company to adopt it.

I won't vilify this motivation; it's a rational response and a net positive for open source. Especially as open source projects proliferate through software development it has reduced the closed source infrastructure available. All to say, there are quite a few projects that simply couldn't be built without either ground up infrastructure creation or utilizing volunteer-supported open source code. The canonical example might be the Linux kernel. Open source is the rails upon which the mainline freight train of software development runs.

One of the core tenants of open source is that it's free to copy and distribute so I firmly declare companies to freely utilizing open source software as a net positive - as long as their cost on the project matches the contribution. But for many projects both will be zero; no issues or feature requests but also no developer time or financial donations. By the very philosophy of open software this is the system working as intended.

There are also broader benefits to companies using open source and here too we're building towards industry benefits. Young software developers and engineers or startups will use the mechanism of open source collaboration to build a business. Job seekers will learn the frameworks and tools used in the industries and roles they want to fill. Startups and consultancies will extend and expand the capabilities of the dominant tech stacks. A company adopting open source for zero dollars is still advantageous to an open source project because of this very dynamic; more attention, more use, and more centralized collaboration is how open source grows and matures.

Open source for industries: the advantage goes exponential

Like compound interest, economies of scale are the immutably powerful force multiplier that dominate the limits of any function. Open source is the mechanism by which software supercharges the entire industry with collaboration at the broadest scale. The tech industry has normalized a freakishly simple yet stunningly powerful practice: collaborate on infrastructure, compete on features.

Horizontal scaling through collaboration

Open source collaboration spreads the costs across every party that could possibly contribute. Kubernetes is pure infra; not a single tenuous link to a user-facing feature and not even particularly useful until your deployment reaches a certain scale. Yet it's open source, freely available to anyone. Used by everyone - Google's competitors and collaborators - and entire new startup companies have emerged to support and expand it. By open sourcing Kubernetes Google took the liability of a necessary internal piece of infrastructure and reduced or nullified the costs by collaborating with the entire industry, gaining new features, and turning their own infra into an ecosystem of projects and companies from which they can draw.

Defining a common substrate of software infrastructure builds a pool of talented individuals and companies that are already fluent in your language. When I speak to an engineer from outside the well financed tech scenes of US/Europe I encounter a ravenous ambition to learn the systems and tools that compose the state of the art. If it's open and available, these ambitious devs will consume it and learn it. But like many tools from legacy industries if the process is proprietary, closed, and commercial then the exchange rate and market conditions make learning impossible without resources. This extends to students and developers from non-traditional backgrounds within the US and Europe as well. With time and moxie nearly any open source platform or workflow can be learned while the benefits of closed source accrue to those already on the inside.

At the industry scale this makes the talent pool for hiring massive and forces both candidates and companies to compete on other attributes than knowledge exclusivity. Developers can more easily take their skills to companies with better pay or benefits while companies can likewise hire from the entire population. No one is stuck with each other due to niche skills or technologies and that free movement of talent and capital creates better outcomes than the alternative. And this applies beyond individual hiring; working with subcontractors, consultancies, acquiring startups, or even outsourcing can all be enabled by open source infrastructure.

Vertical scaling through abstraction layers

These are horizontal scaling advantages; expanding parallelism across the entire industry and minimizing silos. But there is also a vertical de-integration advantage at work and it may be even more consequential.

Building technology is hard and computation is really complicated. Down to the very physical attributes of electricity in silicon, the Von Neumann architecture, and the mathematical origins of computer science. Yet with just a few lines of code I can wrangle billions of transistors into doing useful work. Between my simple abstract program and the semiconductor depletion layers themselves are the layers of abstraction that has allowed the continued march of computer progress. I envision a series of horizontal platforms; common abstraction layers that act as "save points". When technology periodically beats a boss fight they build a checkpoint to return to that state of progress and begin exploring the next area. These might include the invention of C and the rise of portable programs, the BIOS in the IBM-compatible, and the GUI desktop OS. More recently the abstractions supercharging app development are the webview DOM and browser rendering engines. The checkpoints are the abstraction layers that unblock the next generation of technology; the killer apps of a platform or just the next technically difficult problem to solve.

The openness of these abstraction layers is what extends the breadth of that abstraction platform to enable the entire industry to refocus on the next difficult thing. The IBM BIOS is a terrific example because it was intended to be closed. But through a subversive and innovative reverse engineering effort it was opened up and with historical hindsight it's obvious what a revolution that spurred by making the IBM-compatible PCs broadly available. Both hardware or component vendors and software developers could collaborate through the API of the IBM architecture.

Not all of these abstraction layers are open and some even need to be periodically rolled back to reset false assumptions (perhaps the topic of another blog post) but it's clear that the more open the platform the more impactful it is across the industry or by creating new industries. The platforms that are technically closed source - like Windows or Apple iOS - compensate with as much API openness as they can manage, generating novels of documentation and tooling to be an abstraction layer.

Open source is a rising tide

If an individual developer is O(1) and perhaps a company is an O(n) system then any strategy advantages like open source should accrue accordingly. But the very matrix structure of an industry makes it an O(n^2) network, a function that is applied as a cost but also in the possible cost savings from better strategic decisions. Collaborating via open source is the single biggest and most impactful multiplier the software industry has implemented. The advantages have accrued like a freight train gaining momentum, thousands of tons of steel building inertia through the massive scale of thousands of companies and millions of developers all pulling together and pooling efforts.

Automotive needs open source collaboration

This is all almost patently obvious to those with a view only into the tech and software industries. Like many ideological movements, it may be distasteful to some that I've even spent so many words pragmatically justifying a movement that feels intuitively morally correct. But to be the bearer of bad news I regret to report that a bias towards openness is the exception and not the rule in most industries. It is to those fields that I make this case, specifically to the automotive industry in this moment of transition as it tech-ifies.

As the CEO of FIat Chrysler Automobiles, Sergio Marchionne infamously asked why him and all of his competitors were spending hundreds of millions to develop spec-wise identical 2.0 liter turbocharged engines. The answer is that the internal combustion engine is an almost perfectly optimized machine so they were like Olympic athletes at the top of their game; racing to a dead heat with the only hope for advantage that their competitors might make a mistake. Most of the investment into these engine programs is not to build consumer-facing advantages but to meet emissions regulations and drive costs of manufacture down. As an engine nerd it pains me slightly to ask but would the industry be worse off if there was a common engine used by most automakers? Collaboration would lead to more optimization and reliability while manufacturing scale would reduce costs.

While it could be debated whether a modern engine is infrastructure or a differentiated feature the massive content of software on modern vehicles is an even more obvious case for collaboration. A car is much like a computer, with a user-facing hardware and software layer thinly veiling a huge quantity of low level device firmware, buses, and peripherals. The firmware in the controller that actuates the door lock and detects a hand on the handle can only be a liability when it doesn't work or costs too much to build. Outside of its presence and functionality it is unlikely to delight a customer and win a sale.

There are modes of collaboration within the auto industry like AUTOSAR, common suppliers, or standards organizations like SAE, ISO, or ASAM. Yet compared to the diffuse and frictionless collaboration of open source elucidated in the previous sections these are laughably stiff, slow, and unyielding. But the future of automotive is inevitably software heavy. To use a buzzword with no agreed upon definition, I dare even say that vehicles might become software defined.

For automakers to party like tech companies they'll need to do the work and run the whole playbook. This industry has some fundamental business and culture problems that will stand between them and their software-defined dreams but not coincidentally these are exactly the problems for which openness solves.

Auto has a talent problem

I've worked with some absolute intellectual heavy hitters in the automotive industry; engineers, scientists, and technologists packing real horsepower in the gray matter. But the meta trend is unfortunately that we have a talent inflow problem. After the bubble of EV automaker startups in the 2010s, the returns on autonomy were found to be long and expensive, and the recent slowing of battery and EV adoption broadly this industry doesn't have the promise it did a decade ago. The best automotive engineers I've worked with are purely passion driven; the love for cars and tangible mechanical things holds a certain type of personality from going into pure software and tech. Now the tech industry has regained interested in "hardtech" and the slew of space, robotics, and defense startups are offering hardware-oriented industry jobs with better pay and higher returns.

Even still there's a latent interest in the challenges of automotive! Everyone on the planet sees how impactful cars are to their world (for better and for worse). They're unique in being a complicated safety-critical dynamic system with a smartphone-esque consumer electronics product integrated into it. And cars still elicit a passion response from many! So when I tell people at software and tech conferences that I work in automotive there's often a curious and interested response.

But the conversation gets challenging when they ask me what technologies they should learn to break into the industry. My reticent answer is usually a combination of apologetically explaining that many industry tools are expensive and closed while the open technologies I can recommend are not the interesting future-proof areas that ambitious and intelligent engineers are keen to build a multi-decade career upon. This is not putting our best foot forward or rolling out an enticing welcome mat. We're not drawing in the best talent when the only entry point we offer is to move to an auto-heavy area like Michigan to start an entry-level engineering job (paying less than software/tech) and get taught how to use $20k of closed software on your laptop that you won't be able to bring to any other industries.

There are many considerations that go into a company or product tech stack and in safety-critical we can't pick something entirely unsuitable just because the tech industry uses it. But there is a middle ground here, especially with the aforementioned hardtech industries working in auto-adjacent spaces and ready to openly collaborate on new projects. Automotive needs an open tech stack that would allow an ambitious engineer anywhere in the world to execute a project and learn the field. This would create a competitive and talented hiring pool, a flourishing startup ecosystem, and new suppliers and partners.

Platformization requires collaboration

The auto industry is salivating for the platformization that has accrued so much value in the tech industry. Yet most of them are attempting to build a tech platform with diametrically opposed methodologies; no industry-wide collaboration, no universal abstraction layers, and no open source. It just won't work, from either a consumer or an engineering perspective.

As soon as there are more than two competing standards or platforms the average consumer frustration explodes. Try suggesting taking the group chat to a new messaging app (Signal!) and the response is often "ugh there are just so many messaging apps these days". Electric vehicle skeptics or even overwhelmed car shoppers are absolutely gutted to learn that there are two competing charging standards in North America, two outdated/historic ones, and Europe has yet another. So when automakers remove Apple CarPlay/Android Auto because they want to build their own software platform we're not moving towards a nice open duopoly like iOS and Android but towards the preceding state; Palm OS, Blackberry, Windows Mobile, Nokia, and many more. I don't think that automotive can afford to go through a decade or more of proliferation, failure, and attrition to a stable small 2 or 3 platform ecosystem.

We need to build towards the state of platform ecosystem that we already know consumers and developers prefer and this will require some number and distribution of platforms less than the current number of automakers... which means collaboration. Android Open Source Project/Android Automotive is already gaining ground because of access to an app store but why should the auto industry give that powerful platform back to Google just because they all individually failed to build their own? Why can't we openly collaborate on an app runtime and API so that developers can build automotive-specific apps to run on all or most cars on the market?

The platformization also needs to run in the engineering process to streamline cost and development speed. The auto industry dreams of being "software defined" yet the lack of any abstractions at the hardware layer is still defining the vehicle as a product and engineering project. Computers can be a software-defined product because the hardware is absolutely commodified and interoperable. The benefits and advancements of any hardware vendor immediately accrue to not just all computer manufacturers but application developers as well. While I can buy RAM from anyone and install it in (almost, thanks Apple) any computer the interface between an electric drive unit and the rest of a vehicle system is just as theoretically generalizable yet proprietary to each and every platform. The computing industry would be obviously worse off if Dell and HP each developed their own RAM specification and the ecosystem was split into two less optimized and incompatible components.

There are some standards in adjacent industries; J1939 is dominant in commercial vehicles because that market has always required modularity. Now that passenger car dreams of platforms they need to adopt the same open API approach. There are external benefits that I'll vociferously advocate like right-to-repair or second-life batteries and EV components but even without a future state of higher repairability or recyclability just development velocity justifies it.

Opening Up Automotive

I spend a lot of brain cycles comparing the tech and automotive industries, reflecting on what has made tech so interesting and innovative but also the unique and unyielding challenges of hardtech. I could write another 3000 words on all of the ways in which we absolutely can't follow the tech industry due to hardware, safety, and market constraints. But the advantages of open source are undeniable like the laws of physics. The scale of acceleration attainable from moving as an industry, building a global talent and engineering pool, and capturing every iota of innovation through open projects is just undeniable.

Creating open source and open standards is far more difficult than many advocates would like. It comes with footguns and risks that need to be mitigated aggressively. While the software industry is dominated by open source now, we can't forget that it was a decades-long fight that came precipitously close to going another way but for some lucky breaks. The transition to a similar model in other industries will be just as treacherous a journey. But I hope that this exploration has established that this is directionally correct and necessary to build the right cars for the next century of mobility.