<p dir="ltr">On 14 April 2015 at 11:19, Trishank Karthik Kuppusamy <<a href="mailto:trishank@nyu.edu">trishank@nyu.edu</a>> wrote:<br>
> On 14 April 2015 at 11:16, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
>> I agree. Even something as simple as a boolean that triggers a banner<br>
>> saying "this project is looking for a new maintainer" would be useful both<br>
>> from the perspective of project owners who want to move on or from the<br>
>> perspective of users who can't tell if a project is maintained based on how<br>
>> long it has been since a project uploaded a new version (which is why I<br>
>> think someone suggested sending an annual email asking for a human action to<br>
>> say "alive and kicking" to help determine if a project is completely<br>
>> abandoned).<br>
> <br>
> Yeah, I think Guido said something to this effect in his keynote.</p>
<p dir="ltr">Yep, Guido's keynote was the genesis of the thread. For folks that haven't seen it, the specific points of concern raised were:</p>
<p dir="ltr">* seeking a new maintainer from amongst their users<br>
* seeking help with enabling Python 3 support</p>
<p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<p dir="ltr">This thread regarding maintainers being able to more clearly communicate maintenance status to users also relates to my blog post (<a href="http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html">http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html</a>) regarding the fact that folks that:</p>
<p dir="ltr">a) don't personally need to ensure software they maintain works on old versions of Python; and <br>
b) aren't getting paid to ensure it works on old versions of Python;<br>
c) shouldn't feel obliged to provide such support for free</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Regards,<br>
Nick.</p>
<p dir="ltr">[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.</p>
<p dir="ltr">[2] <a href="http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/">http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/</a></p>
<p dir="ltr">-- <br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia</p>