I see project forking as the least desirable alternative, like "war" to make an analogy. This should be used only when there is no way to find a common ground and we eliminated all other alternatives.
I did a special fork approach with Synergy project many years ago because it was unmaintained and there were patches floating around over the internet. I did an integration fork, did some CI work, with the only scope of reviving the project, I was successful and that become the only version, everyone joined forced but it was a lot of effort and it worked because that was a final product not a library. You do know very well that it would be close to impossible to successfully fork virtualenv because nobody will use it, just because they would have to change their code to use the "alternative". If <current-maintainer> does not have time or interest in spending more effort on the project they should gradually just handle more control to it others that do need it and that they are willing to give it few good more years of life. Lots of people are still using py27 in production and I am ready to bet that the EOL date may be updated. I adopted quite a few Python orphan projects over the years and they all ended up on https://github.com/pycontribs because I believe that projects should not depend on a single person. I also assured that at least are at least two people with rights to make a new release on PyPI. virtualenv is already under an organization so there is no need to move it anywhere, all it needs is some attention (looking at the open PRs, it clearly needs attention as people are raising valid contributions that are ignored for very long time). I already said that I am willing to help with that and I could start by doing few reviews (no permissions to perform them now). PS. I find but weird the fact that it was much easier to contribute the same fix to Python core than to virtualenv. On 28 Sep 2017, 23:41 +0100, wrote > > ally care about virtualenv, and know that you would have an audience for the > fixes you're proposing: fork it, prove that you can maintain it, and people > are using it, and then the maintainers will inevitably give you the project. > I mean, they don't really care about it anyway, the
