Spend some time listening to companies with APIs and you may hear one refer to “long tail developers.” Usually it’s said in a derogatory and dismissive manner: “We aren’t going after long tail developers with our API.” So they’ll put their API documentation behind registration walls, or worse make you talk to sales before you can even find out what the API makes possible. In an effort to focus, companies shun the so-called long tail developer for fear that resources will be drained catering to their every whim. It’s common knowledge that you can’t be everything to everyone. But you can show everything to everyone, which buys you the chance for the right developers to make themselves known. Within the long tail—the group of developers who are apparently not your customers—are coders who work for big companies and perfect partners. Also in that group are engineers looking to switch roles, perhaps to a company you would love to have on your client list. In a world where developers are making more decisions, you can’t get in the way of their research. The same companies that poo-poo the long tail will say they’re going after enterprise developers. Just find the coders in these enterprise companies and sell to them, they reason. Let’s just say you have a magic enterprise developer trap. What happens when you catch these high value targets? Chances are they’ll want the same information as any developer—show me documentation, client libraries, sample applications, and use cases that acknowledge not just the what but the how. The developers you want are the ones who are the most curious. You want someone who might attend a hackathon. You want someone who is eager to kick the tires, to test out your API. This sort of starter, this hacker, is going to be most likely to suggest your API to their employer. Further, the opinions of these hungry developers may be valued higher than the others. If you ignore the long tail developer, only do so because there’s no such thing. Do not, however, ignore what the most curious, excited developers want to know about you. Chances are they’re your best shot. To read more about the Developer Relations Team’s thoughts on this, check out Brandon West’s post on Why We Open Sourced Our Documentation.