What exactly does "community owned" mean?

[isaacs]

This is an interesting project. One thing sticks out to me in some of your documentation and the https://liberapay.com/Open-Registry-Community page, where you say that this registry is/will be "community owned".

Like, that sounds great, but I'm really confused about, just pragmatically, what that actually entails.

• What determines who is in/out of the "community"?
• What does "ownership" entitle one to?
• If it's actually "owned" by a 501(c)3, have you given thought to the ways that you'll justify the Public Benefit requirements of such an institution? (I am guessing that you're in EU, I'm not sure how it's different than how this would work in the US. It's a hurdle, but probably not an insurmountable one.)
• If it's actually "owned" by a 501(c)6 (or equivalent), isn't that just "owned by a bunch of companies" rather than "owned by one company"? Ie, how do you intend to ensure that the membership of the foundation properly reflects "the community" as you envision it?
• Is the community on the hook for server and bandwidth bills? How will this be taxed? I explored funding the npm public registry via donations back in 2013, and it's roughly 10000x as big a problem now as it was then.
• Have you given any thought to resolution of disputes between parties? For example, someone posts a package name that's offensive to some group of people, but the package is useful to some other group of people (who are not offended by the name). Who has the final say in those kinds of conflicts? (This is especially relevant where it concerns spam and malware. If it's "community owned", then people have a right to free speech, right? At what point does that get limited in favor of others' freedom from harm?)
• What's the story on publishing? It looks like it's still only a downstream proxy?

I'm happy to chat about this stuff and provide you with the benefits of hindsight as much as I can. There are a lot of devils in these details, and I'm unfortunately quite acquainted with many of them :)

Good luck!

[olingern]

Just a passerby giving his two cents.

What determines who is in/out of the "community"?

I think this is something that would take shape down the road if the project was to get traction. Not unlike the TC39, but probably less stringent. If the licensing is correctly figured out, I think this isn't essential in the initial phase(s).

Is the community on the hook for server and bandwidth bills? How will this be taxed? I explored funding the npm public registry via donations back in 2013, and it's roughly 10000x as big a problem now as it was then.

I would love to see tech giants that depend on Javascript to contribute back to the community in a bandwidth sort of way ( Google, Microsoft, Amazon, npm, etc. ). If they're running they're businesses on open source Javascript, they could shell out a mirror or two. Of course, mirrors probably open another can of security worms. Also, I think Yarn owes a lot of its success to having so many devs at tech giants back it, so I think something similar would help momentum. Mind you, setting up a proxy, mirror fallbacks, etc. would be no small undertaking.

Have you given any thought to resolution of disputes between parties? For example, someone posts a package name that's offensive to some group of people, but the package is useful to some other group of people (who are not offended by the name). Who has the final say in those kinds of conflicts? (This is especially relevant where it concerns spam and malware. If it's "community owned", then people have a right to free speech, right? At what point does that get limited in favor of others' freedom from harm?)

Worthwhile question when there's momentum behind the project and packages actively being posted. My vote would be community mods who could flag packages and admins who would get the final takedown say. Maybe like StackOverflow, but with an admin safeguard to prevent nonsensical mod decisions.

What's the story on publishing? It looks like it's still only a downstream proxy?

+1 to this question. I'm curious, too.

[drewfish]

Mind you, setting up a proxy, mirror fallbacks, etc. would be no small undertaking.

There might be some financial undertaking. I'm hoping that setting up the servers/VMs ideally doesn't take too much dev effort. An npm registry isn't really all that complicated, especially if it's read-only (no publishes).

[victorb]

Hey @isaacs, thanks a lot for stopping by, means a lot.

First of all, thanks for creating npm!

I just wrote down the current state of how finance is organized, and what I see as possible ways forward from the "not enough" solution there is today. Here is my quick answers to your questions, and I'll link to issues with more information where possible.

What determines who is in/out of the "community"?

It is currently setup as described in the bylaws. Short version, everyone who contributes anything is a "contributor", "member" is a contributor who has been voted for and "leadership" is team of people with final say if there is no way of reaching consensus and represents Open-Registry.

The full bylaws are here: https://docs.open-registry.dev/governance

