A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: "Five Thousand Official SDKs, And Nine Thousand That Are Not," Kin Lane, October 20, 2026, https://apievangelist.com/2026/10/20/five-thousand-official-sdks-and-nine-thousand-that-are-not/
Marisol ran developer relations at a small payments company, and she read the post on a Tuesday between two meetings, expecting a roundup. The first number she stopped on was 15,094 candidate packages across 3,802 providers. The second was 5,008 official ones across 1,808 providers. Roughly 8,900 of the rest looked like a provider's SDK and weren't.
She liked the method more than she expected to. A package counts only if its homepage or repository sits on the provider's own domain or GitHub organization, and the publisher matches too. The post says it plainly: "Both legs, every time." She had spent years arguing with colleagues over what official meant, and here was a rule you could check.
Then she got to the part about agents, and her stomach tightened a little. The post says agents don't browse docs. "They install packages." If the official SDK isn't clearly the provider's, an agent "may well pick the wrapper with the better README." She pushed back on that in her head. It was a hedge, not a measurement, and the post gave no count of how often it happens. She also wondered about the community wrappers lumped into the unofficial pile. Some of them were better maintained than anything a vendor shipped, and a rule built on domains and email addresses couldn't see that. She would have liked to say so to someone. There was nobody to say it to, and she didn't invent anyone.
Still, the sentence about a provider leaving the choice "to whoever named their package first" stayed with her. She thought of her own company's npm package. An early engineer had published it years ago, and she was fairly sure the maintainer email was a personal address. The repository link might point at that engineer's own account instead of the company organization. She didn't know, and not knowing was the uncomfortable part. The post would have counted that package as a wrapper, even though everyone in the building called it the SDK.
She also had a second package that hadn't shipped a release in a long while. The post marks an official SDK with no release in 24 months as lapsed. She didn't want to check the date, so she checked it anyway. It was close enough to the line to be embarrassing.
She did not start a project. She did not open a planning doc or promise a quarterly goal. She opened the npm page for the main package and read the homepage field, the repository field and the publisher. Two of the three were wrong, or at least not hers.
Then she wrote one message to the engineer who now owned the release process. She asked whether they could change the homepage and repository fields to the company domain and the company GitHub organization in the next release, and who could add the organization as a publisher. She added that the old package, if nobody planned to update it, should be marked deprecated instead of left sitting there.
She sent it before her next meeting. Whether any agent would ever care, she still couldn't say.