dan's read list

Hi! Hello! There’s a good chance you followed me because you’re a creative person and interested in filmmaking and relatively young (maybe between 14-25?) and probably female. If any of that sounds like you, then I’m talking to you! (If you’re not any or all of those things, it’s cool, you can read this too if you want.)

So I don’t often speak up on issues of race in Hollywood because of various bullshit reasons, but I’ve had some white wine and it’s been a bit of a night/week/month/year so fuck it let’s get into it. 

In case you’ve missed the news, Asian Americans are horribly underrepresented in Hollywood right now. This is the kind of sentence that you read and you go, “yeah, that feels true” but you don’t really get until you play what I call the IMDB Starmeter* Game.

*A feature not everyone knows about on IMDB is Starmeter - where they keep a complete ranked list of the most popular celebrities in their database. I think anyone with an IMDB credit is in there, and it’s an algorithm based mostly on how many people are searching your name and maybe some other things. Actors tend to be ranked much higher than writers/directors/producers, which makes sense because you’re much more likely to see an episode of Community and go “hey, where else have I seen Asian Annie” than you are to think “hey who produced the last season of The Bachelor.” Anyway.

Here’s how you play Yulin’s IMDB Starmeter Game -

1. Open IMDB Starmeter. 2. Scroll down until you find an actor who looks like they could play you in the movie version of your life right now. 3. Have you reached the end of the page and no one is Asian yet? Click next page. 4. Have you found an Asian actress you remember from a movie franchise or a TV show from when you were younger? She’s too old now, she can’t play you anymore. Click next page. 5. Have you found an Asian actress who found success internationally but hasn’t starred in any English-language properties because of her accent? Click next page. 5. Keep scrolling. Click next page for 20+ pages. 6. Give up, you’ll be doing this all night.

The IMDB Starmeter Game is a lot easier if you aren’t an Asian American girl under 25. But you already knew that! 

This is getting long. Click “keep reading” below if you made it this far and you’re on board with more white wine rambling about Asian American representation in Hollywood! (My apologies to you, dear readers on mobile. How’s your thumb doing?)

While remaking my personal site I decided to use some cutting edge framework versions. One of them was bootstrap v4—with the intent to become familiar with some of the new features. Very soon after starting to implement design, I needed to be able to recompile it with changed variables. The effort I put into that process helped me understand the value of development environments, and what makes them useful.

Why do development environments matter?

As teams grow and contributors come and go, projects often require more processes to keep things moving. One of the processes I find useful to keep a project healthy is to have a simple and complete development environment.

By simple, I mean that a “junior” developer will usually be able to get their environment up and running on their own by simply reading documentation. By complete, I mean that developers are able to run and test all features and functionality.

Having an environment that is both simple and complete will lower the barrier to entry and encourage efficient development practices. To contrast, an environment that is not simple will keep “junior” developers from being able to contribute positively. An environment that is not complete reduces the amount of features and functionality that can be fixed, changed, or added and increases overhead for development.

So what happened with bootstrap?

Earlier this week, many npm users suffered a disruption when a package that many projects depend on — directly or indirectly — was unpublished by its author, as part of a dispute over a package name. The event generated a lot of attention and raised many concerns, because of the scale of disruption, the circumstances that led to this dispute, and the actions npm, Inc. took in response.

Here’s an explanation of what happened.

Timeline

In recent weeks, Azer Koçulu and Kik exchanged correspondence over the use of the module name kik. They weren’t able to come to an agreement. Last week, a representative of Kik contacted us to ask for help resolving the disagreement.

This hasn’t been the first time that members of the community have disagreed over a name. In a global namespace for unscoped modules, collisions are inevitable. npm has a package name dispute resolution policy for this reason. That policy encourages parties to attempt an amicable solution, and when one is impossible, articulates how we resolve the dispute.

The policy’s overarching goal is this: provide npm users with the package they expect. This covers spam, typo-squatting, misleading package names, and also more complicated cases such as this one. Entirely on this basis we concluded that the name ought to belong to Kik, and informed both parties.

So far, this followed a process that is routine, though rare. What happened next, though, was unprecedented.

Under our dispute policy, an existing package with a disputed name typically remains on the npm registry; the new owner of the name publishes their package with a breaking version number. Anyone using Azer’s existing kik package would have continued to find it.