What does "ownership" entitle one to?

Deciding the direction of the project, resolving conflicts where no consensus is found and being legally responsible.

In general, as Open-Registry was just created, there isn't a lot of current common practice, I expect us to develop this while we move forward. The bylaws of today will most certainly not be the same as the bylaws of tomorrow, as the needs of the project changes. Ownership is something that should be added more clearly to the governance.

I think @olingern is spot on here, in that this will have to shaped as we move forward. Right now the basics are written down in the governance but obviously it's not perfect.

I opened a issue specifically about ownership here: #21

If it's actually "owned" by a 501(c)3, have you given thought to the ways that you'll justify the Public Benefit requirements of such an institution? (I am guessing that you're in EU, I'm not sure how it's different than how this would work in the US. It's a hurdle, but probably not an insurmountable one.)

Right now it's not owned by a 501(c)3 and I just wrote down how things look right now regarding financing, what the options are and what I think is the best way forward. See #20

If it's actually "owned" by a 501(c)6 (or equivalent), isn't that just "owned by a bunch of companies" rather than "owned by one company"? Ie, how do you intend to ensure that the membership of the foundation properly reflects "the community" as you envision it?

In general, I would not be happy with a solution that requires any companies to own the project. In general in Europe, non-profits are operated by a group of individuals with a common goal, not by companies.

But there is bunch of other ways we can move forward that should be considered as well, such as joining another foundations instead of creating one from scratch.

Opened a issue about it here: #20

Is the community on the hook for server and bandwidth bills? How will this be taxed? I explored funding the npm public registry via donations back in 2013, and it's roughly 10000x as big a problem now as it was then.

Yes, everything goes via the Open-Registry financess and will be public once everything is there to support it being public (meaning, UIs, APIs, infra and all that)

Taxes are currently paid according to spanish autonomo income but it's temporary until we have a better way.

Lower expenses is also one of the main reason why decentralization of the packages are needed, as it would be trivial for individuals/companies to support the project by help hosting the packages, instead of trying to raise the same amount of money from them.

Take a look at the issue for federation for more details: #19

I'm pretty sure we can make it work with a pretty small income if we design it correctly.

Have you given any thought to resolution of disputes between parties? For example, someone posts a package name that's offensive to some group of people, but the package is useful to some other group of people (who are not offended by the name). Who has the final say in those kinds of conflicts? (This is especially relevant where it concerns spam and malware. If it's "community owned", then people have a right to free speech, right? At what point does that get limited in favor of others' freedom from harm?)

If the package contains something that is illegal in the juridiction of the non-profit or servers, it will be blocked.

I think the main way of thinking about a future registry is a registry of registries, where the main registry just keep track of addresses to everything else. Which package you pull from where, is up to you. Different registries will accept different rules, similar to how the Fediverse works. If implemented this way, Open-Registry would just be a gateway for getting content from the other registries.

What's the story on publishing? It looks like it's still only a downstream proxy?

Yeah, right now there is no publishing, only cached proxy to npm registry.

Haven't really got that far yet, what I do know is that I would like us to avoid having to run install-scripts locally, offer a community build-server for native modules, require packages to be reproducibly built and not be uploaded directly to the registry. But all these thoughts are still early.

I'm happy to chat about this stuff and provide you with the benefits of hindsight as much as I can. There are a lot of devils in these details, and I'm unfortunately quite acquainted with many of them :)

That's great! I'm super grateful that you sat down and wrote out your thoughts and questions, as there is indeed a lot to learn about the history and choices of npm.

@olingern

Mind you, setting up a proxy, mirror fallbacks, etc. would be no small undertaking.

Actually less complicated than you might think, the current naive implementation took a couple of hours, a better one might take a few days at max.

I expect the efforts around governance and federation to be the most complicated and time-consuming pieces in the near future.

[isaacs]

Actually less complicated than you might think, the current naive implementation took a couple of hours, a better one might take a few days at max.

Well, yes, writing a proxy, even a very good one, is a pretty small undertaking. The hard part is scaling to support over 10 million users and billions of requests per day, and the social challenges that arise when supporting a large community of people with diverse (and very often conflicting) interests.

