Customer Convos #2: Karen Shea, Mapbox

This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.

Q. Hi! Can you state your name and what you do?

A. I’m Karen, I’m an engineer at Mapbox on the Directions team; directions as in, routing, a to b, take me home and give me an eta! (read more here).

How’s your day going?

Umm… I’m on a bus headed up to New York for a few days, so, great!

Tell me the story of npm at your company. What specific problem did you have that private packages and orgs solved?

Mapbox adopted Node.js as the base of a lot of projects early on, so npm has always been important to publishing and deployment, but there are also private, usually security-related tools that need to end up on the same servers as product code that we can’t publish to npm.

We had developed internal infrastructure for publishing and distributing these private modules, but having them available through npm the same way as public modules is much more convenient because of semver support and less overhead to onboard new team members, i.e., new people only have to learn npm (or not, if they were already familiar!) rather than npm and our internal system.

Can you tell us a story about a specific package you wanted to make that private packages really enabled you to do?

Hmm, nothing too interesting here since we’d gotten by OK with our pre-private orgs internal system.

Does your company do open source? How do you negotiate what you keep private and public? (Feel free to be as vague as you need to be)

Open source has been a core Mapbox engineering value since the beginning (like, small Drupalshop beginning). We consider it an asset to contribute to FOSS communities and benefit from community contributions. In addition to maintaining some 600 open repos under the Mapbox GitHub account, we sponsor a few other big open source projects that are very important in the GIS space, like leaflet, libosmium, and OSRM (Open Source Routing Machine).

Our general rule of thumb is to work in the open from the get-go because it’s easier to keep a project open than it is to later open a closed project. However, sometimes in the interest of time, security, or bizness we develop projects privately, too.

To people who are unsure what they could use private packages for, how would you explain the use case?

Security, for platform infrastructure and user privacy, but with the convenience of open project management. Sharing source code for a cool shader is one thing, sharing a project that is a wrapper around cloud provider account access is another.

How’s it going? How’s the day-to-day experience of using private packages/orgs?

Once we got internal docs written on how to get people using them it’s been a smooth ride.

Would you recommend that another org or company use private packages or orgs? Why?

I would, as long as they also try and maintain open packages as well!

Any cool npm stuff your company has done publicly that you’d like to promote?

Haha, I’ll plug the project I’m working on… We’ve put a lot of work into making Node bindings for OSRM easily available on npm, so anyone can use a routing engine written in cpp without worrying about finicky build systems!