Who can I contact at Ford about OpenXC?

The code has been released on GitHub and you don't need any special permission or agreements from Ford to use OpenXC. A number of Ford engineers participate in the OpenXC Google Group, that's a good first stop.

If you wish to use Ford's expanded data set, you will need to sign a developer agreement to get access to the binary vehicle interface firmware.

Why not just use one of the many commercial OBD-II scanners instead of OpenXC?

You want to use OpenXC because it offers a superset of features compared to off-the-shelf tools. OpenXC connects to the OBD-II port, and you have the option of using standard OBD-II diagnostic messages like every other scanner and dongle, but it's also *entirely open source* and is flexible enough to support more advanced CAN bus development (e.g. "normal mode" CAN) and reverse engineering.

OBD-II has the advantage of being a standard across all vehicles sold in North America since 1996, but the standard message set primarily concerns the emissions powertrain. The rest of the diagnostic messages are non-standard and not available to the public (and certainly not an open source project). AutoEnginuity, an OBD-II scanner manufacturer explains it well:

Although Ford does implement the largest subset of the OBD-II standard, the typical vehicle only supports 20 - 40 sensors and is limited to emissions powertrain.

This situation is not unique to Ford - the majority of OBD-II PIDs are non-standard.

In "normal mode", the OpenXC vehicle interface listens passively to the many CAN messages already flying across the buses that include data not covered by the OBD-II standard. OpenXC provides automakers with a ready-built platform to selectively grant access to this data, and it provides hobbiysts with the tools required to reverse engineer the data for themselves.

The most important difference between OpenXC and existing tools is the standard programming language and OS agnostic output sent via USB. The reference host device is Android, but there's no reason you couldn't use a laptop with another programming environment (see all supported host devices).

How does the data from OpenXC compare to the standard OBD-II messages?

OpenXC provides strictly more data than OBD-II, since the standard diagnostic messages are supported by the open source firmware.

The data available in extended mode is determined by what an automaker releases, and what a developer is able to decipher on their own. OpenXC relies on "normal mode" CAN messages, and more sensors may be available than what is exposed in the OBD-II message set.

One good example is measuring the amount of fuel consumed, for the purposes of calculating fuel economy. The OBD-II set provides the mass airflow, from which you can calculate how much fuel is consumed. When you can take advantage of proprietary sensor data, this can be much easier and potentially more accurate - e.g. with Ford's OpenXC binaries you can retrieve the amount of fuel consumed directly (at 25 microliter resolution).

For more information on the types of CAN messages, see the On-Board Diagnostics section.

Why wouldn't I just use one of the inexpensive smartphone apps that connect to a cheap OBD-II Bluetooth adapter?

Smartphone apps like Torque are great, but most don't provide any programming interface for you to create new applications. OpenXC is not intended to be a "dashboard" application that you install and use - it's a platform for others to make custom applications that take advantage of vehicle data.

There is actually no reason why existing OBD-II adapters couldn't work with the Android library (ongoing work in this issue), though the performance of some cheap adapters can be poor, and some have been known to drain car batteries.

Why does OpenXC use a separate device to connect to the vehicle instead of integrating it into the host device (Android or PC)?
Most consumer level devices don't have the hardware necessary to connect to a car's CAN bus, namely CAN controllers and transceivers. Additionally, few if any vehicle manufacturers release their CAN message definitions. If the translation from proprietary vehicle messages to the standard OpenXC equivalents was performed in the same environment as third-party applications, it could be more vulnerable to reverse engineering. The strict physical separation of translation from user code provides stronger assurance that the message definitions will remain private, and the CAN bus will be protected from malicious writes from bad applications.