The expense of a free service, and the closed nature of exposed APIs

Over the last few months, I have read numerous posts about the use of free services (Flickr, delicious, Microsoft's free email for universities, etc) and about how these services can be used to support teaching and learning. Over the same time, I have also seen more open source developers writing code that leverages the exposed -- or open -- APIs offered by different companies. The examples of exposed APIs that come readily to mind include the usual suspects, and some of the darlings of the Web 2.oh ;) world -- Flickr, delicious, and Google Maps, to name a few.

Both end users and developers can get a lot for free today. Google Maps alone provides functionality to both individual end users and individual developers that would be beyond their reach otherwise. Free social bookmarking -- offered by delicious, Furl, Simpy, and others -- is both useful, and, in this era of increasingly constrained budgets, it comes at the right price. Flickr provides a convenient method of sharing and organizing photos. While none of these sites have the overtly commercial overtones of sites like MySpace, however, there is a lot of noise about how to turn a profit off a free service. Many of these discussions reach a common conclusion: the shortest route to profitability involves some form of selling user data to advertisers.

Open APIs allow individual developers to access functionality designed by larger organizations. Microsoft, for example, exposes the Windows API to allow developers to develop Windows-based applications. Online, however, when a free service exposes their API, it can create confusion about the nature of what is being offered. If something is free, and information about how to use it is publicly available, then it must be open source.

Unfortunately, this is not the case. The API connects to functionality and information that is proprietary -- we can use it, but we can't take it with us. More importantly, using an open API from a corporate provider gives that provider another method of tracking user data, and profiting from that data by selling it to data miners and advertisers. Additionally, these APIs are exposed at the whim and discretion of their owners. While it is not likely that Flickr, delicious, or Google will stop allowing access to their APIs, there isn't much we could do about it if they did. And, in a more realistic scenario, if enough people become dependent on using these APIs, it would be difficult to stop using that functionality if access became fee-based.

The counterargument, of course, is that these companies are providing a great service, and that they have a right to earn a profit from it. If they can simultaneously protect the identity of individual users while aggregating that user's online habits into discernible trends, why shouldn't they be allowed to do that? Having our online habits observed and folded into marketing strategy is the price one pays for convenience.

However, as educators, we need be very clear about what our choices mean for our students. Delicious is useful, but we need to be aware that when we use that service with our students we are doing our little part to help marketers reach teens more effectively. One of the beautiful aspects of open source in education is the complete transparency through the entire system. Using open source software gives users the ability to see what is happening at all levels of the application, from what the user does on the front end (ie, their work) to how their data is stored and used on the back end. The transparency of open source has philosophical similarities for how we teach and how students learn -- no tricks, no gimmicks, no advertisers; just free and open inquiry.