putting apps in cars, which help explain why most software development so far has been done in house: One is the issue of driver distraction, which Ford has attempted to solve by offering outside developers access to a “sandbox” and API, but not the ability to write code directly onto the car’s head unit. The other is the speed of the car’s development cycle.
“The development cycle is two to five years, depending on the vehicle,” Ellis says. “That runs smack afoul of the consumer space, where the cycle is much faster. Ford’s approach is different, but the same challenge affects all OEMs, and it’s mostly being driven by a massive disconnect between a safe driving experience and what people are used to with their smartphones.”
The consumer’s desire for instant gratification has been made worse by the short product lifecycle of consumer electronics, and Ellis says it’s “really hard” to get outside developers interested in designing software for cars. “Lane-keeping technology, for example, isn’t visually sexy or instantly gratifying, but it’s really cool stuff—it involves big data analytics; business intelligence; business modules,” he says. “It’s not apps versus other. It’s all the same skill set.”
The first way Ford is working to overcome developer ennui is through its developer program, which Ellis describes as “a call to arms to come code with [Ford]. Every time we speak publicly, we mention that Ford is actively looking to hire software developers.” Ford also regularly sends recruiting teams out to universities.
Ellis also points out that while designing apps or software for medical or military applications might be just as gratifying as designing for the auto industry, only a company like Ford can put a developer and his or her invention on a test track. “If you want to see cool stuff come to life, come work for Ford,” he adds.
