Ten years ago, on Memorial Day 2012, I authored JSON5, an open-source project that aimed to fix a small problem I felt when writing certain software.

I’d been chewing on the problem for a year when I decided to finally address it. I coded for roughly ten hours that day, then shared what I built to Hacker News (a forum for software engineers) that night. This was the response I got:

Even Mitchell Hashimoto, creator of an industry-changing open-source project himself (and eventually a billion-dollar company as well), piled on. But he went even further: Mitchell took the time to make a parody project of JSON5 (it was genuinely funny, at least 😛), even making fun of me by name. He’s since deleted the project, but the Internet Archive has it here:

This was especially fascinating to me given that Mitchell Hashimoto was a creator himself — a “man in the arena”, not a critic on the sideline — and yet he went to such depths to express his dislike for my project.

I wasn’t upset or offended by any of this. I was mainly just surprised and shell-shocked.

The problem I’d set out to solve seemed so clear. I’d even credited others who had written about this problem before. And yet so many comments disagreed with me that this problem was even real, much less worth solving.

Fortunately, I ignored these comments and just kept building. I got some traction, which attracted others. And with others’ (significant) contributions and leadership, JSON5 slowly flourished.

JSON5 now gets >60M downloads/week, ranks in the top 0.1% of the most depended-upon packages on npm1, and has been adopted by major projects like Chromium, Next.js, Babel, Retool, WebStorm, and more. All adoption has been entirely organic, with no company or marketing behind it.

My favorite example is that even Apple has adopted it now, supporting it natively across all their platforms! 🤯 (This means that every iPhone and Mac now ships with JSON5 built in!) I never even considered this to be a possibility and would have bet against it.

These results are in such stark contrast to the reception I originally got. So what gives?

I take three lessons from this experience that I’d love to share now, ten years later.

Lesson 1: Ignore the haters

This one is obvious. And I admit I enjoyed proving the haters wrong. 😛

But there’s nuance here, and some notable implications.

For starters, the reception I got wasn’t unique to me; it was standard for Hacker News and cliché across cynical communities. The canonical examples here are Drew Houston’s original Dropbox demo and Slashdot’s original iPod announcement:

But there’s something to be said about actually listening to feedback and criticism, right? And not just blindly building in a vacuum, ignoring the world around you?

The key difference to me is to know your audience/customer/market, and listen to them. Linux hackers weren’t Dropbox’s target market, nor the iPod’s. It turns out that all of the various software engineers on Hacker News weren’t my target market, either; specifically JavaScript engineers were.

So when I also shared JSON5 on the Node.js mailing list, the reception was notably more positive:

(Even Ryan Dahl, creator of Node.js, chimed in with praise… just two years later. 😂)

This was who mattered, so this feedback and validation kept me going.

This lesson applies broadly.

One of my all-time favorite articles on building startups is this one from Rahul Vohra, founder of Superhuman, on finding product-market fit. (It’s a brilliant article and I can’t recommend it enough; take the time to read it if it’s relevant to you.) Rahul’s advice is all about listening to customer feedback, and even so, he specifically says to ignore the feedback of users who find your product entirely unappealing:

This batch of… users should not impact your product strategy in any way. They’ll request distracting features, present ill-fitting use cases and probably be very vocal, all before they churn out and leave you with a mangled, muddled roadmap. As surprising or painful as it may seem, don’t act on their feedback — it will lead you astray on your quest for product/market fit.

[These users] are so far from loving you that they are essentially a lost cause.

Just remember to still make something that some people love. One way to do that, as Paul Graham writes, is to simply make something that you yourself would want and love. I got lucky in that regard with JSON5. 🙂

Lesson 2: Share your legos

I mentioned above that JSON5’s success owes in large part to others’ contributions and leadership. That wasn’t hyperbole — others really deserve much of the credit.

I’m grateful to Max Nanasy and Andrew Eisenberg for their significant contributions, and I’m especially grateful to Jordan Tucker, who took JSON5 to a whole new level. Jordan has contributed more code at this point than even me by an order of magnitude:

But what really keeps blowing me away isn’t the quantity of Jordan’s contributions — it’s the quality. Jordan elevated JSON5 from a little toy project to a truly professional-grade standard and ecosystem. He authored an actual formal spec, prototyped several more reference implementations, and even designed a beautiful vector logo:

Jordan’s also an amazing maintainer for the project. He consistently responds to every question, bug report, and contribution both more quickly and much better than I can. He thoroughly internalized the vision for the project, and he consistently upholds that vision and its principles. Most importantly, Jordan always represents the project — and speaks for the both of us — with an ideal combination of knowledgeable authority and kind empathy.

I can confidently say that JSON5’s adoption would be nowhere near what it is today if it weren’t for Jordan’s fantastic leadership and ownership.

So I don’t deserve all the credit, but I think I did at least two things right. 😛

1. I shipped early. Shipping less earlier allowed others to contribute more — and better than I could have myself.

2. I shared my legos. I truly gave up full and direct control, and this was what allowed JSON5 to flourish.

Sharing legos here didn’t come naturally or trivially to me. A lot of people wanted a lot of different things from JSON5, and I was pretty sure that the project would only succeed if it maintained focus. I felt responsibility to uphold that focus, so of course I should maintain control, right?

