Recent headlines from the automotive industry point to a challenge that extends to all embedded software developers.
One story focused on Ford’s decision to bring back experienced engineers—an acknowledgment that institutional knowledge matters. The people who understand why systems were designed a certain way, how they evolved and where potential risks may be hiding are often just as valuable as the technology itself.
Another story centered on Polestar being banned from selling vehicles in the US due to hardware and software linked to China and Russia. Regardless of where organizations stand on the underlying policy discussions, the story highlights an increasingly important reality: the origins, ownership and governance of software are becoming matters of strategic importance.
At first glance, these stories seem unrelated. One is about people. The other is about technology. But fundamentally, both are about the same thing: whether an organization can vouch for systems it depends on—who built them, who understands them now and who will be accountable for them later.
These articles ultimately raise the same questions:
Who’s behind the code?
Not just who wrote it.
Who understands it?
Who maintains it?
Who owns it?
Who can explain it?
And who will still be supporting it years after a product launches?
These are questions every automotive OEM should be asking. They’re questions that manufacturers of medical devices, industrial equipment, fitness products and consumer electronics should be asking as well.
Because software provenance is no longer just an IT concern.
It’s a business concern.
The Software Supply Chain Is Getting More Complex
Not long ago, evaluating software was relatively straightforward. Organizations focused on functionality, performance, cost and delivery timelines.
Today, companies desperate to speed development cycles have changed that equation.
Software may be developed across multiple countries. Components may originate from numerous suppliers. Open-source libraries are embedded throughout modern applications. AI-assisted development tools are generating code at unprecedented speed. Teams change. Contractors move on. Acquisitions happen. Product roadmaps shift.
As a result, many organizations can answer what their software does. Fewer can confidently explain where it came from.
That distinction matters.
Whether you’re building a digital cockpit, a medical monitoring device, a connected treadmill, a smart appliance or an industrial control panel, the software powering the user experience increasingly represents a significant portion of the product’s value—and its risk.
Three Questions Every Manufacturer Should Be Asking
Question 1: Do You Know Where Your Software Is Developed?
For years, software origin was largely viewed as a procurement issue.
Today, it’s becoming a governance issue.
The automotive industry is already feeling the impact as regulators take a closer look at connected vehicle technologies and the software ecosystems behind them.
Geography matters, especially as regulations evolve. Manufacturers should have visibility into where the software is developed, who owns the intellectual property, who controls the roadmap, who maintains critical components and what dependencies exist throughout the software stack.
Transparency is increasingly becoming a competitive advantage. Not because regulations require it, but because leadership teams, customers and stakeholders expect it.
Question 2: Do You Know How Much of Your Software Was Created by AI?
AI is rapidly changing software development.
Used responsibly, AI-powered tools can improve productivity, reduce development time and help engineers solve problems more efficiently.
But the rise of AI-generated code introduces new questions. Who reviewed it? Who validated it? Who is accountable for it? And when a critical issue appears years later, who will be available to explain, maintain and correct it?
The question isn’t whether AI should be used. The concern is whether organizations maintain engineering ownership of what gets produced—whether that means a named engineer signing off on every AI-assisted commit, a documented review standard before code reaches production or simply a policy that no AI-generated component ships without a person who can explain how it works.
Whether code is written by a person, generated by a tool or created through a combination of both, responsibility cannot be outsourced. Someone still needs to understand it.
Especially in products that customers depend on every day.
Question 3: Does Anyone Still Own the Knowledge?
This may be the most overlooked question of all.
The Ford story resonated because every engineering organization recognizes the challenge. Over time, expertise walks out the door. Projects change hands. Teams reorganize. Suppliers evolve. Documentation becomes outdated.
Eventually, organizations can find themselves responsible for systems that no one fully understands.
That’s not a technology problem. It’s a knowledge problem. And it’s one reason why long-term partnerships matter.
Manufacturers need more than source code. They need access to expertise. They need continuity. They need partners who understand not only what the software does, but why it was designed that way in the first place—and who can still explain and support those decisions years later.
Better Questions Lead to Better Products
As products become more connected, more intelligent and more software-driven, manufacturers should challenge their technology partners with a few fundamental questions:
- Where was this software developed?
- Who owns it?
- Who maintains it?
- How is AI used in the development process?
- Who understands the architecture?
- Who will support this product five or ten years from now?
These aren’t just engineering questions.
They’re leadership questions.
They’re questions about whether an organization can confidently stand behind the products it brings to market—today and years from now.
They’re questions about risk, resiliency, accountability and long-term product success.
Why Altia
At Altia, these questions aren’t theoretical.
We’ve been developing software for embedded graphical user interfaces since 1991. Our engineering teams are based in the United States and Europe, and our engineers have been with us for on average longer than 15 years. This means that the people who built your software are very likely the same people who can still explain why it was built that way.
That continuity matters.
Many of our customers have relied on Altia’s technology for over a decade. Those long-term relationships reflect what happens when a vendor treats long-term maintenance and support as a product feature, not an afterthought.
Our team brings deep expertise in embedded graphics, human-machine interfaces, performance optimization, production deployment and long-term product support. Just as importantly, we emphasize transparency around how our software is developed, who supports it and how it evolves over time.
In a world of increasingly complex software supply chains, growing regulatory scrutiny, AI-generated code and rapid technology change, our customers deserve confidence in the people, process and expertise behind our products.
The organizations building tomorrow’s products—whether they’re vehicles, medical devices, exercise equipment, industrial systems or consumer electronics—should know where their software comes from, who stands behind it and who will be there to support it in the future.
Those are the kinds of questions that help build better products—and stronger partnerships.