Adopt & Request a NuGet Package #41
Comments
|
This sounds exciting and has prompted a number of questions.
I have potential answers to some of the above but I don't want to influence or hinder any potential discussion. |
|
Here's some thoughts, but by no means are actual answers. Just my thoughts unfiltered:
I believe other communities use this as a means to see the demand for packages where all avenues to contact the maintainer have been used but the project hasn't necessarily been put up for adoption or orphaned.
Yes, and the license needs to be permissive enough as well for contributions. It cannot prohibit redistribution, be too restrictive, or have other clauses preventing OSS adoption.
Yes, a user would requesting would need to also provide information about it's license.
Should still be able to be requested, but fall into a category such as "Cannot be packaged" or similar.
A package owner would request their package to be orphaned (i.e. find me a maintainer). At this time, no such policy exists for abandoned/orphaned packages and a committee would need to work on one with regards to scenarios where the community is asking for attention on a package and a maintainer is unresponsive. Such a policy may not even be needed, but rather the demand serves as a means to measure the lacking functionality in the ecosystem for the community to take on.
I believe to start, it should be hosted on the .NET Foundation or similar. Perhaps client tooling & nuget.org integration can come later & provide users warning messages about packages looking for adoption.
As part of the working group, we should limit criteria initially and then wean off of it depending on how many requests are being made. Perhaps start with only package maintainers creating requests on behalf of their own projects & expand on that later with community requests.
I see this effort more as a means to bring attention and awareness towards packages and their maintainers. It by no means is a formal process to determine ownership of a package. Rather more like a job board / bounty board for the .NET OSS community to look through and support each other.
This is up to the maintainer. This proposal serves no part in this.
We can consider adding links to popular guides like https://opensource.guide/best-practices/ or linking our own.
That's up to the individual to assess the project's current state or talk to the maintainer.
See if there's enough promise in this proposal first. Then if accepted & taken on by the .NET Foundation, see what type of demands and requests are being made, and continue to have a pulse on the asks every quarter or so while evangelizing it through the .NET OSS community.
Anything considered to be packaged on nuget.org should be fair game.
I think so. When a package owner puts up a package for adoption or orphans it, usually there will be a reason why. They can choose to disclose that if they wish. Most reasons I've seen are that the maintainers don't use it anymore, don't have time, want to focus on other things, retiring, health, moved on to another ecosystem, etc.
Any package ecosystem can adopt this. I think NuGet is a good place to start. |
|
Sorry I missed these last points.
You should provide your thoughts on this issue to help the committee members who review these proposals have more information!
As for getting involved, I don't really have an answer right now as this is a fairly new process. I'd assume if approved, we can kick-off a working group to see this thing through. |
|
If you want to join us for the monthly meeting and discuss this, we'll review this in the meeting: |
|
Is there a calendar invite link? The link above just goes to a Teams call. |
|
Sorry if you missed this. Can you let me know how we can help? We love the idea but I'm not sure exactly how we can help make this happen. Do you think a section of the dnf website where people can request/fulfill requests? Is this to just create a NuGet package for existing code, or more about helping contribute/adopt an open source project? Details will help us move forward. |
The proposal would be to work together & create a landing page or email automation for the .NET ecosystem to request & see packages available for adoption or requiring help from their maintainers similar to the examples in the prior art section. A section on the dnf website I think would be perfect for this type of effort if there's consensus it's a positive addition to the community & is best suited for the foundation. I apologize in advanced that I missed because the link above is just a call link. I wasn't aware of the time or date these meetings happen until re-reading: https://github.com/dotnet-foundation/wg-outreach#joining-the-committee--meetings |
|
If you're interested in helping with this, we have a working group meeting tomorrow. Send me a message to get added to the Teams call. |
@shawnwildermuth yes please |
|
Adding this to the agenda for the next working group meeting to get volunteers. Next meeting is August 10th at 2pm. |
|
@nicoleabuhakmeh can you add anyone that asks to the meeting invite so that they can volunteer? |
|
I just wanted to pass along how this went for npm. |
|
This seems like a bad idea with good intentions. Would like to understand how this would have a different outcome, or combat the outcome that @andrewmd5 refers to in his link. |
|
That is an unfortunate situation for all involved @andrewmd5. Thanks for sharing! For reference, here is NuGet's policy. This proposal isn't intended to be about disputes. Rather to bring a central board of requests to the .NET package community. I mentioned earlier in a comment above that may have been buried. This proposal has no business in defining the ownership of packages. Ultimately it is up to the involved parties to work out the resolution. That is usually the poster and an interested party such as a package maintainer requesting a package be orphaned and a new maintainer taking on the package to which the original maintainer then transfers ownership. I don't have strong feelings for the proposal other than the fact that I've been involved in other communities recently and noticed this wasn't something in the .NET community. I really liked the idea and I wanted to provide a valuable suggestion to help work towards this with the new working group effort. If it's a dumb idea, let's close the issue and move on. If it's one that people would like to see out, I'd love to help from the NuGet side. |
|
I want to toss in my own anecdotal experience with NPM's claims process - one that counters what @andrewmd5 ran into. I've used NPM's old process for claiming abandoned / zombie packages and organizations. I recently worked for Allergan Data Labs (whose parent is Allergan - the big pharma joint) and was asked to see if we could acquire the It sucks that @andrewmd5 had a bad experience that disrupted the lives of some folks connected to the package he targeted. HOWEVER that doesn't mean the idea is flawed - it means the process by which whatever support representative at Github took, was faulty. Afterall, if someone came looking to claime https://www.nuget.org/packages/JuiceUI/ - which I published while at AppendTo, and which is no longer relevant nor compatible with anything modern - I'd want them to be able to use it for something meaningful. As a user of NuGet wayyyy back in the day, someone who still has some aging packages on NuGet, a prolific registry publisher and user, and someone who has used a similar process with great success, I encourage this community to give the idea consideration. |
|
It seems there are a couple of ideas here and maybe the goals for this proposal should be split accordingly.
Goal 2 is where lots of potential monsters lie--as highlighted in some of the stories linked above. I think this goal should be deferred to a future time (if it ever happens) as NuGet already has an official process for handling arguments over ownership and deceased maintainers, etc. Goal 1 is already a complex issue. Maybe only focus on one thing at a time. Bonus possible alternative to goal 2 above. |
|
One significant issue that concerns me here are the supply chain attack considerations. When a package owner changes, for any reason, that means that all existing users have to now automatically trust that the new owners are trustworthy. I don't think that's a statement that can be made. I think that an alternative approach is to never allow the ownership to change like this and instead enable forked packages to subsitutute for an existing on in the graph. That would enable the community to fork the code, publish it to a new ID, and enable dependencies to redirect to it instead. |
It's a good point, but doesn't it just move the problem? If a redirect can happen without the consumer having to do anything, don't the same issues exist? But good points that need discussion/exploration before building anything. |
|
@mrlacey the redirection I refer to would be via a config in the repo/project file--so it's explicitly opt-in by the consumer, not a silent redirect. It also means that there could be multiple forks available and consumers could pick which they want to use. |
So a standard file or content in the repo saying that a specific fork is now recognized as the continuation of the project. If there's only one fork taking over, this could presumably be used in combination with the original package being deprecated on NuGet and something from the fork being listed as the alternate package. I like it. Minimal effort is needed and no new technology is required. The challenge then becomes encouraging this behavior when a maintainer retires from or abandons a project. |
If that's a concern, one shouldn't be using a package manager of any type. Pretending this doesn't exist at the moment would be burying one's head in the sand.
As someone around from the first days of NPM I can tell you that this just doesn't work. Established, popular packages will continue to be used and most folks will not seek out forks. It takes discovery, and that's not something people do proactively. The only way super popular, abandoned packages die in favor of forks is if there is concerted community driven behind a fork. That tends not to happen organically. The only way to dissuade a userbase from using a package which came up as popular but was ultimately abandoned is to develop tooling that marks the package as unsafe, etc, and blocks the user from using it. And then you're opening multiple new barrels of monkeys. I highly encourage the foundation to do things on practical, objective, functional bases, rather than possible or perceived fears. Afterall, I would imagine the goals are to make things more functional and provide a better developer experience than that which exists, and not to introduce a less discoverable, more confusing DX. Good luck folks 👍 |
I believe the concern is about introducing a new risk / opening another vector of supply chain attack to pile on the many more that already exist as you point out. Users update packages to newer versions assuming they are coming from the same author that they previously decided to trust when they first installed the package. i.e. Users are already taking several risks including the package author going rogue or their CI pipeline getting compromised. If it becomes possible to someone easily takeover packages and release new versions under the same package ID, this is introducing a new risk that was not there before. |
|
I'm closing this proposal as the discussions feel a bit tangential to the original proposal of "creating a https://wnpp.debian.net/ for the .NET / NuGet community". Thank you everyone for the comments & discussion on the topic. At this time it feels best to not invest more time or energy into this. |
Title:
Adopt & Request a NuGet Package
Description:
Packages and their respective maintainers have lifecycles.
In various Linux communities & other application package managers, there are "adopt a package" programs. This is where:
The project proposal would be to create a small web application or automated email workflow that would allow users to request packages to be put up for adoption or requested for various reasons above. It would then list all the packages that have been submitted on a publicly available website. This might be a:
Measure of impact:
Thousands of packages, hundreds of maintainers
Requested Budget:
N/A
Size of Committee Requested:
2-3 Volunteers
Which Goal and Priority is this project aligned with:
How will we know this outreach is successful?
Prior Art
The text was updated successfully, but these errors were encountered: