The GitHub registry public beta is live

The way they have set things up, every github account/organization (the first thing after a slash) is it's own separate 'source' to rubygems. (I am sure they have done this because it would be inconvenient to integrate with rubygems/bundler any other way).

So you'd still need to add a separate source for each dependency hosted on github to your own project Gemfile. Including for each indirect dependency, knowing which indirect dependencies exist that need a github repo source.

If you could list this for the entire project... it'd probably be a performance issue as rubygems/bundler check every repo source you list for every dependency (including every indirect dependency; a Rails app has hundreds, still an order of magnitude or two less than a react JS project heh).

Even if you could only list "github's ruby registry" once (per project? for your account? and keep in mind this is hypothetical, you can't), it would still mean any gem expressing a dependency on another gem hosted on github would have to include in it's instructions "oh, if you use this, you need to manually make sure to add github to your sources. Or you'll get an error that says some gem you've never heard of can't be found, and have no idea how to fix it." Unless it's a bid to get _everyone_ to do that, and basically make github ruby registry a standard part of the ecosystem that everyone just always adds to every project.

I don't think there's enough/any value added by the github ruby registry to get the ecosystem to shift like that. It's unclear what it does that the 'standard' rubygems.org gem source doesn't do already (unless rubygems.org can't solve their recent severe compromised account security problems... but as it is, with the indirect dependency problem, I think github registry will be too painful to use even if you'd like to to escape rubygems.org security issues).

https://help.github.com/en/articles/configuring-rubygems-for...

I believe it's going to affect the whole developer community in a bad way.

Right now, all the major package manager are indirectly making each other better, they experiment, improve and borrow good ideas from each other. It's open-source and there is a little barrier for developers to contribute.

If n years from now GitHub becomes the defacto standard for package managers and replaces all the existing ones the further innovation will be much slower.

It might transform into "Want to improve package managers? You have to work for Microsoft"

It isn't a customer's responsibility to be a company's guinea pig, and it's not a secret that customers would be unhappy that tech companies treat them as such. This is especially true when Product Managers intentionally implement features that take advantage of users by monetizing their data and then implementing high switching costs that make it even more painful for the customer once the Product Manager ends their "experiment". If tech companies want to perform market research by experimenting on customers, they should do the same thing that other industries do and compensate the experiment subjects, not take advantage of them.

If you want to disrespect customers by treating them like disposable guinea pigs (and not even giving them the courtesy of notifying them they're part of an experiment), don't be surprised if they start to catch on and treat your company as if it's disposable, too.

I think you're conflating package managers and package registries here. This GitHub product has almost no overlap with package managers like pip, gem, maven, or npm. It is not a replacement for docker.

This is a replacement for npmjs.com (the hosting service, which is not the same thing as npm the package manager), or for rubygems.org (again, the hosting service, not the gem tool), or for Docker Hub.

If anything, this may actually improve the collaboration between package manager developers because there will now be a large development team that will be working with the backend of various package registries and will have better insight into what each one is doing wrong and what each one is doing right.

> In other words a "copyright takedown request" isn't valid, unless the author was in violation of the copyright of somebody else while publishing those packages and this was decided in a court of law.

The DMCA process is law. Maven Central (like anyone else who hosts things) have to respond to valid takedown requests (which means taking down content long before any court case; even if a counter-notice is filed the content still has to be taken down temporarily) or else they'd become liable for infringement themselves. It's less common than on github or NPM, sure (which I suspect has more to do with the complexity of maven central's registration process than anything else), but it happens and any host on the scale of maven central needs a process in place for doing it.