8 ms·

Issue: find a new home for repos including Requests

162 points by maximilianroos 7y ago

Deimorz 7y ago
> Therefore, if you or your organization are open to the idea of monetary exchange for ownership of a repo / pypi project, please email me Am I somehow misinterpreting that, or was that really a blatant attempt to sell the repos and pypi ownership of some extremely popular Python libraries?
- ijpoijpoihpiuoh 7y ago
  So it seems. Would that be a problem for some reason?
  - Deimorz 7y ago
    "Buy this and you will be able to put any code you want into any project that uses Requests and doesn't carefully audit the changes in new versions" is potentially a pretty huge problem, yes. Similar issues have already happened with people buying or otherwise taking over popular NPM packages.
    - LyndsySimon 7y ago
      This immediately follows: > I am considering this an unlikely and rare situation. Only serious offers will be considered, and money won't influence maintainer-ship decisions.
    - JadeNB 7y ago
      > "Buy this and you will be able to put any code you want into any project that uses Requests and doesn't carefully audit the changes in new versions" is potentially a pretty huge problem, yes. Would not taking money somehow obviate the issue?
    - Spivak 7y ago
      I mean this isn't that weird. I'm sure a lot of companies would like to buy 'control' of the project and move it in the direction that the original maintainers didn't necessarily want to. Plus being the company/org that maintains requests is pretty good PR. There is absolutely an exchange of value here, no reason to assume that a change in maintainership means cash for malware.
    - ijpoijpoihpiuoh 7y ago
      IMO people should have a right to sell things they've made. I get that that is inconvenient to open source folks. And most of the time it will be fine. But, IMO, if this is a concern, someone should make it worth it to this owner not to sell it to a bad organization. It is just not good enough to say, "You can't sell this thing because it is inconvenient to me, someone with whom you have no contract and to whom you owe no duties."
      - bhaak 7y ago
        What about the other maintainers of the code? If you are the sole person that contributed code, that's fine, but what about codebases that had lots of code contributed by other people?
        LyndsySimon 7y ago
        What’s being transferred here isn’t ownership of all the code, but control of the project and the IP associated with it.
- AmrMostafa 7y ago
  > Only serious offers will be considered, and money won't influence maintainer-ship decisions
fibers 7y ago
what will this mean for an async version of requests?
- kamyarg 7y ago
  Someone more responsible can actually make it happen.
  - hartator 7y ago
    kennethreitz has not been responsible? `requests` is my favorite http library in all languages so far.
    - kamyarg 7y ago
      Take a look into pipenv issues and how he handles legitimate broken features such as --keep-outdated and you will know[1]. Requests I agree has been very stable. Also as an extra reading regarding async support for requests take a look at this article by a Python core Developer(Nathaniel J. Smith): "Why I'm not collaborating with Kenneth Reitz" https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet... [1] https://github.com/pypa/pipenv/issues/1554 https://github.com/pypa/pipenv/issues/1554
    - jrimbault 7y ago
      He has shown patterns of bad behaviors. One recent example of the top of my head : - https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet... - and HN's thread https://news.ycombinator.com/item?id=19826680 https://news.ycombinator.com/item?id=19826680 Request has not been maintained by Reitz for some time now (meaning he hasn't contributed).
- florimondmanca 7y ago
  On a side note, there has been work on an async HTTP client in a separate project conducted by the Encode organization here: https://github.com/encode/http3 https://github.com/encode/http3
