Moving REST framework forward

[tomchristie]

Hey all,

REST framework could clearly do with new leadership at the moment.
The latest release was 18 months ago and since then I've hardly had any spare bandwidth to dedicate to the project.

(My open source work is currently almost all directed at httpx, which feels by far the best use of my time.)

There are a handful of options that seem reasonable to me...

• Remain under encode.io - The project remains under encode.io, with new members stepping into a leadership role.
• jazzband.co - Plenty of projects under this banner at the moment. In it's favor they've got a neat process for enabling new contributors.
• DSF - The Django Software Foundation might choose to reach out and adopt the project, perhaps?

The project is in good shape & widely used, and there's plenty of businesses that I'd assume have a stake in helping out here.
We also have ongoing sponsorships at the moment which we've options with, either allowing us to fund new contributors or continuing to enable other work under the encode banner.

I'm interested in feedback from potential contributors around these options in order to help us start moving the project forward again?...

[ulgens]

I think the DSF option is the best choice, considering the importance of the package. Even if they haven't reached out yet, it may be worth taking a shot 🥛

That being said, what is the biggest need for maintenance / future plans right now? Are there any items that need immediate help from people reading this discussion?

[tomchristie]

what is the biggest need for maintenance / future plans right now?

At a minimum we need someone to determine if there any release blockers for 3.15, which probably comes down to are there any outstanding PRs required in order to fully support Django 5.0? Once we've answered that then we can roll a release.

[ulgens]

Got it. I think the discussion on #9210 is a good starting point and I'll check there if there is anything I can help with.

[auvipy]

@tomchristie I merged this recently #9233

[Kraust]

