This morning, I sat in on the "Great Open API Debate" hosted by NTEN. First off, a tip o' the hat to NTEN for organizing this, the participants of the panel for an interesting conversation, and Mark Bolgiano from the Council on Foundations for awesome moderation.

There were four perspectives:

• For-profit vendors - Tom Krackeler, GetActive , Steve Wright, Salesforce, David Lawson, Kintera, Dave Crooke, Convio and  Shaun Sullivan, Blackbaud
• Nonprofit vendor -  Nick Ballenger, Democracy in Action
• Open Source developer -  Zack Rosen, Chapter Three
• Nonprofit Organization Tech - Peter Campbell, Goodwill

If I was going to complain, I'd say it was way for-profit vendor heavy (63%?). It would have been nice to have heard from a circuit-rider or "for-little-profit" integrator/consultant type person, and maybe another nonprofit type (a moderately tech savvy ED?)

There was also a backchannel chat room, which was really useful and interesting. (I hope NTEN can post the transcript.)

I'm not going to go through everything they said at all - I think a recording will be available on the NTEN blog or site at some point soon, I expect. But I'm going to highlight what interested me most, and talk a little bit about the zen of APIs.

So, first off, one of the interesting things was that there was some initial differences of opinion as to how to define open APIs, and what they were used for. There were two different kinds of APIs discussed - the ones that help organizations with interoperability within their organizational systems - getting data from one app to another, and using APIs for things like Google maps mashups. Also, basically, what made an API "open" was that it was free to use, and well documented. It seemed that only Blackbaud had APIs you have to pay for. The other vendors either supply their paying customers with APIs, or, in the case of civicspace, the APIs are, well, free and open, like everything else about open source. I have to admit that I went into this thinking much more about the more public types of APIs even though the APIs for internal data integration has been a real interest of mine, and a real concern, as well.

Zach brought up an interesting point, and I think it is worth highlighting. From his perspective (and mine, too) one of the big issues (as he put it, the elephant in the room) is how open APIs impacts the business model of vendors. It's no secret that some competition for the vendors comes from open source software, and perhaps that's a good thing - it provides them with the incentive to match features - like open APIs. One vendor said that very few nonprofits have the resources to take advantage of APIs. Someone (I think it was Nick or Peter) said that nonprofits can do more than vendors think they can - so providing the resources is important.

One of the other key things that I think was important is the sense that in some way, openness and security are at odds with each other. As both someone in the backchannel, and a couple in the debate said - security is important the minute you open one port to the world. You can have openness and security. I did feel that the vendors had a small tendency to indicate some concern about security when asked about openness. That bothered me a bit - they are totally different issues.

So what I got out of this was a couple of key points. This conversation would not have happened a couple of years ago, and that it is happening now is great (late, but great.) The sores on my head have only just recently healed (must have been seminary) from helping a couple of organizations a few years ago to plan for integrating some of their internal databases with a big vendor database that-shall-not-be-named. So I guess I should be happy that there were so many for-profit vendors at the table, and that this means that it will be easier for nonprofits to do the kinds of integration between applications that was nigh impossible a couple of years ago. That's good news.

APIs are here to stay. In fact, they are the future. The standards and technology have matured in such a way as to provide the potential for real richness in data integration, both inside organizations, between organizations, and with bigger, broader entities such as Google. The more that nonprofits understand them as useful to them, and demand them from vendors that provide (or build) software, the better, as far as I'm concerned.