Harper Turns 1.0 Today

Today, we pub­lished Harper’s 1.0.0 re­lease. It’s a huge mile­stone, and in this post I’d like to dis­cuss why it took so long, why we’re do­ing it now, and what’s next for the pro­ject.

A Round of Applause, Please

As I men­tioned: This is a huge step for the pro­ject. Before I say any­thing else, I want to take a mo­ment to ap­pre­ci­ate the col­lec­tive work of our many con­trib­u­tors. It has taken many it­er­a­tions to get to where we are to­day, and it would­n’t be pos­si­ble with­out the com­mu­ni­ty’s ef­fort and feed­back.

Why Now?

Until to­day, I’ve kept Harper in a pre-1.0 state for one rea­son: I wanted to move fast. More specif­i­cally, I wanted the free­dom to build and break things as many times as I needed to. I knew that it would take many cy­cles of build­ing and re­build­ing ar­rive at a ro­bust sys­tem that ad­dresses the peo­ple’s need for a pri­vate writ­ing tool. I be­lieve that build­ing some­thing good can of­ten mean tak­ing the bad parts out. Once a pro­ject is “1.0”, it be­comes much harder to re­move things. Naturally, that pushed me to hold off on “going 1.0″.

Of course, that did­n’t stop us from get­ting the soft­ware into the hands of users. Today, tens of thou­sands of peo­ple ben­e­fit from Harper’s fast and pri­vate gram­mar check­ing in Chrome, Obsidian, VS Code, and Neovim (among many oth­ers). We’ve racked up hun­dreds of thou­sands of down­loads be­fore ever slap­ping any­thing other than zero be­fore the first dec­i­mal point of our ver­sion num­ber.

I’m sure your think­ing: “Elijah! Get to the point!” Fine. The rea­son we’re do­ing this now, rather than ear­lier or later, is be­cause our pri­or­i­ties have just re­cently changed.

For one, Harper’s API has been rock-solid for a few months now, which means we can safely say that our need to move fast in that area has di­min­ished. The op­por­tu­nity cost of abid­ing by a sta­ble API has gone down.

Secondly, I’ve been hear­ing pro­gres­sively more in­ter­est from po­ten­tial con­trib­u­tors and con­sumers who want to put Harper di­rectly into their own apps or ser­vices. They have the de­sire to help make Harper more wide­spread, but they can’t com­mit to it un­less Harper com­mits to a sta­ble API. That’s what we’re do­ing to­day.

I can imag­ine a fu­ture where Harper is na­tively in­te­grated every­where: learn­ing man­age­ment sys­tems, doc­u­ment ed­i­tors, mes­sag­ing plat­forms, or even op­er­at­ing sys­tems. But great things take time. Today, we’re tak­ing a huge step in set­ting Harper up for the long-term.

What Do I Need to Know?

As an end-user, not much changes. From here on out, we’ll be push­ing qual­ity-of-life tweaks and bug­fixes at a faster rate, all while im­prov­ing Harper’s ca­pa­bil­i­ties across the board.

As a con­trib­u­tor, the patch re­view process might get a lit­tle bit more strict. We’ll be fo­cus­ing more on im­prov­ing the qual­ity of our code, rather than the amount. If your PRs are likely to re­sult in a break­ing change, ex­pect co­pi­ous notes and pos­si­ble de­lays be­fore we hit “merge”.

As an in­te­gra­tor, you win more than any­one. If you’d like to in­clude Harper in your ap­pli­ca­tion, let us know and we’ll do our best to make it easy for you. Take a look at our ver­sion­ing pol­icy if that sort of thing gives you peace of mind.

Where Can I Get Further Updates?

That de­pends on the level of ver­bosity your in­ter­ested in. For those who want to know about every­thing I’m cur­rently work­ing, sub­scribe to my blog. For every­one else, our patch notes in GitHub should suf­fice.