IsaacSchlueter

Indeed!

In general, it is an extremely efficient response. It took a huge number of users all hammering on the same set of 404 handling routes to get our attention, and we were able to handle the load, though it wasn't trivial to do so. The end user impact was minimal.

If it hadn't been a known-good actor, we had some options to shut down the flood a bit more forcefully, but we didn't want to inadvertently cause errors for vscode users. Like my colleagues have said in this thread already, we really dig what VSCode is doing, and as operational fires go, this one got put out very swiftly and did very little harm.

All that being said, knowing the npm devops team, this will no doubt be a source of insights for making the registry even more resilient in the future :)

https://docs.npmjs.com/misc/config

As far as "big sites", several are starting to roll out io.js deployments. Most places don't blog about every upgrade to every internal piece of infrastructure. If you're doing the SOA thing properly, you can start rolling out io.js for new services without removing the versions of node used for other stuff.

At npm, we have some io.js, lots of node 0.10, erlang, java, spidermonkey, python, redis, postgres, etc. It's pretty common to use different stuff side by side in little servers that talk to one another. Less dramatic to talk about than pretending your'e gonna make some big switch-over though.

You don't see many people using `node.http.cat()` any more, for example. And yet the community survived ;)

Why is it a surprise that the people making these privacy tools were motivated by a desire for communication free of the chilling effects of violence?

What's going on in the pattern described is that you're getting a `BazWidget1` object from the `foo` module. Then, you're passing that object you got from `foo` into `bar`, which passes it to `Baz2Flummox(BazWidget2 widget)`.

Why are you flummoxing widgets that you don't know the origin of?

What kind of program needs to mutate state on a object, by passing it from one object-mutator to another? Why do you not have clearly defined ownership of objects, and clearly defined functions that take arguments and return values?

"Inappropriate Intimacy" is a code smell where one class is delving into the inner workings of another, depending on things that ought to be private. The `BazWidget` should be a private implementation detail of `foo` and `bar`, but instead, we are passing this implementation detail from one function call to another.

More specifically, we have `BazWidget1` and `BazWidget2` objects being used interchangeably. It's tempting to blame this on the package manager or module system, but it is just a badly designed program.

This is one class of errors that a "strongly" typed language can often detect and prevent at design time. However, I've seen C++ and Java programs with the same problematic antipattern, just with more layers of Interface wrapping. And, whatever, JavaScript is what it is, and is not "strongly" typed. It lets you pass any value as any argument to any function, and leaves it up to the callee to decide what to do with it.

Personally, I have no strongly held opinion about who's best to handle this responsibility: the compiler, the caller, or the callee. There are benefits to "loosely" typed languages as well, and I'd rather not make this about that.

I've referred to this sort of thing as a "gumby baton". You're passing an object from one worker to another, and each one mutates it a little bit, like runners in a relay race where the baton is made of clay, so it gets the finger print of each worker in turn.

This is a terrible antipattern! This is how we end up with middleware depending on other middleware having been executed in exactly the right order. It is terrible for reasoning about program behavior, and results in unexpected behavior when workers are combined in novel ways. Making programs harder to reason about makes security virtually impossible, and increases the cost of maintenance and re-use. Even up front, it is a challenging pattern to use in building an application, though it sounds appealing in principle if you've never been handed a warped and mangled baton.

So, when I say "Doc, it hurts when I do this", I'm implying that the proper response is "Don't do that".

Ultimately, it's not the compiler's fault. Gumby batons exist in C++ and Java and C and are even possible in pure functional languages. Be on the lookout for it. The compiler won't protect you. The module system won't protect you. You have to use your human brain.

Another caveat just to avoid any "tu quoque" responses: I've made this mistake (and sworn to never do it again!) many times. The most egregious offender in Node is mutating the req and res objects. But, it can be very subtle and hard to spot in the initial design. We just fixed a bunch of really subtle bugs in the lockfile module by changing how it was handling the options object, because it had taken on a gumby-baton behavior internally.

What you're describing is an inappropriate intimacy antipattern.

We do not believe that our commitment to equality, inclusivity, and diversity constitutes a "politically charged environment".

Nevertheless, please feel free to not apply to this job if you worry that your politics would not be a good fit with the culture at npm.

I remain hopeful that we will manage to survive without your valuable contribution.

Thanks.

--

Isaac Z. Schlueter, President and CEO, npm, Inc.

I'm guessing that you've seen it, too. Probably you didn't notice it, because it wasn't directed at you, and everyone in the room was also pretending it didn't happen.

They were extremely easy to work with, and very fast about getting stuff to us and verifying when it was fixed, and I felt like we definitely got more than our money's worth.

A+, would recommend, will hire again.

You're seeing a small piece of a conversation taken out of context. Also, they filed the trademark the day before that letter was sent, so it could not have been "in response"

I didn't delete your comment. I'll look at the moderation queue and see if maybe disqus is set to auto-hide after some time or something. I'm sorry for the confusion there.

I did tell Charlie in November about my intent to take over the registry in Q1 of 2014, if it proved economically feasible. The raise helped accomplish that, for sure, but so did a massive restructuring that means it requires much less resources.

Say what?

The Nodejitsu replica is a downstream replica, not a failover. Very different. 100% of `registry.npmjs.org` traffic goes to npm, Inc infrastructure.

> The cynicism in this thread is so bizarre to me.

Welcome to Hacker News. I see it's your first time here. :)

> Everyone go write modules and share them and be happy

Couldn't agree more.

In general, hiding email addresses doesn't usually make the job of harvesters appreciably harder, and does make the life of genuine users a bit more painful.

