Is this project still maintained? about python-json-logger

[nhairs]

Hi @simonpercivall, this is a good call out. Before I answer I'd like to add some "meta" info.

• To avoid split conversations I'm only going to respond on this issue as I think it will give more visibility to others who do (or should) share the same reservations you have.
• I don't want to downplay your concerns, even without the recent XZ incident, supply chain security of software packages is an important topic.
• Whilst I am open to discussion, I don't believe that we are going to solve supply chain security in this issue nor do I think we should attempt to.

Before I respond with my reasoning I'd like to include the relevant sections of the PEP 541 process so that everyone is on the same page on what we are talking about.

Implementation

Reachability

The user of the Package Index is solely responsible for being reachable by the Package Index maintainers for matters concerning projects that the user owns. In every case where contacting the user is necessary, the maintainers will try to do so at least three times, using the following means of contact:

• the e-mail address on file in the user’s profile on the Package Index;
• the e-mail address listed in the Author field for a given project uploaded to the Index; and
• any e-mail addresses found in the given project’s documentation on the Index or on the listed Home Page.

The maintainers stop trying to reach the user after six weeks.

Abandoned projects

A project is considered abandoned when ALL of the following are met:

• owner not reachable (see Reachability above);
• no releases within the past twelve months; and
• no activity from the owner on the project’s home page (or no home page listed).

All other projects are considered active.

Continued maintenance of an abandoned project

If a candidate appears willing to continue maintenance on an abandoned project, ownership of the name is transferred when ALL of the following are met:

• the project has been determined abandoned by the rules described above;
• the candidate is able to demonstrate their own failed attempts to contact the existing owner;
• the candidate is able to demonstrate improvements made on the candidate’s own fork of the project;
• the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround; and
• the maintainers of the Package Index don’t have any additional reservations.

Under no circumstances will a name be reassigned against the wishes of a reachable owner.

Maintainer's Consent

You're right that I am attempting to take control of the PyPI project without the maintainers consent, however I am not trying to subvert their ownership.

I have actively tried to contact them via both on and off this platform and would be quite happy to work with them should they reappear. I have and will continue to act in the open throughout the entire process.

Additionally, should they reappear the PEP 541 process would immediately prevent me from taking over the PyPI project.

User's Consent

I think the consent of users of the package is entirely irrelevant to the PEP 541 request for the following reasons:

• If the maintainers were to reappear tomorrow and make me the new and only maintainer of the project I will have taken control without their consent and no-one would likely take notice. This happens constantly with packages.
• Users that are concerned about the source of their packages should not be directly relying on public indexes like PyPI for their packages.

PEP 541 Process

The PEP 541 process is a fairly high bar to pass in order to take over a project. It is entirely possible that despite my efforts I am going to have the request rejected on either of the following grounds:

• the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround; and
• the maintainers of the Package Index don’t have any additional reservations.

I agree that perhaps the PEP 541 process is not the best process, especially for highly used projects. However:

• As long as there is the possibility that someone can take over the project with a PEP 541 request I do not intend to withdraw my request. See Trustworthiness below.
• If the process needs updating then you should take it up with the PyPI maintainers. If you'd like to do this the best place to reach them is through their Discord.

Trustworthiness

I agree that there is no good reason for anyone to trust me. Just like there is no reason for me to trust anyone else. Hence I'd rather take over the PyPI project rather than let someone else do it.

However I'd like to offer the following reasons why I'm at least not a "bad" candidate for taking over the PyPI project.

• I'm acting under my real name and profile image.
• I have a fairly large public profile connected to this name and image. This includes my GitHub, website, LinkedIn, and Reddit.
• Under this same GitHub account I already maintain and contribute to a number of opensource projects.
• My fork has already made it's way into the Debian testing and unstable releases

New name vs reusing name

I did consider whether I should fork under a new name or undertake the PEP 541 process. Especially considering undertaking the process is a lot of extra work for me to do.

Here's my reasoning for choosing to do the process:

• There are already a number of competing JSON logging libraries, I did not want to further fragment efforts.
• Why fix things for just myself (and whoever happens to stumble across my fork) when I could help out all users of the library seamlessly.
  • This is especially true in terms of supporting new versions of python, fixing bugs, or addressing security vulnerabilities
• The PEP 541 process requires someone form PyPI to reach out to the maintainers on the PyPI registered email addresses. It is possible that this is different to the ones I could locate and may draw their attention to the project so it can become maintained without the need for the PEP 541 request.
• Longer term I'd like to find a structure that can ensure the continued maintenance of highly used but "low interest" projects like this one so there is more oversight and trust of their maintenance.

Closing thoughts

I hope this at least clarifies why I have chosen to make the PEP 541 request.

Whilst I'm happy to discuss further, if you're still not satisfied I'd encourage you to contact contact the PyPI maintainers about updating the PEP 541 process to have better protections for highly used projects. If you were to do so I'd be happy to put my voice behind it using this project as an example.

[tdg5]

I'm willing to help maintain this package if you're looking for volunteers. Let me know.

[nhairs]

I've begun the process of forking this project, if you'd like to be involved please join the discussion here.

[joeldodson]

thanks @nhairs, your 3.1.0 fixed a bug where taskName was in my file handler output though it was not specified in my custom formatter. Not sure commenting here is the right place to convey this. Thought I'd add it though if anyone is searching issues for taskName.

[simonpercivall]

@nhairs I'msorry, but I hope you realise how dangerous your approach is. You're trying to take over a very popular project without the maintainers consent. And without the consent of all the people who are using this project.

This is not how you do it. You fork, and then publish it as a new package; and over time, your new package, if you build trust, will become the standard.

[simonpercivall]

Thanks for the reply. First: I'm not saying you're trying to do anything bad. Quite the opposite, continued maintenance and development of a widely used project is a good thing.

However, as you say, I do think that the PEP 541 process needs updating. I think that between when the PEP 541 process was created in 2017 and now, the attacks against open source projects have evolved and advanced quite a bit.

I have voiced my concerns, and I'm sorry if that causes issues in further maintenance of this project. I think I would have preferred this project to move under the governance of a group (like for instance https://github.com/jazzband) rather than it being transferred to a new individual contributor.

[nhairs]

First: I'm not saying you're trying to do anything bad. Quite the opposite, continued maintenance and development of a widely used project is a good thing.

🙏 I'm glad that it comes across this way

I'm sorry if that causes issues in further maintenance of this project.

No need to apologise, regardless of outcome I think just having this discussion is of benefit to the users of this project.

I think I would have preferred this project to move under the governance of a group (like for instance https://github.com/jazzband) rather than it being transferred to a new individual contributor.

I agree that group governance would be ideal.

I've only recently discovered Jazzband and am still evaluating whether I think it's an appropriate model for something like this project (it looks like anyone can join and from there make releases).

But regardless of weather it gets transferred to Jazzband or some other group, the first step is to undertake the PEP 541 request.

[cunla]

I would be happy to support the package maintenance. I have experience adopting packages and growing them (see https://github.com/cunla/fakeredis-py)

[nhairs]

I've made a v3.1.0 release that fixes a number of bugs, expands on functionality, and has greatly expanded docs. This will be the last time that I update the issue until either the PEP 541 request is accepted or I decide to upload the fork to PyPI under a different name. For further updates please watch the forked repository. If you are interested in helping maintain the fork please make sure to watch the repo and get involved in any PRs or issues.