Hacker News Reader

Comment by JeremyBanks | Hacker News Reader

I like Wasmer, but I very much dislike the idea of another major package repository being owned and operated by a commercial entity. They seem like good people doing valuable work now, but that doesn't tell us very much about who the company will be in five or ten years.

I've grown uncomfortable with NPM being operated by NPM Inc instead of The Node.js Foundation, but it's a hard thing to change once it's established. We should hesitate to support the establishment of another community package manager by a for-profit company.

View on HN

I completely understand your concerns, especially given the issues that NPM had lately. We are an open-source focused company and our success is tightly tied to the success of our open-source solutions.

Here are some of the things that we are doing in order to resolve (or minimize) the concerns:

* Completely open API to retrieve the registry data (it's a work in progress, but our GraphQL API is open to everyone to use: https://registry.wapm.io/graphql )

* De-centralized hosting of the packages (news to come soon!)

Thanks! This is a good start.

Do you have ideas on how you will make the governance of the registry open? Who will make important decisions around policies, and how will they be made? I personally find this to be the core reason I find it hard to use startup-run package registries.

We are starting to research on governance, but to date nothing is defined (since we have just launched).

However, I would love to follow up with you personally to make sure we make the right choices from the start. Can you write me an email to syrus@wasmer.io so we continue the conversation there?

> our success is tightly tied to the success of our open-source solutions

It is not obvious from your website, so if your success is tied to your open source solutions - as you say - how do you actually make money?

> De-centralized hosting of the packages (news to come soon!)

Is the index also going to be changeable? Will I be able to completely avoid your servers if I wanted to?

> * De-centralized hosting of the packages (news to come soon!)

Given that "integration in package managers" is a big point in the IPFS 2019 Roadmap[0], I'm going to guess those two are related.

[0]: https://blog.ipfs.io/78-ipfs-2019-roadmap/

How are you going to make money? How are you going to fund offices in CA + developers + the operating costs of the registry?

I really don’t think a private entity should be running a registry. Ruby is just about the only example of a registry handled correctly - via the community and non-profits.

When I proposed package management for web assembly in 2015 I suggested that it should be a fully distributed system. https://github.com/WebAssembly/design/issues/320

It seems like whenever a new language pops up there's a race to build all the standard ecosystem tooling.

WASM should use something like GO where you can use any git/mercurial/bazaar repository to fetch the packages and 3rd party services(i.e godoc.org) to index them.

Not a good idea. Semver range on dependency plus lock file is the holy grail of dependency management (ask Maven people) and cannot be done with git (cvs) registries. You’re tied to pinned versions (lockfile) only.

Don't let the perfect be the enemy of the good. WASM is barely off the ground and already we have a company trying to establish itself as the authoritative package manager and registry host the way NPM has become for javascript.

It's more important to prevent centralization by demanding that there be no authority other than the end user, and by building tools to enforce those expectations, than to have a "holy grail" of dependency management be controlled by a single corporate interest.

I'd rather WAPM be built with their registry as a default option, but designed to be completely agnostic regarding registries or repositories. I'd like to use it and never have to touch their servers if I don't want to.

> Don't let the perfect be the enemy of the good

We’re not talking about good vs perfect. We’re talking about «a big ball of hairy non-compatible dependencies» vs «an upgradeable declarative definition of dependencies».

> I'd rather WAPM be built with their registry as a default option, but designed to be completely agnostic regarding registries or repositories.

That’s how npm works, yet you don‘t see git/vcs dependencies very often. That’s because they don’t work.

In fairness, the OP mentioned Go, but you're dropping details.

Ie, in Go it works just fine but it is more than just plain Git, there is a dependency file. Semver works with the repo itself based on repo tags.

I think you're not arguing against what the spirit of OPs post meant, aka the "like Go" part. Like Go does work, Go is using it and it includes a lock file just like you mentioned.

There are definitely downsides to using repos as dependency resolution hosts, but none of that in my view is what you mentioned. Lockfiles in repos are not complex or unsolvable, I'm not sure why you pit them as such - again, look at Go.

If you want to talk about why repos shouldn't be used, imo, talk about the volatility of them. A de/centralized host specially targeted at distributing source seems to have less volatility in existence when compared to git repos. It's rare to have packed disappear from Cargo (Rust's package manager), but I've had it happen multiple times in Go.

Agreed. I wonder why package managers can't follow Go's lead in re-using DNS system for packages and then offering a service that just indexes what is available.

Example indexing service: https://godoc.org/

Example package: https://godoc.org/go.uber.org/zap

Julia uses git and GitHub. This was a stroke of brilliance until microsoft bought GitHub. It still will probably be a clever decision, GitHub could be phased out in favor of another git site.

Yes, at least they could host it on IPFS or dat.

Reply on news.ycombinator.com