Thank you for asking. The goal of this new PLIP is to lift off work from core developers, release teams, framework teams, admins, etc. And to make new things happen. In a natural manner. Natural manner has to do with intuition. Not everybody has the same intuition. That is why it is a good thing that Python 2 can have more than one intuitive way of doing things as compared to Python 3.
Lifting off work means creating time to make new things happen. Example: work invested in migration to Python 3 would have been put in to other things. This new PLIP is born out of my own need to be lifted of this migration work now and in to the future. I need to invest my time and energy and other resources in to other work to make my projects happen. And to make new things happen. In a natural manner.
The resources that will be invested, and the who or what will make the investment, depends on the cooperation of the Py2-supplier. The more this supplier suits the needs of Zope/Plone the more work can be lifted off from the core developers, the release teams, the framework teams, admins, etc. And the more new things can happen. In a natural manner.
There are options.
First option
The most easy way to start is for the dev-teams of Plone and Zope to report back to Python (TM) that it has to give rebirth to Python 2. Zope and Plone are after all sponsors of Python (TM).
Second option
If Python (TM) stays unwilling to take care of Python 2 and the wants and needs of its users, than Plone can team up with an existing Py 2-fork. The Py2-fork that is active on Github exists of a small group that can be joined by Plone and others. This new Py2-fork strive to be the "drop in" replacement for Python 2.7. Some distro’s are preparing to ship this Py2-fork. I would like it to be a FreeBSD-port. I do not use Redhat. And I do not use Docker. I want to have Plone on FreeBSD in a buildout.
The investments are made by volunteers who know how to maintain Py2 and Plone and those who support. First of all it seems a job for.... those who know how to. Others need to support. I am willing to do what is in my capability to make this happen. The new Py2-supplier needs to be a serious community. All the investments for that need to be made. That can be done on Github by first of all joining this new Py-2 supplier to become acquainted and figure out whether it really can be the new Py2 supplier for Plone. The quality of this Py2-supplier needs to be established by core-dev.
Resources that will be invested is work and attention for this Py2-fork. With respect to Plone Legacy security updates are needed. In the state Python 2 is in today there are not much security issues to be expected in the nearby future. With respect to Plone Current security updates and maybe extra modules and/ore imports for the ___future___
module are needed.
Plone needs to be compatible with this fork. To my knowledge this means that changes need to be made to RestrictedPython, the installer and virtualenv. This is in fact not much work for someone who knows how to. It is IMO mostly a matter of the will to make use of this new Py2-supplier and adjust some code according to that. PIP is also making efforts to support this Py2-fork. I have done tests with Plone on this Py2-fork and not everything works out of the box on this fork yet. Till now I am not able to fix these issues myself. I think that if Plone shows interest in to this new Py2-supplier others who know how to maintain Py2 will join this supplier to share the burden of maintaining the new Py2 because there is a demand for Py2. 50% of the companies using Py2 have no plan to migrate. I even would like to use some Plone 4.1 third party products for on-line production sites. The migration to Python 3 is not a free choice of the market. There is and there was reluctance to migrate to Python 3. Python (TM) forced the acceptance of Python 3 by EOL’ing Python 2.7. Killing projects that do not have the resources to follow. The big companies accepted Python 3 first. They have the resources to get a dev-team on the job.
If Python 2.7 was not EOL’ed the market share of Python 3 would have been significant less than today. The market share of Python 3 is due to the killing of Python 2. It has nothing to do with natural acceptance by the market ore with technical needs ore security necessity. The above discussion proves IMO objectively that there is no need for Python 3 because Python 2 can do the job today and in the future thanks to its modularity.
Third option
If Python (TM) stays unwilling to understand and teaming up with others for a new Py2-supplier does not work Plone can choose to maintain its own Py2-fork. The state Python 2 is in at this moment does not predict much work on this fork securitywise in the nearby future. Most work depends on the extra wants and needs of its users. Roughly calculated the maintaining of a Plone owned Py2-fork must be less work than the migration by all Plone users on all there Plone sites to Python 3 and every other Python-version next. The work done on this fork need to be compared to the work of all Plone users migrating all there Plone sites to Python 3 and its successors, for the check and balance between investment and profit. The benefits of a Plone owned Py2 fork are for instance: control, independence and the ability to use all Plone versions on one Python-stack. That can make Plone Legacy with its rich egg supply on PyPy a powerful competitor on the market without risking future development. The new Plone owned Py2-supplier keeps markets open and even can create new markets for Plone integrators and solution providers.
That is how to lift off work from the core developers, the release teams, the framework teams, admins, etc. And make Python 3 obsolete. In natural manner.
Hope this answers your questions.