Results tagged “tumblr”
May 20, 2013
Seven years ago, my wife Alaina Browne and I were living happily in San Francisco when she went off to NYC to visit with our friends and attend a party. By the time she flew back, we were on a path that not only led to our return to New York City, but to getting a front-row seat to the birth of what would become Tumblr. Along the way, I've had the chance to see Tumblr from the perspective of a user, a competitor and a fan. Since so much of the conversation today is about the dollar amount of their sale, and the speculation about their future with Yahoo, I thought it'd be nice to look back at a few distinct moments in their evolution, as seen by an interested outsider.
Before the Beginning
Alaina had come back excited from visiting New York, telling me about having been introduced to Ed Levine by our friends David Jacobs and Meg Hourihan. Ed wanted to build a food community site called Serious Eats, and had hired two young guys recommended by Fred Seibert to build out the site. I heard secondhand from my friends about the content management system that was being built by Davidville, the consulting company run by David Karp and Marco Arment. David and Marco were building a tool to power Serious Eats, but I didn't know anything about them except that they were really young.
Serious Eats had gotten a launch sponsorship, and as a result needed to get up and running by the holiday season. But by October, all that I'd seen of the publishing tool they were building was a very simple single-column blog that presented photos really nicely, but had no way to show standard banner ads at all. After debating whether the ads that needed to be delivered could be fit into the simple structure of the tool that had been built, the team decided in favor of just launching Serious Eats on off-the-shelf technology because they needed to get running quickly. As David Jacobs described in his post on the Yahoo/Tumblr deal, the team picked Movable Type since they were all very familiar with the software and knew those of us who worked on making that app.
In short, some of the fundamental constraints that shaped Tumblr in its most nascent stages was that publishers weren't yet able to get advertisers to buy native, in-stream ad units, and that traditional ad buys made units that were not easy to integrate into super-simple tumblelogs. Hmm!
Update: I think Marco had some objections to my characterization of this point in the evolution of their work. His tweets on the matter follow:
As usual, Anil Dash is wrong: dashes.com/anil/2013/05/s…Serious Eats and Tumblr shared no code except our generic PHP MVC framework.— Marco Arment (@marcoarment) May 20, 2013
What we built for Serious Eats wasn’t too simple — it was too complex and overreaching.It wasn’t a single-column blog for photos… at all.— Marco Arment (@marcoarment) May 20, 2013
Given that I made no assertion over how much code was shared between the two companies, and since a simple CMS is usually little more than a nice wrapper around an MVC framework, it seems there's little in dispute here except whether the content management system was a poor fit for being too complicated or for yielding output that was too simple. I'm happy to believe Marco has a better memory of the project than I do, since he worked on it and I barely even visited.
Marco also offered some other snarking at Meg about whether the client or consultant was to blame for an underspecified set of goals for the content management system, but these things are almost always everybody's fault, and that's sort of beside the point which is that the ideas of Tumblr were in tension with conventional blogging of the era.
Tumblelogs Take Off
Meanwhile, David and Marco took that simple publishing system they'd built and kept refining it. They were insistent even in those early days on calling the output "tumblelogs" instead of just "blogs", which I mentally filed away as "those sites like projectionist".
At the time, Tumblelogs had been around for a little while, best known to us old-time bloggers due to Jason Kottke's seminal post on Tumblelogs, which defined the format just as it was about to take off, and featured project.ioni.st as its leading light. But in a classic case of geeks looking at a thing from a technical standpoint instead of from a cultural one, many of us who were familiar with blogs already saw tumblelogs as "just a simple blogging template", similar to what we were already doing on Movable Type or WordPress at the time, rather than a fundamentally different medium.
Despite that myopia, there was a lot of momentum around simplified, media-rich blogging at that moment in history. Twitter had launched just a few months earlier in mid-2006, without any of its current photo or video capabilities, but with a super-simple posting experience similar to what made Tumblr so easy to use. Much of the early team behind Movable Type had moved to working on a platform called Vox, which was a simpler blogging tool for sharing media from other services, but included privacy features similar to the Flickr or LiveJournal, which kept it from being as dead-simple to use as Tumblr. WordPress, too, had incorporated a feature called "Asides", based on a popular plugin from Matt Mullenweg, and it made regular posts of photos, quotes and video clips easy to integrate into a more traditional blog.
At a technical level, many of these efforts were descended from a super-geeky concept that folks had been kicking around a few years earlier, called structured blogging. The technical focus of people in the community resulted in it having the super-nerdy name "structured blogging" and yielded a set of poorly-adopted technical specifications rather than a usable experience for normal people. But the fundamental idea behind structured blogging was that people would want to easily post the cool stuff they were finding on other sites and publishing in other media such as photo or video. And Tumblr proved that the idea of this kind of sharing was exactly right, even if the "structured blogging" name and implementation was exactly wrong.
One of the most important justifications for putting "structure" around different kinds of content was so they could be aggregated together into a reader, something like Google Reader, or earlier tools like Bloglines or My Yahoo or Userland Radio. The difference with Tumblr was that David and Marco very early on built in their reader, just like Twitter and LiveJournal had done, making viewing and creating take place in almost the same environment, and forming better connections between users on the site.
Tussling With Tumblr
By the time Tumblr opened up to the public just a few months later, it was clear they'd hit a perfect mix of features to connect with an audience that cared more about expression than technology. Gina Trapani was one of the early, enthusiastic users, and as Marco rightly pointed out in a podcast the other day, part of what made Tumblr so popular early on was that they let people use their own domain name, with a beautiful design, for free. Other free tools were either more complicated, or like WordPress or Blogger, they charged extra to use a domain name and/or constrained the template customization that a user could do.
Since I worked at the time for a company that mostly made its money by selling paid software and support for blogging, I didn't really see Tumblr as a threat so much as an interesting new entrant that offered the best free product for many users. I jokingly made a reference to Tumblr a year later on a promo page for TypePad, which I worked on at the time and after Fred Wilson and Bijan Sabet picked it up, Marco took offense, to my great surprise. In retrospect, it was obvious that Marco would see us as competitors and my joke as disrespect, but at the time I really had thought it was clear I was being playful but respectful because Tumblr had made something cool and I had met, and liked the founders.
Elbow to Elbow
When I say that I knew Marco and David a little bit, it's impossible to overstate how close the NYC tech community was at this point. The office where Tumblr was still based back then was 419 Park Avenue South, and Tumblr shared the space with Serious Eats, Next New Networks (now YouTube Next Lab) and Frederator, Fred Seibert's studio.
When I ran into David around that time a few blocks away at Shake Shack, I excitedly pulled him aside and said "I really think Tumblr is like LiveJournal 2.0", which is another one of those endorsements that probably sounded to him like a slight or an insult or some willfully obscure reference, but to me was about as high a form of praise as I could offer — LiveJournal is and was the most seminal social networking platform that's ever existed, and almost nobody had captured the addictive, expressive environment of its friends list as well as Tumblr's dashboard did.
Part of what I learned in my very-limited interactions with David and Marco in those early days was how disconnected and arrogant my own view of blogging and social software could be. Because Tumblr recapitulated many earlier ideas, albeit in a vastly superior way, I had thought it wasn't really as new as it has turned out to be. And some of this is just generational; My very first impression of meeting the then-20-year-old David and 24-year-old Marco was "Wow, these guys have a really good eye, and are really full of themselves." I still think both those things are true, and that those traits have served them very well.
But there was also a half-generational gap between me and these millennials, a cultural difference I hadn't yet understood or reckoned with. It led me (and many others I know) to underestimate what Tumblr's importance was, and actually retroactively made my analogy to LiveJournal seem more apt than perhaps I'd intended.
In the case of LiveJournal, I got to watch first hand as many of the most fundamental parts of social networking and blogging were invented and then mishandled as advertising was introduced. But I never thought those mistakes were intrinsic to this kind of evolution in communities - it just required leadership that understood and truly respected a community.
In the case of Yahoo's acquisition of Tumblr, I mostly don't have a lot to say — my Activate cofounder Michael Wolf is on the board and we've done work that makes me far from objective in this regard, but even if we hadn't, I'd be optimistic about this deal. For me, it's the concepts I wrote about in Stop Publishing Web Pages — we've found a model for user interaction and social connection that really works, and it feels like the more places that's adopted and embraced, the better. Whether that's on Yahoo's homepage or Tumblr's Dashboard, or in some new app on my iPhone, we're reaching a consensus around how we want to connect with each other.
It's been fascinating to watch Tumblr evolve, and as a member of the New York tech community, I am thrilled for the whole team (and its inestimable investors) on the success of the company. As a blogger, it's still a really sweet moment to watch the medium of blogging be validated in this way, since a huge number of dollars is a clear signal even to those who don't understand the artistic and expressive importance of blogging. And as someone who still loves hacking on these kinds of software, it's been tremendously useful to see my own assumptions and preconceptions be challenged by a new generation of young entrepreneurs and creators who take this medium I've watched since its inception, and push it to fascinating and inspiring new forms.
December 18, 2009
Update: We've got some results already! Joseph Scott at Automattic mentions in the comments that he's added RSD support for the Twitter API to WordPress.com. I should also make clear that I am very confident that we'll be building apps on top of this API at Expert Labs, so insofar as I'm the Director of the labs, I've got a vested interest in seeing efforts around an open API succeed.
Twitter's API has spawned over 50,000 applications that connect to it, taking the promise of fertile APIs we first saw with Flickr half a decade ago and bringing it to new heights. Now, the first meaningful efforts to support Twitter's API on other services mark the maturation of the API as a de facto industry standard and herald the end of its period of rapid fundamental iteration.
From here, we're going to see a flourishing of support for the Twitter API across the web, meaning that the Twitter API is finished. Not kaput, complete. If two companies with a significant number of users that share no investors or board members both support a common API, we can say that the API has reached Version 1.0 and is safe to base your work on. So now what?
How We Got Here
Like a lot of folks, I've been thinking out loud and pondering the future of Twitter and open web APIs pretty much all year. Some key ideas have bubbled up:
[A]ny site or application can deliver realtime messages to a web-scale audience, using free and open technologies at low cost and without relying on any single company like Twitter or Facebook.
- Upgrades to the web are incremental.
- Understanding new tech needs to be a weekend-sized problem.
- There has to be value before everybody has upgraded.
- You have to be able to understand and explain it.
Those posts from this summer show that the ideas behind the Twitter API's "overnight" ubiquity have been kicking around in developer circles for months, if not more than a year. Finally, though, we have shipping examples of broad adoption of an API that's lightweight and suitable for today's most interesting applications. It's not just that Twitter's realtime, though of course that is compelling, but also that these APIs are simple enough for weekend hackers to build interesting projects on, and that they're easy to implement even on mobile devices and in almost any programming language.
So, today, we have support for the Twitter API from Twitter (of course), WordPress and Tumblr. I know I saw folks working on this for TypePad's free service when I was at Six Apart, so I'd assume they just wanted to finish OAuth support before supporting it as well. (See below.)
Of course, I don't need to make any suggestions to developers about what to do with these APIs — I'm sure the gears in everybody's heads are turning about cool new applications to build. Instead, I'd like to make a series of suggestions for the entire Open Twitter API ecosystem, based on what we've learned from past successes and failures in APIs around blogging.
What Server Developers Should Do
- Please please please support OAuth: It's egregious that the newest implementations of the Twitter API are stil encouraging people to share their passwords with third-party sites. Five or ten years ago, this was common practice in APIs because we didn't have better options. Twitter started out using shared passwords, but mercifully has started to bring OAuth support online. But for new services to be encouraging the horrible practice of users entering their passwords into every application willy-nilly is just unacceptable. I think we have a two-week window or so within which the new services supporting the Twitter API could announce their intention to support OAuth and really catalyze client developers into doing the wrong thing, but I fear we may lose another generation of API evolution to this terrible practice. If just one or two services announce intent around OAuth by the end of the year, client developers will follow — if you use WordPress or Tumblr, encourage your service provider to do this. (This is usually where I'd insert a dozen examples of how sharing passwords screws users, services, and the ecosystem, but I know that developers often just use shared passwords because they're lazy. Do the right thing, guys. The client devs will follow along.)
- Support Really Simple Discovery: The RSD format isn't sexy by today's standards, but grew organically out of some smart thinking from when blogging APIs were at the same state of maturity as today's tweeting APIs. Instead of reinventing the wheel, developers should look at supporting RSD and looking for something like a "tweetsapi" endpoint for these new services. That way, any arbitrary site can advertise that it supports the Twitter API, or even future versions of an open MetaTweets API. Pay attention to which APIs are listed as "preferred".
- Think about overloading of
sourceelement of status updates in the Twitter API is very interestingly open-ended, and supports use of URLs. Instead of merely advertising your client app, smart use of
relattributes and URLs here could help bootstrap some very interesting new potential.
What Client Developers Should Do
- Support RSD: Same logic as above.
- Start sharing parsing libraries: Client devs going to be doing a lot of duplicate work to parse out URLs and usernames and hashtags and maybe even slashtags. But almost every scripting language supports some similar variation on regular expressions, and if you're using that method to tease out meaning from short messages, then lighten your burden by sharing the load. John Gruber's work to share his URL parsing rules should be a model for a dozen other GitHub projects — compete on features and execution, but not on these fundamental interpretations of text.
- Build in the big services, but support the little ones: You'll naturally want to offer menu options for users of the big, centralized hosted services. But (perhaps as part of supporting RSD), you should allow for all of us to have arbitrary Twitter API endpoints on our own domain names — this is good for the web!
What Every Developer Should Do
- Think about piping Twitter API endpoints together: I think it will be common for some kinds of applications that support the Twitter API to be both clients and servers, supporting piping content through, and perhaps applying transformations to the updates. This idea of daisy-chaining services together is likely only going to happen if a lot of parts of the infrastructure support OAuth well, but has the potential to be truly revolutionary if the ecosystem allows it to happen.
- Start looking at people's firehoses: Twitter's firehose of all status updates is about to be broadly available for developers, I know about the free TypePad firehose from my time at Six Apart, and I think WordPress will sell you access to theirs, but I haven't yet been able to find a reference for one for Tumblr. No matter — we should assume that free, open versions of these are coming, and start to figure out how to encourage similar collaboration around the reading side of things, now that the writing side of things is getting hashed out.
- Consider adopting a "+2 Rule": The natural inclination right now for geeks of a certain type is to start dreaming up new standards bodies, or how they can participate in the Open Web Foundation to make a Super Awesome Twitter API Evolution Committee. Here's my recommendation: Don't. Don't do any of that shit, and don't run off to make membership badges for the Treehouse Club quite yet. Instead, just iterate and ship. Keep making new apps and see what you can do to stretch the limits of the existing methods and structures. I love the new geocoding and contributor aspects of the Twitter API, but as I said at the top of this post, I think the period of rapid iteration on the core Twitter API is ending, as new efforts going forward will have to reach consensus.
The good news is, consensus around evolution of the Twitter API can happen simply by saying to each other, "If two application developers who share no common investors or board members can reach agreement around an extension to the API, and between them they have a significant enough number of users to be relevant, then we should all just adopt their work."
This is important because it reframes the conversation from being about technical merits, and all the boys who like to play with APIs always think they know what's "better". I'm sure if I wanted to waste an afternoon, I could tell you a dozen ways in which the Twitter API could be "improved". But guess what? That shit does not matter. Adoption matters, and I'm heartened by the fact that people seem to be getting that.
So, get to work! Please give me feedback if I'm wrong or being stupid about one of my recommendations, but if not, then just start hacking. Stop encouraging people to share passwords, start encouraging services to share tweets, and let's all join in a hearty session of finger-pointing and mockery in Facebook's general direction for their sense of Not Invented Here having overshadowed their opportunity, because they could have really clearly done an "embrace and extend (and extinguish)" on the Twitter API if they hadn't wanted to make their own system a year ago, and now they've lost that power.
Finally, thanks a lot to Dave Winer for essentially inspiring a lot of players in blogging to move towards embracing the Twitter API. Sure, lots of us had the idea, and I've spent a lot of times in meetings arguing for this stuff across the industry, and Automattic and Tumblr and others were brave enough to embrace it. But I don't think anybody's done more to publicly advocate for an open Twitter API than Dave. I'm glad we've evolved as a community to the point where these kinds of breakthroughs aren't the contentious, immature shitfests they used to be.