[Distutils] pip/warehouse feature idea: "help needed"

Nick Coghlan ncoghlan at gmail.com
Wed Apr 15 02:14:32 CEST 2015


On 14 April 2015 at 11:19, Trishank Karthik Kuppusamy <trishank at nyu.edu>
wrote:
> On 14 April 2015 at 11:16, Brett Cannon <brett at python.org> wrote:
>> I agree. Even something as simple as a boolean that triggers a banner
>> saying "this project is looking for a new maintainer" would be useful
both
>> from the perspective of project owners who want to move on or from the
>> perspective of users who can't tell if a project is maintained based on
how
>> long it has been since a project uploaded a new version (which is why I
>> think someone suggested sending an annual email asking for a human
action to
>> say "alive and kicking" to help determine if a project is completely
>> abandoned).
>
> Yeah, I think Guido said something to this effect in his keynote.

Yep, Guido's keynote was the genesis of the thread. For folks that haven't
seen it, the specific points of concern raised were:

* seeking a new maintainer from amongst their users
* seeking help with enabling Python 3 support

Past suggestions for social features have related to providing users with a
standard way to reach maintainers and each other, and I'd prefer to leave
maintainers in full control of that aspect of the maintainer experience.
I'm not alone in feeling that way, hence why such features tend not to be
viewed especially positively.

The one thing that *only* PyPI can provide is the combination of a
publication channel for maintainers to reach their user base without either
side needing to share contact information they aren't already sharing,
together with the creation of the clear understanding that providing
sustaining engineering for a piece of software represents a significant
time commitment that users benefiting from an open source maintainer's
generosity should respect.

This thread regarding maintainers being able to more clearly communicate
maintenance status to users also relates to my blog post (
http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html)
regarding the fact that folks that:

a) don't personally need to ensure software they maintain works on old
versions of Python; and
b) aren't getting paid to ensure it works on old versions of Python;
c) shouldn't feel obliged to provide such support for free

Supporting legacy platforms is generally tedious work that isn't inherently
interesting or rewarding. Folks that want such legacy platform support
should thus be expecting to have to pay for it, and demanding it for free
is unreasonable.

The perception that open source software is provided by magic internet
pixies that don't need to eat (or at the very least to be thanked for the
time their generosity has saved us) is unfortunately widespread and
pernicious [1], and PyPI is in a position to help shift that situation to
one where open source maintainers at least have the opportunity to clearly
explain the sustaining engineering model backing their software while
deflecting any criticism for the mere existence of such explanations onto
the PyPI maintainers rather than having to cope with any negative feedback
themselves.

Regards,
Nick.

[1] As far as *how* that mistaken perception that failing to adequately
compensate open source developers is OK became so widespread, my own theory
is that it stems from the fact that open source was popularised first in
the context of Linux, which relies heavily on the corporate patronage model
where companies like Red Hat make money from customers that often aren't
interested in technology for its own sake, while making the underlying
software freely available as a basis for shared collaboration and
experimentation. I personally like that model [2], but plenty of folks have
entirely reasonable concerns about it and hence need to support their open
source work in other ways. My view is that appropriately addressing that
complex situation involves actively challenging the common assumption that
adequately compensating the project developers for their work is somebody
else's problem, and thus that it makes sense to eventually build the
ability to issue that challenge directly into the software distribution
infrastructure. It's not at the top of the priority list right now, but
Guido's keynote made me realise it should be on the list somewhere.

[2]
http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/

-- 
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150414/869d634c/attachment.html>


More information about the Distutils-SIG mailing list