I re-published a blog the other day about SDKs. Originally when I published it, some people perceived it as a rant. I didn't mean it as a rant. I hoped it was mildly clever and possibly the germ for a discussion about SDKs among colleagues. I still think that's an important discussion to have but maybe this isn't the place for it.

In the end, the vision I have for useful reference material pushes into new areas. If you think there are better ways to create SDKs, I'd be happy to hear about them.

For example, I think a Wiki approach would be a good approach for anything like reference material, i.e. classes, members, etc. Here's why. I think the important classes can be identified by a product team in the beginning. Over time, the users of the API might invent new ways to use the existing technology. In fact, that's what a company wants when it creates an architecture.

My model for this is something like a fastener, e.g. a screw. When the first person needed to fasten two things and came up with the screw, they didn't envision all the ways that another person might use that fastener.

By putting the reference content in a Wiki, you could create a single place for decentralized inputs. A lot of people could edit the one material and enhance it for a lot of people. The documentation team would still have a role, but it would also allow any synergy to happen where users take the original functionality to new places.

(I fear that this fails to take the audience into account. It is more 'technology focused than user focused.)