→ Twitter will bring RSS back from the dead

Last week the Twitter CFO made waves when he said that Twitter needs “an algorithm that delivers the depth and breadth of the content we have on a specific topic and then eventually as it relates to people.” That’s code for a filtered and managed timeline ala Facebook.

The twitterati and internet punditry class exploded with criticism, and rightly so. The most relevant point I saw on the topic hits the nail on the head:

Sure, Twitter executives may think that a reverse chronological feed “isn’t the most relevant experience for a user,” but it’s their only differentiating feature. It’s the very heart of what Twitter is. The unmanaged firehose of information of tweets is the user experience.

Facebook is a cesspool for most people. Aside from its ability to drive traffic—which is both it’s best and worst feature—Facebook is practically useless for catching up on breaking news, following your friends and contacts in real time, or wide open conversations. Twitter excels at all of these use cases because of the current timeline structure.

There are lots of interesting implications for Twitter and the internet, but one particular idea struck me immediately. I think RSS will see a comeback.

Four the last four years, one of the dominant narratives around Twitter is that it killed RSS. I never thought Twitter was a great competitor to RSS, but the results of the last few years disagree. Many users and publishers have adopted Twitter as their de facto standard for syndication.

Real time syndication will be hurt badly by a drastic change to the timeline, and I bet RSS has a comeback. It has all of the advantages of the open web that have shown to be so resilient over time. Most of all, it cannot be manipulated at the whim of a public company, and so far that is a killer feature on the internet.

The spirit of open source and the question of ownership

Update: Jeff Atwood and company have updated the name to ‘CommonMark’ in consultation with John Gruber. My thoughts below the original post.

Today Jeff Atwood (I’m a fan) and a working group announced a new fork of Markdown (which I am writing in, on a keyboard Atwood designed), a text markup language created by John Gruber (also a fan, a big fan)1. They created a new spec, intended to remove the ambiguity of Gruber’s original spec, and a standard set of test suites. They call it “Standard Markdown.”

They created this new project without Gruber’s involvement, and it looks like without his blessing—both of which are just fine in the open source world. I haven’t read the new spec in detail yet, and I think the standard tests are a great idea. This project was clearly conceived with a clear purpose because of a felt need. I think this is a good idea in many ways.

But the name is terrible. “Standard Markdown” is absolutely the wrong name for this project. And this isn’t nit-picking either, the name is so bad it casts a pall over the whole project.

First, reusing the name Markdown is a poor choice. I understand that we are all tired of “X flavored Markdown” as naming approach, but using the name Markdown on a fork of the syntax clearly marks this effort as trying to take the place of the original spec. It’s unnecessarily aggressive.

But beyond using that familiar moniker for the project, the team went a step further and claimed the mantle of “Standard.” This decision cannot be interpreted in any way other than an attempt to wrest ownership of the thing called Markdown from the guy who invented it. It’s an overly bold move, full of hubris.

I’m an open source proponent, but just not a Stallmanist2. I affirm this team’s right to take the Markdown language and syntax and make it better. I affirm the right of others to take that and use it instead of Markdown. That would be a good thing, in fact that is how technology advances. So don’t misread me, I’m in favor of this project existing.

But don’t call it Markdown, and certainly don’t call it “Standard Markdown.” Claiming something new to be a “Standard” version of an existing open source project is poor form. Gruber created the Markdown syntax and its first parser, he claimed a copyright, and released it to the world. It is open source. It has been built on, modified and extended well beyond its original incarnation. That’s all well and good. In a real sense, Gruber has a form of ownership over both the Markdown default implementation and syntax, open source though it is.

The chosen name for this project seems to reveal the intentions of the team behind it: take over the intangible ownership of a successful idea, and it’s brand, without the permission or help of the creator. Building on top of Gruber’s work is a good thing, it’s a great example of the open source ethos. But trying to claim a “standard” that is divorced from the original spec is not.

The fix is simple. Keep the new spec. Keep the test suite. Keep all the good work that moves Markdown forward. But change the name. It’s not the “standard” Markdown, and calling it that is dishonest.


On the second try, the project formerly known as “Standard Markdown” was renamed to “CommonMark.” First the renamed it to Common Markdown, and that names holds many of the same issues as the first.

Ultimately, this is the right outcome. There was lots of back and forth on Twitter between Atwood and Gruber, and of course their respective teams, and it looks like the name contention was eventually resolved in private.

