Meet Jordan Harband: he currently maintains more than 200 npm packages.
Jordan’s foray into the world of open source began serendipitously. His first job was as a social worker in a group home, but he soon realized it wasn’t possible to raise a family in the Bay Area on a social worker’s salary.
So he switched gears and focused on his other passion, which was programming, and used those skills to help start a company called MixMatchMusic in 2006 out of the CEO’s family garage. It was originally a music collaboration and remixing community, then morphed into a phone app.
How to become a maintainer
Though MixMatchMusic was moderately successful, it never totally took off, so he started working as an engineer at a company called BrightKite in 2010. That’s when he submitted his first pull request to fix a bug in a jQuery plugin, and his work as a maintainer began.
“Over time I would fix bugs and things,” Jordan said, “and a lot of maintainers will be like, ‘Here, you do it,’ and I’d take over a project, because the maintainer wanted help.”
His maintainer portfolio grew slowly over time. One of the more popular packages he maintains is called es5-shim, which offers ECMAScript 5 compatibility polyfills for legacy JavaScript engines, like Internet Explorer 9. Jordan’s work as a maintainer cinched him an invitation to ECMA International's TC39, which is a group of experts who collaborate with the community to maintain and evolve the definition of JavaScript. He’s now a member of the group and an editor of the specification.
Maintaining polyfills
Many of Jordan’s packages are JavaScript polyfills, which are pieces of code used to provide modern functionality on older browsers that do not natively support it.
“Once a polyfill is fixed and working you don’t have to touch it much,” Jordan said. “With polyfills, I don’t need to entertain feature requests.”
A systematic approach to maintenance
For the projects he maintains that aren’t polyfills, like a query string parser called qs, he fields many feature requests because everyone has a certain format that they would like to work. In cases like these, Jordan has a systematic approach to maintenance, which helps him keep his code healthy.
“There’s an art to envisioning in advance which abstractions are going to scale to more use cases and require less breaking changes,” Jordan said.
Besides filtering feature requests, Jordan tries to support a wide range of compatibility. This means for something like his qs project, he applies any new changes to almost every older release stream.
“My philosophy is to make it as easy as possible to upgrade to the newest versions of their dependencies,” Jordan said. “I don’t want my stuff to ever be the reason something is harder for people to upgrade. The slightly increased maintenance cost on small packages is really worth the objectively larger amount of pain that will be caused to other people if I don’t do that.”
The more dependencies the better
He’s also a firm believer in small, single-purpose modules, which is sometimes a controversial viewpoint.
“I think strong, separate modules, with more dependencies are better,” Jordan said. “It’s not overkill to make a separate one- or two-liner.”
Jordan cites the left-pad debacle as an example. Quick refresher: in 2016, a maintainer unpublished all of his 200-plus modules from npm, which resulted in millions of broken builds and failed installations.
A lot of people thought it was overkill to make a separate package for a functionality left-pad provided. However, because of Jordan’s work on the padStart proposal for TC39, he had found bugs in every potential left-pad replacement he’d found online.
“But if you write an independent module, and you do it well,” Jordan said, “you’re gonna test all possible inputs to your function and therefore if someone uses it in a way you don’t intend, you cover it. You can’t misuse it.”
Jordan’s process for writing quality code includes writing thorough tests, having lots of people review it, and getting lots of people using it. These processes make it possible for Jordan to maintain as many packages as he does, and feel confident that most of his modules will remain bug-free.
And if there’s a bug, he said, he’ll fix it. But he’s confident there won’t be many bugs.
--
Jordan Harband maintains his many JavaScript packages through the Tidelift Subscription, providing commercial support and maintenance for es5-shim, eslint-plugin-react, object-keys, qs, resolve, is-callable, define-properties, and more. If you’re interested in learning more about the benefits of managed open source, check out the 451 Research Pathfinder Report: Managed open source.
Image courtesy of Edgar Chaparro on Unsplash
Top comments (2)
Great!, thanks for sharing the story. Should be a series (if it’s not already) 👍
Ooh, thank you for the suggestion! We've actually written up a few other maintainer interviews; I need to post the rest to dev.to. You can find them here for now 😊 blog.tidelift.com/tag/lifter-inter...