I stumbled on them by accident, but once I discovered Subversion supports action hooks that can fire before or after a transaction, I knew exactly what to do with them.

The Phonepedia concept is simple: take Wikipedia’s rich content and add voice recognition. It’s as easy as calling a number and asking your question, the answer will be returned via SMS and email. Go ahead and try it for yourself.

The voice recognition is powered by Jott, and thanks are due to Heidi for writing so glowingly about it (Cluetrain moment: I’d heard about Jott before, but hadn’t been stirred to look at it until I saw Heidi’s post speaking in the voice of a real person). And the thing about Jott that got me interested was the remixability of the service. They call it Jott-Links, and it allows any user to connect external applications to the service.

Jott handles all the interaction with the user. The email responses look like these, though the URL is truncated from the SMS message. Wikipedia doesn’t offer an API, and the content requires a lot of massaging to get consistently useful text for applications like this, so I built those pieces, as well as the glue to connect it to Jott.

It’s not perfect, and I’m certain there are a number of things it gets wrong, but it’s worth a try. I think it also highlights the value of having free information and remixable systems. I’m looking for ways to connect it to a library catalog, but I’m at a loss at the moment to figure out what kind of spoken questions of our catalogs can be usefully answered in a 140 character response.

Of course this also raises the question about which technically aware people might have questions for Wikipedia and have a Jott-registered phone but don’t have web access handy. But I’m a librarian, I wouldn’t be doing my job if I wasn’t looking for new ways to access and use information.

Finally, I hope nobody is so confused as to think this is in any way officially affiliated with or sanctioned by the Wikimedia Foundation or Jott.com. It’s not.

I guess the criticism is that it’s one thing for somebody to open up their music for remixing, but an entirely different thing to do the same with a movie. Or is it? Is it (click re-fragmented)?

Web 2.0 has matured to the point where even those who endorse the moniker are beginning to cringe at its use. Still, it gave me pause the other day when Cliff (a sysop) began a sentence with “Web 2.0 standards require….”

Web 2.0 is now coherent enough to have standards? We used to joke about rounded corners and gradient blends being the rule, but something more has indeed emerged. O’Reilly defined Web 2.0 by example, Time Magazine echoed Kevin Kelly’s assertion in naming You as person of the year: Web 2.0 is about people. And “the rules” are emerging as a matter of market forces and natural selection.

Open Source

No matter your position on the Free Software Foundation’s philosophy, open source development reduces costs while improving quality and helps projects get to market faster with new ideas.

Flickr is among those that’s been rather public about their use of the LAMP stack, though Google and others have quietly built their business on it too. WordPress, a rare example of a downloadable Web 2.0 application, has enjoyed active development (and even a resurrection) due to its GNU license.

Still other Web 2.0 applications extend the open source model further. Open source content, or the user’s ability to declare a Creative Commons license on their content in these Web 2.0 applications is becoming common (and demanded by some). We may argue about the efficacy of Wikipedia, but the fact is that it’s among the most likely sites to appear for a web search and it’s consistently ranked among the top sites for traffic.

Wikipedia’s early contributors, looking at a young site with an unclear value proposition, could trust that their work would be protected by license (specifically, the GNU Free Documentation License).

Built for Remixing

Amazon reports that almost a third of their sales are attributable to remixers and boasts 180,00 registered developers of their API.

Google Maps didn’t include a public API when first released, but the community responded with enthusiasm and quickly reverse engineered the JavaScript to build new applications. Google responded by releasing a public API, making internet mapping and Google almost synonymous.

Dan Cat mashed up flickr and Google Maps on his own before Yahoo!/flickr snatched him up to build those features into flickr’s own site. But the company still enjoys the efforts of developers building applications to the flickr API, independently developing new features and adding value to the service.

Like open source, remixability and APIs engage a larger pool of talent than is available inside any company and serve two very important audiences: those who want features and those who care about their exit strategy. Neither group is remarkably large, but both are influential, passionate users. (More: Usability, Findability, and Remixability, Especially Remixability.)

Well Behaved and Social

Predictable and reliable URLs are essential to allowing users to bookmark and link to your site; well-formed semantic markup makes it easier for screen readers and search engines to make sense of the content. Semantic markup and microformats aid in remixability, contribute greatly to the Semantic Web, make site redesigns easier, and generally display better in a broader variety of formats and clients (think HTML vs. RSS).

People are anxious to leave comments telling us how right or wrong we are, so a site without comments/trackbacks/pingbacks is turning its back on its users. Good sites recognize the value of their users and cultivate the community. Caterina Fake did a lot of that for flickr (see her comments on my first photos there), while MetaFilter exists entirely as a community.

That doesn’t mean users are itching to build somebody else’s site, the lesson is that personal value precedes network value. Good sites make it easier for people to do what they want to do, not what their boss or the site’s creator wants.

If it isn’t obvious already: empower the user to achieve their own goals and control their experience.

rules, web 2.0, web applications, open source, remixability, social software, well behaved

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

Speaking Thursday at the Boston Library Consortium’s annual meeting in the beautiful Boston Public Library, my focus was on the status of our library systems and the importance of remixability.

My blog post on remixability probably covers the material best, but my slides are online as both an animated QuickTime and PDF.

BPL, BLC, boston library consortium, boston public library, presentation, remixability, library, libraries, library systems, l2, lib20, library 2.0