Today was the day Meteor went public and I haven’t been so excited by a web framework since Rails. As I’m writing this, the Hacker News announcement has scored 1126 points. A friend mailed me about it this morning (he’s never informed me about a new web framework before), I told a colleague via IM and, just as I was doing so, he overheard another conversation in the office as one guy said “Have you heard about the new Meteor framework?”. There’s clearly a lot of buzz. I expect a lot will be published in the next few days discussing the technical merits or pitfalls of Meteor and I’ve barely even played with it yet so I’m not going to cover that topic in much detail here. What fascinates me though is how the project managed to conjure such a wave of enthusiasm and that’s going to be the subject of this post.
Now, Meteor isn’t the only web framework news item this week. Yesod, “a Haskell web framework for productive development of type-safe, RESTful, high performance web applications”, 1.0 was also announced on Monday. From my searches, it appears to be highest scoring web framework announcement in 12 months, yet it only made 141 points on Hacker News. So what’s the difference? There are a lot of web frameworks, so why did Meteor stand out? It comes down to the age old tried-and-tested formula used by any product which manages to break through in a crowded market: one killer feature plus great marketing. We’ve seen it succeed in great products such as the iPod and great services such as Heroku but it’s surprisingly rare to see it in open source projects.
I said I wouldn’t delve much into the technical details but I think it’s worth just clarifying what Meteor’s killer feature actually is. There are 9 points listed on the home page but one thing stands out as particularly fascinating and unique. It’s how it completely blurs the distinction between client and server and does so from the client’s point-of-view.
What’s also interesting is that while Meteor has a killer feature, it currently lacks some pretty basic essential ones! Security is non-existant, it can’t serve static contant, it’s Mongo-only etc. Yet Meteor 0.3.2 is a fine example of what the Lean Startup crowd would call a Minimum Viable Product. So long as you can kind of write a webapp and Meteor really does deliver on this new and awesome data synchronization with “latency compensation”, people will come flocking.
As killer features go, I think it’s a pretty good one. But then again, almost every web framework had some killer feature in mind in the first place otherwise their authors wouldn’t have been motivated to write them. A lot of frameworks, mind you, don’t do anything more unique than to port existing ideas into a new language. (The aforementioned Yesod smells a little of this but shoot me if I’m wrong as I’ve never even tried it.) Many frameworks, libraries and tools of all kinds though really do possess some killer feature yet still they languish in the graveyard of GitHub. That’s because for a project, or indeed a product of any kind, it takes more to gain traction than just being good at something.
When I first looked at the Meteor site today, I had a flashback to 2005. A tingly feeling inside, my head started nodding, and a bit of my brain telling the rest of me “This is going to do exactly what you want.” And I hadn’t even read the front page properly yet. What’s that all about? Marketing, pure and simple.
Thanks to the magicians at the Wayback Machine, we can go back to 2005 and see how the Rails site looked just after its public release. Sure, the flow diagram looks a bit garish nowadays, but all the elements which got us going in the first place are still there and if we compare it alongside the Meteor page, we see the old formula still holds true. First, a bold statement about what it is (check), then comes the killer feature - for Rails it was Convention over Configuration and Don’t Repeat Yourself - (check), then a screencast (check), then more features (check). The only significant difference with the Meteor page, aside from looking a lot more fashionable, is that it places greater emphasis on contacts and getting involved. It’s a crying shame that in seven years (I seem to remember the look of the Rails site being something of a revolution at the time) there aren’t a lot more open source projects adopting this strategy. It’s easy, mind, to overlook the importance of design and Meteor’s done a wonderful job for which they should be heartily commended.
The goodness doesn’t stop at the front page, and I think the following could be used almost as a recipe for creating great project sites:
- Provide multiple, simple examples. Most project provide a single example, perhaps intentionally to make it appear more simple, but the concept becomes much more potent when there’s an example fairly close to your use case. Meteor has roughly one example per use case and I can pick the one which is closest to the project I’m planning on using it for.
- Low barrier to adoption. Everything’s a one-liner. Installing, running, testing, getting examples etc. This tells me that I’m going to waste at most 2 minutes if I try out the project and it’s a dud.
- Talk to users. Following the Hacker News post, the Meteor developers were busy answering comments. While chatting on IRC. While providing answers on Stack Overflow. Users prefer to discuss on different channels. The whole Meteor team had a busy day covering all of them.
- Provide great documentation from the start. There’s never time to write the documentation later so the only way it to build it up as you go along. Meteor has all the technical documentation on a single page with a navigation menu down the side so I can print it, use Ctrl-F to find keywords etc.
All this has a profound effect on our first impression of the project. We’re so used to investigating new projects that most of us probably only spend a minute or two before we have a feeling for whether the project is a good one or just another reject. We have different ways of making that assessment which is why it’s important to try to cover as many bases as possible. What happens if our main criteria are fulfilled (particularly if they are done so exceedingly well), is that we become convinced that this is a “good” project. These guys know what they’re doing. Whatever shortcoming there may be, they’ll fix it. We’re sold.
If you’re hacking on a project which you think will be the next best thing, and getting traction and more people involved is important to you, I urge you to take a couple of leaves from Meteor’s book. You must have your killer feature in place before anyone’s going to take notice, but as little of the rest that you can actually get away with. When you’re ready, make sure you have the documentation, examples, screencasts in place and make it blindingly simple to get startet. Next, tell the world!