There are many political systems which exist in the world. Most of us live in a democracy of some kind or another. However there are also autocratic regimes and communist societies. It is not my place to state that one or other of those approaches is "better" and indeed all of the above are used in FOSS projects of one kind or another.

While none of these examples are perfect, you could see OpenStack project or Debian as democracies since for the most part, changes (either in code in OpenStack's case, or project structure/policy in Debian's case) are voted on. An example of an autocratic project might be Python whose founder Guido van Rossum is by definition the project's Benevolent Dictator For Life. Projects whose governance more closely mirrors communism include CentOS which is essentially "by the users, for the users" and is very successful with it.

There is, however, one project organisational scheme which I am aware of, for which I cannot think of a political instance of outside of FOSS projects, and that is a do-ocracy. Since many FOSS projects are managed by small teams, or even individuals, a doocratic approach is often taken. Maintainers, while they will be wary of patches "thrown over the wall", will often be grateful for work done on their behalf and unbidden. In such a project, simply by virtue of doing something do you become authorised to do more.

The larger a project is, the more likely it is that the management of the project will be a blend of all of the above, along with its own unusual rules, tics, tweaks and confusion points. Part of the fun of contributing to FOSS, for me at least, is in learning how to fit into such a wide variety of organisations productively and enthusiastically. No matter if it interests you or not, understanding a project's organisational structure will aid you greatly in successfully participating in, and changing, a project.