Can the Auto Industry Make Silicon Valley Developers Feel Welcome?

6/10/14Follow @XconomyDET

It’s often said that today’s automobiles are close to being to computers on wheels, with more than 50 million lines of code—10 times more than what’s in a Boeing 777 jet—controlling everything from braking systems to navigation units to entertainment. Software development has never been more critical to a vehicle’s design and operation.

But the shift to smart cars raises a number of tough questions for the auto industry. Can Detroit, where the U.S. auto industry is still headquartered, convince software developers that working for car manufacturers is a career path just as potentially lucrative and satisfying as, say, going to work for Microsoft or Google? Will Silicon Valley acknowledge that it has something to learn from Detroit in terms of making products that operate reliably across decades of iteration? How can Detroit entice young developers at the forefront of making fun, innovative apps that customers love to make products for the in-vehicle environment? Will young drivers who have been connected to the Internet since birth truly demand that their cars have the same app and Web capabilities as smartphones?

These questions were part of the subtext at last week’s Telematics Detroit conference, an annual event that has grown to become the world’s largest forum dedicated to the future of connected cars, drawing thousands of auto manufacturers, suppliers, telematics companies, and software developers to discuss trends, infotainment, vehicle-to-vehicle and vehicle-to-infrastructure technology, security, safety, and more.

Most of those questions remain unanswered, and it’s possible to talk with four different people in the industry and hear four completely different points of view—as we did for this article. But what is clear is that many software developers find the prospect of working with the auto industry daunting. After all, Silicon Valley software culture is praised for being agile and innovative while Detroit’s car culture is often accused of being slow and secretive.

Within the telematics industry, there are different opinions on the wisdom of recruiting developers from outside the auto industry, but few viewpoints that garner universal agreement. Anyone paying attention to the auto industry knows that connected cars and the increasing receptivity toward outside innovation are popular topics of conversation, but the specifics of how connected cars will evolve to satisfy both tech-savvy consumers and safety regulations are still up in the air.

At a connected car summit called AppConext Auto that was held in mid-May at Southfield’s Lawrence Tech University, the “developer dilemma”—whether the app developer/gamer crowd should attempt to design products for the auto industry—was highlighted in a presentation by Abhinav Gupta, CEO of Game Scorpion.

Gupta feels that there are a handful of things auto manufacturers should do to make the industry more attractive to outside software developers: The auto industry should make it easy for developers to design in-vehicle software; in-vehicle software operating systems should be open and accessible to developers working outside the industry; cars should support popular platforms like Android and iOS; developers should be protected from lawsuits if anything goes wrong with an app while a driver is using it; and auto manufacturers should clearly communicate how software developers will make money from the products they invent.

“Car companies really want to get in on [recruiting outside developer talent] because consumers will demand it,” Gupta says. “And it opens up a whole new revenue stream for developers.”

Gupta, who has developed more than 40 apps for more than 20 different markets worldwide, says he sees similarities between the current auto industry and the mobile app industry of 2008, when “very young developers” took over.

For senior developers back then, apps were scary, Gupta says. Kids already loved playing around with screens, so they naturally gravitated toward creating mobile apps. Getting those same young developers to begin making products for the auto industry will be a challenge, he believes, because they’re impatient and not terribly interested in learning proprietary in-vehicle operating systems that vary from brand to brand. Instead, he says, cars should be able to run off the Android or iOS platforms.

“You have to make it easy for us,” Gupta argues. “I went to Ford’s website and I couldn’t find where developers go. Instead, we’ll end up going to [Ford’s] competitors that make it easy for us. To get developers more interested, the auto industry needs to open up to new ideas. They should invite developers to their headquarters so [developers] can test the apps they’ve created. It would open doors and say, ‘We know you’re important.’ Those companies that treat developers like they’re not important will see developers leave.”

Gupta says the auto industry must also spell out exactly how outside developers will monetize the in-vehicle products they create: “If I spend a month or two developing apps for a car manufacturer, how will I recoup that time and money?”

In Gupta’s opinion, nobody in the auto industry is showing true leadership in the area of courting outside developer talent, though he praises Ford for making the attempt.

In contrast, Scott McCormick, president of the Connected Vehicle Trade Association, is somewhat skeptical that app designers can move easily to auto software. There are some fundamental differences between games and apps, and software developed for the in-vehicle environment, he explains.

“There’s a completely different level of robustness and ubiquity inside a vehicle,” McCormick says. “The app must work the same in Detroit as it does in Alabama.”

McCormick makes another point: Maybe the auto industry should not focus on courting outside gamers and app developers because the in-vehicle environment requires not only software knowledge, but also adherence to host of safety regulations that limit driver distraction.

“The video game and app industries have relatively few restrictions on the user interface,” McCormick notes. “The fundamental difference with a car is that [the car] can be deadly. There are lots of limitations as to what you can do and where you can do it. There have to be protocols built in. We tend to trivialize that—you can’t just put an app into a vehicle. There are all these factors, like user interface, interoperability, and safety. You bring developers in and they think about it: Telematics is a $10 billion industry, but gaming is worth $100 billion. A lot of them say, ‘I guess I’ll stay in gaming.’”

McCormick says that, so far, he’s yet to host a conference that has truly succeeded in bridging the outside software developer/auto industry gap. “It’s getting there,” he says. “NVIDIA understands that [connected vehicle] space. Cisco understands that space. But NVIDIA and Cisco have created a vertical where developers learn the space and build products for it, instead of taking an app or video game developer and putting him in a vehicle.”

