search

dotnet-foundation / wg-outreach

Outreach working group
MIT License
40 stars 18 forks source link

Adopt & Request a NuGet Package #41

Closed JonDouglas closed 3 years ago

JonDouglas commented 3 years ago

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

mrlacey commented 3 years ago

This sounds exciting and has prompted a number of questions. In no particular order:

I have potential answers to some of the above but I don't want to influence or hinder any potential discussion. I'm also potentially interested in being a volunteer for this project. What would be involved if I did?

JonDouglas commented 3 years ago

Here's some thoughts, but by no means are actual answers. Just my thoughts unfiltered:

What would happen when the community asks for an update for a package? (How is this--or would this be--different from current ways of contacting the owner or raising an issue?)

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.

Would the source of a project need to be available for a package to be considered for adoption under this proposal?

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.

Would the package need to be available with a certain type of license to be considered for adoption under this proposal?

Yes, a user would requesting would need to also provide information about it's license.

What about packages where no one has the source any longer?

Should still be able to be requested, but fall into a category such as "Cannot be packaged" or similar.

How to determine what qualifies as "orphaned"? (& handle any dispute from the owner about this?)

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.

Would integration with the NuGet site (& IDE UIs) be necessary? or beneficial?

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.

How to run this as a trial before opening up to the world? (I see a potential for lots of requests for updates or to mark packages as abandoned when this initiative goes live.)

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.

How to ensure there are people ready to consider adopting packages when others are ready to abandon or request new ownership of packages? (This project has the potential for lots of the common issues when launching a two-sided marketplace.)

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.

What can/should be done to help new maintainers taking over a package?

This is up to the maintainer. This proposal serves no part in this.

What can/should be done to help people consider becoming a maintainer for the first time?

We can consider adding links to popular guides like https://opensource.guide/best-practices/ or linking our own.

What can be done for people considering taking on ownership of an abandoned package? (How to assess what's involved and what they may be committing to?)

That's up to the individual to assess the project's current state or talk to the maintainer.

How to ensure this is something that could last for the long term?

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.

Would this need to be limited to certain languages, package sources, repository types, etc.?

Anything considered to be packaged on nuget.org should be fair game.

Could this also include a way for a maintainer of a project (that isn't part of the foundation) to say how to handle the project in the event of their death (or decision to abandon all technology and become a shepherd on a mountain top?) -- (How do GitHub, NuGet, etc. handle these scenarios currently?)

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.

NuGet: https://docs.microsoft.com/en-us/nuget/policies/governance#package-succession-under-special-circumstances

Could this be extended to consider other things beyond NuGet packages, such as IDE extensions?

Any package ecosystem can adopt this. I think NuGet is a good place to start.

JonDouglas commented 3 years ago

Sorry I missed these last points.

I have potential answers to some of the above but I don't want to influence or hinder any potential discussion.

You should provide your thoughts on this issue to help the committee members who review these proposals have more information!

I'm also potentially interested in being a volunteer for this project. What would be involved if I did?

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.

https://github.com/dotnet-foundation/wg-outreach/blob/master/proposals.md#what-is-the-proposal-approval-process

shawnwildermuth commented 3 years ago

If you want to join us for the monthly meeting and discuss this, we'll review this in the meeting:

Monthly Outreach Working Group Meeting

JonDouglas commented 3 years ago

Is there a calendar invite link? The link above just goes to a Teams call.

shawnwildermuth commented 3 years ago

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.

JonDouglas commented 3 years ago

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?

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

shawnwildermuth commented 3 years ago

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.

mrlacey commented 3 years ago

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

NicoleAbuhakmeh-zz commented 3 years ago

Adding this to the agenda for the next working group meeting to get volunteers. Next meeting is August 10th at 2pm.

shawnwildermuth commented 3 years ago

@NicoleAbuhakmeh can you add anyone that asks to the meeting invite so that they can volunteer?

andrewmd5 commented 3 years ago

I just wanted to pass along how this went for npm.

gortok commented 3 years ago

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.

JonDouglas commented 3 years ago

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.

shellscape commented 3 years ago

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 @adl NPM scope. Turns out that no packages were published under that scope, not even private packages, and they hadn't recorded any usage data for it since its creation. ADL was awarded the @adl scope. I've followed the same process a number of times for other abandoned package names, which I now actively publish and make use of. All of them had been packages with no content other than a package.json file, and less than 10 weekly downloads (which, for the uninitiated means that only NPM itself and a few bots are pulling the package down).

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.

mrlacey commented 3 years ago

It seems there are a couple of ideas here and maybe the goals for this proposal should be split accordingly.

  1. Allow maintainers to make clear they are looking for people to take over a project and for people looking to become a maintainer of a project to find projects they could help with.
  2. Allow consumers to flag projects/packages that look abandoned with a view to contacting the owner and getting/enabling someone else to become the maintainer.

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. Goal 1 may sound simple but it's a two-sided marketplace and these are notoriously difficult to establish. To launch, you need not only to have enough people wanting to put up projects for new maintainers, you also need potential new maintainers. Without either, it's much harder to attract the other. I assume that it will be easier to find people who might be interested in maintaining existing projects than those who may be looking to hand over maintenance and so building a list of existing maintainers who might consider taking on maintenance of other projects is probably the easiest place to start.

Bonus possible alternative to goal 2 above. In an ideal world, new maintainers for a project would come from the community of contributors to that project. Projects that are already part of the foundation need to have a community of contributors and so are unlikely to be a target fit for the above matching of projects looking for new maintainers. Is there something related that can be done to help projects that aren't in the foundation build a community of potential maintainers or help a small, niche, project with a single maintainer prepare (or be prepared) for circumstances that leave them unable to continue maintaining the project? (Or is goal 1--above--the first step towards this?)

clairernovotny commented 3 years ago

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.

mrlacey commented 3 years ago

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? It also introduces another potential issue:. If a package is abandoned, a fork gets redirection, but then the original owner later picks up the project again, can they get the original name back? Or will it be forever redirected?

But good points that need discussion/exploration before building anything. It would be good to have input from the NuGet team on whether they've looked at redirection or how to indicate to consumers that a different package (name) might be a suitable update to one they're already using.

clairernovotny commented 3 years ago

@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.

mrlacey commented 3 years ago

@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.

shellscape commented 3 years ago

One significant issue that concerns me here are the supply chain attack considerations.

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.

The challenge then becomes encouraging this behavior when a maintainer retires from or abandons a project.

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 👍

augustoproiete commented 3 years ago

One significant issue that concerns me here are the supply chain attack considerations.

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.

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.

JonDouglas commented 3 years ago

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.