In the end, this is the right solution. Given the people and platforms involved, there was no chance this would be resolved completely behind the scenes, but this result is good for all involved. Certainly CommonMark is not the best name ever, and some time spent thinking about alternative could result in something better, but it works. I’m glad the team decided to change the name, and I’m glad the web has a strict Markdown implementation. In fact, I’ll be investigating the test suite myself.

  1. This is a weird perfect storm of fandoms and respect. I’ve got so many horses in this race I think it all evens out. I have so many conflicting biases, I feel unbiased. 

  2. To be honest, I don’t even know what his opinion on this would be. I just think of him as the far-out open source radical. I bet he’d just think we’re all a bunch of sell outs. Which is cool, and maybe right. ;) 

Smart watches won't go mass market

Smart watches are the supposed trend du jour these days, except I don’t see anyone wearing them. Okay, that’s not completely true—my fellow geeks are all over them. So I guess I should say that I don’t see any normals wearing them.

At work we are examining at the viability of wearables for enterprise use. We’re testing several different versions of Android watches and the Pebble Steel. Several people are using them, and I had a Pebble Steel for a week and a half. The feedback is both positive and negative, but no one is overwhelmed by their potential for the enterprise.

I’m skeptical of smart watches, but I’m careful not to form opinions about products I have no experience with, so I participated in our tests. Going into the week and a half I had the following objections:

  1. I don’t like to wear watches. This is the biggest problem I have, and it’s one that I share with some, but certainly not most people
  2. I don’t see a functionality gap between what my phone currently offers and what a smart watch does. I have no perceived need for the device
  3. I am not persuaded that checking a smart watch every time it buzzes is less rude than checking a phone. After all, before phones the body language for ‘I’m not that interested in what you are saying’ was checking a watch

With those three biases in place, I wore the Steel for about 10 days. I wasn’t convinced.

All three concerns I outlined above were confirmed. Admittedly, these biases set me against it from the start, but I genuinely did not get enough value out of the watch to even consider buying it. I don’t think I’m alone, which is why I don’t think smart watches will be successful as mass market devices. The main arguments are well-worn:

The battery issue will be solved, but it’s not solved yet. I think the other two objections will probably always be valid. But those aren’t the real obstacle to adoption in my mind.

It comes down to one central question: what does a smart watch really offer in addition to what a phone does? Because all the major smart watches depend on phones, you will always have both with you to get the full value of the watch. So what does the watch bring to the table that is unique?

The thing that separates us geeks from the rest of the world is our love of the technology itself. Our fanboyism is rooted in a love for the devices themselves, and the tech inside. The rest of the world doesn’t look at technology this way. They look for utility, for specific added value. If a device does not fill a hole in their capabilities or create a new hole, by and large they are not interested.

A great example of this is how my father adopted the iPhone. When I bought one on launch day he was interested, he thought it was cool. He played with it a bit, but wasn’t compelled to get one. When his company started supporting email on it, he was more interested. Then when the app store launched, he pulled the trigger. The utility of the device finally matched his perceived needs.

Health and fitness trackers are the most successful wearables so far, because they offer functionality that is unique to their form factor and device type. A FitBit or Up has much greater utility than a smartphone app that measures the same things specifically because of the form factor. In real life a phone does not travel on your person every minute of the day, a wearable does. These products have a convincing answer to the question that matters.

Until these new watchmakers have their own compelling answer to that question, regular people will not adopt smart watches in large numbers.

→ Are we prepared for automation?

An automated world is closer than most of us realize.

This is the not Jetson’s future I was promised, but that’s okay. There is a problem though, as the video points out, in the economics.

When I talk about automation leading to efficiencies, I often frame it terms of freeing resources to do more interesting work. I still think that’s true, but this video offers a great rebuttal. There will be people doing more interesting and innovative work than before, but not enough to head off potentially disastrous levels of unemployment.

I really appreciate the summary though, because the automated future is not necessarily bad, but it will be if we are not prepared. As someone who is pursuing automation right now, I must admit we need to spend more time thinking about how to better handle the challenges that will result.

→ Is the App Store better than a minimum wage job?

Brent Simmons:

My city (Seattle) is in the process of raising its minimum wage to $15 an hour, which is about $30,000 for a full-time job. Many iOS indies would do better at minimum wage jobs here than on the App Store.

Ouch. If true, this is cold water on the dreams of many wannabe indie developers. And that’s too bad.

For software developers the dream of a one man dev shop, or at least a small team seems like nirvana. The problem is, nirvana may have a ‘no vacancy’ sign.