Is DRF still considered alive?

[hnykda]

Hey.

Let me start that I really appreciate all the work the encode is doing for python ecosystem, I am really grateful for that.

However, I went through 2020 and 2021 reports and there isn't really much about DRF, as it's considered feature complete and stable. Reports where DRF is mentioned:

1. https://www.encode.io/reports/april-2020
2. https://www.encode.io/reports/march-2020
3. https://www.encode.io/reports/february-2020
4. https://www.encode.io/reports/december-2020
5. https://www.encode.io/reports/october-2020
6. https://www.encode.io/reports/march-2021

the main take-away is that even if it's the main source of income for Encode, it's not where the most focus goes. From my perspective, this is the image I get (and it might be unfair!):

1. significantly slowing down on merging PRs, most of them actually not being about any new features or bug fixes/reports. E.g. looking at the commit log since last March, there seems to be only one commit that actually adds dev/user-facing feature (and it's still fairly minor). Others feel much more like fixing typos and links here and there, improving test, or bumping deps. Even though there are clearly many reported bugs or feature requests on the issue tracker (and clearly e.g. OpenAPI schema generation has a plenty space for improvement).
2. https://fund.django-rest-framework.org/topics/funding/ sections drastically outdated (version 3.6 is ~4 years old, Tom surely not working on this full-time, definitely not 80-90 closed issues/PRs / month, this section doesn't seem to be worked on at all)
3. 141 unmerged PRs, many without even a single reaction of maintainers for months or weeks
4. some of the issues not addressed at all as well (I know - you have a discussion-first workflow, but still, if you want to make the project better, I think going through those 120 issues would IMO still improve it significantly and could be IMO categorized/split into some work-to-be-done quite easily)
5. the long-term future of the project is looking a bit grim - there are no new maintainers/adopters apparently, and encode doesn't focus on this. Because of the points above, it probably doesn't attract that many contributors (maybe also because there is some bias of type "They get paid for it, so they do it?")

I like DRF, used that in many projects, but I am starting to worry. This is not looking good.

[tomchristie]

Hiya,

Okay, so I ought treat this one as a prompt - I've been pretty clear in the reports lately about prioritizing other Encode projects, for quite a while, but yeah it's clearly out of balance. Even though I think the best us of my OSS time at the moment is elsewhere, there really does need to be more maintainance time on REST framework, and if not then it'd be time to start talking about transfering it elsewhere (eg. over to the DSF.)

There will need to be some kind of transfer one of these days, but right now let me just treat this discussion as a prompt and get back to commiting at least some of my time back onto the project. Ensuring that at least one of my five working days a week was dedicated to REST framework would be a great plan.

Here's the obvious things I can think of prioritising:

• Number one priority has to be ensuring we're keeping up with any changes in newer Django releases.
• Keeping issues well triaged, and where possible working towards processes that help minimise the ongoing maintainance required. There's also some good process stuff that has come out of the other Encode projects that we could bring to REST framework. (Eg. the automated release process.)
• The only bits of functionality work I'd cosider feasible ATM are probably OpenAPI related tickets. Otherwise we should be considering the project feature-complete.
• It'd be great to give the docs a refresh, either moving to sphinx/readthedocs, or to mkdocs material.
• As you mention, there's some chunks of the docs content that are well out of date. Esp re. funding.

What priorities would you like to see, @hnykda?

[auvipy]

DRF 3.13 is already few months delay so that would be great to focus on. there are some django related stuff, without whom I dont think its feature complete. django is 16 years old and still not feature complete, and as DRF is a django extension, unless django is feature complete, as the new features which are not supported in drf from django is not working properly. dedicating 1 working day per week would be great. you could consider adding some more collaborators who contributed to drf for few years. You can consider me for help in ongoing maintenance hand.

[hnykda]

Thanks Tom!

Even though I think the best us of my OSS time at the moment is elsewhere, there really does need to be more maintainance time on REST framework, and if not then it'd be time to start talking about transfering it elsewhere (eg. over to the DSF.)

I agree. I do think that you working on the other projects is actually better for the ecosystem. That's why I think you wouldn't have to necessarily do all the job by yourself, but rather invest your time in a plan to have long-term maintainers.

What priorities would you like to see, @hnykda?

The ones you listed sound good to me. And honestly, I think you can tell better.

I want to appreciate you taking this seriously and with a good-faith assumption.

[auvipy]

If I could be a future collaborator of this project, I can manage monthly fund for my time spending on the project.

[tomchristie]

@auvipy That's an interesting proposition. Right now Encode is only just about break-even for my full-time salary so we're not able to take on a contractor right now, but it's feasible that could change. You're very welcome to email me privately and fill me in on what current OSS contracting you're taking on (I know you're a celery maintainer, and they have some funds managed via open collective, right?) and what your expectations would be from a contracted REST framework position.

[auvipy]

thanks Tom for your kind reply, I will be reaching you soon as ASAP. tom@tomchristie.com is this the email to reach you?