Help identify forks before publication (and look for alternative path)

[zwilias]

Intro

One of the best things about Elm is the ecosystem. In no small part, this is due to the tooling:

• the author is part of the package, which makes it easy to say "oh, I've used another high quality package by abc, so I'll go with that one"
• Semver is strictly enforced
• packages are encouraged to have descriptive names. something-extra for extensions to existing functionality, -exploration for experimental overhauls
• etc.

Problem statement

However, there are some painpoints:

• We have 5 packages that have something to do with your keyboard, excluding elm-lang/keyboard. Of these 5, 3 are called keyboard-extra. Note that, after the release of the most recent of those, @eeue56 intervened and helped out in getting the package author to communicate with @ohanhi. Eventually, changes were made to ohanhi/keyboard-extra that made the new package redundant, and it was unreleased.
• We have 2 elm-bootstrap packages, and it's been mentioned on Slack that the second one is a fork which came about without any communication with the original maintainer.

Note that even though licensing allows this, and there is no inherent problem with forks; I do feel like the tooling could work harder to prevent splintering and duplication.

How to handle this

I propose three possible improvements.

• elm package publish could check if the package name was already in use. This could just be a are you sure? y/n type thing, but pointing it out would at least prevent it from happening by accident.
• elm package publish could check if the API of a certain package has significant overlap, and mark it as a fork. When it does, it could ask if any attempt was made to communicate with the original maintainer - if not, point out how it could help the ecosystem more than by just forking and splintering. Either way, having a description of why a package was forked could be helpful.
• On package.elm-lang.org, there is no way of identifying forks easily. Adding that, in addition to displaying the reason for the fork, could help people selecting which package they're really after.

Note that the elm-bootstrap fork might just be to enable testing some changes, for personal use or whatever. And that's fine, but if it's not meant for general consumption, elm package could provide some pointers on how to test a package without publishing it (git submodules, etc).

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[ohanhi]

For the last point (forks not being easy to recognize), I made this quick mock up of how I think it could look like:

[nvaldes]

Hello,

I'm the scrub dev who forked elm-bootstrap and then published it. To anyone interested, I opened elm-lang/package.elm-lang.org#227 to see if I can get my fork removed from the package manager.

FWIW, I agree wholeheartedly with the solution proposed in this issue. Whatever message is displayed when elm-package finds an identical package name should be extremely strongly worded, so that would-be publishers are made thoroughly aware that publishing a fork without the original maintainer's blessing is a major insult to that developer's efforts.

[jvoigtlaender]

I don't think your last half-sentence is consense.