PEP 803: add section for maintainer comments

Author: ngoldbaum

peps/pep-0803.rst

@@ -50,7 +50,6 @@ for free-threading should be prepared and defined for Python 3.15”.
 
 This PEP proposes the Stable ABI for free-threading.
 
-
 Background
 ----------
 
@@ -80,6 +79,75 @@ were a part of older versions.
 This PEP proposes additional API limitations, as required to be compatible
 with both GIL-enabled and free-threaded builds of CPython.
 
+Ecosystem maintainers want decreased maintenance burden
+-------------------------------------------------------
+
+A major advantage of the limited API and stable ABI wheels is that new
+Python versions are supported on the day of release. Without stable ABI
+wheels, maintainers are left with a choice between closely following CPython
+releases and producing wheels during CPython beta periods or dealing with
+inevitable user requests for support for new CPython versions.
+
+Cryptography
+^^^^^^^^^^^^
+
+The cryptography project shipped 48 wheel files with their `most recent release
+<https://pypi.org/project/cryptography/46.0.5/#files>`_. Cryptography is
+somewhat unusual in that they ship 14 wheels each for both the ``cp38`` and
+``cp311`` stable ABIs to enable optimizations available in newer limited API
+versions. They also ship 14 additional ``cp314t`` wheels and 6 wheels for
+pypy. If there is no free-threaded stable ABI, then with Python 3.15,
+cryptography will be using roughtly the same amount of space on PyPI to support
+two versions of the free-threaded build as *all* non-EOL versions of the
+GIL-enabled build.
+
+Cryptography maintainer Alex Gaynor `expressed a desire
+<https://discuss.python.org/t/making-pyobject-opaque-in-the-limited-api/77206/2>`_
+on discourse for a free-threaded stable ABI:
+
+    Just to state this explicitly from the PyCA maintainers perspective, as
+    long as we have O(1) builds, that’s ok. What we can’t/won’t do is O(n)
+    where we need new builds for every Python release.
+
+moocore
+^^^^^^^
+
+The moocore project `ships seven abi3 wheels
+<https://pypi.org/project/moocore/0.2.0/#files>`_. It has a much smaller
+userbase than cryptography and has a smaller appetite for build complexity. When
+the topic of adding support for the free-threaded build `came up on the moocore
+issue tracker <https://github.com/multi-objective/moocore/issues/37>`_,
+maintainer Manuel López-Ibáñez let the person reporting the issue know that:
+
+    The free-threading versions are still experimental so each new
+    free-threading python version will need its own wheels.
+
+    Moreover, since free-threading is still experimental and not the default,
+    there may be bugs that only the Python developers can fix. I would expect
+    most users of moocore and pymoo to use the default non-free-threaded version
+    of Python 3.14.
+
+    [...]
+
+    **I don't want to build for 3.14 free-threading unless you really need it.**
+
+Later, after discovering the tracking issue for supporting the limited API on the
+free-threaded build, he commented:
+
+    By the way, python/cpython#111506 is about extending the stable ABI to
+    support free-threaded Python. If they do that, then the builds of moocore
+    will work in both classical and free-threaded Python versions, without
+    needing to build new wheels for each Python version.
+
+    [...]
+
+    I will revisit this again once Python 3.15 is released. Hopefully the ABI
+    will be stable (or even better, free-threading will be the default).
+
+These two libraries -- cryptography and moocore -- are on opposite sides of the
+maintainer bandwidth spectrum, but both would still really like to have a stable
+ABI on the free-threaded build they can use to ship wheels and reduce their
+maintenance burden.
 
 Rationale
 =========