I expect the efforts around governance and federation to be the most complicated and time-consuming pieces in the near future.

It would be wise to focus almost exclusively on that problem at this point. Designing features like package signing and server building is more exciting, but I assure you, these are much smaller problems, and they can be tackled iteratively over time.

That's why I was immediately curious about what exactly "community" and "ownership" mean in this context. These are the biggest challenges ahead of you. It is reasonable to assume that unraveling this stuff will take years, not months. (I'm not saying this to dissuade you from it. It is genuinely interesting to me, and I'm looking forward to seeing how this plays out, but I don't want to see someone run into the wilderness without preparing for what's ahead.)

It is currently setup as described in the bylaws. Short version, everyone who contributes anything is a "contributor", "member" is a contributor who has been voted for and "leadership" is team of people with final say if there is no way of reaching consensus and represents Open-Registry.

So, it sounds like the decision makers are the people who "contribute" to the open registry project?

What's the incentive for people to spend time and money on this? But it sounds like the main incentive is that people who contribute get a vote in the membership/leadership.

I'm not a lawyer, and this is not legal advice! You should get your own lawyer to consult on this asap! But, speaking as a layperson who's been in this space for a while: In practice, at least part of the reason why most open source foundations are 501(c)(6) organizations is that (a) it's difficult to justify public benefit to the satisfaction of the requirements of a 501(c)(3), (b) the oversight and prohibition on self-dealing can cause a lot of challenges, and (c) a 501(c)(6) can do things that benefit an industry sector as a whole, and are less limited in their activities as long as that benefit is maintained. (For example, you can easily make the case that an open source project or a registry of packages benefits all the members in the tech sector who use it; it's much harder to say it's a "charitable" cause, however.)

For example, ICANN is a 501(c)(3) public benefit organization. This is (part of) why they cannot make distinctions about which domains are "illegal", or really have any kind of opinion at all about what goes on the internet. "The Internet" is a public benefit. "There is no malware on the internet" is much less clear, since it involves a judgement call about what constitutes "malware".

If the package contains something that is illegal in the juridiction of the non-profit or servers, it will be blocked.

By whom? And how are they paid for that service?

Another important thing to consider is that people need to eat, and this is a big project. Even if you spread out the server and bandwidth costs with federation, the sticky part of the puzzle is how to handle name consistency and management without some central point of control. And if you have such a central locus of control, (a) how do you ensure that this group is not biased, and (b) how are they getting their bills paid? If they're being paid by Open Registry, then there you go, you've got a private organization that has to make payroll every month, and is going to be incentivized by that need. (I don't personally think this option is so bad, obviously, but it has its drawbacks.) If they're being paid by a day job, then either they're doing this work in addition to their paying gigs (some will, but it's not really fair to demand or expect), or their employer is paying them to work on this specifically (which means that their employer sees it as beneficial to their bottom line, and then you've got the traditional financial bias that open source foundations have to contend with).

Putting aside the considerable game theory challenges, two big challenges federation are performance and consistency.

If the Open Registry is a "registry of registries", and there isn't a single "registry of packages" per se, and anyone can publish to anywhere, what happens if I publish a package named "foo" in California, and at the same time you publish a package named "foo" in Spain? If you approach this as "consistency for writes, availability for reads", then that would mean that write operations would tend to get very slow as the number of registries increases, and also result in write outages when the network inevitably partitions. If different registries have different content and federate from one another, this gets even more challenging. Say you've published "foo" in Spain, and I've published "foo" in California, and then someone wants to pull in packages from both of us?

One way to approach this might be to tie the registry name to the package name. So, for example, I publish us_ca/foo and you publish es_ba/foo. What happens if the us_ca server goes away, and then a new server is spun up in its place, which publishes a new and completely different foo? You'd need to make sure that registry names could never be reused, and also figure out how to maintain disaster resilience in the network.

At the very least, the set of package names and versions needs to be populated throughout the network, along with the authoritative source and ownership, and it'll mean that people need to start putting registry names in their package.json files, which imposes some UX and portability challenges.

Presumably there'd have to be some way to suspend bad actor registries that flood the network with garbage. (This is not hypothetical or outrageous. Spammers are a very real thing; we spend quite a bit of effort fighting them.) You'll need to consider how to go about cleaning up that garbage as it spreads throughout the network. This is also relevant when a package needs to be deleted, whether because it contains malware or for IP/security reasons. All in all, security and moderation is much simpler when the registry is controlled by a single entity, and it's still a huge challenge. In a federated architecture, it gets much more challenging.

The Fediverse has many of these same problems, but humans and toots are more resilient to failure than computer programs and their dependencies. If you can't read my microblog, you might be less entertained for a little while. But if you can't get my packages, you can't ship your app or do your job.

Please forgive my cynicism, I have paid dearly over the years to acquire it ;)

