Coffee|Code : Dan Scott

I recently insulted Richard Wallis and Rob Styles of Talis by stating on Dan Chudnov's blog:

To me it felt like Talis was in full sales mode during both Richard's API talk and Rob's lightning talk

I must apologize for using the terms "sales mode" and "sales pitch" to describe their talks. They were not selling anything; no tangible product was available and no price was attached. My mistake was one of terminology; I believe Richard and Rob were in full marketing mode on behalf of the Talis brand.

My perspective on this comes from having been a product manager for a commercial product and having been fortunate enough to have proposals accepted at open source conferences. My approach to avoid accusations of using the community as a sales platform was to make it very, very clear when a presentation I proposed was related to my product by using the name of the product in the title of the proposal and the presentation. I also proposed and gave presentations on topics unrelated to my product or company. If people wanted to find out how my product integrated with a given open source technology, they knew they could attend my talk about that product; likewise, they were able to avoid my talk about that product because I had made the subject clear in advance. The community also learned that they could trust that I wasn't going to spring product pitches on them in the middle of my unrelated talks. I considered it a matter of personal integrity - and I made a lot of friends during those years.

So maybe I have overly-sensitive marketing senses as a result of my prior experiences as a representative of commercial interests. Or maybe I'm all alone on this, out on the edge of the code4lib community. But I feel that I have to explain why I believe Richard and Rob were in marketing mode during their presentations at code4lib 2007.

Richard's proposal for the conference, which was voted in by the code4lib community, was submitted as:

Title: Library data APIs abound! Richard Wallis, Talis From Z39.50 to xISBN, they share the limitation of providing a single stream of data from a single source. How to add value to data from one source with relevant data from another, and how do you orchestrate that interaction in a scalable way? A review and practical demonstration of augmentation APIs and their orchestration in a way that would make those used to Unix Pipes principles, feel at home.

I felt, and still feel, deceived by the presentation that Richard actually gave at the conference because it was simply a demonstration of Talis APIs.

Richard responded to my comment:

The only Platform that is currently openly delivering that functionality in that way is the Talis Platform. Therefore as all the examples are based upon Talis Platform capabilities this can unfortunately be easily interpreted as a sales pitch. Nevertheless, looking at the proposal I submitted and the presentation I gave, I think my presentation was mostly as advertised[...]

"mostly as advertised" suggests that Richard knows he made a mistake. His presentation wasn't advertised as a demonstration of Talis-specific functionality. All that Richard had to do to avoid any whiff of deception by commercial interests from the beginning was to include the word "Talis" in the text of the proposal. As in:

A review and practical demonstration of Talis' augmentation APIs and their orchestration in a way that would make those used to Unix Pipes principles, feel at home.

One little word, and this really wouldn't have been a problem. People would have voted on the proposal with the full knowledge that it would have been a Talis demonstration. Or they wouldn't have voted on it as a result. Either way, I wouldn't have had anything to complain about.

Rob was personally offended as well. At the end of his response was a lot of hyperbole about "evil vendors" and "scary vendors" that has no relevance to anything I said, and which I will not discuss. He also made a reductivist argument suggesting that as we all get paid to write code for libraries, you can't draw a line between business models. Well, you can draw a line if you consider the degree of freedom associated with that code. If you share that code freely with others, that's a hell of a lot different than if you make the APIs available, but require your users to store their data on your servers and pay for the privilege to use those APIs in conjunction with your data.

What I will address is Rob's stated motivation for giving that lightning talk:

The reason I chose to do the lightning talk was essentially because I saw a lot of talk about Open Source and yet one of the biggest problems we face (all of us, not just me) is one of Open Data. I probably was "in full sales mode" but for Open Data, not for Talis.

If so, there is an incredible correspondence between the substance of Rob's talk and Talis' trademarked phrase: shared innovation (yes, this is literally a trademarked phrase). Watch Rob's talk again. Note how many times Rob mentions the keyword "share", "shared", or "sharing" (I counted 4). Note the slides in the middle of the presentation that pick up keywords highlighted on Talis' home page. Note that Rob ends the talk with a slide showing Talis' trademarked phrase. In the marketing world, this would immediately be recognized as a branding exercise: you're attempting to make a connection in your audience's minds between your brand and a few key elements. And that audience just happens to be a room full of the most influential library developers in the western world!

Sorry, Rob, but I simply can't buy your claim that your lightning talk was not a marketing pitch for Talis. Colour me skeptical.

Our baby is growing up so fast. Near the end of February she tottered a couple of tentative steps from me to Lynn.

Last weekend, she walked right across Jason and Kelly's kitchen floor. You can see for yourself if you don't believe me!

Update:

By popular demand, I've posted this video on Google Video. No more worries about codecs! Of course, Google owns me: my searches, my email, my programming projects, my RSS feeds, and now my videos. Curse them for being so competent!

For the past couple of days, I've been playing with Casey Durfee's code that uses Solr and Django to offer a faceted catalogue. My challenge? Turn a dense set of code focused on Dewey and Horizon ILS into a catalogue that speaks LC and Unicorn. Additionally, I want it to serve as both a proof of several technologies (Solr for faceted searching and Django as a Web application framework) to my colleagues and as a reasonable backup catalogue for when our main catalogue fails (as it all too often does).

I emailed Casey today to tell him that I had a number of patches to contribute as a result of my experiments. It turns out that he's not really interested in pursuing this particular project much further, so he gave me his blessing to take his throwaway code and do whatever I want with it. Thus, the emergence of the FacBackOPAC project on code.google.com. If there's a grant out there for worst project name ever, this project's in the running... Anyways, I have contorted Casey's code so that it supports both Dewey and LC, and with a bit more torture it should be flexible enough to support both Horizon and Unicorn.

Right now I've twisted it all the way to meet my Unicorn needs and consequently have broken Horizon support, but it won't take much to make it support Horizon again - or any other ILS, for that matter. The main requirement is that you have to be able to get your MARC records and holdings out of your ILS. A secondary requirement is to know how to create links to detailed item views in your current catalogue, because this thing does not yet have any current awareness about item status.

There. My itch has been scratched for the time being. Go play with the FacBackOPAC project -- I even have (very) rough documentation on how to get the pieces installed andthe MARC records indexed, although you'll have to dig through the source in the Django catalog tree to overcome some hardcoded strings and URLs for the time being. Don't worry, pulling that hardcoded stuff out of the templates is high on the list of priorities.

So, a huge thank you to Casey for freeing this code and making this possible. For something he considers throwaway code, I've learned a lot from walking through it and making it start to meet my needs. I hope it helps you, too!

Update 2007-03-18:

Edited links to point to the FacBackOPAC project page, rather than the wiki (which is subject to change, and which did -- breaking the dang links in the original version of this story. Argh!)