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. ;) 

→ 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.

→ Confessions of an ex-developer

If you attend an iOS/Mac dev meetup and hang around long enough, you’ll start to hear the whispers and the nervous laughter. There are people making merry in the midst of plenty, but each of them occasionally steps away to the edge of the room, straining to listen over the music, trying to hear the barbarians at the gates. There’s something wrong with the world, Neo.

Great read from Matt Gemmell. I’ve been in this spot and gone back to development, I get where he is coming from.

There is something on the horizon, although I don’t know exactly what it is. There are so many changes afoot in the development world and in the industry that I don’t think anyone can see very far down the road anymore. Developers have become a recognized asset in the broader world, yet it seems like there are lots of people who don’t want to let that stand. The next decade will be fascinating.

→ DevOps and ‘The Phoenix Project’

When a colleague handed me The Phoenix Project I was very skeptical. I’m a reader and a writer, and if I can be honest, I’m more snobby about it than I should be. I was skeptical of the book, but I read it.

I read it in one day. I really liked it.

It’s not great literature. The criticisms of the storytelling and writing in the reviews I’ve read are dead on. That’s okay by me though, that’s not the point of the book. Sure, in an ideal world the level of art would be higher and match the lofty ideals of IT presented here, but it didn’t, and I’m okay with that.

The book tells the story of an all-too-typical IT shop. Everyone is under pressure, well intended processes are ignored because they are too cumbersome, and IT can’t deliver critical features to the business. Our hero is thrown into a battlefield promotion, and must save the day. He learns DevOps from the ground up, by thinking it through (with a touch of help from an all-knowing operations zen master-type), without ever using the term.

If you want to learn about DevOps, and why everyone thinks it’s a big deal, read this. If you need to convince someone else that DevOps is a good idea, hand them this book. It’s not the best novel, but it gets its job done. Actually, all things considered, it does its job well.