[victorb]

@isaacs Thanks again for taking the time to leaving a reply.

Well, yes, writing a proxy, even a very good one, is a pretty small undertaking. The hard part is scaling to support over 10 million users and billions of requests per day, and the social challenges that arise when supporting a large community of people with diverse (and very often conflicting) interests.

I was answering specifically to "setting up ... would be no small undertaking", I do understand that scaling it further is of course not as simple as the initial implementation itself, but I think the social challenges will be the really hard part as it deals directly with humans. The other parts are just software and has been solved in the past (by npm as well as others)

It would be wise to focus almost exclusively on that problem at this point. Designing features like package signing and server building is more exciting, but I assure you, these are much smaller problems, and they can be tackled iteratively over time.

I agree, hence they are in the "future" section of the current roadmap.

That's why I was immediately curious about what exactly "community" and "ownership" mean in this context. These are the biggest challenges ahead of you. It is reasonable to assume that unraveling this stuff will take years, not months. (I'm not saying this to dissuade you from it. It is genuinely interesting to me, and I'm looking forward to seeing how this plays out, but I don't want to see someone run into the wilderness without preparing for what's ahead.)

Yeah, and I thank you for creating this issue. Stuff taking years is not a problem, as long as they are done correctly and we can have a proper open registry.

So, it sounds like the decision makers are the people who "contribute" to the open registry project?

Indeed.

What's the incentive for people to spend time and money on this? But it sounds like the main incentive is that people who contribute get a vote in the membership/leadership.

The users using Open-Registry want to have a open registry that is not under the whims of a for-profit company. Generally, people contributing to non-profits do so for the greater good the non-profit is providing. Not sure how non-profits works in the US.

In practice, at least part of the reason why most open source foundations are 501(c)(6) organizations is that...

Open-Registry won't be registered as a US 502(c)(6) organization, so this doesn't apply here. Although similar considerations have to be done no matter where the organization is based. So thanks!

By whom? And how are they paid for that service?

Good question. Initial idea while the scale is small is that Leadership is responsible for that, but further down the line it probably needs a dedicated team.

As of now, no one is getting paid to work on Open-Registry and there is no plan to implement that in the near future either.

Another important thing to consider is that people need to eat, and this is a big project...

Thank you a lot for the questions and thoughts, they help to shape my own thinking. Essentially, all the details about the federation will be worked on in the issue about federation linked before.

Rather than having the same naming issues npm registry has (which all the problems you outline comes from [a centralized service with distributed, private backend]) won't apply for Open-Registry in the way I'm thinking about the federation.

Rather than focusing on who gets what name, image the packages are content-addressed and it doesn't matter what name you use for your project. You'll still use it in the codebase by one name, but the distribution, namespaces and lockfiles don't need the proper name, they just need the address.

Again, all this will become clearer once we get closer on nailing down Federation. Currently doing more thinking and writing about the federation as I see it. I hope we can continue any discussions about federation specifically in the dedicated issue about it: #19

You'll need to consider how to go about cleaning up that garbage as it spreads throughout the network

I'm pretty sure the federation won't work as a thing if package updates gets propagated automatically without any action from the other side. I'm seeing a different flow of information right now for the federation.

Please forgive my cynicism, I have paid dearly over the years to acquire it ;)

Please don't excuse yourself, I find all of this super helpful and if you have more thoughts, criticism, ideas or anything else I'm very happy to hear more.