Results tagged “pushbutton”
May 31, 2011
I've been waiting a year for someone to write about this, but my laziness has not yet paid off, so here are a few things that we all know about everybody's favorite Cupertino fruit company:
- Apple has client app software on hundreds of millions of devices in the form of iTunes on PCs and Macs and, well, all of the bundled software on iOS devices.
- Apple has an extremely large-scale realtime messaging service, in the form of Apple Push Notifications, which has scaled with high reliability to what must be an extremely large number of messages, certainly on the order of hundreds of millions a day.
- Apple has account info for every person receiving those notifications, usually including credit card information.
- Apple has lots of experience making client applications for short-length interpersonal messaging.
- Apple has a proven ability to get the attention and interest of artists and tastemakers who influence culture and inspire a following.
And here are a few things which Apple doesn't have:
- Any success or demonstrated ability in making compelling clients for social networking, whether in the form of Game Center or Ping.
- A usable API for developers to build on this realtime networking infrastructure in a lightweight way in web apps, or in languages other than Objective C.
But in short, the hardest, most expensive technical part of building a web-scale Twitter competitor already exists in Apple's infrastructure. What's missing, in an odd reversal of Apple's usual pattern, is a well-designed, simple user experience that makes people want to participate.
Could a small team of developers and designers within Apple make a credible realtime messaging service with first-rate native clients on every important platform? Could they graft on a simple, REST-based web-style APIs to the complicated, old-fashioned API that enables push notifications right now? It'd be a lot like building a usable, delightful user interface on top of well-established, but complicated, technological underpinnings, wouldn't it? I wonder if Apple has those skills.
August 18, 2009
Phew! Seems like there are a ton of people talking about the topics we've all been discussing here lately. Here's some highlights:
After I posited that the U.S. executive branch is the most interesting startup of 2009, there have been some amazing responses. Craig Newmark (you love his list!) very kindly gave a nod towards my post, adding "In some results, it's run like a really good Silicon Valley startup", and spreading the word on The Huffington Post as well. Mike Masnick at Techdirt chiimed in as well:
For plenty of reasons that you can guess, I'm pretty jaded by people in government, and it's rare to come across people who seem to be doing things for anything other than "political" purposes. But I have to admit that the amazing thing that came through in both [Federal CTO Aneesh] Chopra's talks was that they were both entirely about actually getting stuff done, with a focus on openness and data sharing. Chopra talked, repeatedly, about figuring out what could be done both short- and long-term, and never once struck me as someone looking to hoard power or focus on a partisan or political reason for doing things. It was never about positioning things to figure out how to increase his budget. In fact, many of the ideas he was discussing was looking at ways to just get stuff done now without any need for extra budget. Needless to say, this is not the sort of thing you hear regularly from folks involved in the government.
Towards the end of my essay, I'd pointed out one particular challenge that faces this new startup-minded government effort: "Acquiring and retaining talent is hard, especially in a city that doesn't have as deep a well of people with tech startup experience." Amazingly, the latest perfect example of the type of talent that are heading to D.C. these days just popped up, with Christopher Soghoian's announcement that he is joining the FTC. I only know Christopher's work by reputation at Harvard's Berkman Center, but I think the fact that the government is looking for talented people in academia (a talent pool that typical tech startups often overlook) is a great sign.
Of course, there are skeptics. Gautham Nagesh covers the government for Nextgov and Atlantic Media, and he thinks I'm believing the hype". Of course, I think Gautham and I just disagree about government's role in general, and that I'll take small signs of progress as successes, even if there is a lot of work left to do yet.
In fact, I'll be talking about this a bit later today on Federal News Radio's Daily Debrief show. If you're in D.C., tune in to 1500 AM at 4:05 EDT and one idea I'll be discussing is how the recent web achievements by the executive branch are a lot like Microsoft's recent success with Bing; It doesn't mean that the whole giant organization is on the right track, it just means that it's still possible for these behemoths to do the right thing.
The potential is also hinted at in Brady Forrest's post about EveryBlock's acquisition over on O'Reilly Radar. I'm ecstatic to see Adrian and his team at EveryBlock get even more resources for their work, but just as pleased to see the government's work being discussed as a peer to even the most cutting-edge startups in the private sector.
Google's Wave Moment
After my recent posts about The Wave Way and Google's Microsoft Moment, I was very graciously invited to join Leo Laporte, Gina Trapani and Jeff Jarvis on their awesome podcast about Google and cloud computing, This Week in Google. If you have an hour or so to spare for listening to a podcast, I am very proud of how it came out, and especially that I got to participate with such pros on a show like this. TWiG is available on iTunes and Boxee and all of those usual services as well.
The idea that Google is facing a reckoning as it grows in size and influence seems to have caught on, and comparing the company to Microsoft has gone from seeming a bit radical at the time I posted to becoming much more popular when Wired covered the idea to finally having become something approaching conventional wisdom in just a few weeks. Take, for example, New Google is the old Microsoft, by Galen Ward, which lists the ways that Google ties its nascent (or even unsuccessful) efforts to the results of its dominant search engine.
Apple Blinks on Secrecy?
Less than three weeks ago, I was arguing that Apple's culture of secrecy can't scale. Fortunately, we may never know if I'm right. Astoundingly, Apple has opened up to some degree, most notably via VP Phil Schiller reaching out personally to bloggers John Gruber and Steven Frank. Of course, that's not a complete course change for Apple, but it is still significantly more human, personal and open than any recent communications they've made about their efforts.
Meanwhile, the idea that Apple's traditional secrecy is untenable has gotten an even larger audience with The Times' lengthy look at Steve Jobs and Apple:
[A]long with computers, iPhones and iPods, secrecy is one of Apple’s signature products. A cult of corporate omerta — the mafia code of silence — is ruthlessly enforced, with employees sacked for leaks and careless talk. Executives feed deliberate misinformation into one part of the company so that any leak can be traced back to its source. Workers on sensitive projects have to pass through many layers of security. Once at their desks or benches, they are monitored by cameras and they must cover up devices with black cloaks and turn on red warning lights when they are uncovered. “The secrecy is beyond fastidious and is in fact insultingly petty and political,” says one employee on the anonymous corporate reporting site Glassdoor.com, “and often is an impediment to actually getting one’s work done.”
But employees are one thing; shareholders are another. Should Jobs (who, as far as the world is concerned, is Apple) have been allowed to conceal the seriousness of his illness? Warren Buffett, the greatest investor alive, doesn’t think so. “Whether [Steve Jobs] is facing serious surgery or not is a material fact.”
Some say another sign that Apple omerta has gone too far was the death of Sun Danyong, a 25-year-old employee of Foxconn, a Chinese manufacturer of Apple machines. He was given 16 prototypes of new iPhones. One disappeared. Facts beyond that get hazy, but it is clear that Sun committed suicide by jumping from a 12th-storey apartment. Internet babble says he killed himself because of the vanished prototype and, therefore, because of Apple’s obsessive secrecy.
Pushing the Right Buttons
Finally, the idea of the Pushbutton Web seems to be gaining steam. I am delighted to point out Om Malik's The Evolution of Blogging, which Om uses as an example of a longer-form blog post he's enjoyed recently, but which I also hope will be a catalyst for the evolution of blogging that he's calling for in the post overall.
That point is taken even further with Farhad Manjoo's ruminations in Slate, which reference my Pushbutton post:
[A]s technologies like PubSubHubbub proliferate around the Web, with companies like Google, Facebook, and others embracing them, real-time Web updates will become the norm. It won't be hard to build competitors to Twitter—systems that do as much as it does but whose decentralized design ensures that they're not a single point of failure. Winer envisions these systems coming up alongside Twitter—when you post a status update, it could get sent to both Twitter and whatever decentralized, next-gen Twitter gets created. If these new systems take off, Twitter would be just one of many status-updating hubs—and if it went down, there'd be other servers to take its place.
Seeing so many great conversations pop up recently around the topics I've been obsessing over has been very inspiring; Right after I made offhand mention of one of my Big Think interviews being about the Philology of LOLcats, my original piece on LOLcat language, Cats Can Has Grammar, was indirectly cited in Time's profile of "I Can Has Cheeseburger", through a reference to "kitty pidgin". It might seem like a minor mention, but the idea that a random dude like me can write a post that results in a phrase showing up in Time or The New York Times is still very exciting to me, after all of these years.
Best of all, there have been a spate of amazing comments on all of these posts lately, both on this site and in some of the responses I've linked to above. I'm having more fun than ever in watching the conversation across the blogosphere.
In the meantime, two to consider:
August 12, 2009
I know I just did one of these roundup posts yesterday, but there are a whole bunch of new conversations branching off of the topics I've been blogging about here. You might find some of these interesting.
- Big Think posted a series of video interviews with me as part of their ongoing effort to capture ideas from people in a wide variety of disciplines. Rex and Choire both gravitated towards me talking about LOLcats (naturally), but I was pretty happy with the segment about the fact that those of us who create social media technologies have a set of responsibilities that come along with our privileges:
- Marshall Kirkpatrick at ReadWriteWeb asks, Is a Perfect Storm Forming for Distributed Social Networking? Answer: Yes! There's a nice nod to Pushbutton technologies there, but the whole piece is worth reading as it lays out some key events that are opening the door for some new technologies to succeed.
- Similarly, Wired's Eliot Van Buskirk asserts "Open Source ‘Twitter’ Could Fend Off the Next Twitpocalypse". This piece echoes Marshall's premise, pointing out that recent weaknesses demonstrated by platforms like Twitter might lead to solutions that take advantage of the web's inherently decentralized nature:
Other open, Twitter-like concepts are in the works: OpenMicroBlogger, Google’s pubsubhubbub, Dave Winer’s RSSCloud and Anil Dash’s “Pushbutton Web.” If this trend towards open microblogging trend continues, in whatever form — and despite Twitter having seemingly every reason not to cooperate — it will no longer be possible to shut down micro-blogging with one or two concentrated attacks.
- I've been ecstatic to see my friend Baratunde Thurston get a ton of recognition for his amazing work lately, but perhaps the most amazing milestone is seeing the debut of his new show Future Of.... With Baratunde as host, Popular Science backing the effort, and the Science Channel broadcasting it, I am extremely optimistic about this smart, funny show's chances. (Though I do wish it were possible to watch it on the web.) The incomparable Lynne d Johnson wrote up the premiere for Fast Company and I was just one of the people raving about the series and Baratunde's work in it.
- Finally Clint Boulton in eWeek takes another look at Google Wave and my questions about some of its complexity:
[Gartner analyst Ray] Valdes, who wrote his first Wave robot in 30 minutes using 30 lines of Python code at Google's Hackathon last weekend, also believes Wave suffers from a complexity problem, just not in the same vein as Dash. Dash argued that the many moving parts of Wave, including XMPP and OpenSocial, make it a bear to use, unlike the easier RSS and AJAX Web technologies. Valdes said:
"I do think that Wave has a complexity problem, but it is not so much internal technical complexity as user interface complexity. In its current form, Wave fails the 'grandma test'—that is, can my grandma use it? I am speaking, of course, of online grandmas that are already using e-mail and IM and Facebook—which these days, there are very many that are. I think Google needs to simplify the Wave user experience if they want to achieve mass adoption."
While I bristle a bit at Ray's use of the tired "grandma" trope, I can't say I disagree with his premise. I didn't want to be too critical of Wave's user experience as I understand that it's still early in the process of the platform's development, but as it stands today, it is a wee bit confusing most of the time.
August 7, 2009
Google Wave is an impressive set of technologies, the kind of stunningly slick application that literally makes developers stand up and cheer. I've played with the Google Wave test sandbox a bit, and while it's definitely too complex to live up to the "this will replace email!" hype that greeted its launch, it certainly has some cool features. So the big question is whether Wave will succeed as overall in becoming a popular standard for communications on the web, because Google has made an admirable investment in documenting the underlying platform and making it open enough for others to build on and extend. I think the answer is no, and the reason is because the Wave way is not compatible with the Web way.
What do I mean by "the Web way"? Well, if we look at the history of new technologies being adopted to extend web sites and enhance communications, we see a few trends emerge:
- Upgrades to the web are incremental. Instead of requiring a complete overhaul of your technical infrastructure, or radical changes to existing behaviors, the web tech that wins is usually the sort of thing that can be adopted piecemeal, integrated as needed or as a normal part of updating one's websites or applications.
- Understanding new tech needs to be a weekend-sized problem. For a lot of web developers, long before they start integrating a new protocol or platform into their work, they hack together a rough demo over a long weekend to make sure they truly grasp how it works. And a weekend-scale implementation on a personal site usually translates roughly into a 90-day implementation cycle in a business context, which is a reasonably approachable project size. (In tech, three days in personal effort often translates to three months of corporate effort.)
- There has to be value before everybody has upgraded. This is basically a corollary to Metcalfe's Law. While we know networks increase in value as they add more nodes, the nature of web tech is that, in order to be worthwhile, it has to provide value even if the people on the other end haven't upgraded their software or web browsers or clients or servers. Otherwise you're shouting into an empty room.
- You have to be able to understand and explain it. Duh.
Now, if we take a look at some examples of what has worked, we can see how various successful technologies have displayed these traits. One great example is feeds. When RSS feeds were new, it was easy to understand their potential immediately, and since I was working at a newspaper at the time, I just spent an afternoon understanding the format and hacking together a quick feed of headlines that anybody could subscribe to. If nobody had adopted feedreaders yet, that was no problem, since there was no cost to just having the feed sit there with no subscribers — the "nobody's upgraded" problem would only result in me having wasted a few hours.
Ajax had a similar adoption pattern. It took a little bit more time to comprehend, but not much more than an afternoon, and the development effort required for adding Ajax enhancements to an application started as a weekend-scale project and has only gone down over time. Following the principles of progressive enhancement, well-designed implementations performed just fine on older browsers or systems that couldn't handle the new features. And most sites that have added Ajax features have done so by adding the requirements as a checklist item in the course of normal ongoing updates, not as standalone efforts to migrate to a new technology.
This brings us to Wave. Wave offers excellent opportunities to extend its core features and to add richness to its "wavelets", and I have no criticisms over its utility as a developer platform that third parties can build upon. But the fundamental Wave protocols are, I fear, a bit too complex to ever be fully and correctly implemented by anyone other than Google. Interoperability is likely to be a challenge that plagues the platform for its entire existence. In short: It's likely that nobody will ever build a fully-compatible clone of Wave that competes with Google's own implementation.
Why is that true? Let's look at what's built in to Wave:
- Powerful realtime collaboration features
- Unlimited versioning of content
- Built around robust XMPP protocol
- Combines chat, document editing, and message threading — wikis + blogs + comments + IM
- Delivered as a very polished rich user interface
Each of these is a very compelling experience. But a lot of developers' reactions to seeing them was not just "I can't wait to use that!" but also "I want to add that one feature to my own existing application!". And that's where it gets tough. Let's take a look at Joe Gregorio's list of the protocols that power Wave. (Joe works at Google, but made this list before he was working on Wave. I appreciate his research and openness on this topic, and presenting his work here is a tribute to what makes Wave great, not a criticism of his effort.)
- Federation (XMPP)
- The robot protocol (JSONRPC)
- The gadget API (OpenSocial)
- The client-server protocol (As defined by GWT)
That's a lotta stuff! XMPP alone is a bear to implement, let alone to deploy at large scale. (I can't think of anyone outside of Google, Earthlink and LiveJournal who have deployed XMPP to millions of users.) But if you wanted to make another application that truly interoperates with all that Wave can do, combining all of these pieces would just be the starting point.
And people aren't looking for a replacement for email, or instant messaging, or blogs, or wikis. Those tools all work great for their intended purposes, and whatever technology augments them will likely offer a different combination of persistence and immediacy than those systems. Right now, Wave evokes all of them without being its own distinctive thing. Which means it's most useful in providing reference implementations of particular new features.
If a developer wants one of the compelling individual features of Wave, like near-realtime collaboration, they're more likely to use something like (wait for it...) Pushbutton technologies. The infrastructure afforded by the components of the Pushbutton Platform comes nowhere near the richness and polish displayed by Google Wave. Pushbutton isn't even designed to offer the benefits demonstrated by Wave. But to its credit, Pushbutton displays nowhere near the complexity of Wave in its interoperability requirements. More importantly, integrating Pushbutton features into a website or application isn't a monolithic process of building dozens of cutting-edge features, but rather can be deployed incrementally by even non-expert webmasters.
In this context, it might help to think of Pushbutton tech as a "micro-Wave". As Gina Trapani said in mentioning Google Reader's support for PubSubHubBub:
Huh-wha? you ask. Yeah, I know. It's no Google Wave. But that's what makes this exciting. This kind of small Pushbutton implementation is how real web pages will easily use existing technology to notify one another of new updates. The Google Reader/FriendFeed integration is just the first tiny step in what will be a broad deployment of realtime-enabled sites. These sites and services will let one another know when they have new data to share without the sucky inefficiencies of polling. Check out how fast FriendFeed updates when you share an item in Google Reader in the video above.
In short, it's almost zero latency.
Why is this clearly "inferior" technology going to win? Well, as just one example, XMPP is way too complicated for any normal human to deploy. Whereas if you're reading this, you probably already have access to a regular HTTP web server that could talk to a Pushbutton hub. In fact, the only two backers I know who have worked extensively with XMPP are Brad Fitzpatrick and Artur Bergman, who co-created Djabberd. And they are both excited about PubSubHubBub. Realistically, someone like Yahoo might try to do all of this, and inevitably one or two open source projects will try to lash together open implementations of each of these pieces to make a kind of FrankenWave application. There are probably already one or two teams working on the inevitable "Enterprise Wave Server" platforms as well, though I haven't heard about them myself. These efforts may succeed, but that doesn't mean they'll ever be robust enough that people will trust them for communicating on the web.
More to the point, I'm a regular blogger who knows a little bit about scripting on a normal web server. I can poke around the documentation and add a few tweaks to my RSS feed (or, in my case, do nothing and have Feedburner automatically handle it for me), and all of a sudden my blog's feed is part of the Pushbutton web, ready for others to build on. I literally wouldn't even know where to start with the Wave developer documentation if I wanted to integrate it with my site or any of the little apps I like to hack on during a long weekend. What seems more realistic — that someone will figure out a way to incrementally build on top of realtime feeds to enable Wave-like experiences, or that all this talk of Waves, wavelets and blips is going to suddenly become easy to understand.
In short, web-way tech like feeds, Ajax and Pushbutton win because people who make good sites and applications have a place to start with it. Does this mean we get fancy realtime simultaneous editing right away, now that Pushbutton exists? Nope. In fact, Wave might even get the early jump on those kinds of features for web apps, simply because it's pioneered that part of the user experience. But Wave only runs to its full potential on the most cutting-edge web browsers. And there may only be a dozen companies in the world with the in-house expertise to clone the entire complement of technologies underlying Wave in order to make a full-fledged competitor. Worse, the monolithic nature of the Wave experience means it will even be a challenge to make a full-fledged open source competitor to the official Google service.
I hope that Wave succeeds, because I love to see ambition and innovation rewarded. But I think it's mostly likely that Wave's success will be in inspiring people to create similarly compelling experiences by adding incremental enhancements to their existing sites. That's how the web's always advanced in the past.
August 6, 2009
I've really been enjoying the response to my recent blog posts — here are some more thoughtful replies.
In one scenario, this is a bubble of sorts. Apple may be doing OK now, but they’re headed for a big crash when people get sick of their behavior. In another scenario — one that I think is, sadly, more likely, Apple continues as they are, adjusting when it must to address reality, but only in the most minimal way.
I've also really been enjoying watching Dave Winer's work recently. In the past we were both too young and stubborn to realize we're amused by a lot of the same things (There's my refrain of "We hate most in others that which we fail to see in ourselves" again!) but these days it is just plain entertaining to watch Dave go. My amusement is amply covered in "Anil's belly laugh", which mentions my response to Dave's latest bit of hacking. As I mentioned on my Twitter account, I also recorded an episode of the Bad Hair Day podcast with Dave and Marshall Kirkpatrick last week.
Speaking of podcasts, This Week in Google is a new one featuring Leo Laporte, Jeff Jarvis and Internet Hero Gina Trapani. This week, they had a very nice look at The Pushbutton Web towards the end of the show. I'm delighted how many people have told me they found that post valuable or useful in talking about this whole area of innovation. Since I'm a lousy coder, writing blog posts like that is the most helpful thing I can do.
Finally, as it's come up in several contexts lately, it's probably worth repeating the key point of a post I wrote two years ago, which attracted some attention then but is probably even more relevant today. The core concept is about "The Watery Web":
It's not true to say that Facebook is the new AOL, and it's oversimplification to say that Facebook's API is the new [MSN] Blackbird, or the new [AOL] Rainman. But Facebook is part of the web. Think of the web, of the Internet itself, as water. Proprietary platforms based on the web are ice cubes. They can, for a time, suspend themselves above the web at large. But over time, they only ever melt into the water. And maybe they make it better when they do.
Thanks, as always to people who've responded to what I've written, and especially to all of those who've taken these posts as starting points and expanded the ideas into some truly inspiring creations.
July 24, 2009
Pushbutton is a name for what I believe will be an upgrade for the web, where any 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. The pieces of this platform have just come together to enable a whole set of new features and applications that would have been nearly impossible for an average web developer to build in the past.
The most interesting area of new development on the web is the innovation happening around realtime messaging, the ability to deliver updates to a website or application in one or two seconds. While various systems like Yahoo News Alerts or feed readers like Google Reader have offered some simple ways of delivering fairly fast notifications, they are still built on an infrastructure that relies upon requesting a web page repeatedly. These systems do the equivalent of hitting the "reload" button in your web browser over and over.
While those systems have been using these inefficient methods to deliver updates, newer platforms like Twitter, Facebook and FriendFeed have focused on building the infrastructure for efficient large-scale delivery of updates using their own proprietary networks. A lot of attention has been paid to Twitter's 140-character limit, or Facebook's News Feed, but the compelling technology that enables the user experience on these platforms is the immediacy with which updates are delivered. Earlier systems like instant messaging or chat allowed realtime messaging on a one-to-one or small group basis, but it's been harder to deliver those realtime messages to anyone in the world who wanted to receive them unless you had a lot of money, expertise and infrastructure.
Another barrier is that, while there are many different programs and clients that let you connect to Twitter or Facebook with your own applications, there haven't been any free and open options for delivering realtime messages to a large audience if you couldn't, or didn't want to, rely on those companies.
But recently, a few key pieces have fallen into place that make it inexpensive and relatively easy to add realtime messaging as an incremental upgrade to existing websites and web applications. This set of related technologies, which I'm calling the Pushbutton platform, will yield a broad new set of capabilities for users, publishers and developers on the web. Best of all, Pushbutton technologies are free, open and decentralized, meaning that the arrival of realtime on the web will not be owned or controlled by any single company.
The concept and potential of Pushbutton is a lot like Ajax — it's not a single technology or invention, it's a whole family of technologies, some of which have been in development or deployment for nearly a decade, that together enable this new realtime web. Pushbutton's foundation is built on these systems:
- Atom and RSS: The most common feed formats, for syndication on the web
- PubSubHubBub and RSSCloud: Powerful new "hubs" for distributing messages
- Web Hooks: Simple web services for receiving messages, rather than sending them
Pushbutton systems rely on the web's fundamental HTTP protocol for communication between these component parts. The architecture of Pushbutton message delivery is also simple to understand. Before Pushbutton, in today's systems, when you create a message (a blog post, tweet or other update) that's published in your RSS or Atom feed, every application or site that wants updates from you has to repeatedly request your feed to know when it's updated. You can optionally notify ("ping") some applications to tell them it's time to come collect your new updates, but this is time-consuming and resource-intensive on both sides, especially if you want to notify a lot of people.
In the best case, the system we have now is analogous to a person coming by your house and saying "Hey, there's a new edition of your favorite newspaper today. You should go get it." And then you have to go to the newspaper's printing plant to pick it up. In a Pushbutton web, that person is delivering each story to your house the moment it's complete.
That's because Pushbutton-enabled applications will improve upon the current state of affairs by proactively delivering not just the notification that there's a new message, but the content of the message itself. And instead of requiring all those applications to come to your site to read the update, it uses a hub server in the cloud to pass along the message directly to all the receivers that are interested in it.
- You, the Sender, create a message to be delivered via RSS or Atom
- Your application gives the messsage to one or more PubSubHubBub or RSSCloud hubs, which reside in the Cloud
- The PubSubHubBub or RSSCloud hubs deliver the message to any Receivers, the applications or sites that have requested updates from you
In this way, each time you create a new message, a large number of Receivers can consume that message in near realtime (usually less than a second) without a lot of complexity. This kind of messaging has been possible with custom-built or more obscure technologies in the past, but the Pushbutton ecosystem is a breakthrough for a few reasons:
- Sending messages just requires a minor change to an RSS or Atom feed, and a simple, well-defined update notification, instead of major changes to the application where you create your messages.
- Receiving messages is also very simple, only requiring a developer to handle incoming notifications of updates.
- Most of the system's complexity is handled in the hub servers, which are well-documented, implementable in a variety of programming languages, and built around open code that will likely attract a large developer community.
- Most of the scaling effort and expense happens at the hub level, and all current hubs are designed to run on inexpensive cloud systems like Google App Engine or Amazon's EC2.
- The software for Sending, Receiving or running a hub is free, open source and available on almost any platform.
- Messages sent on Pushbutton platforms are delivered via HTTP, which is familiar to any web developer and runs well on any hosting environment. All requests between the different layers of a Pushbutton system can be made as simple REST calls.
- Pushbutton technologies can be adopted incrementally, so that features can be added piecemeal on either the sender or receiver side, without requiring a wholesale upgrade to infrastructure or application architecture.
Who's Behind Pushbutton?
Pushbutton technologies have been created and advocated by some of the most credible and experienced developers of social web technologies. Here's a brief overview of the impressive pedigree of these components:
- PubSubHubBub was co-created by Brad Fitzpatrick and Brett Slatkin of Google. Brad was founder of LiveJournal, and created or co-created fundamental social web technologies like Memcached, OpenID and more.
- XML-RPC update pings, RSS and the RSS Cloud ideas were pioneered by Dave Winer, who has been actively developing open implementations of each of these technologies.
- Web Hooks have been evangelized by Jeff Lindsay, and have been deployed by a variety of different companies and platforms which all independently developed the technique.
In addition, Google has supported Brad and Brett's development of PubSubHubBub, and enabled it on the Google FeedBurner service. A number of smaller companies are deploying large parts of this infrastructure as well. In short, some of the best reputations in developing open web systems have made Pushbutton possible, from the biggest tech companies to the most steadfastly independent developers on the web.
Related Ideas and Prior Art
There are a lot of existing technologies that have influenced the creation and evolution of Pushbutton technologies; If you're familiar with any of these systems, you're probably already ahead of the curve in understanding part of what Pushbutton is trying to enable.
- Twitter Firehose, FriendFeed SUP, TypePad Update Stream: These realtime delivery systems offer up the content of their respective platforms as an unending stream that developers can consume and use in their applications. At the present time, they all have varying licenses and degrees of openness, and slightly different formats for delivering updates, but have proven the utility of the "sending" part of Pushbutton's realtime functionality.
- XMPP (Jabber), NNTP (Usenet), IRC: These older internet protocols all delivered various degrees of realtime messaging and distributed messaging capabilities, and can form a very useful base of experience for Pushbutton developers to learn from. In some cases, fundamental architectural choices about security, authentication or architecture were made when the Internet was less populated and less complex, making them inappropriate for today's applications. In all cases, these protocols are less-known by most contemporary web developers, and thus lack familiar toolkits and development resources, which make them quite challenging to deploy in common, inexpensive environments.
- TrackBack and Pingback: These systems for delivering updates between blogging systems were very effective in enabling rich distributed conversations in the early days of the blogosphere. These have declined in usefulness due to poor or missing implementations of authentication, which led to spam problems, and a general lack of understanding of their utility by a lot of newer bloggers. Pushbutton may offer an opportunity to restore some of the value of the idea behind these systems.
- Reverse HTTP may end up being a useful component of some Pushbutton deployments, as a complement or companion to Comet and related techniques.
What should we worry about?
- A format war? If you're familiar with the communities around technologies like feeds, you may know they have a deserved reputation for being contentious and even breaking into heated disputes over arcane details. I don't think that's likely to happen this time, because there are only one or two viable formats for each layer of the platform, and the creators of each part have shown some consistent good-faith efforts to promote interoperability where possible and peaceful coexistence where necessary. In the Ajax community, for example, the "X" in Ajax often stands for JSON instead of XML, but this hasn't hindered its broad adoption at all. I'm also willing to personally commit to try to prevent any kind of interpersonal conflict that would inhibit the adoption of Pushbutton technologies. Worry? No.
- Scaling issues? There will inevitably be some learning to do about how to scale the resource-intensive hub layer of a Pushbutton system. But because the hubs live on cloud systems that make enormous amounts of computing resources easily available, because the coders creating the reference implementations of the hub software have great experience making web-scale systems, and because it's relatively simple to introduce new hubs as needed, this will likely not be a gating factor for adoption of Pushbutton. Worry? No.
- Intellectual Property Concerns? I'm not a lawyer, and this isn't legal advice. But there has already been a great deal of interest in these systems, and it's likely that any bad actors who were interested in throwing their patent lawyers at this sort of system would probably already be suing people left and right. And the main players who are already involved have shown a consistent desire to make truly open systems that don't have IP encumbrances. Put simply, I think anybody smart enough to invent these kinds of technologies is smart enough to not want to look like jerks by suing somebody for using them. Worry? Probably not.
- Competition from centralized systems? Pushbutton technologies are not just free and open, they're decentralized, which is a serious threat to the "lobster trap" model of social software. We can expect serious competition from the centralized networks that are currently building these sorts of systems. If a threat arises to Pushbutton's adoption, this is the most likely source. Worry? Definitely.
- Bad user experience? One of the worst things we can do in making use of new technologies is to ignore the social, personal or even political implications of their use. Messages that are immediately delivered can't, by their nature, be erased from all the places they appear. The idea of permanently archiving these types of messages is unfamiliar to a lot of less technically-savvy users. And whenever we see something shiny and new, we have the temptation to use technology for technology's sake, whether or not we're solving a real problem or providing a real value. If Pushbutton gets a bad rap early on despite having tremendous potential, this will be why. Worry? Hell, yes.
I have tremendous excitement about the new realtime era of web applications. While I'm fundamentally an optimistic person, I have great skepticism when it comes to mindless hype about new technologies, so it's with a bit of reluctance that I indulge in some hype myself. But I think the Pushbutton web has the opportunity to give individuals and organizations with distinct and passionate voices the ability to be even more immediate and expressive on the web, and after ten years of publishing on the web, that's the part I love the most.
I have no doubt that some skeptics will say "Pushbutton is just PubSubHubBub by another name", just like they said "Ajax is XMLHttpRequest by another name", and if that's what the super-geeky guys want to believe, I'm fine with that. And I'm sure there will still be some significant technical details to resolve. But I think by giving the overall concept an approachable, understandable name and (hopefully!) an explanation that can be understood by anyone with an interest, it can catalyze interest in a whole new area of innovation on the web. And to be honest, when I see folks like Brad Fitzpatrick and Dave Winer hacking on the same set of problems, I can't help but think something interesting will come of it.
Over the next few days, I'll be outlining some of the opportunities around Pushbutton, espousing more of the philosophy that has the potential to imbue Pushbutton with a bit more meaning than most new web tech, and providing some simple explanations of how you can get started both learning about and taking advantage of these technologies. Most of all, I hope you'll offer your pointed criticisms, thoughtful critiques, detailed corrections and even better ideas. I'll be following the conversation here in the comments, across the blogosphere, and on Twitter using the tag #pshb.