Mashup Case Study: Giveness

John Musser
Oct. 04 2007, 12:41AM EDT

How can open APIs be used to help charitable causes? In this case study interview we speak with Richard Waldvogel, founder of Giveness, a social network for philanthropy that builds on open APIs like Amazon's and eBay's to enable people to support their favorite charities while they shop.

Q: Can you give us a bit of background on Giveness?

A: The concept behind Giveness started in late 2003. At that time I was thrust into a scenario where I was doing a lot of fundraising. When a good friend's life is on the line, it really hits home, you get slapped with a reality check and your perception of fundraising changes. I discovered that fundraising can be an extremely time consuming and stressful task and as a programmer, I started to think of ways that I could solve the bottlenecks in the system.

Having just finished a large project that used the Amazon AWS service extensively it dawned on me that instead of asking all of my coworkers for a $5 dollar donation, I could simply ask them to make their Amazon purchases through a service that funneled those Associate commissions to a charity. Myself and Dan Werling launched Givezilla.com in 2004. In mid 2006, we started working on our next version of Givezilla.com and launched Giveness.com in March 2007.

Q: What is your business model?

A: Our main vision is provide a service that allows a supporter to make a purchase from a merchant affiliated with Giveness and allow them to personally designate which charity will receive the commissions generated from the sale. Each network benefits from this connection. Supporters are given the opportunity to easily generate additional funds for a cause they have an interest in without incurring any additional out of pocket expenses. Charities can leverage a new revenue stream that is easy for them to complement their existing fundraising programs. Merchant networks get another service promoting their products and generating more sales.

Currently, our revenue comes from advertising. Sponsorships and premium services are also revenue channels that we are pursuing. We are adamant on ensuring that 100% of the commissions generated from the supporter network go directly to the supporter's selected charity at Giveness.

Q: What APIs did you use and what were the best and worst aspects of using them?

A: We use a variety of APIs from several different companies. Currently we use Amazon's ECS for shopping and their S3 service for storing all our media. To broaden our user's shopping options, we implemented eBay's API for auctions. To fill out some of our offerings, we also work with Google's Map API and geo-coding services along with their video service, as well as YouTube's.

The best and worst aspect of working with Amazon's and eBay's commerce services is their sheer size. It's important to use the services that support your overall goal and not incorporate every feature that is available.

Standards become an issue when you're trying to incorporate different APIs that cover similar services. You really have to study the schema to understand them in a way that allows you to incorporate each service into your object model. One service may call the name of a product "Title" while another refers to it as "Name". I don't foresee this issue going away anytime soon.

The more mature APIs are really starting to stabilize, but if you are intent on working with some of the newer ones being released, then you better be prepared to make changes in your code on a moments notice.

Q: What programming languages and tools is this built with?

A: We use C# on top of the .NET framework for our main development. We utilize REST requests for our API communication. SOAP is easier but the REST method saves us from having to manage numerous and potentially bulky .wsdl files in our projects.

Q: Do you foresee using other APIs as part of your service in the future?

A: As our community grows, we're looking to integrate communication tools that allow our users to connect with one another through Giveness. We think there are some interesting opportunities with a service like the Skype API where someone seeking help or counseling could speak with other members that are experiencing the same issues.

APIs don't necessarily need to be public in order to be of benefit to your business. If you are creating business relationships with 3rd parties, it's quite easy to make a case on the feasibility and benefit of having them expose an API specifically for your needs.

Q: Using third-party APIs is seen by many as introducing business and technology risk. How do you view this issue and how do you account for it in your strategy and implementation?

A: Anytime you rely on a third-party for your business, you're taking a risk. You have to mitigate this risk by doing your research and using services from companies that you trust. You have to remain flexible and have a good back up plan. It's important to incorporate these APIs in way that is either unique or adds a distinct value to your core business model.

Q: From an API and mashup perspective, what are the main lessons learned from this project and/or is there any advice you'd like to share on the development, design or business side of mashups?

A: APIs are slowly starting to deliver on the reason they were created in the first place. 5 years ago I was spending a lot of development effort creating page scraping technologies and these horrors are still fresh in my mind.

When a company opens up an API, you have to realize that there is probably going to be several thousand other developers integrating it as well. Giveness is not unique because we use APIs, it's different because we used available API technologies to solve a fundraising problem.

Q: And finally, besides your own service, do you have a favorite mashup?

From a mashup standpoint, Pageflakes seems to have a great framework in place for integrating numerous APIs. It's a clean design and the personalization features are very impressive. They are very active in the .NET development community and share a lot of their experiences in building their application, so I have a lot of admiration for their work.

I really enjoy a mashup that does something thats really fun. I saw twittervision the other day and was just sitting back watching twitters pop up on a map. Brilliant.

We'll continue this interview in Part 2, where we'll get into more details on API reliability, REST vs. SOAP, and other mashup lessons learned. Big thanks to Richard for particpating in our case studies series.

John Musser

Comments

Comments(1)