In this case, though, without warning to developers of dependent projects, Azer unpublished his kik package and 272 other packages. One of those was left-pad. This impacted many thousands of projects. Shortly after 2:30 PM (Pacific Time) on Tuesday, March 22, we began observing hundreds of failures per minute, as dependent projects — and their dependents, and their dependents… — all failed when requesting the now-unpublished package.

Within ten minutes, Cameron Westlake stepped in and published a functionally identical version of left-pad. This was possible because left-pad is open source, and we allow anyone to use an abandoned package name as long as they don’t use the same version numbers.

Cameron’s left-pad was published as version 1.0.0, but we continued to observe many errors. This happened because a number of dependency chains, including babel and atom, were bringing it in via line-numbers, which explicitly requested 0.0.3.

We conferred with Cameron and took the unprecedented step of re-publishing the original 0.0.3. This required relying on a backup, since re-publishing isn’t otherwise possible. We announced this plan at 4:05 PM and completed the operation by 4:55 PM.

The duration of the disruption was 2.5 hours.

What worked

We stand by our package name dispute resolution policy, and the decision to which it led us.

Given two packages vying for the name kik, we believe that a substantial number of users who type npm install kik would be confused to receive code unrelated to the messaging app with over 200 million users.

The dispute resolution policy minimizes disruption.

Transferring ownership of a package’s name doesn’t remove current versions of the package. Dependents can still retrieve and install it. Nothing breaks.

Had Azer taken no action, Kik would have published a new version of kik and everyone depending upon Azer’s package could have continued to find it.

It was Azer’s abrupt unpublishing, not our resolution policy, that led to yesterday’s disruptions.

The community stepped in.

It’s pretty remarkable that Cameron stepped in to replace left-pad within ten minutes. The other 272 affected modules were adopted by others in the community in a similar time. They either re-published forks of the original modules or created “dummy” packages to prevent malicious publishing of modules under their names.

We’re grateful to everyone who stepped in. With their explicit permission, we are working with them to transfer these to npm’s direct control.

What didn’t work

Unrestricted un-publishing caused a lot of pain.

There are historical reasons for why it’s possible to un-publish a package from the npm registry. However, we’ve hit an inflection point in the size of the community and how critical npm has become to the Node and front-end development communities.

Abruptly removing a package disrupted many thousands of developers and threatened everyone’s trust in the foundation of open source software: that developers can rely and build upon one another’s work.

npm needs safeguards to keep anyone from causing so much disruption. If these had been in place yesterday, this post-mortem wouldn’t be necessary.

Poor communication made matters worse.

In the immediate wake of yesterday’s disruption, and continuing even now on blogs and Twitter, a lot of impassioned debate was based on falsehoods.

npm did not “steal” Azer’s code.

left-pad was open-source code, and explicitly allows republishing by any other author. That’s what happened in this case.

This incident did not arise because of intellectual property law.

We’re aware that Kik and Azer discussed the legal issues surrounding the “Kik” trademark, but that wasn’t pertinent. Our decision relied on our dispute resolution policy. It was solely an editorial choice, made in the best interests of the vast majority of npm’s users.

npm won’t suddenly take your package name.

Our guiding principle is to prevent confusion among npm users. In the rare event that another member of the community requests our help resolving a conflict, we work out a resolution by communicating with both sides. In the overwhelming majority of cases, these resolutions are amicable.

It took us too long to get you this update. If this were a purely technical operations outage, our internal processes would have been much more up to the challenge.

What happens next

There are technical and social aspects to this problem. Any reasonable course of action must address both of these.

We will make it harder to un-publish a version of a package if doing so would break other packages.

We are still fleshing out the technical details of how this will work. Like any registry change, we will of course take our time to consider and implement it with care.

We will make it harder to maliciously adopt an abandoned package name.

If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm support.

We are updating our internal policies to help our team stay in sync and address community conflict more effectively.

To Recap (tl;dr)

We dropped the ball in not protecting you from a disruption caused by unrestricted unpublishing. We’re addressing this with technical and policy changes.

npm’s well-established and documented dispute resolution policy was followed to the letter. This is not a legal dispute.

We’ll continue to do everything we can to reduce friction in the lives of JavaScript developers.