kamyarg 7y ago
Good, I hope pipenv is also included. Would prevent comments such as "I like the current implementation", "thanks for the feedback, but my ego says no" and "I have no idea" in some of the most important projects of the Python Community. Or passive-aggressive closure of issues that are clearly affecting people and are issues. https://github.com/pypa/pipenv/issues/966#issuecomment-346209785 https://github.com/pypa/pipenv/issues/966#issuecomment-34620... Don't get me wrong, I appreciate requests especially, but a maintainer should be humble also and respect other people independent of how rockstar he is or feels. I am very happy to see Organisations/people such as pocoo - Armin Ronacher and Sentry - David Cramer etc. are already stepping up to make sure these libs land in the right place and continue to be useful to the community. Complementary article: https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
- d4mi3n 7y ago
  While you have a point about behavior, let’s not forget that the library is _free_. Maintaining such projects is often a hard, thankless job. The only obligation any maintainer has is to abide by whatever terms they release their code under. I don’t think it’s reasonable to expect professional support from any project maintained by a single individual.
  - geofft 7y ago
    I don't think that's the only obligation. The other major obligation of a maintainer is to not hurt or impede others in the progress. Hurting others (which, to be clear, I'm not claiming has happened here) is pretty easy to do. For instance, someone opens a request, you say "Patches welcome," they spend time writing a long implementation, and you say "Never mind, I don't like this feature." You're wasting their time, and had you just not said anything, they would have been in a better place. Writing software with backdoors, or recklessly writing software in a way that makes it prone to vulnerabilities, also hurts people. Impeding others is a softer form of this. There isn't the ability for five hundred Python dependency management projects to all exist and be successful. If you get your project listed as the standard recommendation https://packaging.python.org/guides/tool-recommendations/ https://packaging.python.org/guides/tool-recommendations/ , you are effectively promising that it is suitable for people who need a tool like it, and in turn that you have both the willingness and time to make it happen. You don't have to get it so listed. (You can also, of course, change your mind and de-list it.) You can absolutely say, this is a project for my own needs and I don't want to accept support requests at all. Then, at least, someone else can create a similar tool - either their own, or based on your open-source code (and abiding by your license). But if you're signed up to be the standard tool, you're impeding others who actually do have the time and bandwidth for improvements and would be willing to make a competing tool if you're not able to stand by your commitments.
gizmo385 7y ago
Why was the name of this post adjusted to remove mention of Kenneth? I think that the fact that this is Kenneth Reitz is a major element of this story.
- dang 7y ago
  We often remove names from titles, because HN works better when the focus is on content rather than personalities. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0&query=by:dang%20personalities https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme... A nice fix would be if github.com/username could appear to the right of the title instead of just github.com. That's on our list, but not implemented yet.
  - gizmo385 7y ago
    But in this case, isn't a large percentage of the content predicated on the person generating the content?
    - dang 7y ago
      For sure, but how much that's a good thing vs. a bad thing is not so clear. This is one of those cases (like https://news.ycombinator.com/item?id=20186280 https://news.ycombinator.com/item?id=20186280) where it's useful to have exactly one thing you're optimizing for. It helps you know what to do in situations that would otherwise be head-scratchers, and the consequences are often surprising yet rather easy to derive. On HN, the one thing we're optimizing for is intellectual curiosity. That's merely one kind of curiosity and by no means the most powerful. Interest in personalities, especially celebrities or the infamous, tends to be fuelled by one of the higher-octane varieties—call it social curiosity. There's nothing wrong with social curiosity. It's human. But intellectual curiosities are smaller fish than that, and on HN we need to do things to prevent the bigger fish from eating them all up. Everything in our bag of moderation tricks is there to help with that.
      - AlexCoventry 7y ago
m463 7y ago
Why can't requests be adopted by python?
- LyndsySimon 7y ago
  It looks like it likely will be brought under the PSF umbrella. I'm not sure what has prompted this, but Kenneth won't leave them to wither and die. He understands their importance and if he's handing them off, he'll make sure they are in good hands.
  - _wmd 7y ago
    After the smear campaign and mass roasting he received less than 2 months ago, it's not hard to understand why any charitable intentions he had may have completely dried up
    - claudeganon 7y ago
      Context? I follow a lot of Python news, but never saw anything about this.
      - deleted 7y ago
        [deleted]
      - dwaltrip 7y ago
        There was a bunch of hubbub around a preemptive promotion of the `pipenv` package to be _the_ package for managing dependencies in python. There was also a period when development and releases was happening in a somewhat frenzied manner and some github issues were being handled / closed in an antagonistic fashion. I don't know how extensive these issues were, but I remember seeing a few examples that seemed to back up the claims. At risk of potentially stepping into overly personal territory: As I understand it, Kenneth was unfortunately dealing with some mental health stuff during part of that time period. He posted a blog post that mentioned this. Here's one related HN discussion: https://news.ycombinator.com/item?id=18612590 https://news.ycombinator.com/item?id=18612590 My bias: During my usage of pipenv, while it seemed very promising, I felt that it wasn't fully production ready and had some problematic warts.
zokier 7y ago
I guess this is good thing, but I can't help but think that there would have been better way to do this; the process seems pretty rapid haphazard first-come first-serve situation. Most importantly, PSF indicated interest for these in under 2 hours (which is pretty quick response) but there are already some repos that are being transferred to other people. Surely he could have waited at least one day for responses before actually starting to move things?
- geofft 7y ago
  It's about as haphazard as anything else he does. See "To those that criticize the project..." on https://journal.kennethreitz.org/entry/r-python https://journal.kennethreitz.org/entry/r-python .
  - number6 7y ago
    Oh I didnt knew he made pipenv AND requests - both are very fine projects trusted in production. On Pipenv? Why are people so negative about it? If you don't like it - just use another tool. Its not like its M$ or systemD which both are a pain to get rid of if your organisation or distro decided to implement
    - akerl_ 7y ago
      A lot of the complaints about Pipenv were that both its own docs and some of the material on the Python package index suggested that pipenv was a new “official” tool recommended by the Python core team, which isn’t the case.
      - dragonwriter 7y ago
        Didn't it really suggest the recommendation was from the core team, and not PyPA?
    - majewsky 7y ago
      > systemD Honest question: Do people write systemd with incorrect capitalization out of spite, or because they just don't know better? It just irks me, like if someone was writing LaTeX as just Latex.
ricardobeat 7y ago
The author of event-stream on npm got so much flak for handing out the package when he couldn't maintain it anymore, yet I see no mention of any concerns here. Aren't the same risks of malicious takeover present, or is the python module environment somehow safer?
- awithrow 7y ago
  If I recall, the flak wasn't around handing off the package. The flack was for the lack of due diligence in picking a new maintainer. The same risks are present for sure but at least the process is taking place in the open.
  - Master_Odin 7y ago
    Yeah, it was this really. The author had largely abandoned the project, someone emailed him asking for it (who had no github presence whatsoever), and the author obliged. Here, there's in theory the effort that the people being given the project have been more vetted and have to have some amount of github presence to get a repo.
- cfors 7y ago
  This is actually a much more responsible way to go about it than the event-stream issue, since it is being done in a public forum (Github issues). Event-stream was given away over an Email without an announcement [0]. Of course, the risks are still there for malicious takeover, but I think will be minimized due to the owner's notoriety and the amount of press this has already seen just on GitHub. I am pretty sure the maintainers of Pip will be keeping an eye on this over the next few months in case of intervening. [0] https://github.com/dominictarr/event-stream/issues/116#issuecomment-440927400 https://github.com/dominictarr/event-stream/issues/116#issue...
Fellshard 7y ago
This is why I fear our dependence on 'authoritative versions' of libraries. We've already seen the perils of ownership transfers being used to embed vulnerabilities or outright malware, all under the pretense that the new versions are still authoritative and trusted. A more mature approach seems to me to be to ensure forks are first-class, and that dependence is restricted to a specific fork: either by full name (@owner/repository), or - better yet - by Git coordinate (url/sha). This means an abandoned project can be picked up by any number of people. The primary cost I can see is one of cohesion and divergent enhancement under the same library name. But in a way, we have ways to refer to that already. "Mordenkainen's Magic Missile" - the owner + name coordinate already has a natural representation. And perhaps once we've made that step, more progress can be made to help forks coordinate common changes and improvements where possible, or to split into more distinct artifacts where applicable.
- johannes1234321 7y ago
  Another view: It is an issue of libraries owned by individual developers. I commonly argue for organisations of some kind to take over ownership over "relevant" libraries. This of course is nothing which can be enforced. Benefits are not only reduction of "bus factor" on a single developer, but also enables review procedures. Depending on the project this could be a custom organisation, a "generic" organisation like ASF. Libraries owned by a single developer for me are a notable risk, when taking them as dependency.
- em-bee 7y ago
  could you elaborate on how that is supposed to work? how would a dependence on a fork help with the maintainer transfer risk?
  - Fellshard 7y ago
    Let us say the current mechanism - handing a library from one owner to another - is used. If the new owner acts in bad faith, what recourse do you have to maintain a non-abused version of the library? Can you replace the owner's authoritative builds with your own? If you instead have no 'authoritative version' of a library, you lose some elegance to be sure; you can no longer say simply, 'let's use Magic Missile!' as there may be multiple forks of what could be labeled the original 'Magic Missile' library. But what you gain is the ability to maintain multiple versions of the library, and to be able to point out which versions are poorly maintained or even hazardous: "We don't use Drizzt's Magic Missile, it was tailored pretty heavily towards his own projects." "If I recall, Persophone's Magic Missile included a hidden cryptominer. Avoid at all costs."
ausjke 7y ago
why does genius coder like him still look for a job? can python foundation have some permanent fellowship for people like him?
andrewstuart 7y ago
If there was a KeepAlive system for paying maintainers then this sort of thing might be less likely to happen. Not sponsorship, not donations, not support subscriptions - those concepts are not the same a simple payment for nothing more than Keeping a project funded and Alive. KeepAlive payments in which companies pay a minimum $100month fee to KeepAlive projects that they depend on. How many companies have a dependency on Kenneth's requests module? Alot. Hundreds if not thousands. And if there was a self interest obligation for companies to make monthly KeepAlive payments then those companies would not be now wondering what it means to have so many projects that depend on Requests now without the project author. UPDATE: having read https://journal.kennethreitz.org/entry/r-python https://journal.kennethreitz.org/entry/r-python maybe Kenneth would be exiting anyway. But who knows, maybe if companies actually paid to Keep their dependencies Alive then people like Kenneth might remain engaged.
Sir_Cmpwn 7y ago
To anyone reading this, who is also struggling as a free software maintainer: I'm sympathetic to your position, and I have a guide here on how to responsibly step back from your projects at the pace you need, be it today or next week or next year. https://drewdevault.com/2018/12/04/How-to-abandon-a-FLOSS-project.html https://drewdevault.com/2018/12/04/How-to-abandon-a-FLOSS-pr... If you need specific advice or a sympathetic ear, please feel free to reach out: sir@cmpwn.com. I know free software maintainership can be hard. It's too difficult to write large/important free software projects alone. I've also written about my approach to building a healthy community of engaged contributors and co-maintainers to make sure your own investment & workload remains healthy, along with that of your collaborators: https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-projects.html https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-proje... This one is much more subjective, YMMV.

> Therefore, if you or your organization are open to the idea of monetary exchange for ownership of a repo / pypi project, please email me Am I somehow misinterpreting that, or was that really a blatant attempt to sell the repos and pypi ownership of some extremely popular Python libraries?

ijpoijpoihpiuoh 7y ago
So it seems. Would that be a problem for some reason?
- Deimorz 7y ago
  "Buy this and you will be able to put any code you want into any project that uses Requests and doesn't carefully audit the changes in new versions" is potentially a pretty huge problem, yes. Similar issues have already happened with people buying or otherwise taking over popular NPM packages.
  - LyndsySimon 7y ago
    This immediately follows: > I am considering this an unlikely and rare situation. Only serious offers will be considered, and money won't influence maintainer-ship decisions.
  - JadeNB 7y ago
    > "Buy this and you will be able to put any code you want into any project that uses Requests and doesn't carefully audit the changes in new versions" is potentially a pretty huge problem, yes. Would not taking money somehow obviate the issue?
  - Spivak 7y ago
    I mean this isn't that weird. I'm sure a lot of companies would like to buy 'control' of the project and move it in the direction that the original maintainers didn't necessarily want to. Plus being the company/org that maintains requests is pretty good PR. There is absolutely an exchange of value here, no reason to assume that a change in maintainership means cash for malware.
  - ijpoijpoihpiuoh 7y ago
    IMO people should have a right to sell things they've made. I get that that is inconvenient to open source folks. And most of the time it will be fine. But, IMO, if this is a concern, someone should make it worth it to this owner not to sell it to a bad organization. It is just not good enough to say, "You can't sell this thing because it is inconvenient to me, someone with whom you have no contract and to whom you owe no duties."
    - bhaak 7y ago
      What about the other maintainers of the code? If you are the sole person that contributed code, that's fine, but what about codebases that had lots of code contributed by other people?
      - LyndsySimon 7y ago
        What’s being transferred here isn’t ownership of all the code, but control of the project and the IP associated with it.
AmrMostafa 7y ago
> Only serious offers will be considered, and money won't influence maintainer-ship decisions

fibers 7y ago

what will this mean for an async version of requests?

kamyarg 7y ago
Someone more responsible can actually make it happen.
- hartator 7y ago
  kennethreitz has not been responsible? `requests` is my favorite http library in all languages so far.
  - kamyarg 7y ago
    Take a look into pipenv issues and how he handles legitimate broken features such as --keep-outdated and you will know[1]. Requests I agree has been very stable. Also as an extra reading regarding async support for requests take a look at this article by a Python core Developer(Nathaniel J. Smith): "Why I'm not collaborating with Kenneth Reitz" https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet... [1] https://github.com/pypa/pipenv/issues/1554 https://github.com/pypa/pipenv/issues/1554
  - jrimbault 7y ago
    He has shown patterns of bad behaviors. One recent example of the top of my head : - https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet... - and HN's thread https://news.ycombinator.com/item?id=19826680 https://news.ycombinator.com/item?id=19826680 Request has not been maintained by Reitz for some time now (meaning he hasn't contributed).
