Non-Profit Tech Blog

So here’s a first stab at what we should mean when we talk to our vendors about what an Open API is.

Uses open standards

To prevent vendor equivocation about this term, I’ll just resort to the Wikipedia definition of “open standards.” At least in the world of programming, open standards are what makes computing possible. Almost everything in today’s PCs are following an agreed-upon hardware standard, PCI slots, AGP cards to the networking layer with TCP/IP to the way you’re seeing this document in HTML. The “openness” of a standard is always a slippery metric. Some standards are by nature more closed than open such as Microsoft’s Word document format. However, the format is so prevalent that a Word document has become a kind of “closed standard”. This isn’t what we want though. We don’t want our data to be tied any more than it already is to a particular vendor. In general, our useful information wants to be free, so that, lacking vendor constraints, we can put that information to good use.

What’s hillarious to me is that the conversations between myself and Steve are conducted in a language in which neither of us are native speakers. English is an open standard of sorts – having become, by dint of English colonialism and American hegemony, the new Latin of our age. The Latins of programming can be found at http://www.tiobe.com/tpci.htm . In fact, the TIOBE site suggests the following:

“From a supportability point of view, it is strongly advised to stick to mainstream languages for industrial, mission-critical software systems. This is because of three reasons:

The pool of skilled engineers is much smaller for non-mainstream languages
Tool vendors do not write and maintain tools for non-mainstream languages
In general less libraries are available for non-mainstream languages”

I have to strongly agree with TIOBE on this one. Such a viewpoint would knock out vendor-specific attempts at controlling the environment such as salesforce.com’s Apex language. Yes, I know, people like the idea of picking an obviously open standards language such as Java, Perl or Ruby. I think that’s great but ultimately, open APIs are still in the hands of the vendors. And if they want to program their API in something awkward, we will just have to bite our tongues. Ultimately, an open API is a tool for creating marketing advantage and if vendors realize that, they’ll pick languages that are really popular so their product would be easier to market.

Unfortunately, not just the language should be conducted in an open standard but the data should be in a common format. In this case, XML or JSON should probably be the data standard. In the laundry scenario, my clothes are the data but each piece of clothing is tagged with voila! care labels. Steve relies on those symbols to wash my clothing correctly. At least, I think he does this. For all I know he might be putting all the laundry in one washer but I doubt that. I’m not wearing floods at the moment. These cleaning symbols have been agreed upon as the open standard to be shared by those who wash their own clothes and laundromats all over the US. As soon as we can get the vendors to admit that all these are just cleaning symbols to help us do our washing perhaps then they’ll get it.

Supported and documented

Ok, ok, my analogy starts to break down here a little. I don’t really need a lot of documentation when I get my laundry done. All I need is the receipt. Open APIs require tons of documentation and the ability for users to create their own documentation preferably in a framework that the vendor provides. For instance, Amazon didn’t provide a code sample in Ruby that could be used for accessing their Alexa Web Information Services API. I had to write the code sample myself and put it on my blog. It took months for Amazon to put up an official version of their sample . A sample that I believe that is more difficult to understand for beginning Ruby writers than mine (sniff).

Access to our keyed-in data

The API should allow us to read back the data that was originally entered. Basically, I expect to get back the laundry I originally gave to Steve. Nobody wants to have one sock out of an original pair. A one-sock scenario should not exist in a plain-vanilla open API worth the name. This means whatever data I entered I should not get back. The reason that this requirement is slightly controversial is that theoretically (and in real life) vendors have held back on the depth of the data retrieval methods in their API because they fear an extensive API that allows programmatic access to a user’s entire dataset will result in easy migration scenarios. Whew, did you get that? Basically, an extensive API that can read back all the hardearned data that a nonprofit staff has entered is a bit like a sword of Damocles hanging over the head of a vendor. It means that the cost of migration is lowered quite a bit and that with the right kind of code a nonprofit could simply move from one vendor to another with minimal translation during the migration itself.

Open APIs should be low-cost or free

Basically, my laundry is done for very low cost. However, in the world of open APIs, I prefer free for at least the intended user of the product. We shouldn’t have to pay extra for the “privilege” of accessing our data via an open API. I just posted on my blog recently on the possibility that Blackbaud’s was offering an open API to Raiser’s Edge for free. Their marketing people sent me a quick e-mail telling me that it was only free to those who paid for Raiser’s Edge. I think it’s interesting that their take on this issue was directly related to their current but outdated business model. OF COURSE, I understood that one had to buy Raiser’s Edge to get the API and I would be willing to bet that the readers of the article understood that as well.

The other sense of free that I would like our vendors to consider is that it should be free for third-party developers. This raises the possibility of a strong third-party aftermarket for products like Raiser’s Edge. The problem with this, of course, is that Blackbaud’s finger is also in the professional services pie. That revenue stream would probably be hurt if third-party developers could get in on the action. Ultimately, Blackbaud lives in a very competitive marketplace and will have to deal with inroads especially from salesforce.com. Their model is definitely more developer-friendly and I can foresee a completely different marketplace five years from now that could result in lower market share for Blackbaud if they don’t bother to respond to the massive developer community coalescing around salesforce.com.

Unfortunately, we can’t expect this kind of competition for many non-profit line of business applications. It certainly doesn’t occur in nonprofit finance applications, nonprofit property management applications, camp management, etc. These apps also make up the landscape that nonprofit IT directors travel through every day. These applications, because of their fairly low cost and less critical functions, aren’t subject to the heavy competition we’re now seeing in fundraising/CRM software. If I could wave a magic wand and make these applications compete, I could. However, if this essay could add to the wave of interest in open APIs amongst our nonprofit IT brethren and sisthren then there’s no doubt that our vendors will do the right thing by our sector and implement open APIs too.

Frankly, when I talk to CTOs and CEOs of companies that sell these products, it’s apparent that their perception of our sector has been colored by the checkered past of IT neglect in nonprofits. They design their applications with less complicated feature sets and grade-school level user interfaces because their market for the last two decades has not been populated by sophisticated users. To our discredit as a sector, we have not advocated for commercial-grade interfaces and APIs for our software. As a result, both sides of the equation share equal blame for the situation. Obviously, the situation is changing. Go ahead and hand this article to your vendor’s sales people. Ask them to comment. The simple act of asking will raise the profile for this preferred solution tremendously. In coming months, I hope to talk about recent wins for the open API “movement” with nonprofit software. If you can push on your side, it’ll be that much easier for all of us.