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.
Keywords: API, delicious, education, flickr, free, integration, open, open source, social bookmarking, social software
Comments
It does beg the question - do people really care what is happening/who has access to their information/data? Or, is convenience more important?
Dave -- I don't have an answer to your question (or at least not one I can substantiate with any evidence), but my impression is that convenience can short-circuit the tendency to question -- if something is easy to do, we don't give ourselves the time to think details through to their logical conclusions.
Which gets to Jeremy's point -- I don't know if it's necessarily blind trust. I see it more as resigned optimism: we recognize that, by using a "free" service, we are giving permission for our use trends to be analysed; and we hope/trust(?) that the use of our info will be benign.
That's one of the significant differences between open source solutions like Elgg, Drupal, etc and their "free" counterparts -- the transparency of the system allows users to know where their personal info goes, and doesn't go.
Pretty well, actually :)
If you install Drupal or Elgg for your institution, you set up the database on your server -- the code that runs the application is on your server as well.
All the data that makes these apps run (user profiles, posts, preferences, etc) are stored in the database. So, given that you install the code, set up the database, pay for the server space, set access rights for the database, the running application, and the server directories where the code is stored, you have complete control over both the front end and the back end of the application.
And, if you are so inclined, you can change that code to make it do what you want -- or, if you don't code yourself, or don't have the time, you can hire someone to do it for you.
When a "free" service sells your data, they generally sell the use patterns -- all stored in the database. The vast majority of "free" services sell your use patterns without "personally identifying data" attached (in part because many nations have privacy laws forbidding this practice). However, if you read the privacy policy in detail many of these "free" services reserve the right to change their terms without notice -- and, by agreeing to the terms once, you agree that it is your responsibility to monitor these terms for changes -- so, the onus is on the user to onitor the terms and revoke their acceptance of the terms if they disagree with any changes. And of course, these free services all have a cadre of customer service professionals standing by to help you opt out of their service :)
My basic point revolves around the misuse of the word "free" and "open" -- I feel that this misuse contributes to a fair amount of misunderstanding. A "free" service can't be free -- otherwise, the provider of it couldn't stay in business. It needs to be supported in some way -- either by consulting services that help offset the cost of running the "free" service (as is the case with Elgg) or by selling user data (as many other sites do) or by some other method.
Conversely, "free" software isn't free either -- sure, you can download the code for nothing (ie, the code is freely available), but, if you run a system based on OS software, you will need to invest time in maintaining it. Of course, the same is true of proprietary systems -- but that's a different conversation altogether.