This page is addressed to GPS vendors: chipset manufacturers, OEMs, and makers of retail products.

We Matter To Your Future

Linux and other open-source operating systems drive a rapidly-growing segment of the market for embedded location-sensitive systems. The reasons aren't far to seek: (1) Absence of licensing fees is a significant draw for integrators working to hold down unit costs, and (2) open source is now widely understood to lead to software quality improvement.

Uptake of retail GPS units attached to computers running Linux or *BSD is also significant, tracking early adoption of these operating systems by technical experts and influence leaders.

The users of GPSD therefore constitute a major growth area for your hardware sales. The GPSD developers want to help you meet that need, and establish you as a forward-looking company with a good reputation in our world-wide community.

If you've even skimmed the rest of this website, you know that we support dozens of GPS devices, coping on behalf of applications and users with the vagaries of the NMEA standard and vendor binary protocols. Our development team is highly expert in all aspects of GPS and NMEA-based technologies. That expertise can be yours for free.

We maintain a Hardware page that is the open-source community reference for GPS shoppers. A good rating on that page means additional sales for your product. We also maintain a GPS Hall Of Shame, and that is a place you don't want to end up.

We can be of significant technical help to you by forwarding you high-quality bug reports, performance information, and recommendations for documentation and design improvements. In effect, you will be able to use us as an unpaid development and product-support arm.

Understanding Open Source

We've observed that many in the GPS industry are unfamiliar with open-source development, so here is a brief explanation of how it works:

Open-source projects are mostly manned by volunteers attracted to a particular technical problem; the results are published as source code under licenses that encourage free reuse and redistribution, and make the code freely available to all.

By harnessing the power of peer review, this process has been found to lead to a significantly higher average level of code quality than conventional proprietary development. Open-source developers also take pride in their demonstrated ability to respond exceptionally rapidly to bug reports; it is not at all uncommon for open-source projects to issue fix patches the same day as a user complaint.

Another advantage of open source is that we can usually assemble more talent to attack any given problem than any but the largest corporations can afford to hire. There are over two million open-source programmers world-wide, and they tend to be drawn from the top 5% of their profession in ability and experience.

Red Hat and other distribution vendors select and integrate the work of literally thousands of open-source projects like GPSD to produce entire running operating systems of unprecedentedly high quality.

The main disadvantage of open-source development is that, except for the small minority that has attracted direct corporate sponsorship from outfits like Red Hat or major users like IBM, open-source projects have no budgets. Also, for both philosophical and practical reasons, we do not sign NDAs and in general cannot deal with companies that absolutely require them.

Where GPSD Fits In

Some application niches have several active open-source projects competing to serve them; for others there is only one. For GPS monitoring, the GPSD project is it. We do a good enough job for the entire open-source community and every distribution vendor to rely on us.

The current project lead, Eric S. Raymond, is an open-source luminary; as co-founder and President Emeritus of the Open Source Initiative, he has long been one of the movement's principal theoreticians and public spokepersons. On the whole, he'd rather be writing code.

At time of writing in late 2006, the GPSD project has eight core developers and an active development mailing list of sixty-four contributing programmers. These numbers, which are typical for a successful mid-sized open-source project, can be expected to increase slowly over time.

Given the relatively small corporate size of the typical GPS vendor, our mailing lists probably muster more programmers than your company's entire engineering staff. And all that talent wants to add value to your product by writing and giving away software that increases your product's value to customers.

We're in close touch with our user community, and they listen to what we say. Our developers make themselves regularly available on Internet Relay Chat channel dedicated to gpsd.

We're not partial in our benevolence. We write code to solve our problems and because we love a good knotty technical challenge; we'll cheerfully add value to anybody's product, if they'll cooperate with us.

How To Cooperate With Us

The GPSD project, alas, has no corporate sponsors and no budget. We rely on code contributions from technically able users close to their individual problems, and we rely on borrowed and donated test hardware. (We have a wish list; your product may be on it.)

Here are the things we will need from you:

1. Documentation

We will need complete protocol documentation for your product(s). If you are a chip or GPS-board vendor, this probably corresponds to what you ship with your OEM or Evaluation kit.

Note that we are a typical open-source project in that we do not sign NDAs — even if we wanted to, nobody on the project has the authority to bind any of the other developers to an NDA.

Be aware that any portions of the information you give us that are relevant to our programming task will be expressed by publicly available source code and user documentation that anyone can read. The effectiveness of our development process — and all the benefits of it for your company — depends on this.

2. Evaluation units

We will need no fewer than one (1) and no more than three (3) evaluation units of each product you want supported. These units cannot be loaners. As we develop GPSD going forward, we must frequently regression-test the software against supported hardware.

3. A technical liaison.

You should designate a technical liaison from your engineering staff to join our development list. The list has only moderate traffic and our demand on the liaison's time will usually be light, but you will find it is greatly to your advantage to have someone at the table.

We feel safe in predicting that many of your development staff are already running a Linux, BSD or other UNIX-like operating system at home anyway, because engineers do that. We strongly suspect that if you internally broadcast a request for a Linux or UNIX enthusiast to work with us you won't be short of choices.