Add threshhold to transfer ownership of unmaintained packages to fluttercommunity.dev

[Tienisto]

Please add a threshhold of 2 (or any other number) years that unlocks the package name to be transferred to fluttercommunity.dev.

The number of unmaintained package grows over time which clutters the package name space of pub.dev.

You could send a warning letter to the owner that within 3 months of no update, the ownership MAY be transferred to fluttercommunity.dev. The transfer happens automatically when the flutter community publishes a new version of the same package name.

This should be a more actionable approach than #4757, assuming that fluttercommunity.dev is trustful.

[Tienisto]

Ref: aloisdeniel/flutter_device_preview#230

device_preview (unmaintained)
devive_preview_community (unmaintained)
device_preview_minus (new but not popular)
device_preview_plus (waiting for it)

[sigurdm]

I think we should make a well-documented voluntary process for abandoning packages. (Perhaps in the style of https://wiki.haskell.org/Abandoning_a_package)

But automatically losing ownership after 3 months of inactivity is probably not gonna happen.

[Tienisto]

Well, I have said 2 years with a 3 month warning letter. You also don't lose ownership immediately. You only lose it if fluttercommunity.dev decides to take over the project. If no volunteer from fluttercommunity.dev has resources to maintain the project, nothing changes.

[sigurdm]

Well, I have said 2 years with a 3 month warning letter.

Ah sorry, I misread that. :)

[isoos]

@Tienisto: I have a package that has no activity on it since I've last published it 2.5 years ago (has its use, can be considered complete), and I would be really upset if that could lead to automatic loss of ownership (I could be missing my email notifications for any reason).

Instead I'd suggest to reach out to the other developers, discussing their plans and if they want to transfer ownership of the package. Worst case a package can be forked (like it was with package:aqueduct -> package:conduit) and the community can own it. You don't even need to wait two years or more for that...

[Tienisto]

Good point @isoos ,

the issue I see is that people may lose interest or just have more important things to do in their life (which is ok of course). If this is the case, how can we suggest them to reach out to other developers? Doesn't this require to invest even more time into the Dart ecosystem?

In your case that you have a complete package, we can add a "complete status" check box, so this transfer process is getting disabled altogether.

Regarding forks, aqueduct and conduit is a good example but how about device_preview? This package name is top tier. Forks naturally use device_preview_[community,plus,minus,etc.] to indicate that their package is the continuation of the abandoned one.
As a package consumer (so 99% of the developers), we naturally feel that our pubspec.yaml is filled with second-class packages although only the maintainers have changed.

I mean, how should we tell newcomers to the Flutter ecosystem, that they shouldn't use device_info like in the youtube tutorial but they should use device_info_plus instead? Doesn't make it the flutter ecosystem seem unprofessional? Again, device_info is a top tier package name. I could not think of another name that convey the usage the best.

[isoos]

<x> is a top tier package name.

It may be, but I also think people will follow trends. You can always introduce a new fork with a completely different name (like package:eric recently from Reddit), or a name prefix, like the jaguar_<*> packages, and the users will follow. At the end of the day, most of us want to get the job done, and if the package is called device_info or the_very_best_device_info or device_info_2023 may not matter that much.

This kind of naming argument was really heated in the CockroachDB community, whether that name was professional enough or too lame. I'm really glad that they persevered, and provided a good example that names can be both fun and memorable.

[Tienisto]

You are right.
Thinking about it again, I am fine if #4146 gets resolved.

[medz]

I have a different opinion, why don't we allow package name to support namespaces?

This may involve a certain level of support (import) from the Dart SDK

Isn’t pubisher just a ready-made Mingming space? We allow the publisher to customize an ID, and then the release package under the publisher becomes

@{publisher}/{package}

Just like NPM or the Composer community, publishing a package under the @{publisher} name requires certain publisher permissions.

In another nice-to-have but better proposal, the Dart SDK imports from package:*** without requiring a specific file name, such as package:a or package:@foo/bar

We can solve this problem once and for all. For communities or some companies, they prefer to use names containing namespace when publishing packages. For example, there are often @vue/core/@vercel/kv etc. in npm.

[medz]

In addition, I do not agree with the transfer and grace period referred to in this issue for anyone, whether he is squatting or otherwise or has left the Dart language. The packages he releases are the assets of his labor. For example, I have a very stable infrastructure. It has not been updated for three years, but it still works very well. There is no need to continue to optimize it. I have been using it. Suddenly one day I received an email from pub.dev asking me to update it or I will lose ownership of it.

Think about it, if there is a public place that allows everyone to plant trees, and the tree belongs to the person who planted it, the tree I planted will grow up, and it will be nutritious and can still grow without anyone's care. Suddenly the government told me that if I don’t go and take a look at this tree, the tree will be given to someone else. How bad.