Lately, here at Spark, we’ve been thinking about “tools on tools”: online tools built on top of other, more foundational tools, that don’t work without such foundations. I’m thinking here of something like Xobni, a productivity plugin to manage your Outlook, or Flipboard, which turns your friends’ social media news into a lovely magazine format for the iPad, or innumberable quizzes and games designed to be used within the world of Facebook. Useful, or just neat technologies, which nonetheless are tied to a bigger technology. It’s a trend we’ve been noticing for a while now, but last week, when Facebook went down, we started thinking about some of the implications of building tools on top of tools, especially when the foundational tool is a closed system. That’s where Jer Thorp comes in. Jer is a data artist and educator from Vancouver, who is also ‘data artist in residence’ at The New York Times. I wanted to talk to him about why this is about more than niche-y geek trendspotting. It has a lot to do with the kind of online world we want to create and support.
A shorter version of this interview will air on the October 3rd and 6th episode of Spark, but you can hear the full, uncut interview below, or download the MP3. [runs 14:29]
Play audio:
If you like hearing these extended interviews, why not subscribe to Spark Plus? You’ll get regular weekly episodes, plus additional blog-only content like this. [Subscribe via RSS] or [Subscribe with iTunes]
I have not had a chance to listen to the piece yet, but needed to chime in. I'm familiar with some of Jer's previous work.
The idea of building tools on tools is what we have always done, you can't make a computer without a microprocessor, you can't make one of those without a transistor. Each of these tools is an abstraction, a system of representations, and as such it embeds certain ways of looking at the world. A (digital) computer makes no sense if we don't believe the world can be decomposed into little bits of binary data. The world is analogue, and so its abstracted into something else a digital system can digest.
This abstraction inherently must simplify what you feed it. From the zillions of photons hitting a flower in a physical world, to the digital photograph. This simplification requires that someone (engineer, programmer, polititian, laywer) decide what is important and what is not.
As we layer more and more of these abstractions we get further and further from the reality on which they are based. Wthout literacy about these nested structures we cannot be critical about the choices of what is important, and the nature of this nested structure that is socially constructed, and also entirely transparent.
I recently did a presentation about these issues at the Banff Centre: http://www.ekran.org/ben/wp/2010/constructed-agen…
Honestly I was quite disappointed in this interview. The entire concept of what constitutes a core tool was totally misplaced throughout the interview. The internet is built atop a huge stack of mainly free and open technologies.
Now – things like Facebook or Twitter are so much higher up the stack than something like the http protocol. Facebook for example is built atop a massive infrastructure of networking technologies, PHP, databasing, etc. It in itself is a tool upon a tool. In some ways what they offer is an interesting way to look at a database of users uploaded content. These interesting ways can be via their API or via the regular old facebook.com webpage. This isn't a new idea.
It is dangerous and misleading to conflate the high level service offered by Facebook/Twitter with the low level foundational standards and protocols that enable the entire apparatus.
Please be more careful when treading into territory that is clearly outside of your expertise!
Hi Harry,
Thank you for your thoughtful comments. I certainly take your point about what technically constitutes a foundational, or, as you say, "core" tool. Of course, things like Facebook and Twitter are themselves built on top of other, more foundational technologies.
The focus of the interview was really about what happens when you start to build tools on top of hugely popular tools, which are not themselves open protocols.
Jonathan Zittrain, who has much more expertise in these matters than I, has referred to Twitter in particular as a 'foundational technology' in this looser sense of being (as he says elsewhere) a 'building block' technology, here:
http://futureoftheinternet.org/the-twitter-virus
Thanks again.
I was about to make a similar comment.
The distinction seems to be open-vs-closed, not foundation.
Building on top of twitter is no more dangerous as building on top of Microsoft .NET.
There are alternatives in identi.ca and MONO.
Twitter itself is built on top of Open Source, and like most "web 2.0" couldn't likely have existed without it. As software matured the "open" moved up the software stack. I believe the same will happen with things like social media as it matures and the immature closed is replaced with open.
A while ago I wrote an SMS tool for my desktop. It was quick enough so I though I'd add a list of service provider gateways. So far I have over 150 mobile phone company gateways that I rely on (meh..) for it not to break. Now I'm putting it on facebook as an app (SMSem). A tool on top of a tool, on top of a tool, on top of a tool because If my host goes down, it won't be available.
When the Internet first became available and companies were starting to rely on it, I was as pessimistic as they come. I've grown to use and integrate it with business processes and yes depend on it as well.
I'm still nervous about it though because prototypes and proof of concepts have a tendency to migrate to production.
These tools in question, are software. Software, as it currently stands, is a programmer's own highly articulate opinion about how a particular process should be handled. In its effect, the returned results from any particular algorithm (even if the input was made by another person) makes several presuppositions from its programmer's ideological beliefs, in addition to operating off of the programmer's mental habits, organizational patterns, and other basic or nonbasic logic.
As an example: I read a lot of poetry in my spare time, therefore I tend to make programs that store vocabulary phrases as easily-readable strings. A more mathematically minded person would store strings at a further level as integer arrays of their ASCII/UNICODE assignment. The math-oriented version of the program then can support better modes of encryption and security (closed off), but the language-oriented version would be more human-readable and more apt to become open source so that other programmers may understand it (opened up). Minor things like these can have large implications later on.
So what's a guy to do when he wishes to make a tool, but he simply does not agree with the views and opinions of a foundational tool's programmer?
I guess the answer is find another foundational tool you agree with, but even then the answers are never the most economical thing if you want people to use the software you eventually make. More people use Facebook, therefore the money is in Facebook, even if you loathe Facebook with every fiber of your being. Therefore, to make an application you need people to use, you need to deal with some degree of cognitive dissonance from a "master ideology".
Freudian projection exists at all levels, I guess.
Nora, I thought you let Thorp off too easy in this discussion. There are definitely some clear benefits to more centralized technologies — email hasn't changed since 1995, for example, but Facebook is getting upgraded all the time. Even if Thorp thinks closed systems are bad on balance, it would have been good to hear Thorp's response to this issue.
I know Spark is not a debate show, but you do frequently have guests who make very sweeping claims (usually "technology X is bad") and I for one would like to see some more pushback in your interviews. The show should not just be a platform for these opinions, but a forum to critically examine them.
Still love the show, though — keep up the great work.