Maintenance status of serde

[jplatte]

Hi!

It seems to me like serde is a bit low on maintenance manpower. @dtolnay seems to be the only person reviewing PRs, but quite a few are still open after months without any feedback from a maintainer and many recent issues also seem to have gotten no maintainer attention at all. Same goes for the serde website repository.

I'm not trying to say that anybody should feel bad for that, that's just the way things go. However, I want to ask whether you (the maintainers) have this on your mind and have anything in mind to improve the situation.

[gilescope]

@jplatte I'm just going to leave this here for you: https://blog.burntsushi.net/foss/

I have to say I'm consistently amazed by pretty much everything that @dtolnay has turned his hand to at the moment. He's doing brilliant work - I hope he keeps in this creative zone as I honestly can't wait to see what he turns his hand to next.

(If you want to lend a hand on Serde, just ask what you can do to help.)

[jplatte]

I'm just going to leave this here for you: https://blog.burntsushi.net/foss/

@gilescope Already read that :)

I have to say I'm consistently amazed by pretty much everything that @dtolnay has turned his hand to at the moment. He's doing brilliant work - I hope he keeps in this creative zone as I honestly can't wait to see what he turns his hand to next.

I agree! And I've already tried to help – that's the reason I've opened this issue. I've got an open PR on this repo and one on the website repository, but both haven't gotten any feedback. Additionally, I've talked to @dtolnay about other potential improvements to serde over at #1510 (last two comments), but haven't got any feedback since my last comment mid-december.

[dtolnay]

I think what you are observing is that mature projects naturally become increasingly selective about feature work over time.

Serde 1.0 was released 3 years ago. If I were someone using Serde, and Serde were still jamming in more and more and more features throughout those 3 years with no sign of slowing, that would be far more concerning to me as far as the future of Serde than the current maintenance investment.

Regarding pull requests: this is sad but it takes a huge amount of time to do a good job explaining why not to make most changes, and also a lot of expertise. Among the few people who could do a good job of this, it is not among the most impactful ways that they could be contributing to the Rust community. We do accept PRs, especially ones that improve the codebase without introduce user-facing changes, so I would recommend not taking this as a sign of the project being ignored or abandoned.

Regarding maintainer attention to support issues: I don't see this changing; we can't guarantee everything gets attention as the community scales. Users are free to help each other but in reality just responding to issues isn't something that most people would get excited about doing.

[jplatte]

@dtolnay I worked on the first PR because you wrote in the corresponding issue that you'd accept a PR for it. If you have changed your mind mind about that, I understand.

However I don't see how what you've written applies to my documentation improval PR or my question in #1510 about what kind of non-feature work you're looking for (this part has been resolved).

[gilescope]

It would be great if the above was a paragraph in CONTRIBUTING.md - hopefully that way it could save any future disappointment and everyone might get a little bit more of what they want as efforts are channeled into sought after areas.

_{Sent with GitHawk}

[H2CO3]

@gilescope I also have a PR open that hasn't gotten any feedback since november 2019 (#1685). I don't believe it falls into the "I need explaining why I shouldn't do it" category, since it's a small (but important IMO) improvement, and a mere follow-up to, and a completion of, another one I made earlier and which was merged. So I don't really know what to do about it.

[Mingun]

For quite some time, watching the project, creating several issues and offering several PRs, all of which are still unanswered, I want to return to the problem of maintaining the repository.

If you look at the project analytics from GitHub, you can see that the only active maintainer is @dtolnay, but he has not been paying time to the project lately. Perhaps he simply does not have enough time to engage in support, or even lost the motivation to engage in the project. Of course, this is the right of everyone and no one is obliged to do anything without payment or obey the requirements of doing something.

However, I will still ask you not to forget that, according to @dtolnay himself (can not find the link), serde is used in about 25% of Rust projects. serde is an important part of the infrastructure, so widespread that it has become a de facto standard that it does not allow "to simply use something else", as they like to advise in such cases.

serde deservedly deserved its place in the ecosystem, but you need to remember that with great strength comes great responsibility, which means that the community cannot and should not allow the project to stagnate, which is apparently now happening :(.

To correct the situation, I suggest that the Rust team take care of the project in order to revive it and begin accept new PRs for fixing the old problems, which have accumulated a lot. Unfortunately, I don't know who will be addressed specifically, which people reconcile decisions, but I think these people will be able to help:

• @alexcrichton
• @killercup

I hope that in my message no one will choose any charges and all of us will try to do reasonably and prevent the death of the project.

[zeenix]

I think what you are observing is that mature projects naturally become increasingly selective about feature work over time.

That would be a good explanation for lack of active development by core contributors but not PRs fixing important issues, not getting any attention. The problem is that if maintainers don't have time to look into PRs for months, the chances of bringing in new maintainers over time, also diminishes quickly.

I would suggest that maintainers take the time to go through contributors and give maintenance rights to folks who have made significant enough contributions to possibly get out of the current situation. Just my two cents.

[Mingun]

Time passes and I again want to appeal to people with PR merger rights (can we have the list of these people anywhere?). Unfortunately, the number of requests and PR is growing, but most of them do not receive any attention from maintainers. I see a bad signs in that approach. If maintainers don't have enough time for a project, shouldn't they to request help from community by giving them PR merging rights? @dtolnay, @oli-obk , what do you think?

[oli-obk]

I think the right approach is to finish the serde_core work and let the community handle forking and modularizing serde_derive.

No one is actually blocked on that tho, as you can use serde without serde_derive already. In my book serde_derive is in maintenance mode and will only receive critical bug fixes or rare features at maintainer discretion. Not sure if that is also David's view, but it is how I approach this

[Mingun]

Not all problems related to serde_derive and not all of them can be solved without changing core serde traits. This is especially applicable to various model transformation derives, such as flattening. What the plans to proceed with them? Examples are Deserialzier::__deserialize_content and Visitor::__private_visit_untagged_option.

[Mingun]

To help moving this question forward I created an unmaintained advisory in RustSec repository.

[Anders429]

IMO serde_derive being in "maintenance mode" is not the same as it being "unmaintained." I don't think it should warrant a RustSec advisory.

I think the right approach is to finish the serde_core work and let the community handle forking and modularizing serde_derive.

I am curious if this still feels like the path forward. It looks like the serde_core work has been making progress again recently; does it still look like the community forking serde_derive is the right solution?