Although this wasn’t formally written as a “question for Steering Council candidates”, I kinda sorta take it as such, since it’s an important topic.
The highest-order bit, for me, is creating a sustainable cadence of development in Python (which is mostly CPython right now, but perhaps won’t always be). This should respect the tradition of quality work done by our community’s volunteer development model. But it should also recognize that we are failing to engage commercial users of the language, and that gap could threaten the long-term growth and health of our language.
I have been somewhat outspoken in my view that we need to form an auxiliary capability to engage commercial development dollars, to fund both the upkeep & maintenance of core Python dev infrastructure as well as to put real velocity behind fixing outstanding bugs, reviewing PRs, and tackling larger “thorny” work that would be hard to drive based solely on relying on volunteers.
Oftentimes it gets repeated that “just give devs money” solves the OSS sustainability problem. I agree somewhat, but I hold that that only works in the small scale. Once the dollars and the level of effort gets to something the size of Python, we need to treat the project and product management of Python-the-language as an intentional, explicitly coordinated group effort. I believe this should and can be done in concert with organic coordination of the volunteer group, and under the charter of the PSF.
The PyData community has suffered “user hypergrowth” harder and faster than most other tribes of Py, as the last three years have seen a global spike in machine learning and AI. Watching the strain put on my friends and colleagues in that community - and watching various different sub-communities try to respond to it - has really changed how I view the relationship between truly sustainable OSS and corporate usage and corporate dollars.
I was never a die-hard FSF-style open source purist, but my main point of learning is that when the world decides to really start using your free beer/free speech/free code, you had better be ready to innovate as hard as your users demand, or else they will embrace, fork, and leave you behind. We’re seeing this now with the fragmentation in core array libraries that big, commercial, open-source deep learning frameworks are imposing on the user community. We’re starting to see it with “proprietarization” of Jupyter by each major cloud vendor. And, I see similar dynamics with big commercial users of Python making private forks of CPython (or making plans to maintain internal forks of 2.x at the end of the year).
These latter examples demonstrate the failure of our community to scale product management, and to apply meaningful dollars/resources towards coherent software development. I don’t mean that statement in a harsh or critical tone, but rather one of self-awareness. Just asking everyone to row harder, when commercial ships pull up alongside with steam boilers, is not a sufficient answer.
I hope that the new Steering Council - whether I’m on it or not - will meaningfully engage on this topic, because I think it’s an existential meta-capability for our language and our community.
)