5 ms·

Let us say the current mechanism - handing a library from one owner to another - is used. If the new owner acts in bad faith, what recourse do you have to main

Let us say the current mechanism - handing a library from one owner to another - is used. If the new owner acts in bad faith, what recourse do you have to maintain a non-abused version of the library? Can you replace the owner's authoritative builds with your own? If you instead have no 'authoritative version' of a library, you lose some elegance to be sure; you can no longer say simply, 'let's use Magic Missile!' as there may be multiple forks of what could be labeled the original 'Magic Missile' library. But what you gain is the ability to maintain multiple versions of the library, and to be able to point out which versions are poorly maintained or even hazardous: "We don't use Drizzt's Magic Missile, it was tailored pretty heavily towards his own projects." "If I recall, Persophone's Magic Missile included a hidden cryptominer. Avoid at all costs."

em-bee 7y ago
so this is not a technical change but a change of presentation and perception. instead of one person or team having the authority, there is a community notion of who can be trusted. this does exist. and it seems to happen when authority falls down or is not there to begin with. for example several community builds around distributions for the GPD pocket emerged, and some lived longer than others and some where more reliable than others. in fact the emergence of linux distributions themselves follows this model. each distribution is packaging applications they did not create, and are hence not the owners of the authoritative builds. and we pick distributions based on which one does the best job. of course distributions create their own authority on their collection, but the principle remains. they also may easily switch the source for their packages. i do remember a few examples where this has happened. another area where this can be seen is with binary builds for projects where the original developers only release the source. it's the same dynamic. build your own, or pick a community contributed build by someone else. either way noone gets to use the authoritative builds because they don't exist. (or they exist only for one platform, in which case the situation is limited to those who are on different platforms for which there are no authoritative builds)
- Fellshard 7y ago
  It's both a matter of perception and of tooling. Consider the Java ecosystem. Dependency targets are specified by coordinates of both group and artifact, which satisfies the above separation fairly well, to the best of my knowledge. Consider the NPM and rubygems ecosystems: they specify dependencies by the name of the library alone, implicitly enforcing the 'authorized artifact' model.
  - em-bee 7y ago
    so you are saying that in java this works because i can choose the group where i get the artifact from, just like i can chose a different package repo for a package for my linux distribution. but in NPM and ruby i am limited to one single global repo and thus have no choice but to get the one that is controlled by whoever owns the name.
    - Fellshard 7y ago
      Similar, yes. You can also choose repositories in Java, as well, which is closer to your Linux package repo. So there's just another tier in the hierarchy, there, basically. You can run your own private artifact repositories for NPM and Ruby, and select which concrete artifacts they contain; but that's not the publicly hosted repositories. One option could be to centralize into a cluster of public repositories, which is closer to what the Java and Linux ecosystems have, and that may be a sufficient compromise in many cases. I think the layer of abstraction between repositories and concrete artifacts is still useful.

em-bee 7y ago

so this is not a technical change but a change of presentation and perception. instead of one person or team having the authority, there is a community notion of who can be trusted. this does exist. and it seems to happen when authority falls down or is not there to begin with. for example several community builds around distributions for the GPD pocket emerged, and some lived longer than others and some where more reliable than others. in fact the emergence of linux distributions themselves follows this model. each distribution is packaging applications they did not create, and are hence not the owners of the authoritative builds. and we pick distributions based on which one does the best job. of course distributions create their own authority on their collection, but the principle remains. they also may easily switch the source for their packages. i do remember a few examples where this has happened. another area where this can be seen is with binary builds for projects where the original developers only release the source. it's the same dynamic. build your own, or pick a community contributed build by someone else. either way noone gets to use the authoritative builds because they don't exist. (or they exist only for one platform, in which case the situation is limited to those who are on different platforms for which there are no authoritative builds)

Fellshard 7y ago
It's both a matter of perception and of tooling. Consider the Java ecosystem. Dependency targets are specified by coordinates of both group and artifact, which satisfies the above separation fairly well, to the best of my knowledge. Consider the NPM and rubygems ecosystems: they specify dependencies by the name of the library alone, implicitly enforcing the 'authorized artifact' model.
- em-bee 7y ago
  so you are saying that in java this works because i can choose the group where i get the artifact from, just like i can chose a different package repo for a package for my linux distribution. but in NPM and ruby i am limited to one single global repo and thus have no choice but to get the one that is controlled by whoever owns the name.
  - Fellshard 7y ago
    Similar, yes. You can also choose repositories in Java, as well, which is closer to your Linux package repo. So there's just another tier in the hierarchy, there, basically. You can run your own private artifact repositories for NPM and Ruby, and select which concrete artifacts they contain; but that's not the publicly hosted repositories. One option could be to centralize into a cluster of public repositories, which is closer to what the Java and Linux ecosystems have, and that may be a sufficient compromise in many cases. I think the layer of abstraction between repositories and concrete artifacts is still useful.