florimondmanca 7y ago
On a side note, there has been work on an async HTTP client in a separate project conducted by the Encode organization here: https://github.com/encode/http3 https://github.com/encode/http3

kamyarg 7y ago

Good, I hope pipenv is also included. Would prevent comments such as "I like the current implementation", "thanks for the feedback, but my ego says no" and "I have no idea" in some of the most important projects of the Python Community. Or passive-aggressive closure of issues that are clearly affecting people and are issues. https://github.com/pypa/pipenv/issues/966#issuecomment-346209785 https://github.com/pypa/pipenv/issues/966#issuecomment-34620... Don't get me wrong, I appreciate requests especially, but a maintainer should be humble also and respect other people independent of how rockstar he is or feels. I am very happy to see Organisations/people such as pocoo - Armin Ronacher and Sentry - David Cramer etc. are already stepping up to make sure these libs land in the right place and continue to be useful to the community. Complementary article: https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...

d4mi3n 7y ago
While you have a point about behavior, let’s not forget that the library is _free_. Maintaining such projects is often a hard, thankless job. The only obligation any maintainer has is to abide by whatever terms they release their code under. I don’t think it’s reasonable to expect professional support from any project maintained by a single individual.
- geofft 7y ago
  I don't think that's the only obligation. The other major obligation of a maintainer is to not hurt or impede others in the progress. Hurting others (which, to be clear, I'm not claiming has happened here) is pretty easy to do. For instance, someone opens a request, you say "Patches welcome," they spend time writing a long implementation, and you say "Never mind, I don't like this feature." You're wasting their time, and had you just not said anything, they would have been in a better place. Writing software with backdoors, or recklessly writing software in a way that makes it prone to vulnerabilities, also hurts people. Impeding others is a softer form of this. There isn't the ability for five hundred Python dependency management projects to all exist and be successful. If you get your project listed as the standard recommendation https://packaging.python.org/guides/tool-recommendations/ https://packaging.python.org/guides/tool-recommendations/ , you are effectively promising that it is suitable for people who need a tool like it, and in turn that you have both the willingness and time to make it happen. You don't have to get it so listed. (You can also, of course, change your mind and de-list it.) You can absolutely say, this is a project for my own needs and I don't want to accept support requests at all. Then, at least, someone else can create a similar tool - either their own, or based on your open-source code (and abiding by your license). But if you're signed up to be the standard tool, you're impeding others who actually do have the time and bandwidth for improvements and would be willing to make a competing tool if you're not able to stand by your commitments.

gizmo385 7y ago

Why was the name of this post adjusted to remove mention of Kenneth? I think that the fact that this is Kenneth Reitz is a major element of this story.

dang 7y ago
We often remove names from titles, because HN works better when the focus is on content rather than personalities. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0&query=by:dang%20personalities https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme... A nice fix would be if github.com/username could appear to the right of the title instead of just github.com. That's on our list, but not implemented yet.
- gizmo385 7y ago
  But in this case, isn't a large percentage of the content predicated on the person generating the content?
  - dang 7y ago
    For sure, but how much that's a good thing vs. a bad thing is not so clear. This is one of those cases (like https://news.ycombinator.com/item?id=20186280 https://news.ycombinator.com/item?id=20186280) where it's useful to have exactly one thing you're optimizing for. It helps you know what to do in situations that would otherwise be head-scratchers, and the consequences are often surprising yet rather easy to derive. On HN, the one thing we're optimizing for is intellectual curiosity. That's merely one kind of curiosity and by no means the most powerful. Interest in personalities, especially celebrities or the infamous, tends to be fuelled by one of the higher-octane varieties—call it social curiosity. There's nothing wrong with social curiosity. It's human. But intellectual curiosities are smaller fish than that, and on HN we need to do things to prevent the bigger fish from eating them all up. Everything in our bag of moderation tricks is there to help with that.
    - AlexCoventry 7y ago

m463 7y ago

Why can't requests be adopted by python?

LyndsySimon 7y ago
It looks like it likely will be brought under the PSF umbrella. I'm not sure what has prompted this, but Kenneth won't leave them to wither and die. He understands their importance and if he's handing them off, he'll make sure they are in good hands.
- _wmd 7y ago
  After the smear campaign and mass roasting he received less than 2 months ago, it's not hard to understand why any charitable intentions he had may have completely dried up
  - claudeganon 7y ago
    Context? I follow a lot of Python news, but never saw anything about this.
    - deleted 7y ago
      [deleted]
    - dwaltrip 7y ago
      There was a bunch of hubbub around a preemptive promotion of the `pipenv` package to be _the_ package for managing dependencies in python. There was also a period when development and releases was happening in a somewhat frenzied manner and some github issues were being handled / closed in an antagonistic fashion. I don't know how extensive these issues were, but I remember seeing a few examples that seemed to back up the claims. At risk of potentially stepping into overly personal territory: As I understand it, Kenneth was unfortunately dealing with some mental health stuff during part of that time period. He posted a blog post that mentioned this. Here's one related HN discussion: https://news.ycombinator.com/item?id=18612590 https://news.ycombinator.com/item?id=18612590 My bias: During my usage of pipenv, while it seemed very promising, I felt that it wasn't fully production ready and had some problematic warts.

zokier 7y ago

I guess this is good thing, but I can't help but think that there would have been better way to do this; the process seems pretty rapid haphazard first-come first-serve situation. Most importantly, PSF indicated interest for these in under 2 hours (which is pretty quick response) but there are already some repos that are being transferred to other people. Surely he could have waited at least one day for responses before actually starting to move things?

geofft 7y ago
It's about as haphazard as anything else he does. See "To those that criticize the project..." on https://journal.kennethreitz.org/entry/r-python https://journal.kennethreitz.org/entry/r-python .
- number6 7y ago
  Oh I didnt knew he made pipenv AND requests - both are very fine projects trusted in production. On Pipenv? Why are people so negative about it? If you don't like it - just use another tool. Its not like its M$ or systemD which both are a pain to get rid of if your organisation or distro decided to implement
  - akerl_ 7y ago
    A lot of the complaints about Pipenv were that both its own docs and some of the material on the Python package index suggested that pipenv was a new “official” tool recommended by the Python core team, which isn’t the case.
    - dragonwriter 7y ago
      Didn't it really suggest the recommendation was from the core team, and not PyPA?
  - majewsky 7y ago
    > systemD Honest question: Do people write systemd with incorrect capitalization out of spite, or because they just don't know better? It just irks me, like if someone was writing LaTeX as just Latex.

ricardobeat 7y ago

The author of event-stream on npm got so much flak for handing out the package when he couldn't maintain it anymore, yet I see no mention of any concerns here. Aren't the same risks of malicious takeover present, or is the python module environment somehow safer?

awithrow 7y ago
If I recall, the flak wasn't around handing off the package. The flack was for the lack of due diligence in picking a new maintainer. The same risks are present for sure but at least the process is taking place in the open.
- Master_Odin 7y ago
  Yeah, it was this really. The author had largely abandoned the project, someone emailed him asking for it (who had no github presence whatsoever), and the author obliged. Here, there's in theory the effort that the people being given the project have been more vetted and have to have some amount of github presence to get a repo.
cfors 7y ago
This is actually a much more responsible way to go about it than the event-stream issue, since it is being done in a public forum (Github issues). Event-stream was given away over an Email without an announcement [0]. Of course, the risks are still there for malicious takeover, but I think will be minimized due to the owner's notoriety and the amount of press this has already seen just on GitHub. I am pretty sure the maintainers of Pip will be keeping an eye on this over the next few months in case of intervening. [0] https://github.com/dominictarr/event-stream/issues/116#issuecomment-440927400 https://github.com/dominictarr/event-stream/issues/116#issue...

Fellshard 7y ago

This is why I fear our dependence on 'authoritative versions' of libraries. We've already seen the perils of ownership transfers being used to embed vulnerabilities or outright malware, all under the pretense that the new versions are still authoritative and trusted. A more mature approach seems to me to be to ensure forks are first-class, and that dependence is restricted to a specific fork: either by full name (@owner/repository), or - better yet - by Git coordinate (url/sha). This means an abandoned project can be picked up by any number of people. The primary cost I can see is one of cohesion and divergent enhancement under the same library name. But in a way, we have ways to refer to that already. "Mordenkainen's Magic Missile" - the owner + name coordinate already has a natural representation. And perhaps once we've made that step, more progress can be made to help forks coordinate common changes and improvements where possible, or to split into more distinct artifacts where applicable.

johannes1234321 7y ago
Another view: It is an issue of libraries owned by individual developers. I commonly argue for organisations of some kind to take over ownership over "relevant" libraries. This of course is nothing which can be enforced. Benefits are not only reduction of "bus factor" on a single developer, but also enables review procedures. Depending on the project this could be a custom organisation, a "generic" organisation like ASF. Libraries owned by a single developer for me are a notable risk, when taking them as dependency.
em-bee 7y ago
could you elaborate on how that is supposed to work? how would a dependence on a fork help with the maintainer transfer risk?
- Fellshard 7y ago
  Let us say the current mechanism - handing a library from one owner to another - is used. If the new owner acts in bad faith, what recourse do you have to maintain a non-abused version of the library? Can you replace the owner's authoritative builds with your own? If you instead have no 'authoritative version' of a library, you lose some elegance to be sure; you can no longer say simply, 'let's use Magic Missile!' as there may be multiple forks of what could be labeled the original 'Magic Missile' library. But what you gain is the ability to maintain multiple versions of the library, and to be able to point out which versions are poorly maintained or even hazardous: "We don't use Drizzt's Magic Missile, it was tailored pretty heavily towards his own projects." "If I recall, Persophone's Magic Missile included a hidden cryptominer. Avoid at all costs."

ausjke 7y ago

why does genius coder like him still look for a job? can python foundation have some permanent fellowship for people like him?

andrewstuart 7y ago

If there was a KeepAlive system for paying maintainers then this sort of thing might be less likely to happen. Not sponsorship, not donations, not support subscriptions - those concepts are not the same a simple payment for nothing more than Keeping a project funded and Alive. KeepAlive payments in which companies pay a minimum $100month fee to KeepAlive projects that they depend on. How many companies have a dependency on Kenneth's requests module? Alot. Hundreds if not thousands. And if there was a self interest obligation for companies to make monthly KeepAlive payments then those companies would not be now wondering what it means to have so many projects that depend on Requests now without the project author. UPDATE: having read https://journal.kennethreitz.org/entry/r-python https://journal.kennethreitz.org/entry/r-python maybe Kenneth would be exiting anyway. But who knows, maybe if companies actually paid to Keep their dependencies Alive then people like Kenneth might remain engaged.

Sir_Cmpwn 7y ago

To anyone reading this, who is also struggling as a free software maintainer: I'm sympathetic to your position, and I have a guide here on how to responsibly step back from your projects at the pace you need, be it today or next week or next year. https://drewdevault.com/2018/12/04/How-to-abandon-a-FLOSS-project.html https://drewdevault.com/2018/12/04/How-to-abandon-a-FLOSS-pr... If you need specific advice or a sympathetic ear, please feel free to reach out: sir@cmpwn.com. I know free software maintainership can be hard. It's too difficult to write large/important free software projects alone. I've also written about my approach to building a healthy community of engaged contributors and co-maintainers to make sure your own investment & workload remains healthy, along with that of your collaborators: https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-projects.html https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-proje... This one is much more subjective, YMMV.