McCormick says how much visual, audio, and tactile stimulation a person can handle is very specific to that individual, which complicates the task of designing the user interface. There is also no set of universal, connected vehicle software standards, though entities like the GENIVI Alliance are working to change that. (More on GENIVI later.) There are about 42 networks and up to 200 different sensors in every car, McCormick says, making the in-vehicle environment especially challenging for software developers outside the auto industry.

McCormick points out that after a sometimes rocky relationship, Microsoft is no longer managing Ford SYNC. Instead, Ford will now partner with an early smartphone pioneer—Blackberry—and use its QNX operating system. “If Microsoft couldn’t figure it out, how can one gamer or app programmer?” he asks.

McCormick also says it’s not always true that drivers want apps to work the same in the car as they do on smartphones, and he shared survey data with me that supports that claim. “Having Internet access in the vehicle is about the fifth thing down on the list [of customer demands],” he adds. “More than that, people want a car that is safe, efficient, and affordable.”

Additionally, he says the way auto executives talk in private about the future of connected cars and in-vehicle apps is often different from what they say in public. “An auto exec told me it will take 20 years for automated vehicles to hit the market, but he said in a magazine article that it would take five years. Why the disparity? He said, ‘I told you the truth, but I told the media what our public relations department told me to say.’”

McCormick figures that smartphones have come so far and work so well—if it ain’t broke, does it really need fixing? “If a phone can sense information and send it off, do you want information from the car or from the phone?” he asks, saying that developers might put their skills to better use by focusing on advancing automated car technology. “If you can get to that point where cars are driverless, then you’re freed up to interact with your smartphone in the car.”

In order for drivers to use apps comfortably in the car, McCormick says, some of their driving responsibilities must be alleviated. “If developers would do things to reduce driver workload, lots of [automakers] would be interested in that,” he points out. “If you want to develop apps for the car, you need to understand the environment and find ways to be complementary. Only then will you be successful. If you can add value to what’s already there, you’ll find someone inside the company receptive to it.”

Even though there isn’t much agreement on how software developers will design apps for the connected car, there’s plenty of room for working together according to Joel Hoffmann, a strategist for Intel’s Automotive Solutions Division. One of the founding leaders of the GENIVI Alliance–a nonprofit industry organization committed to driving the broad adoption of an open-source, in-vehicle infotainment (IVI) development platform—Hoffmann says McClintock and Gupta are both right.

GENIVI aims to “align requirements and offer certification programs to foster a vibrant open-source IVI community,” which it hopes will result in shortened development cycles, faster time-to-market, and reduced costs for companies developing IVI equipment and software.

When we spoke on the phone two weeks ago, Hoffmann was at a GENIVI meeting that he says was full of developers happily working for the auto industry. “It’s not so much that developers are afraid to get in the automotive business—quite the opposite,” Hoffmann says. “There’s a philosophy in Silicon Valley that encourages employees to work on passion projects, which doesn’t exist in the automotive industry. Those types of developers, who like working in an open environment, are gathering around companies like Google and Apple because they offer more freedom.”

What Hoffmann sees are scores of outside software developers hungry for automotive work. “They’re knocking on doors trying to get in the industry because it’s a huge growth market with very large contracts,” he says. “Car manufacturers are reaching outside of typical workspaces to bring these developers in because they recognize the typical Tier 1 auto supplier employee might have difficulty keeping up with the newest technology.”

Though they recognize the need for outside talent, auto manufacturers aren’t willing to compromise the safety and functionality of their products by revealing the whole operating system to third-party developers. For instance, Hoffmann imagines, what if an app designed by a third party inadvertently caused a car’s airbags to deploy at inappropriate times?

“The legal issue is definitely relevant,” Hoffmann says of Gupta’s concerns. “And the jury’s still out on how to do this. Nobody has completely figured it out.”

Hoffmann says GENIVI is evangelizing for a different option entirely: An open platform that is welcoming to developers working inside the auto industry to solve specific technical challenges and that also facilitates collaboration with developers from outside the industry. GENIVI is focusing on the Linux operating system because it’s both flexible and modular.

“I’m advocating for more people to get involved with open-source platforms,” he says. “When cars hit the market using the Linux operating system and the cost savings can be demonstrated, the market will align. Linux isn’t a developer environment you can build a car on, but it’s great for experimenting and dreaming up new ideas. You can create innovations on a non-commercial platform that can be applied to a commercial system later.”

Hoffmann applauds Range Rover for using Linux to work with outside developers, and hopes to see other automakers take a similar path.

“Smaller developers with good ideas can create an app on a small device and someday turn that into something they can sell,” he says. “That’s a significant change in the auto industry, and the reason it’s moving forward is because of intense competitive pressure from smartphone makers. Some car companies are pretending to be open, but when it comes down to it they fall back into secrecy. At some point, every car will have to support the ability to plug in an Android phone or iPhone. The question is, what will the level of integration be?”

In yet another point of view, John Ellis, a global technologist and head of Ford’s developer program, says he sees two main challenges ahead when it comes to 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.

Sarah Schmid is the editor of Xconomy Detroit. You can reach her at 313-570-9823 or sschmid@xconomy.com. Follow @XconomyDET

By posting a comment, you agree to our terms and conditions.