I was inspired here by this post from prolific open-source developer Felix Geisendörfer on a simple “collaboration hack”:

Whenever somebody sends you a pull request, give them commit access to your project.

This sounded crazy at first, but his reasoning and results were spot on. Like Felix, I was often too busy to review code and manage contributions in a timely manner. (I had a demanding day job, too!) And the most significant contributions often needed the most time to properly review and accept. So of course episodes like this happened, where I left a contributor hanging for nine months:

This case pushed me over the edge, and I decided to give Felix’s suggestion a try:

And just like Felix said, the results spoke for themselves.

Within a few hours the same person who had just submitted a rather mediocre patch, had now fixed things up and committed them. This was highly unusual, so I started using the same strategy for a few other small projects… And it worked, over and over again.

Initially I was very worried about giving up control over these projects, but the results speak for themselves. Both projects are now maintained by a bunch of amazing developers, writing much better code than I ever received in the form of pull requests before.

Felix explains this phenomenon much better I can, so I’ll just quote him here:

So why does it work? Well, I have a few ideas. Once people have commit access, they are no longer worried that their patch might go unmerged. They now have the power to commit it themselves, causing them to put much more work into it. Doing the actual commit/push also changes their sense of ownership. Instead of handing over a diff to somebody else, they are now part of the project, owning a small part of it.

Attracting great people you can trust and giving them true ownership is a powerful leadership lesson I’ve learned (on both sides) throughout my career.

A related leadership lesson is to inform and inspire. I love Netflix’s “context, not control” value and this advice derived from Antoine de Saint-Exupéry:

If you want to build a ship, don’t drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.

This is a topic I want to write more about on its own. For now, I’ll end this lesson by summarizing:

Give up control. Share your legos. Benefit from more Jordans. 🤩

Lesson 3: We’re all blind (so be kind)

The future is crazy hard to predict. That’s doubly so with new ideas.

When an idea is new, it’s not only difficult to know whether it’ll succeed — it’s also easy to assume that it won’t.

As Jony Ive said so eloquently in his eulogy for Steve Jobs:

You see, I think [Steve] better than anyone understood that while ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts — so easily missed, so easily compromised, so easily just squished.

I look back on Mitchell Hashimoto’s example as a fascinating case study here. Mitchell is and was an expert programmer and amazing technologist, and even he failed to see the value here. That makes sense in hindsight given that Mitchell’s background was more with Ruby and YAML than with JavaScript and JSON — but that’s the point. We’re all blind and touching different parts of the elephant.

Successful investors know this well. Paul Buchheit, creator of Gmail and partner at Y Combinator, made this point elegantly in a 2007 post: it’s easy to dismiss new ideas and be right most of the time — but if you want to be successful as an investor, it’s better to be optimistic and wrong most of the time (since the most successful ideas yield disproportionate returns). Hence, most successful investors approach new ideas with openness, curiosity, and humility, even if they ultimately reject them.

(An example of Paul’s success with this philosophy was Twitch, which is now one of the most popular sites on the web, but which started as Justin Kan simply streaming his life 24/7. Paul expanded on this example and others in his wonderful 2014 Startup School talk — highly recommend reading.)

But this isn’t just about our own self-interests — it’s also about the impact we have on others.

It’s taken me a long time to say this, but I believe that several of the initial responses I got crossed the line from disagreeing about an idea to being unkind. And this included Mitchell’s parody project — even though it was funny.

I feel fortunate and privileged that I wasn’t deterred. Due to whatever combination of nature and nurture I was brought up with, I maintained my conviction. But not everyone is so lucky or secure — and it’d be a shame to put those people down.

Heather Arthur, another open-source creator, wrote about her own experience being ridiculed for her work in this powerful post from 2013:

It seemed liked I’d done something fundamentally wrong, so stupid that it flabbergasts someone… So of course I start sobbing.

Then I see these people’s follower count, and I sob harder.

Heather fortunately turned out okay, as did I. But she had the same thought:

I evangelize open source whenever I meet new coders or go to meetups. I tell them to make something that they would find useful and put it out there. Can you imagine if one of these new open sourcerers took my advice and got this response without the support I had? Can you imagine?

I reached out to Mitchell as part of writing this post (my first ever interaction directly with him) to let him know I’d be referencing his project. Given that he deleted it some time ago, I assumed he regretted it in retrospect, and I harbored no grudge or ill will towards him. We all make mistakes and do things we’re not proud of sometimes.

Mitchell confirmed this assumption to be true and offered a genuine, sincere apology. Thank you, Mitchell — I appreciated that a lot. ❤️

Learn from Mitchell’s example, and Corey Haines’ and Steve Klabnik’s in Heather’s case. Be aware of the impact of your words and actions, and (especially if you have standing in your community) lift others up rather than push them down.

Let me end with two closing quotes from Ratatouille (god I love this scene):

The world is often unkind to new talent, new creations. The new needs friends.

Not everyone can become a great artist; but a great artist can come from anywhere.

And this one from Ted Lasso (not Walt Whitman 😛):

Be curious, not judgmental.

Great ideas can come from anyone, and we’re all blind — so let’s be kind.