We'll probably start hiding email addresses altogether once we have a messaging system so that it's still easy for npm users to contact one another when they need to. Until then, I'd accept a patch to do the standard silly "hiding" thing with some JS that shows it on the page.

1. Backwards compatibility, as you mention. We do plan on re-evaluating and seeing what client changes would allow us to do this more efficiently, but there's a big time lag on rolling out a new npm and people actually adopting it. It's safe to say that someone out there will still be using the current release in 2 years or so, so if we can keep it working, then that's a friendly thing to do.

2. If the Skim Worker daemon falls over, the attachments are still going somewhere, and we can always have it catch up later. Apart from disasters, it also means we can treat this daemon a bit roughly. If we change a config or spin up a new one, or otherwise mess with it, no biggie.

3. In the race where you publish, and then someone fetches it right away, before the Skim Worker gets to it, the Fastly configs can detect the 404 and pull it out of the DB directly.

4. If Manta ever goes down, the skimworker will start failing (and pinging nagios, of course) and if need be, we can have the binary GETs go first to FullfatDB and subsequently to SkimDB. That Fastly config change takes about 30s to roll out, so we can mitigate downtime very quickly.

Eventually, we'll probably restructure the PUT endpoints so that it's a bit more clever, but still maintain backwards compatibility in our public API surface.

People outside a team rarely have much insight into the day to day relationships. That's just how it works. That's what a "team" is.

"Libel"? What did Bryan write that was a false statement? There were some unkind judgements, but I didn't see any factually untrue statements in it.

If not, then as it turns out, your claim that Bryan committed libel is itself libel, as it impugns his character by promoting a falsehood (ie, that he committed libel).

Don't use words you don't understand.

If "make money" ever appears to be in conflict with the thing that puts us in a position to make money, then we're thinking about it wrong.

For example, imagine if Twitter were not from the get-go a for-profit company. If they got really popular, and then said, "Hey, guys, we can't keep the lights on without figuring how a monetization strategy, so we're gonna take some VC and do that." It wouldn't be wise to assume that "make money" was going to mean "charge to read or post tweets". Forget love or greed or good and evil, that wouldn't be a smart way to make money.

What is currently free will remain free, precisely because the free-ness of it is what makes npm interesting.

Bottom line, I've done a lot of work on npm over the last 4 years, and I've got some ideas about how to best take care of it in the future. Those ideas require money, and it's a lot easier to get money if you have a plan to turn it into MORE money. (This IS still a site about startups, right? ;)

If things keep expanding and growing like they have, then it's going to require more money. So, we've gotta earn our keep to be sustainable, and the way to do that is to provide stuff people will pay for.

Also, I like to make money. It's fun, and it keeps you grounded in reality, if you run it like a responsible business. So that's another nice plus of going this route. I still have full flexibility to carve things up however I want later on, and like I said, we're keeping every option on the table.

The tricky thing is that, while there ARE some VCs that back them, most of them are pretty interested in bigger plays than "sharing javascript programs with other javascript programmers".

Disconnect is a pretty revolutionary idea, that will change society in some dramatic ways if it catches on. Most VCs that invest in benefit corps are looking for bigger plays than what we're doing. This is a pretty straightforward technology service that already has loads of adoption and upward-trending engagement graphs. It was just a lot easier to go the more traditional C Corp route first.

Well, that depends on your shareholders.

Mozilla Corp can do this, because its only shareholder is Mozilla Foundation.

However, the minute you take institutional investment, hand out shares to employees, take on debt financing, etc., you are now bound by a fiduciary duty to do right by those other parties. You still can focus on other things, but only if they don't conflict with turning a profit.

In my opinion, "turning a profit" in fact serves the greater needs of the npm/node community, because servers cost money. npm isn't just a program, it's a service, and services require infrastructure. So, it's not a conflict at all.

It is a very foolish business person who sees an exponential curve of user engagement, and decides that the best way to make money is to screw all those people.

The money you gave to Nodejitsu to continue supporting npm was a huge part of getting us in front of the exponential growth curve. I'll continue to be closely involved with Nodejitsu.

But a service of npm's scale and importance can't survive on handouts forever. At some point, we need much more continued investment and a focused team, and the way to get that is to develop additional features that people are willing to pay for.

> There's simply too much money going around Node at the moment and while it might eventually be a good thing (as involved companies will push node adoption among devs), it's also scaring and quite weird.

Yes, there is the hazard of extrinsic motivation messing up intrinsic motivations. That's why pursuing revenue around npm must be done carefully.

A good leader makes themselves obsolete by taking the community somewhere new. A bad leader gets themselves into a problem they can't fix. Either way, occasional change is good and healthy :)

I don't feel strongly (as some do) that non-profits guarantee benevolence. There are many evil non-profits (and many more incompetent ones!) which do harm to the world, and many capital-G Good for-profit companies. In many cases, a non-profit can easily become an empty hand-wavey thing. (And in that case, what's the real difference, except $800/year to the state of California?)

Of course, it has worked out well in some cases. Mozilla and WordPress are great examples of this sort of thing functioning really well to facilitate the interaction between a company and an open source community. But it is very early to even be worrying about such things.

In any event, even if we do create a non-profit, the first step is to create a Delaware C as a for-profit company to generate the money that can allow us to create new products, spin up new infrastructure when necessary, and employ people to run the thing. So that's what I'm up to these days. npm has gotten too big to be just some dude's hobby project :)

And it had about as much to do with this announcement as Ben's departure from Node last year.