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

A: Because we compare them to the wrong things.

I’m in training today for a piece of software used in libraries. It’s the second of three days of training and things aren’t going well. Some stuff doesn’t work, some things don’t work the first (second, third…ninth) time, and other things just don’t make sense. At lunch, one of the other participants mentioned to the trainer that some of the activities in the software seemed to have too many steps, too many places to go wrong, too many turns between beginning and end.

The answer began by explaining that the most analogous activity would be the acquisition of books for the collection. Adding a book to the collection requires first identifying the book, reading the reviews, choosing to purchase, identifying a vendor and cost, identifying funding, ordering, receiving, cataloging…

The list went on, perhaps with too much detail, but it landed on the following: “there are at least 12 steps to just putting a book on the shelf. When you think about it like that, our software is easy.”

I bit my tongue at that moment, but I’ve been grinding my teeth about it since.

Here’s what’s eating me: You can compare one unlikable thing to any other unlikable thing and come out ahead, but what about “real-world” comparisons?

Paul Graham explains in his “Hardest Lessons For Startups To Learn” essay that developers often compare themselves to the wrong things, misunderstanding who their competition is:

A lot of startups worry “what if Google builds something like us?”

What you should fear, as a startup, is not the established players, but other startups you don’t know exist yet. They’re way more dangerous than Google because, like you, they’re cornered animals.

Looking just at existing competitors can give you a false sense of security. You should compete against what someone else could be doing, not just what you can see people doing. A corollary is that you shouldn’t relax just because you have no visible competitors yet. No matter what your idea, there’s someone else out there working on the same thing. (emphasis added)

Graham is talking to startups, but switch some words around and you’ll get my message: if you compare yourself to something that sucks, you’ll only be able to say you’re more or less sucky.

A better comparison for this product would have been against flickr, where activities that are closely analogous to those in the software we’re being trained on often require only one step. And taking Graham’s advice, the best way to approach it would be constantly ask “can we do this better?” “Could a competitor we don’t yet know about do this better?”

(Aside: social software is that which gets spammed, that which gets you laid, and that which you’ll need no training on.)

Please, stand with me now and repeat:

When something sucks I will say so. When vendors spout crap I will call them on it. My staff deserve good tools, my users need good tools, and I can’t afford to buy stuff that sucks.

Together, we’ll fix the world one product at a time.

bad answers, compare, comparison, competition, crap, developers, development, failure, future libraries, lib20, libraries, library 2.0, software, startups, suck, sucks, sucky, training, vendors

As with all my other presentations, the my slides tell less than half the story, but I’ve posted them anyway. I’m told the audio was recorded, and there’s a chance that will help explain all this, but until then you’ll have to piece this all together from my previous writings, what little I’m about to offer here, and the slides (which, again, without the spoken component, probably do more to misdirect interested readers than answer questions).

My code4lib 2006 presentation included discussion not only of (WPopac, my open source OPAC based on WordPress, but also a plea for us within the libraries to look outside our community for practices and standards that are in use and supported by larger populations than we can ever hope for on our own. WPopac is one attempt at that, using an application that can already claim “hundreds of thousands” of current users and many thousands of developers. Amazon offers another example, boasting 140,000 registered developers of its API, making it the defacto standard for the exchange of bibliographic information online. Meanwhile, our community of programmers within libraries, which is far smaller than 1% of Amazon’s registered API users, must contend with dozens of metadata standards (MARC, MODS, METS, DC, etc., etc., etc.) and communication interfaces (SRU/SRW, z39.50, and more) to do substantially similar work.

I’ve talked about this before (here, here, here, and here, among others), and I’ll be talking about it more yet. Most exciting for me, I wasn’t alone in my plea, as Art Rhyno made some great points about how our acquisitions and accounting processes are substantially similar to what’s called ERP in the outside world.

library, libraries, standards, wpopac, code4lib, presentation, great wall of standards, population density, sustainable development, sustainability, programmers, coders, developers, isolation, future libraries, library 2.0