Add another maintainer?

[nhumrich]

Question

Hey @jcrist. In previous issues you have mentioned that you are spread thin with other things and are mostly ignoring this repo for the time being. I think that is very much your right! Congratulations to you for taking care of yourself.

You have built quite a remarkable library here that numerous people are using. You have given a great thing to the community. I now encourage you to let the community give back. I am sure there are many people that would be willing to help maintain this library so you don't have to do it all by yourself. Would you be willing to give maintainer access to one or two other people (of your choosing) to keep this library going?

If so, I will help facilitate the transition and find possible candidates for you. I myself, do not have any desire to maintain this library, but I very much want to see it stay alive.

[jacopoabramo]

+1 to this, although it feels unfair since as OP I also don't have the technical ability not the time bandwidth to contribute as I would; but I would like to see the project thrive.

Another possibility would be to transition this library to a separate organization.

[return42]

Another possibility would be to transition this library to a separate organization.

Whats about:

• https://github.com/nightsailer/msgspec-x, python package msgspec-x started by @nightsailer?
• https://github.com/eamartin/msgspec/, python package msgspec-fuf started by @eamartin

[EthanC]

@return42 it doesn't look like the msgspec-x or msgspec-fuf have the proposed fix for #651, unless they've taken a different approach. I'd consider that a pressing issue, so I question the viability of those alternatives, unfortunately.

Regardless, I hope to see another maintainer added. msgspec is a fantastic project that deserves proactive development.

[eamartin]

Chiming in since I got tagged for eamartin/msgspec and msgspec-fuf:
I created the msgspec-fuf package solely because I needed this patch of mine ( #796 ) to be installable through PyPI. fuf stands for "forbid unknown fields".

I'd like to see msgspec maintained (so that patches like my own can be reviewed and perhaps merged), but I unfortunately don't want to maintain msgspec myself.

[btakita]

Adding msgspec_m.

[sobolevn]

Looks like many CPython core devs are sending PRs to the project and discussing PRs. See #877 and #852

I would be also interested to see this project alive :)
As well as Litestar folks (since we use it for many things inside, but not speaking for the other people here surely).

Maybe create an org as the first step? :)

[jcrist]

Thanks for the interest all, and apologies for the radio silence here. I've been feeling very very burnt out on open source for a while now (having 2 young kids and a job that no longer revolves around OSS contributions certainly doesn't help). I had hoped I'd snap out of it or at least have mental capacity to keep up with python releases (if not feature/bugfixes), but that's not proving to be true.

I've added @ofek to the repo as a collaborator. I'm hoping I can help them onboard and get the Python 3.14 support released in the coming week or so.

I'm open to adding more collaborators later too (people I know either directly or through the python community would be easier adds than random first-time contributors), I definitely don't want the code here to bitrot or leave it in an unmaintained state. I don't think we need to necessarily move to an org at this point (that's adding work, not removing it), but not opposed to that in the long run either.

[ncoghlan]

Thanks for the update @jcrist (and thanks for all your work on the library!)

Adding @ofek definitely makes sense (given https://pypi.org/project/msgspec-click/).

I'd be open to taking a more active maintenance role if you and/or Ofek would be interested in that.

[ofek]

I would love having you as a fellow co-maintainer! @jcrist They are very active and a well-known figure in the Python community.

Alyssa, I discussed with Jim that our preference is to focus on maintaining existing features and resolving long-standing issues but... if these sound interesting to you, I began tracking a few investigatory endeavors which will invariably lead to committing changes:

• Investigate inlining functions from annotationlib #883
• Improve startup overhead #884

This week I'm going to try organizing the open FRs & bug reports by priority as best I can.

[ahopkins]

I have been contemplating as well bringing something like this into the Sanic org. If there's interest, I'm willing to throw my hat and project into the mix if needed to keep this alive, especially if anyone wants to partner on it.

[nhumrich]

Closing as the core issue has been solved! Feel free to keep discussing whatever is needed still.