Last week Bitly announced that they’re morphing from a URL shortening service into a bookmarking service. I actually don’t think this is a bad idea.
Why do people start using URL shorteners? To share links that were unwieldy in the context in which they were to be used. I started using them in email because so many sites used URLs that were more than 80 characters long. It’s funny that with SEO and parameters used to track traffic sources, links are getting that long again. Anyway, that was the original use case.
One of the first thing Bitly did to add value beyond the basic shortened link was to offer analytics. When you shorten a link via Bitly, they collect basic analytical information about the people who click on it. So by using Bitly to shorten links you post to Twitter, you can get some idea of how many people are clicking on the links you share. This feature is remarkably useful, and is completely invisible if it’s not something you care about.
Bitly correctly assumed that people tend to shorten links that they care about, and that they may find value in having those shortened links saved as bookmarks so that users can come back later and view the archive. I think that was probably a good idea. I was a longtime user of Delicious and am a current user of Pinboard, and I have Pinboard automatically import any links that I post to Twitter. Most of those links are ones that I shortened using Bitly. In that sense, I’m pretty much the ideal use case for a Bitly bookmarking service. The main impediment would be that I have thousands of links stored in Pinboard already and I have no desire to move them.
The problem Bitly ran into is that they changed the basic link shortening workflow that people were used to. It used to be that if you shortened a link through the Bitly Web site or the Chrome extension, you’d immediately be presented with the shortened link. Unfortunately, Bitly has decided that promoting its new bookmarking service is more important, so now the first thing you’re asked to do is “Save this bitmark,” only after which can you see and copy the actual shortened link. Furthermore, Bitly gave you a nice box with the title of the page the link points to and the shortened link that you could easily post to Twitter with optional edits. That too is gone, replaced by a form that’s less useful.
Bitly would have really benefitted by enabling its users to wade into the new functionality rather than diving in. They should have maintained the old workflow and then presented a form that optionally allowed the user to add a description of the link, I think most users would have been much less frustrated with the changes. Bitly leapt out and tried to change a tool that people found pretty useful into a completely different tool. It’s not surprising that the existing user base revolted.
That said, Bitly needs to address this by tweaking the interface to satisfy existing users, not by throwing out the entire Bitmarks system. I think their idea that it’s a useful complementary service for them is correct.
PHP’s hidden strength
It’s easy to complain about PHP. Look, here’s Jeff Atwood complaining about PHP. He proposes to create something that will replace PHP. I’m all for this project — as an industry, we should constantly be working to improve and replace things, and we should be building great things in case they do wind up becoming popular.
If you’re going to try to replace PHP, you need to figure out what it is about PHP that enables it to maintain its massive market share. Everybody knows about the friendly learning curve and the easy availability of inexpensive hosting. If you want to create your first Web application, PHP is the simplest way to get started.
What’s interesting, though, are the reasons why you see some of the biggest Web sites deployed on PHP. It’s not because developers love it. It starts with the fact that PHP is easy to operationalize at any scale, or at least easier than most other technologies. It doesn’t require an app server, or a virtual machine, or anything that’s outside the realm of basic Unix processes.
What’s more important, though, is that many of the most experienced ops people in the industry who have deployed large scale sites have a PHP background. They understand how PHP works and where it fails. Building that experience on a different stack would take the same thousands of hours that they’ve already invested in learning how PHP scales. It also seems to me that you see less scaling-related drama from PHP-based sites than you see with sites that try newer technologies, or eclectic mixes of technologies. We’ve never seen Facebook go through growing pains like Twitter has gone through.
If you’re working on something with the goal of displacing PHP, the Twelve-Factor App manifesto is not a bad place to start. The other option is to build something that runs on top of the JVM, because there’s a lot of operational expertise in that area as well.
That said, the simplicity of PHP from an operations standpoint and the deep experience with it will make it somewhat difficult to displace PHP from its current position in the industry, no matter how much programmers like to gripe about it.