Comments on: Getting your vendor to support Open Standards http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards?utm_source=rss&utm_medium=rss&utm_campaign=getting-your-vendor-to-support-open-standards Confessions of a Non-Profit Executive Director Sat, 28 Jan 2012 12:36:51 +0000 hourly 1 http://wordpress.org/?v= By: paulmorriss http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards/comment-page-1#comment-31 paulmorriss Tue, 06 Jun 2006 11:18:55 +0000 http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards#comment-31 I get at Raiser's Edge via ODBC into the backend SQL database. If an API were defined, someone could at least do the read-only bit by writing a bit of code at the backend to do the SQL. I get at Raiser’s Edge via ODBC into the backend SQL database. If an API were defined, someone could at least do the read-only bit by writing a bit of code at the backend to do the SQL.

]]> By: abenamer http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards/comment-page-1#comment-20 abenamer Sat, 22 Apr 2006 22:54:02 +0000 http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards#comment-20 I think long-term you're entirely right Michael and that's where I want to go too. The only problem is how to build enough industry momentum on our end. I don't like to aim too high when I talk to my vendors simply because there's a lot more code and cost associated with data insertions because they have to make it secure. A badly-coded API can lead to easy SQL injection exploits. At this point, I think if we try to put too much on the vendor, we'll just end up with a lot of pushback. After all, our "power" over the vendors is fairly indirect once we've purchased the app. That's why I prefer a rolling start where we just ask for read-only methods in an API. In fact, that's basically what many commercial vendors are giving out for now. This is not to say we can't argue for updates and inserts later but let's just get the low-hanging fruit while we can. I think long-term you’re entirely right Michael and that’s where I want to go too. The only problem is how to build enough industry momentum on our end. I don’t like to aim too high when I talk to my vendors simply because there’s a lot more code and cost associated with data insertions because they have to make it secure. A badly-coded API can lead to easy SQL injection exploits.

At this point, I think if we try to put too much on the vendor, we’ll just end up with a lot of pushback. After all, our “power” over the vendors is fairly indirect once we’ve purchased the app. That’s why I prefer a rolling start where we just ask for read-only methods in an API. In fact, that’s basically what many commercial vendors are giving out for now. This is not to say we can’t argue for updates and inserts later but let’s just get the low-hanging fruit while we can.

]]> By: michaelatmo http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards/comment-page-1#comment-19 michaelatmo Fri, 21 Apr 2006 12:36:09 +0000 http://www.nonprofittechblog.org/getting-your-vendor-to-support-open-standards#comment-19 I'd go one step further. Picking up on your reference to Raiser's Edge - I'd say that all apps - not just hosted ones, should provide an API. Just because the data resides on your server does not mean you have acceptable access to it. We had a user of our product ask us to move some data from our web app into Raiser's Edge and we found the API is sold separately and it's not inexpensive! And remember - access is not just the ability to extract the data, but to insert transactions. Unless you really understand the relational structure of the system, this can be very difficult without an API. As I said to Alan when he mentioned this on ISF recently, a real dream would be for the nptech community - vendors, users, consultants - to define a minimal API for each functional area: what do you need to expose for membership management, for events management, etc. This would let users build custom pages over their vendors products, and really leverage their investment. --michael I’d go one step further. Picking up on your reference to Raiser’s Edge – I’d say that all apps – not just hosted ones, should provide an API. Just because the data resides on your server does not mean you have acceptable access to it. We had a user of our product ask us to move some data from our web app into Raiser’s Edge and we found the API is sold separately and it’s not inexpensive!

And remember – access is not just the ability to extract the data, but to insert transactions. Unless you really understand the relational structure of the system, this can be very difficult without an API.

As I said to Alan when he mentioned this on ISF recently, a real dream would be for the nptech community – vendors, users, consultants – to define a minimal API for each functional area: what do you need to expose for membership management, for events management, etc. This would let users build custom pages over their vendors products, and really leverage their investment.

–michael

]]>