Intuit Developer and our open source community

We try to make the experience of integrating with QuickBooks Online as easy as possible for our developers, and a big part of that is providing SDKs to make interacting with the API in your favorite language fast and simple. While we provide SDKs in 3 core languages (Java, .NET, PHP), there are other languages developers might want to use, and that is where the magic of our open source community comes into the picture.

You can find a number of third-party libraries for our APIs on Github as well as our own site, but we want to make them even better and more integrated to the Intuit Developer experience. Today we are publishing a set of guidelines we are going to use to select and improve our third-party SDKs and build a better, more connected developer experience with our community. These will be the same set of guidelines we use to select third-party libraries to share on our developer site. Check them out (and give feedback!) below.

Qualities of a good open source API library

• First Time User Experience This is an incredibly important aspect of any code that many people neglect when creating something for the open source community. If you are in the weeds on some code, then it can be hard to think back to a developer who might be new with the language or writing code in general. Notes about how to include the library in a project and get up and running should be easily found, a blank readme isn’t going to help anyone. There should also be links to developer.intuit.com and instructions on how developers can generate their API keys. Without this info, a new developer would have a hard time getting their project off the ground.
• Completeness How far along is the library in API coverage? Can it handle all of the authentication and all of the API’s endpoints? What about switching between production and development tokens? Are minor versions supported?  or  What about advanced functionality like batching requests? The more complete an SDK is, the better it can serve the needs of our developers.
• Recency Our APIs aren’t static entities, they are constantly being updated and expanded so the libraries for them will likely need to be updated as well. If a project doesn’t have a consistent maintainer, it will be hard for it to stay relevant.
• Sample Code In many cases, sample code can be a much more effective teacher about how to use the API than any documentation can be. I’d like our open source libraries to have at least a working sample application that only requires you to paste in your OAuth credentials and App Token. Samples on how how to use each type of entity would be even better!
• Documentation hopefully the SDK is fairly symmetrical with the API and many of the objects and functions are self-evident. That being said, there should still be at least a basic explanation about what some of core object properties and methods are.
• Licensing/Contributing/Authors Github has many mechanisms that can be utilized for these concepts, and they should! Licenses are important in letting other people know how to use the code, contributing guidelines help build the community of useful contributions, and author recognition is something we think everyone deserves.