3 ms·

I agree with most of those, although I'd add a bullet point to the agreement: - If I don't have the time or interest to support the project any longer I agree

I agree with most of those, although I'd add a bullet point to the agreement: - If I don't have the time or interest to support the project any longer I agree to reach out to trusted contributors and give them commit rights, or put a clear notice on the readme: "This project is not actively maintained" so users can make an informed choice

jaitsu 10y ago
Great point. I think there always comes a time for developers of popular open source libraries where their "workload" (that is their responsibilities to their end users) becomes too much for them to deal with, even if you don't have a family. The only sensible solution here is to bring on regular contributors as repository owners and spread the responsibility.
verytrivial 10y ago
That said, the is a fork button.
- Wintamute 10y ago
  True, but there are problems with GitHub forking: namely that its often non-obvious which is the best fork to use, since too much prominence is given to the original project. Also if the maintainer doesn't even put a note on the readme "This is dead, use XXX fork" you have even more problems. Also maybe the original project was published to a package manager ... forking is one thing, but publishing and maintaining your fork on a package manager too?
  - mgbmtl 10y ago
    It can take some effort to feel comfortable giving the keys of a project to someone else. In one project that I had abandoned, I encouraged others to fork and rename the project. They can advertise it as a fork of the original project to attract stranded users, I would even have promoted it, but I think that it would have been very misleading to our users if suddenly the project changed hands. (the project was a management tool often used by non-profits, it stored personnal data and security was important. I had received a ton of very shady non-sense proposals, to this day, 10 years later, I still get the occasionnal weird message or request for support)
- caseysoftware 10y ago
  Forking is an approach to keep the project moving but the underlying problem is then notification & distribution. If I use one of the package managers - npm, composer, gems, etc - people only know of the original project and have its namespace somewhere in the project. If I fork a project, resolve all the issues, and make it better, faster, etc, there's not a mechanism for those users to pick up my fork unless they actively go looking for it. I think many of those package managers would be well-served to have a 301-like redirect saying "deprecated, but continued over in this new package"

jaitsu 10y ago

Great point. I think there always comes a time for developers of popular open source libraries where their "workload" (that is their responsibilities to their end users) becomes too much for them to deal with, even if you don't have a family. The only sensible solution here is to bring on regular contributors as repository owners and spread the responsibility.

verytrivial 10y ago

That said, the is a fork button.

Wintamute 10y ago
True, but there are problems with GitHub forking: namely that its often non-obvious which is the best fork to use, since too much prominence is given to the original project. Also if the maintainer doesn't even put a note on the readme "This is dead, use XXX fork" you have even more problems. Also maybe the original project was published to a package manager ... forking is one thing, but publishing and maintaining your fork on a package manager too?
- mgbmtl 10y ago
  It can take some effort to feel comfortable giving the keys of a project to someone else. In one project that I had abandoned, I encouraged others to fork and rename the project. They can advertise it as a fork of the original project to attract stranded users, I would even have promoted it, but I think that it would have been very misleading to our users if suddenly the project changed hands. (the project was a management tool often used by non-profits, it stored personnal data and security was important. I had received a ton of very shady non-sense proposals, to this day, 10 years later, I still get the occasionnal weird message or request for support)
caseysoftware 10y ago
Forking is an approach to keep the project moving but the underlying problem is then notification & distribution. If I use one of the package managers - npm, composer, gems, etc - people only know of the original project and have its namespace somewhere in the project. If I fork a project, resolve all the issues, and make it better, faster, etc, there's not a mechanism for those users to pick up my fork unless they actively go looking for it. I think many of those package managers would be well-served to have a 301-like redirect saying "deprecated, but continued over in this new package"