Hello! I'm Sebastian, I'm the creator of FastAPI, an open-source Python web framework for building production-ready APIs quickly and easily: with autocompletion everywhere in your editor, automatic type checks, as little code as possible, automatic API documentation, and several other features.
It's a new framework, released just one year ago, that combines the best parts and concepts that I found over the years from different projects and tools, plus some ideas of my own. But mostly, it inherits the vast knowledge of many great projects that have existed in the past and combines it in the best way that I could. And now, it also incorporates many great ideas of contributors from the community.
I had used many different tools for building APIs, and at the time, I had a clear idea of the features I wanted to have: automatic data validation and serialization, with automatic and clear errors, a nice web UI to explore the API interactively, and the adoption of standards like OpenAPI with JSON Schema, OAuth2, etc.
I had a complex set-up including frameworks, plug-ins, and external components to more or less provide those features. It was complex and a bit fragile as it was made of many different independent parts and tools, but at least it provided what was needed for an API. Finding all those frameworks and tools, and their perfect combinations, was not an easy task. It required a lot of work, a lot of trial and error, and a lot of what is common to research: "lost work" - discarding something (an idea, tool, concept) after having invested a lot of effort into it, just to reach a dead end, and having to go back to start exploring something else.
But after all that exploration I had a clear idea of what could be achieved with the currently available tools and the best combinations of them. At least I knew that I wasn't missing something that already existed and could be used. I was pretty sure that if someone dedicated enough time to improve their API in different ways, they would come up with the same (or very similar) complex set-up as I did.
And at the same time, I had had the chance to develop many different types of software with different types of tools (and even some other programming languages), I also knew the things I liked from each of them. I knew the "development experience" features I liked. So, I wanted to have all those API features (but nothing more if it would be out of scope) with the best development experience possible. That's what started the initial investigation and design (even before development) that led to FastAPI.
At the same time, I knew that with my complex set-up I was not having the best performance Python could offer. So, if I was going to make something new and I could use the best parts available, with the best performance (Starlette and Pydantic), without any sacrifices, why not?
It's funny how the most interesting parts of building this framework were the tasks right before starting to code FastAPI itself. I would consider the first steps were all those previous years of investigation combining and fine-tunning other tools and learning from them. I wouldn't have done all this without learning and getting inspiration from all those previous great tools.
The next step, after considering that it might require something new (after not finding something that already did what was needed), was a lot of reading and studying technical specifications, JSON Schema, OpenAPI 3, OAuth2, HTTP, etc. during several months. I needed to know how all those standards were correctly pieced together and what was needed to make it all as robust and standards-based as possible. But at that point, I was just trying to understand how it all would fit together. I wasn't sure I would build something new.
The next step was a lot of just "designing". FastAPI is very developer-centric. It's heavily oriented towards giving a great development experience to the user. In several cases, that means that there's a lot of code repetition in the internal code of FastAPI, just to save some code repetition for the developer. It also means a bit of extra maintenance burden for the internal code of FastAPI itself; there are many extra tests required, the internal code is a bit more complex, etc. But it's worth it to create a better experience for final users of FastAPI (including myself).
So, at this point, I spent a couple of weeks just "designing" the development experience and trying each of those designs in several code editors. The idea was to make sure that coding with FastAPI was a pleasure for developers. It had to require as little code as possible, have all the autocompletion that editors could provide, work well in all the editors, but still allow for full flexibility extending and customizing everything in the API.
The next step was to add the missing features to the great tools that would power FastAPI. So I added JSON Schema support to Pydantic and improved support for some features that would allow a better development experience. All this in a sequence of pull requests during some months. Then Pydantic had all the features I needed from it. Starlette already had the best performance available and was the perfect micro-framework/toolkit to be the base of a new web API framework, it provided just the minimum to build on top of it. And it was built by Tom Christie, the creator of Django-Rest-Framework and also other tools that inspired FastAPI heavily.
So, all the foundations, design, and knowledge were in place. Next was the actual development. It was just some months of long hours, very long nights, little sleep... at some point one finger in my hand started to get numb, I started to get a tic in one eyelid, and a very lonely wife. Nevertheless, I couldn't hold myself. I loved it. I knew I was building something that would help me a lot with developing. And I wanted to make sure it could help a lot of other people too. I hoped it would.
Then, after having written the main codebase, I explored how to best document it. I liked the documentation of Starlette, it's pretty and clear, using MkDocs which is very simple to use, and a nice theme. I also loved spaCy's documentation, it's so beautiful that the first time I saw it I thought there had to be a catch somewhere! But replicating that style was too complex for me at the time, so I went with Starlette's style, it would also make FastAPI docs familiar for Starlette users. And at that moment, there was just a lot of time dedicated to writing documentation. With a lot of reviews and iterations reading and correcting it with Camila (again, the patient wife).
I put a huge amount of effort into providing good documentation, making it clear, approachable, understandable, practical, etc. I think that helps in several ways. On one side, if it contains information on something, there are more chances that it will show up in searches for that topic. On the other side, people can share parts of the docs, link them, etc. I think that's one of the things that people like most about FastAPI, its docs.
I also shared it in some places related to this same type of tools, websites about Python development, guides for those standards (OpenAPI, OAuth). In many cases, those websites are open source and can receive a pull request adding a relevant project.
At some point, I shared it on HackerNews and Reddit, and some people liked it, I guess that helped others finding out about FastAPI and giving it a bump in "popularity".
And there seem to be quite a few people liking it and sharing it with others. A tool recommended by a friend tends to receive more attention.
My priorities for FastAPI are more or less:
Things I find or that others report that need special/urgent attention.
GitHub pull requests
Lately, I've been receiving several pull requests a week, handling that takes some time/effort. I think contributions from others are very important but sometimes the state of a pull request is not great yet; there can be code errors, documentation typos, missing tests, etc. On some occasions, it seems it could be easier to just redo it from scratch. But I still try to get those same PRs to a state where they can be merged and merge them.
For a long time, I have been just a "newbie" trying to help some open source projects, and I know the stress and uncertainty involved in trying to directly suggest an improvement/change to something that you care about and admire, while still feeling like "maybe I'm not entitled to do this". But that's the magic of open source. Everyone can help, no matter where they come from or who they are. Everyone can directly help the projects they care about with no need for intermediaries. And I also know the amazing feeling when you propose a change in a pull request to something and it is accepted and merged. And suddenly you are a contributor to that thing you care about. So, yeah, I think contributions by others are quite important.
Backlog of ideas
Next, I have my own backlog of ideas for things that could be added (or maybe just tested to see if they would work).
In some cases, those things could solve several problems at the same time, so they have this special priority. And this also includes documentation. I think I probably spend even more time in documentation - writing Markdown, examples, editing them, etc. - than writing the code for FastAPI itself.
The next priority level goes to GitHub issues. They can be questions, ideas, bugs, or in many cases bugs in the user's code.
The incoming flow of issues is very high, and many are not actual bugs. Or are bugs in the user's code, or don't have a way to be replicated. So that's why they have this lower priority than other things. Nevertheless, issues are searchable in Google and GitHub. So many questions people could ask might be already answered, and they can find those answers on GitHub.
Next is the FastAPI chat on Gitter. There are right now about 350 people there, and it's a quite active community. And that is great, it's an easy way to have a quick conversation about something with anyone else that is in there at the moment.
But conversations in Gitter are not that easily searchable, linkable, etc. And as it has no structure (it's just a chat), it's very easy to ask very generic questions and spend quite some time re-formulating the question in a way that can be answered. And some people might also feel like it's easy to just ask everything there, instead of searching for information by themselves, and that ends up being counterproductive because it incentivizes people to skip researching and studying and instead just ask questions immediately and demand answers. And at the same time, it can take a lot of time from me and several other very active community members.
Fortunately, the FastAPI community has grown to be quite healthy, and there's a lot of nice people trying to help each other. There are some "members" that have put a really amazing effort into helping FastAPI, answering GitHub issues, answering questions in the Gitter chat, writing articles about FastAPI or special use cases, and implementing bug fixes and even new features.
For example, David Montague (user dmontagu) deserves a special mention here. He not only has helped a lot, but he's also extremely smart and has helped with many bug fixes and features. And there are other brilliant community members, like Benoit (user euri10), William Hayes (user whayes), and many others that help in the Gitter chat, GitHub issues, and code contributions.
It has varied a lot. But since I established myself in Berlin things are becoming a bit more consistent.
Now, I'm lucky to work for Explosion AI, because I've been able to see from the inside how important open source is for the company and my bosses. And that applies not only to the great open-source software products built by the company but also to other projects. It was part of the conversation from the beginning that the company would give me enough time to keep maintaining FastAPI and other open source projects.
I don't have a predefined work schedule or official metrics but I try to allocate about 25% of my working time to open source. On top of that, I add a lot of my personal "free time" to open source. That also includes lots of "wife time". I also try to spend some time helping with Pydantic, Starlette, and other tools. But as FastAPI is built on top of Pydantic and Starlette, all the improvements there are inherited by FastAPI too.
Additional to my time, there's a lot of time invested by several community members that help with issues, bug fixes, etc.
At several points, time. Finding the time to dedicate to it. But that's a lot better now.
Another really big obstacle is demotivating comments. It's strange how a single bitter comment, negative criticism disguised as "help", or a demanding message can really lower your mood. Fortunately, this is counteracted by each friendly comment and message. From time to time I receive a message saying just something like "I really like FastAPI, it has helped me a lot, thank you", and that's enough to put a big smile on my face.
I think open source might seem like something that "only others" can do. It might seem daunting to someone new to try and contribute.
And then if someone tries to contribute a pull request but leaves some errors or doesn't do it correctly, maintainers (or others) might not like it, get stressed by it, etc. and then they reply aggressively. That can hurt the confidence of someone new quite badly. And by not including new people, we hurt the ecosystem. I think we, maintainers, should do an active effort to encourage others to help, and help them do it right.
I hope it can grow and help a lot of other people. My intention is to help others create things more easily. I think developers can easily help others, help fix their local problems, their communities, create new products, create more value. And I think (hope) FastAPI can aid developers in achieving that.
There are many things I have planned for FastAPI; features, more docs, and sibling tools. I would like to make it easy for someone to get into code through Python and FastAPI. I've thought of maybe creating a course to learn to program from scratch, using these tools, and the same approach used for the documentation... we'll see.
For new developers, not yet maintainers:
Documentation is one of the easiest things to contribute to. And it is especially difficult for maintainers and people that are already "expert" with a tool, because they don't recognize what is obvious and what is not. An active maintainer doesn't have enough time to re-read those same docs again and again and discover those things. And a maintainer probably wouldn't discover small errors, because everything is already "obvious" to them.
A "newbie" has a strange and unique advantage of having a completely clear and fresh point of view. I think that when a new developer is studying a new tool, right after finally understanding the existing documentation and understanding how to use that tool, that developer has the best mindset possible to improve that documentation. Find the things that should have been explained before, the links that should have been added, the things that could be rephrased or explained better and, of course, all the typos.
For maintainers and projects:
UX (User Experience) is a huge topic for product creation. If you're building a software tool for others to use, those developers are your users. So, "Developer Experience" is key.
It's important to make sure that the tool can not only do something great, but can also be easily used. For example, adding Python type hints fuels autocompletion, a feature loved by at least 80% of the developers. In the same vein, documentation is extremely important. Some say that a feature is not done until it's tested. I guess a tool doesn't exist completely if it's not documented. Unless you want to only use it yourself... Here's a quick tip for developing docs. Adopt the point of view of the developers. What can they do with your tool? What problem would they be wanting to solve to come to your tool? How can they just use it? That might be more important than listing all the names of the "classes" and what inherits from what, etc.
Another tip is to encourage a friendly community. And encourage others to help, not only to ask for help. We all benefit from that.