I love remixes, mashups, and covers. I love it when bad songs get good covers, I love it more when it’s a bad cover. I’m a fan of Coverville and I get excited every time I find yet another version of Smells Like Teen Spirit (hey, this is just a sampling: lullaby version, Patti Smith, The Bad Plus, another jazz version, and another jazz version, a string version, no, two string versions, a tango, a damn chant version, some lounge thing, and one for the opium lounge).

But I think I have yet to hear a decent cover or remix of a track from a rock opera. Take One Night In Bangkok: sexing it up doesn’t help. You just can’t out rock a rock opera. (Really, look for yourself.) It might help that Chess featured a character loosely based on eccentric chess master Bobby Fischer, but rock operas just might be too weird for remixing.

Though…I’d like to be surprised. Perhaps a folk version?

I can, however, appreciate the irony in a sex-laden video for a song that had criticized moral decay. Video may be NSFW.

I’ve been talking a lot about remixability lately, but Nat Torkington just pointed out that the web services and APIs from commercial organizations aren’t as infrastructural as we might think.

Offering the example of Amazon suing Alexaholic (for remixing Alexa’s data), he tells us that APIs are not “a commons of goodies to be built on top of for fun and profit, like open source software.” Here are his “six basic truths of free APIs:”

1. Free APIs are not a god-given right. Businesses offer them for their own self-interested reasons. If you build on top of the API but aren’t delivering the value for the business that provides the API, your use of the API will probably go away.
2. If you build your own business on top of an API, you need a contractual relationship to ensure the service doesn’t get taken away from you. These generally cost money.
3. If you find a way to get something from a site that isn’t explicitly offered as something for you to build on, your use of it will probably be fought unless you’re delivering value as in (1).
4. The provider of your API will find it easier to implement services on top of their API than you will. Therefore you have to add something of your own that’s difficult to replicate, something beyond a simple UI tweak or a feature like “search”, so that the business that provides the API doesn’t simply compete with you when you look like you’re succeeding.
5. For these reasons, free APIs are a very poor substitute for having the source and the data and thus owning and controlling every piece of your application.
6. For these reasons, there’s no such thing as a free API if you’re looking to build a business.

Surely Torkington means free as in free beer APIs, as many of the problems he cites arise because the data and services are not free as in free speech. And this leads to two things I want us to be aware of in libraries: giving over our data to companies that lock it up behind licenses that restrict how it can be reused and remixed is dangerous; and we have an opportunity — some would say responsibility — to build out some of that information infrastructure and deliver free as in free speech APIs and data for all to use.

remixability, mashups, self interest, public good, api, apis, free, free beer, free speech,

It’s been more than a year since I first demonstrated Scriblio (was WPopac) at ALA Midwinter in San Antonio. More than a year since NCSU debuted their Endeca-based OPAC. And by now most every major library vendor has announced a product that promises to finally deliver some real improvements to our systems.

My over-simplified list said that our systems failed us in the categories of usability, findability, and remixability, and now people are asking me what I think about what I’ve seen from the vendors so far.

In general, they all include improved search results, and everybody seems ready to address comments and user-tagging, though the system vendors seem to be leaving findability to OCLC’s WorldCat efforts.

What’s missing, I fear, is remixability.

Remixability is the quality of a system or data set to be used for purposes the original designers or owners didn’t predict or intend. If I can define one buzzword with another, remixability is what allows mashups.

In 1971, in the earliest days of ARPAnet, Ray Tomlinson showed his friend a project he’d been toiling on on the sly: email. “Don’t tell anyone! This isn’t what we’re supposed to be working on,” he’s reported to have said.

In a different world, with a slightly different set of circumstances, the at sign on our keyboards might be lost. If he had had to ask his bosses for permission, or if the simple structure of that nascent internet was less open, Tomlinson would have been finished before he’d even gotten started. But as it turned out, Tomlinon was able to remix computers from mathematical machines to communication devices.

Fellow remixer Tim Berners-Lee explains it well:

Twenty-seven years ago, the inventors of the Internet designed an architecture which was simple and general. Any computer could send a packet to any other computer. The network did not look inside packets. It is the cleanness of that design, and the strict independence of the layers, which allowed the Internet to grow and be useful. It allowed the hardware and transmission technology supporting the Internet to evolve through a thousandfold increase in speed, yet still run the same applications. It allowed new Internet applications to be introduced and to evolve independently.

