Go read OnStar gives Volt owners what they want: their data, in the cloud, by Sean Gallagher, in Ars Technica. It’s a VRM story. The vendor is Chevrolet, the vended product is the Volt, and the relationship management is a DIY hack by one customer. The story begins,
You probably don’t think of your car as a developer platform, but Mike Rosack did. A few days after buying his Chevy Volt, Rosack started slowly mining his driving data. But he eventually revved up his efforts and created a community platform for drivers to track their own efficiency. Today more than 1,800 Volt owners compare stats with each other, jockeying for position on Rosack’s Volt Stats leader board.
The Volt uses OnStar, a GM subsidiary known through its advertising for providing a way for drivers to call for roadside assistance; but which is actually a sophisticated cell-based data system through which cars communicate constantly with the mother ship’s cloud. While OnStar generously shares data back to customers through an app called RemoteLink, much more can be done with it, since it’s data and comes out through an API. Now here is where the story gets VRooMy:
Rosack initially wanted to do more with his own driving data than just view it on his phone. So he built what eventually became Volt Stats to capture this data, then started sharing it with other Volt owners. There was just one small problem: Volt Stats relied on Rosack’s reverse engineering of an interface for OnStar’s RemoteLink mobile application (iOS and Android). When OnStar moved to shut down the Web services interface Rosack had plugged into in mid-October, Volt Stats arrived at a screeching halt.
Rather than leaving Volt Stats stalled on the roadside, GM and OnStar accelerated efforts to give developers a new public Web API to create services on top of OnStar data. The companies even worked with Rosack to get him onboard and get Volt Stats re-launched. Now, Volt Stats is back online and other would-be car data hackers will soon be able to connect their Web applications to GM owners’ vehicle data (provided, of course, that they have privacy policies that meet with the approval of GM and OnStar lawyers).
OnStar had already developed an API for GM partners such as the car-sharing service RelayRides, who need to get access to some of the remote control and telematics elements of the service. But this new interface takes advantage of technologies such as OAuth and JAX-RS and it’s a step toward turning OnStar into a broader platform for the “Internet of things.” It’s also a way to give car enthusiasts a new kind of access to something they’ve always thought of as their own—their cars’ data.
Now come the VRM questions:
- Where and how might customers store that data? Are current PDS (personal data stores) compatible and ready for it?
- How might customers use that data — especially outside and between multiple vendors’ apps, APIs and relationship silos?
- Might we see an ⊂ (r-button) on the dashboards of car? How might that work? And if it does, how do we make it standard?
- What usage and new market-driving scenarios might we start to imagine here?
- How might customers assert their own privacy policies and terms as demand begins to drive supply?
- What other interfaces do cars have that might be brought into the picture?
- How can what happens here model what we do with the rest of the “Internet of things?”
- What are the meshy wireless things we can do among ourselves and our cars, outside any vendor’s box? (Would love Robin Chase‘s thinking here.)
These are questions especially for VRM developers. Look for answers (and more questions) here and on various blogs.