A few years back, ProgrammableWeb had four directories; the API directory (what ProgrammableWeb is famous for), the Mashup (app) Directory, a directory of mashup source code that was discovered elsewhere on the Web, and a Resource directory that was a mish-mash of anything else that could be helpful to API practitioners (developers, providers, etc.). If we came across something relevant that didn't qualify as an API, a Mashup, or Source Code, we tossed it into the fourth bucket. This included things like software development kits (SDKs), frameworks, and libraries and there was no clear understanding of what these terms meant. What was a Library to one person was an SDK to another. If you were looking for an SDK and it was classified in our resource directory as a library, chances were you wouldn't be able to find it.
As we leaned back to look at how helpful our directories were to our audience, we also saw the rising importance of the SDK. SDKs, if you're not familiar with them, are language specific tools that make it easier for software developers to work with a technology. That technology could be a mobile operating system like Android, an application server Platform like Enterprise Java or .NET, a hardware driver like a TWAIN driver for controlling a scanner, or, in our case an API. SDKs make developers more productive by giving them the equivalent of shortcuts that would otherwise take longer to code if they had to work in the target technology's native mode. Those shortcuts bridge the gap between the developer's preferred language and whatever the target technology understands natively.
Automated SDK creation is now among the many beneficial outcomes (like automated Documentation and automated test harnesses) of using API description specifications like the OpenAPI Specification or RAML. But they have their downsides too. For example, one downside is that an SDK typically requires more system resources at runtime (not good if such precious resources are scarce) when compared to the resources when working directly with an API. And, while SDKs include many shortcuts designed to make a software developer more productive, the shortcut you most need might not be included.
As we watched the interest in SDKs explode, we knew it was time to set aside a special directory just for them. This way, developers could not only come to ProgrammableWeb to search for SDKs (in addition to APIs), but they could also start their search by looking for the right API, and from there, find a list of SDKs that supported it. On our API profiles, the SDK tab is now just one of many tabs that you can click in order to find resources related to an API as illustrated in this partial screenshot of our profile of the Twitter API:
We did this with the best interests of developers and API providers in mind. One thing that developers look for in an API is a solid list of SDKs that support it and we aspire to help them answer that question. On the flipside, API providers can now populate our SDK directory in a way that might convince developers of their commitment to providing a great developer experience. In the case of unofficial SDKs that come from open source developers and other third parties, we are constantly hunting those assets down and adding to them to the SDK directory ourselves. These services are free of charge and we know of no other destination on the Web that makes it possible to search APIs and any associated SDKs (official or unofficial) in this way, and without restriction.
As can be seen, just this one modification forced us back to the drawing board for both our User Experience as well as our data model (for more on my thoughts about data models, be sure to read Why Forcing LinkedIn to Allow Scrapers Sets a Dangerous Precedent for the API Economy). This was all done with ProgrammableWeb's end users in mind.