When, seventeen years ago, I designed the Web, I did not have to ask anyone’s permission. The new application rolled out over the existing Internet without modifying it. tried then, and many people still work very hard still, to make the Web technology, in turn, a universal, neutral, platform. It must not discriminate against particular hardware, software, underlying network, language, culture, disability, or against particular types of data.

These innovations resulted not from management directive, but inspired moments urged along by a supportive network architecture. The value of the internet was built on it’s remixability.

There are two ways to look at mashups of today, like Flickr Colr Pickr. Some see them as amusements and question who would build such things, others wonder how they can build systems that are as open to reimagining as Flickr.

And while some remixes might be simple amusements, others can be much larger. Flickr user Dan Cat, who imagined putting Flickr photos on the map (and built a mashup that let Flickr users do just that), ended up being hired by the company to build those features into their official site. Amazon, meanwhile, says remixers — including the 180,000 registered Amazon Web Services developers — account for almost a third of their sales.

The lesson is that when you open up the tools of remixing, people will use them, and the innovations that result will offer value even for non-remixers.

Today, we’re likely to invest in the software architecture of our libraries on a scale that matches the expansion during the Carnegie era. We might do well to think about one of the remarkable features of that period:

The Carnegie libraries were important because they had open stacks which encouraged people to browse. The open stacks were more democratic. People could choose for themselves what books they wanted to read. The libraries were meant to be for people of all walks of life.

The crisis in library systems arose because the people who build them and those who pay for them couldn’t imagine them in any other way. Open, remixable systems will allow patrons of tomorrow the opportunity to build the information solutions we can’t now imagine.

Is remixability in your next RFP?

remixability, mashups, library, library systems. l2, lib20, library 2.0, libraries, api, soa

O’Reilly’s Where 2.0 Conference isn’t until the end of May, but Google just released two sweet new map-related features: GeoRSS support and MyMaps.

The GeoRSS support means that any application that can output it’s geocoding — as simple as <georss:point>45.256 -71.92</georss:point> — can now be linked to a live map with no more effort than it takes to paste the feed URL into Google Maps’ search box. Google holds this up as the exemplar, but I’m a fan of the cheese photo map here. (Here’s some notes about GeoRSS feed validation.)

And if that isn’t easy enough, the MyMaps feature that allows anybody to start marking up a map in their browser.

The really cool part, however, is Google is now indexing all this data and supposedly will be making them part of their local search. The result? Geo mashups have now gone from peculiar examples of the new technology to the loosely linked nuggets that made Google search and the web magical in the first place.

Expect more, way more.

(Also worth noting: with these announcements, the release of the 1.0 version of the Geo Mashup WordPress plugin, and Cliffy’s experience, I’m now formally throwing in the towel on my own bsuite_geocode plugin.) (Tip o’the hat to Ryan for telling me about the GeoRSS support.)

mashups, maps, mapping, loosely linked, local search, google, georss, geocoding, geo, mymaps

ProgrammableWeb pointed out an InformationWeek story that claimed 28% of Amazon’s sales in early 2005 were attributable to Amazon affiliates. And C|net claims Amazon now has 180,000 AWS developers (up from the 140,000 Amazon was claiming about a year ago).

(Note: not every Amazon affiliate/associate is an Amazon Web Services (AWS) developer, but Amazon hasn’t shared more specific numbers.)

These slides, from Amazon’s AWS developer relations team explain a lot about what AWS is.

API, amazon web services, AWS, Amazon API, developers, earnings, Amazon.com, mashups

The MTA, the folks who run New York’s subways and busses and such, weren’t the only ones to smack a cease and desist down on iPod Subway Maps last week, but they’re the first to tell they can pay $500 for the privilege of distributing those maps in an iPod-readable format — but only for non-commercial distribution.

Cluetrain moment: doesn’t the MTA understand that services like this serve potential tourists like me? Don’t they understand that the availability of such maps increases both the likelihood of my visit and the commercial opportunities of my visit (tourists don’t spend money in subways)?

What I really want to leave with, however, is this: Barb Dybwad at Engadget got this one right when she aknowledged the two sides of the issue and added:

These are exactly the kinds of cases in which traditional copyright law feels unsatisfying in the age of digital mashups, and we can only see the demand for these kinds of “information conversions” increasing.

tags: cease and desist, conversions, copyright law, distribution license, engadget, ipod, ipod subway maps, ipodsubwaymaps.com, mashups, mta, subway maps, subways