The lack of traction over the past 5 months (since 5.0 beta's release) has been very frustrating. I've been waiting since the beginning of the year for a release so I can upgrade my production systems to Django 5, but DRF is currently the only project holding me back from doing so. I assume there are many orgs in the same position that also are struggling with this right now and have likely made the (dangerous) decision to build their own forks and pray for the best.

I would be nice to have some clear list of outstanding tasks remaining for a release - there are many people out there who have modified the guts of DRF in the past (including myself) who would be willing to participate if there was some direction from the project's maintainers on what is taking so long and what it would take to get a 3.15 release out the door.

It's not even like moving to alternatives is possible either if you're currently the sole maintainer of a project that has hundreds of endpoints. The rework required for that would be massive.

FWIW (if anything) I really like jazzband's projects and they seem very open to changes.

[sevdog]

I would like to contribute in keeping this project live and working. The lack of any new feature or release to keep up with the development of Django in the last 18 months was a bit frustrating.

It would be very good if this project moves under DSF, but I feel that currently it is not on roadmap since "you may implement a Django REST app also without DRF".
On the other hand Jazzband in the last year does not seem to work very well, some projects are stale while others are well maintained, I feel that everything depends on which team is in charge of a particular project.

Probabily the best would be to build a new team of developers/maintainers to keep everything up&running.

[TGoddessana]

Personally, I think DSF is the best option because of its size, number of contributors, and reliability.

The proposal to include DRF in django's contrib package has been a popular discussion. However, I think it would be very expensive for django to adopt it, but I think it's worth trying. Do you have a to-do list for DSF adoption? and if so, I'd love to help out a little bit.

I think the jazzband is a good organization and team, but as far as I know they do maintenance almost unpaid. Considering the size and impact of this project, I think we need a rigorous maintainer who is more passionate about the project...

In my opinion, the most realistic option is still to keep the project in encode... This is because I believe that the most important thing to maintain an open source project is, ironically, money.

[auvipy]

I will go with Remain under encode.io - The project remains under encode.io, with new members stepping into a leadership role.

As DSF do not have any dedicated resource for it. and I don't think Jazzband is reasonable for a project like this.

I started maintaining this back in November 2022. until very recently I got busy with my relocation but as I'm settling down, I think I can continue to contribute. I think If we want we can cut a release in next 2 weeks for sure. @tomchristie

[tomchristie]

Okay, thanks everyone... consensus seems to be that we're probably in the right place at the moment, tho we need to get things back on track.

• 3.15 Release #9210 needs to be reviewed and resolved, I've taken a look over tho I don't want to be the bottleneck here... If you're invested in being part of the team then let me know on this thread and I'll send an invite to the @encode/django-rest-framework team, and ensure you've got approve/merge permissions.
• Once that's merged then we can review our release process and get that done.
• From my perspective the most important thing we need from maintainers is saying no. The project should be tracking new Django releases, improving documentation, and addressing security issues. And absolutely nothing else.
• I'm up for considering we fund and support our maintainers, we'll need to figure this out as we go.
• We'll want to review how best to handle security related issues, again I don't want to be a bottleneck here - I've got too many other commitments.

[tomchristie]

It should be maintained, yes. Intent should be minimal noise on here, keep pace with changes in Django and squish any security issues. It doesn't need any ongoing featurification.

[tomchristie]

The issue list since the 3.15 release is a good example of the negative trade-offs that changes to the project introduce at this point in it's lifespan...

...We'll be able to resolve those and get a new point release out, but it highlights where our priorities for the project should be.

Our policy (in my view) should be a very clear...

No pull requests will be accepted except for:

• Changes required to support newer Django releases.
• Security fixes.
• Documentation improvements.

...The project is mature, with plenty of scope for third party packages and adaptation. Further changes at this point are just creating risk, churn, and unnecessary busy-work.

[TGoddessana]

This part of the documentation seems to hint at adding some features to the framework, are there still plans to add Websocket & JWT & CORs support? (https://fund.django-rest-framework.org/topics/funding/)

Or would it be better to improve the documentation?

(I apologize if this is a sensitive area, I just wanted to know what your thoughts are on this at this point).

[tomchristie]

There's no off-limit conversations here... yep those aspects of the documentation are long out of date.

(The funding did help WebSockets support in Django, to the extent that uvicorn and starlette have been instrumental in maturing the ASGI ecosystem. And I'd probably re-assess "bring existing third party packages into core" as a no at this point.)

I think what we actually want at this point in time is redirecting our funding pages towards https://github.com/sponsors/encode and figuring out how we can be dealing with sponsorships and our available funds across the whole range of encode projects.

[peterthomassen]

Hi @tomchristie, I agree with the scope you laid out above for maintaining DRF, and am interested in stepping up as a maintainer.

[thibaudcolas]

👋 DSF board member here. I’ll add this to the agenda of internal DSF discussions.

[thibaudcolas]

We discussed this in yesterday’s DSF board meeting and confirmed what others have said above, which is that we care about the success of DRF but the DSF doesn’t currently have capacity to look after more packages. We have DEP 7: Official Django Projects as a policy when adopting projects under the Django org, however this still requires forming a maintainer team and renewing it over time. Which is the hardest part of maintenance. So doesn’t feel like it would help too much here (happy to be told otherwise).

And – people like Django Fellows who are paid to do maintenance and community support – are paid to do so for Django itself. They can work on helping with other packages as they deem appropriate, but that’s at their discretion. Everything else is volunteer-based.

---

Back to what the DSF can do – collaborative package maintenance over time is a real challenge for open source communities like ours. And DRF is in use in about half the projects out there, so we definitely want to help how we can.

In the short term I’ll get in touch with other people at the DSF and ask them for thoughts. Lots will have experienced package maintenance challenges for Django itself, and with Jazzband, and elsewhere. We have a DSF working groups mechanism to make Django community things happen with formal support (a budget, infrastructure, comms w/ other Django initiatives, etc). Perhaps a package maintainers working group could be a good way to support the new DRF maintainers in the short term, and also help with open source sustainability considerations in the wider ecosystem?

In the very, very short term – our Django Discord server has a #packages channel, which is a good place if you want to ask maintainers for their wisdom. And not Django related but GitHub as a great Maintainer Community which I’d recommend as a safe place to ask tough open source community questions.

[cclauss]

DRF is in use in about half the projects out there

Probably another 10%-20% of projects are doing APIs without DRF. It sounds like Django REST Framework should be built into Django instead of being an optional add-on. FastAPI and other modern web frameworks are a recognition that APIs are vital (not optional) for building modern web applications.

[thibaudcolas]

Valid point. Personally I’d recommend considering this separately from maintenance of DRF. See recent roadmap-level discussions on the Django Forum, in particular Built-In API Framework. There was interest but no one volunteering to make a more fleshed-out proposal. I’d recommend starting a discussion on the Django forum to take this further.

[foarsitter]

The only thing that needs to be happening in my perspective is to adopt the Djangorelease roadmap. Under which flag this happens is less important since the same people will do the heavy lifting.

According to the roadmap the next release would be Django 5.1 plannend for august.

Since shared responsibility is no responsibility I think community should appoint a release manager.

[tomchristie]

Having a release process in line with Django's is certainly a good idea.

Perhaps someone would be motivated in drafting a change to the project management docs which are somewhat out of date.

the same people will do the heavy lifting.

The lifting here should mostly consist of... improving the docs, making sure we've got a nice safe release process, handling security issues, dealing with any updates strictly required by newer Django versions, and helping say "no" to pull requests and issues.

should appoint a release manager.

I'm unsure how we should handle that. Interested individuals could self-nominate in this thread as a starting point, perhaps?