Successful open source projects often get to a point where they feel the need for some sort of formal existence as a legal entity — to be able to accept donations (see Chapter 5, Participating as a Business, Non-Profit, or Government Agency for discussion of how to handle incoming funding), to purchase and maintain infrastructure for the project's benefit, to organize conferences and developer meetups, to enforce trademarks, etc.
There may be a few exceptional circumstances where forming your own organization from scratch would be the right solution, but for most projects it is much better to join an existing organization. There are umbrella organizations whose purpose is to provide a legal home for open source projects. Working with multiple projects gives these organizations economies of scale and broad experience — any of them would almost certainly do a better job of providing services to your project than your project could manage if it started its own organization.
Here are some well-known and reputable umbrella organizations:
These are all based in the United States, but there are similar umbrella organizations outside the U.S. — I just didn't know them well enough to make recommendations. If you're a U.S. reader, remember that the distinctions the U.S. tax code makes between different types of non-profit corporations, such as 501(c)(3) tax-exempt organizations vs 501(c)(6) trade associations, may not be meaningful to members of your project outside the U.S., and that the tax benefits available to donors under 501(c)(3) won't apply to non-U.S. donors anyway.
If your project joins or creats a non-profit organization, make clear the separation between the legal infrastructure and the day-to-day running of the project. The organization is there to handle things the developers don't want to handle, not to interfere with the things the developers do want to handle and are already competent to handle. Even if the non-profit becomes the official owner of the project's copyrights, trademarks, and other assets, that shouldn't change the way decisions are made about technical questions, project direction, etc. One of the reasons to join one of the existing organizations is that they already have experience with this distinction, and know how to fairly read the will of the project even when there is controversy or strong disagreement. They also serve as a neutral place for resolving disagreements about how to allocate the project's money or other resources. More than one of the organizations above has had to play "project psychotherapist" on occasion, and their ability to do so should be considered an advantage even by a healthy and smoothly functioning project.
 I think the Software Freedom Conservancy is a good choice for most projects, which is why I listed it first. But I should add the disclosure that I joined their Evaluation Committee, a volunteer committee that evaluates projects applying to become members of the Conservancy, while revising this book for its 2nd edition. The recommendation of the Conservancy was already in the in-progress text before I joined the committee.