Hi Everyone,
I'm peeping a head up from working on various engineering tasks to speak to some of these concerns. We definitely want to clear up some of the questions raised.
Starting with the most recent point, Kiva has 5 full-time engineers. (we are looking to hire a sixth). The "Kiva Engineering Team" (aka, BrainCrave) is more what you would call a "product development team" at traditional companies. So, we also have 2 full-time product managers. Roma and Casey design features, collect input, prioritize tasks, and fill in tons of other tasks that keep the team moving along. They do this for the lender-focused website, which you see, but also the enormous part of Kiva you don't see which are tools for translators, field partners, customer service, fellows, and Kiva staff. I'm sure many of you know about the largest beast of all of these, which is PA2. In addition, BrainCrave has IT staff (keep the printers and email going) and people to help keep the production environment up (keeps servers from crashing or burning). I myself wear many hats and focus on designing and building features for developers - including developers who work here at Kiva! Given that about half of engineering time is devoted to maintaining all of our software (for lenders, partners, and volunteers) we have to be judicious about what new features we invest in.
Which brings me to the developer program. First off, I'm glad someone posted the "Stop It With the APIs" post because the author points out some important questions we weighed carefully when considering investing more in APIs and Platforms. I encourage those of you interested in this thread to read my response at:
http://econsultancy.com/blog/3246-please-stop-it-with-the-apis#commentsNow as to a couple of concerns about the evolution of the API itself, I'll make a couple points that should put some of you at ease:
1) To Peter's concern about 3rd party apps & passwords, this is a great point. You should never give anyone your Kiva password except Kiva. Make sure you can always see "kiva.org" in the browser Location field (URL) before you enter your password on a website. The current Kiva API does not support user login, so all applications should work perfectly w/o your password. Some applications may ask for your "Lender Page ID" or your "Lender ID" and you will have to decide if you want to put this in an application. If you're lender page is public then your "Lender ID" is already public, so there's really no risk here. The application probably just wants to help you customize your experience based on loans you've made. For example, I think someone is already working on a plug-in that users can add to a blog so they can advertise their recent loans on their personal site or blog.
In the future, we will allow access by third party applications to Kiva Lender data on a per-user approval basis. Figuring out who to trust is not easy, and how to help lenders with this is a problem we are working on before launching these features. However, in the end, it will be your decision. Mint.com is a similar site which wants access to your bank accounts to help you manage your money. How do you decide if you should trust Mint.com with your financial data? It's a tough question for sure.
Our current plan is to allow you to "authorize" applications to have various permissions. You might approve an application to facilitate loans for you. You might trust the app to look at your detailed loan history or account balance and calculate statistics. The most important point is you would be able to revoke application access from Kiva.org at anytime. (You could see a similar model to this "trust" between applications and users at Flickr.com or another site i worked on, Fireeagle.com). If all this sounds scary and confusing, you shouldn't use third party applications, but our hope is that you'll wait until all this is figured out and released before making a decision.
2) To Ian's point that the API is not really an API, it is true that what we offer now is a very much like what is on the site, but in computer-friendly formats (ie, JSON, XML). However, by providing powerful search capabilities (more to come) and key identifiers to relate data together, there is a lot more power available here than just web pages. Also, the current API is a set of building blocks for actions that will come later where you can change things... make a loan, give a gift, join a team, etc.
3) Finally, there is a lot of concern about "bots" or what not that will snatch up loans. We certainly want to take caution here. Third party applications should add to the Kiva experience, fill in feature gaps, and introduce innovative new ideas, not detract from the current experience. All Kiva Developers are bound to the Kiva API Terms of Service, and must abide by our Code of Conduct. Additionally, we'll take technical measures to make sure applications don't inadvertently cause significant disruptions. Currently it is not technically possible for an application to put loans in a basket, but that's a hurdle we plan to remove soon. The result we are hoping for is more loans is baskets because the end goal of the API is get more people involved in helping more entrepreneurs with loans. More loans in more baskets (with the right provisions) is a good thing. Inadvertent or malicious abuse of Kiva and it's content is a bad thing and is behavior we will not tolerate.
Thanks to everyone for your interest in the Kiva Developer Program. We hope you're as excited about it as we are. We at BrainCrave don't have time to create every feature the community wants, but we are committed to building features that get more lenders more engaged to bringing relief to those living in poverty. Where we can't get to a request, we hope the Kiva API empowers developers (and lenders!) to fill in the gaps. I personally am very excited to see what develops.
Cheers,
skylar
