This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
🙏 Find maintainers for FastAPI #4263
Comments
k4black
changed the title
|
100% this. To stay at the level of Flask and Django, there needs to be a team of core maintainers. We can't just rely on a single person. FastAPI being a single maintainer project is a big reason some companies don't want to start experimenting with it/using it. |
|
Totally! We have the same issue in our company I really want it become only-option for python api. And we'll have |
|
@benjamin-kirkbride No, it's an initiative. Sorry if I was vague. This is an |
|
Some past discussion has taken place here: #3970 |
|
There are Microsoft and Netflix that use fastapi. Maybe it's possible to have reinforcement, help by these 2 futur sponsors technically and financially and why not organisationally |
|
As a team lead I am evaluating Fast API for a major new project and of course one of the things to do is look through issues, how many open PRs there are and to understand the governance of a project. |
|
@tiangolo seems to be burnt out and he may need his well deserved rest. I agree this project needs to be openly maintained by a group of community members. |
its a shame that amount of quality PRs that have been ignored. |
|
If an initiative gets going with more maintainers, I'm happy to volunteer time. I am currently using FastAPI in production though I haven't contributed to the codebase yet. I can probably help with issue triage and PR review to start. I do have extensive opensource experience from other projects. |
|
@etimberg I guess, the bottleneck here is not the number of maintainers 😅 |
There are alot of good quality PRS that needed to be merged, that shows that there are a lot of good developers wanting to maintain this project.
|
This is part that worries me about this whole thing; he hasn't been seen commenting on pretty urgent threads in months. Things that have already been figured out and just need a simple merge; I wonder if something's happened to 'em. |
|
@kevr - I hope he is alright. you can see that he does work on other projects, see https://github.com/tiangolo/asyncer for example |
...I guess that's even worse. He's straight out ignoring a project that he gets sponsorship from, and that starlette primarily implemented for him. We've been using FastAPI for a new version of Arch Linux's User Repository in development for the past half a year or so; after running into a number of real issues that have been quickly closed for unreal reasons, then seeing how all of this plays out for a minimal core dep upgrade, I'm considering just moving everything over to using Starlette and taking FastAPI's Form implementation for our own project; we will most likely do so, in fact. The starlette devs themselves do a great job at looking at their project. |
|
The solutions that suggest a new governance or a new workflow in the continuity of the existing project can not be implemented because they require the tiangolo's agreement. Today, the only solution I see is the difficult path of the fork. I decided to stop investing time in the FastAPI ecosystem (PR, issues, etc). I'll rewrite the backend of one project in Django (my usual framework for the past 10 years) + Django Ninja. That said, I'm sorry about the current situation because I prefer to use SQLAlchemy than Django ORM and I like the performance of Starlette. Another idea would be to create a third party application for Starlette that would provide the Pydantic validation decorators for the endpoints, just like Django-Ninja with Django, we would have a third party starlette-ninja package for Starlette. It would then be easier to track versions of Starlette. I encourage the actual sponsors to found maintainers who cares about their users... |
Yeah ,I hope hes alright .. , that seems he is totally burnt out to a point that he didn't want to look at this repo and issues/comments at all . He just need to say : Many of us will step up on helping because this awesome framework being used in production. None of us , who using Fastapi in production won't want to let this project go to waste , this have huge potential to become the best python web framework , over 40000 stars , over 280 contributors , over 440 open PR , over 170 paid sponsors -> All he need is request for help . |
|
+1 , it is frustrating this centralization on tiangolo. I´m also regretting this choose of framework because of the governance. |
|
Hey! Thanks a lot for your interest. NumbersLet's start with the numbers. I think you might be evaluating the number of issues and PRs with a different/biased point of view, here's how. Most of the issues are actually questions, and not bugs. And I use issues for questions because those allow imposing a bit of structure that can help users, me, and any of you here that also help. Additional to that, I don't close issues once I or someone answers them, I feel that would be a bit rude (although maybe practical). I wait for the original poster to close them or I mark them to be closed later by a bot. Many of those questions are already answered and I haven't had the time to mark/close them. But that's what counts for the biggest chunk of the "issues open". Also, some of the issues are just a place to handle some admin, for example, there's an issue for each one of the languages being translated, and I wrote a bot that comments there to let participants to know there's a new translation to review. Those are not many, but still, another chunk of "issues" that are not really issues and are not expected to be "closed". Now, about PRs, a big chunk of the PRs open are just translations. I can't merge them until I get 2 approving reviews from native speakers. So they just stay there for a while. And I can't force people to come and help reviewing translations for their language. Then, there are many PRs that I would have an easier time re-implementing them myself than updating the code from the PR, maybe they add extra things not relevant to the current PR, or maybe they implement it in a way inconsistent with the rest of the code, etc. But I try to put an effort into updating the original PR instead of just discarding and re-writing. That also makes the process a bit slower. Issues and PRs to handleIt's true I do have a bunch of issues and PRs to review across the projects (not just in FastAPI). But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. For the same reason, I can't just give permissions to others to simply merge PRs. An important part of what has worked with FastAPI is that I have personally and very carefully handled it all, the best way I can. I can't renounce to that now, at least not yet, and risk the codebase quality. I would probably give permissions to others (and I have done it in the past), after several non-trivial PRs that don't need any change from me. But that doesn't happen frequently. And still, even after some trusted approvals, I would try to review each PR myself before merging. Short Term FutureI even changed my working structure to optimize for more open source. I didn't get the chance to work as much as I hoped for last year. I'm finishing a very large migration to FastAPI. This will also result in documentation around that process and how to handle compatibility with other frameworks and async/sync code. But I'm already arranging to compensate it this year soon that I finish that migration, and I'll spend a lot of my working time this next quarter or two on FastAPI and friends. During this time, I'll also get the chance to see many contributions from others, and who knows, maybe I'll feel more confident about giving extra permissions to some others. Conversations like this oneSadly, new issues and new discussions like this one asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. It also doesn't help to comment or send me private messages or emails telling me to handle one specific issue. That becomes another message I have to handle on top of the thousands I receive from GitHub notifications for issues and PRs. The same way, asking me to find new maintainers doesn't really help me, because it just becomes another task you are asking me to carry out. It's also not something that I can myself go out and find. I wouldn't go and ask people to come and help for free, while at the same time I have never seen their work, in particular here, or I have seen only very little. It's also not a matter of people simply volunteering to be maintainers if they have never contributed a non-trivial PR (or very few). None of those options are really enough for me to give them permissions. But again, as I get the chance to review PRs, maybe I'll find some active contributors with impeccable code and reviews that I would feel confident about giving them more access. Recent WorkI'm prioritizing the work that can have the most impact. Recently I was helping a bit with AnyIO and Trio, as AnyIO is used underneath by FastAPI (and it requires double compatibility with asyncio and Trio) and all that could end up used by you and your projects, even if you didn't know about it. That's not even visible in my projects, but you would still benefit from that work. For example, helping fix support for contextvars when executing synchronous tasks in a thread worker from an async context. You might end up needing all that in your projects, even without knowing, because it could be used by third party libraries you use. And these improvements make sure everything will simply work correctly underneath without you having to worry too much about it. I was also working on a couple of small things for Pydantic, that would be used by SQLModel and FastAPI. Before that, I released SQLModel, as I had the code, the ideas, and everything mostly ready, and people seemed to be needing something like it and no one was able to make it, so I spent the time to finish a first version that people could start exploring, before jumping to the next most impactful thing to do. In the same way, I just released Asyncer a couple of days ago, to help the projects that need to work with concurrent code and that need to mix async and sync code, which I would think is a very strong use case for FastAPI. RoadmapI have several things that I want to work on, but my roadmap is flexible, as while working on one thing I could end up finding that there's something with high impact that I could do, and if it's worth it, I might just do that instead of a previously fixed plan that was made based on suppositions. I currently don't have investors or similar, so I don't have to force myself to meet some product or marketing deadlines, or to figure out how to monetize something, etc. I can focus on whatever seems like what would have the most impact. Even if that means working on a third party open source library that isn't even mine, but still feels like the right thing to do. I can do that now. That's also why the roadmap is not very fixed. As an example, I want it to be easier for people to work with async code. To run concurrent tasks, to be able to mix sync code with async code but reducing all the confusion around threads, thread workers, event loops, contextvars, thread locals, etc. That includes a lot of documentation I want to write. And it also ended up including building Asyncer, to be able to have a good developer experience with autocompletion, inline type errors, etc. All that work on Asyncer started as PRs to Trio and AnyIO, and then in Asyncer itself, which is this tiny library to let me (and you if you want) use that API design, while those PRs are evaluated in Trio and AnyIO themselves. But the realization that it would make sense to make it its own tiny library, even if temporary, was last month, and then I finished it (almost all of it) during the break. All that to say that I feel it's an example of the benefits of my flexible roadmap and focusing on the resulting impact. Come and Help me MaintainThe word "maintain" and "maintainer" probably means different things to each one of you, and each one of you probably measures it in different ways. If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/ One of the things that consume time the most for a maintainer is handling issues created by others. Many issues are incomplete questions. If you can go and check them, and if you can write a simple, minimal, self-contained example that shows the actual issue (or shows how to solve the user's question), that's normally the biggest chunk of time and you would be saving me from doing it myself. Then, you would be maintaining FastAPI. If it's actually a bug, I can probably reuse your example as a test case, and that's probably the biggest part of the work. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs. That's work that a maintainer has to do. Wanna do it? I would be most grateful! Any of you can do it. You can also review PRs yourself. But have in mind that adding a comment of "I have this problem too, merge this soon" doesn't really help if you are not really reviewing the code, trying it in your project, and confirming that it indeed solves your use case. And if you did all that, please mention it. In some way, here's me asking you all to be maintainers for FastAPI. FastAPI PeopleA lot of this work is already done by a bunch of people. Not many, but a few very dedicated and helpful volunteer people. For example, @Kludex is one of the most helpful people here, always helping others, and always with a supportive and friendly attitude. That's why I created FastAPI People, and the FastAPI Experts. Those are the people that have helped maintain FastAPI, helping others with their questions: https://fastapi.tiangolo.com/fastapi-people/#experts Do you have open issues? Go check it. Are they solved? Then please close them. Help me maintain this. On the other hand, overly critical, aggressive, and demanding comments like those from @kevr, @stephane, @bratao only drain me, make me sad, and take out the energy I should be spending in working on this instead of arguing. At the same time, none of those users show up in FastAPI People, which means that none of them are helping FastAPI, helping maintain it, answering questions in issues, reviewing PRs, etc. But for the rest of you, thanks a lot for your support and understanding. 🙇 |
|
Thank you @tiangolo for this very detailed answer on the governance you want for FastAPI. Choosing a framework can be a big risk for a company. Over the months, I have been reading worried comments hoping for a reaction from you and you finally provide an answer. This new information helps to make decisions. I'm not very proud about the last line of my last comment. Please, accept my apologies for this. I'm disappointed that you choose to name and shame. You can find my contributions to FastAPI ecosystem here: I wish the FastAPI project the best 🚀 |
|
Apologies, but, the lack of correspondence has unfortunately left me hungering for reliability. It's fine if a project needs to take some time to do something, but, the fact that all of these things seem to be done by community members means that really, the work has been done for you and there really is not much effort that needs to be given to consume. Being put off with absolutely no input from you is a huge issue (for me). If users are then hung to make their own random decisions because we don't really know what upstreams thoughts or plans are, I believe a lot of those users' confidence would end up degrading because they have no source of truth to depend on. It also means that we have to spend time on things that upstream normally deals with. There were urgent tasks up here, and you go off on this speel about all the work you're doing in parts that we don't actually see; well, here's some news for you: what we were seeing was screwed and several of us had to maintain our own forks just to be able to use the dep in our project. How exactly can folks trust that a project is going to be stable if the maintainer is seen as completely MIA for several months with no real follow-up from the only person who can actually merge such changes. Frankly, this thread is a great idea; I hope it does help the project out. Shame me all you want; you wouldn't get this kind of reaction if you literally just gave some words on the situations. TL;DR - Folks here are most annoyed about governance, not your actual code work. |
|
Edit: it looks like the comment this was in reference to was deleted. So this is now out of context. It was specifically replying to a comment suggesting gitflow could help with FastAPI's development. I'd rather see the merge queue feature used. No one should be using GitFlow nowadays (see https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow, "Gitflow is a legacy Git workflow") |
|
I came here pissed off about how long #4145 took to get merged, I agreed with the complaints about not having other maintainers that could merge PRs and I was a bit disappointed by @tiangolo's reply. However, having had some time to think about it and having just read this, I have to say that he is totally right. This is his project and he can do with it whatever he wants, including nothing. I don't have a maintenance contract with him, so there is no reason why he should care that not merging #4145 for two months was making my life slightly more difficult. Even if I were sponsoring him, that would still be money with no strings attached and he is under no obligation to give me the time of day. Do I wish this were different? Sure, but then I should either sign a contract with him that states what his obligations are and what he gets in exchange, or I should fork the project and use my version instead. If using a particular framework is that big of a risk for my company, then surely it is reasonable to spend money to mitigate that risk. Complaining about the "governance" is polite shorthand for "I want better service for free", and that is not something I can demand. @tiangolo, thanks for all your hard work, I really appreciate it and I'm sure I'm not the only one. |
|
@tiangolo thanks for the reply, I have now see the direction and vague view of your decision for governance.it's seems to mean : "It's my project so, codes have to come from me " |
Frankly, it's not service for free. Look at the list of donations he gets all across the open source community. He's being paid to support this project. imho, this guy should be linking his sponsor button directly to starlette; or he should've named this project Additionally, I do just want to add: none of what we're saying is degrading the time and effort he has put into the project, and we're all thankful for this; it was a lot of our reasons for choosing the project. We are not ungrateful for this. I can't speak for others, but for us personally, we were eager to use the project. |
Maybe the emphasis will help. A donation is not a payment for a service. |
If it's such a small amount of code and such an annoyance, just fork this project, merge all the PRs, implement a community governance model that works and start accepting donations of which you give 80% of to Starlette. Can't be too hard. /s |
|
@tiangolo there seems to be lots of peple who would like to see the project run in a different way. Would you be OK with a fork being created? I'm not saying I'd do it, I'm just curious to know if you would object to that, because it seems the obvious solution to the many people who seem unhappy with the way its currently being run. Sometimes project founders have no problem at all with forks, sometimes project founders get upset about it. I'm just wondering how you would feel. |
Starlite is going that way . Not worth forking anyways since Startlite is better implemented , well architected , well intented , and community founded on the ground up. |
|
Any updates on this? |
|
I will be switching to starlite; not because I think it's much better or that I even understand the difference between the two but because I fundamentally cannot trust an adult who uses emojis in every single commit |
Wtf 😂😂 |
I had switched to starlite after 2 year of FastAPI , never being happier. Can use both FastAPI style and OO Style . The OO Style is a little hard to use to but it nicely separate your code into manageable controller classes , no more pile of mess of FastAPI when project getting bigger. The community (now have 6 maintainers) are very active, they are trying many innovative things like rust based routers and stuff. |
|
Hello all! I updated the docs about helping FastAPI, there's a new section Help Maintain FastAPI. The biggest work maintaining FastAPI can be done by any and all of you here. And that work is what demands the most time. There are many more details about how to help maintain FastAPI, the specific tasks, and what YOU can do, right now. So, please, come and help me maintain FastAPI! 💪 🤓 |
|
Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs. |
|
Finally , community effort paid off ! |
tiangolo
added
question
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
First Check
Commit to Help
Description
At the moment, all contributions to the FastAPI are made with @tiangolo (directly or through a PR review).
@tiangolo is doing a great job 💪, but fast developing project with great community like FastAPI demand much more time.
(It can be seen by the number of open issues and pull request)
Wanted Solution
Suggestion is to find several active community members and add them to the repository maintainers, as other projects (e.g. Flask and Django) do. 👨👩👧👦
This will help the development of the project and make the atmosphere for third-party contributors much more pleasant. 👾
Hope @tiangolo will consider this possibility
upd: discussion on this #3970
Wanted Code
The text was updated successfully, but these errors were encountered: