
Issue: find a new home for repos including Requests - maximilianroos
https://github.com/not-kennethreitz/team/issues/21
======
kamyarg
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-34620...](https://github.com/pypa/pipenv/issues/966#issuecomment-346209785)

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-
kennet...](https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-
reitz/)

~~~
d4mi3n
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
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.

~~~
d4mi3n
Excellent points I had not considered.

If as you say, somebody released code saying that it was something they were
willing to support, it’s reasonable to expect said author to stand by their
statements.

That said, this seems like it would be a more implicit expectation than an
explicit agreement in many cases. How could a community enforce good behavior
in this regard?

Going by your previous example, would it be reasonable for the recommended
list of libraries to be more carefully curated for people on such a way that
only stable _and_ well supported libraries are put forward? Putting hard
requirements on official recommendations seems like it’s be a fairly simple
way to avoid such situations.

------
zokier
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
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
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_
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
Didn't it really suggest the recommendation was from the core team, and not
PyPA?

------
Sir_Cmpwn
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-
pr...](https://drewdevault.com/2018/12/04/How-to-abandon-a-FLOSS-project.html)

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-
proje...](https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-
projects.html)

This one is much more subjective, YMMV.

------
Fellshard
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.

~~~
em-bee
could you elaborate on how that is supposed to work? how would a dependence on
a fork help with the maintainer transfer risk?

~~~
Fellshard
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."

~~~
em-bee
so this is not a technical change but a change of presentation and perception.
instead of one person or team having the authority, there is a community
notion of who can be trusted.

this does exist. and it seems to happen when authority falls down or is not
there to begin with. for example several community builds around distributions
for the GPD pocket emerged, and some lived longer than others and some where
more reliable than others.

in fact the emergence of linux distributions themselves follows this model.
each distribution is packaging applications they did not create, and are hence
not the owners of the authoritative builds. and we pick distributions based on
which one does the best job.

of course distributions create their own authority on their collection, but
the principle remains. they also may easily switch the source for their
packages. i do remember a few examples where this has happened.

another area where this can be seen is with binary builds for projects where
the original developers only release the source. it's the same dynamic. build
your own, or pick a community contributed build by someone else. either way
noone gets to use the authoritative builds because they don't exist. (or they
exist only for one platform, in which case the situation is limited to those
who are on different platforms for which there are no authoritative builds)

~~~
Fellshard
It's both a matter of perception and of tooling.

Consider the Java ecosystem. Dependency targets are specified by coordinates
of both group and artifact, which satisfies the above separation fairly well,
to the best of my knowledge.

Consider the NPM and rubygems ecosystems: they specify dependencies by the
name of the library alone, implicitly enforcing the 'authorized artifact'
model.

~~~
em-bee
so you are saying that in java this works because i can choose the group where
i get the artifact from, just like i can chose a different package repo for a
package for my linux distribution.

but in NPM and ruby i am limited to one single global repo and thus have no
choice but to get the one that is controlled by whoever owns the name.

~~~
Fellshard
Similar, yes. You can also choose repositories in Java, as well, which is
closer to your Linux package repo. So there's just another tier in the
hierarchy, there, basically.

You can run your own private artifact repositories for NPM and Ruby, and
select which concrete artifacts they contain; but that's not the publicly
hosted repositories. One option could be to centralize into a cluster of
public repositories, which is closer to what the Java and Linux ecosystems
have, and that may be a sufficient compromise in many cases. I think the layer
of abstraction between repositories and concrete artifacts is still useful.

------
andrewstuart
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.

------
gizmo385
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
We often remove names from titles, because HN works better when the focus is
on content rather than personalities.

[https://hn.algolia.com/?query=by:dang%20personalities&sort=b...](https://hn.algolia.com/?query=by:dang%20personalities&sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0)

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
But in this case, isn't a large percentage of the content predicated on the
person generating the content?

~~~
dang
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.

~~~
mst
I remember an email thread with you some years ago where I was complaining
about someone/thing and you not only responded to the problem brilliantly but
also smacked me deservedly for my part in letting the problem exist.

Your optimisation approach seems to me to be working out nicely.

~~~
dang
Hopefully I've learned to be less smacky in the meantime.

------
ricardobeat
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
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
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.

------
m463
Why can't requests be adopted by python?

~~~
LyndsySimon
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
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
Context? I follow a lot of Python news, but never saw anything about this.

~~~
dwaltrip
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.

~~~
hobofan
> There was a bunch of hubbub around a preemptive promotion of the `pipenv`
> package to be _the_ package for managing dependencies in python.

AFAIK that never happened, and was only marketing from his side, and never an
official stance from the PSF (or whoever would be the authoritative source).
That's just one the many questionable things that has happened with him in the
past.

~~~
dwaltrip
I think there was language added to the front of some official python website
(one of pypa's I think?) that gave that impression. It was later changed.

Yeah, it's true that the marketing around pypenv was definitely over the top.

------
Deimorz
> 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
So it seems. Would that be a problem for some reason?

~~~
Deimorz
"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.

~~~
ijpoijpoihpiuoh
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
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
What’s being transferred here isn’t ownership of all the code, but control of
the project and the IP associated with it.

------
fibers
what will this mean for an async version of requests?

~~~
kamyarg
Someone more responsible can actually make it happen.

~~~
hartator
kennethreitz has not been responsible? `requests` is my favorite http library
in all languages so far.

~~~
jrimbault
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-
kennet...](https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-
reitz/)

\- 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).

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

