@aurynn @drq Sure! By the OP, I assume about the way pleroma is/was ran?

Note that I only started to follow the project in 2018 and only got more involved about a year ago. So some things may be somewhat one sided.

Basically lain started pleroma and other people started to contribute and work together. I don't know how it exactly evolved to this, but eventually you had some people working on pleroma based on some unwritten rules. Basically, if you wanted something in pleroma, you could make an issue or MR. In case of an issue, maybe someone would take it up. In case of an MR, people would review it. If a maintainer considered it good to merge, they approved it, if a second maintainer also agrees, they merge it. These were unwritten rules, so there are exceptions (mostly for smaller changes), but in general this worked.
There were some frictions from time to time however, because sometimes things would happen that someone disagreed with, but things never really got discussed. I don't have examples of this, this is based on what I've been told later.
Eventually these frictions got worse, remained undiscussed and ignored, and people started to leave. By this time there were payed devs, so development continued and the problems kept being ignored. Eventually the money ran out and it became clear that most people had either left or gotten burned out. Meanwhile pleroma had turned from a reputation of being a solid lightweight codebase, to being a buggy software no lighter than most other microblogging fedi software out there.
Some people still wanted to work on pleroma, but it became clear there were two different (and incompatible) expectations. On the one hand you had people who wanted to work in a more consensus based way. On the other hand you had people who just wanted to push stuff as long as lain didn't complain.
Eventually most of the people who wanted a more consensus based way of working left and started working on a fork. Two people still wanted to mend things between pleroma and the people who were now working on the fork, including lain who said they basically want the same thing.
Talks happened and lain made it clear that they want a consensus way of decision making and always wanted that. It was also made clear that other maintainers have both the power and the permission to act when they see things going in a way they think is wrong. Some people returned to pleroma and the fork died out. This was around new year.
By now there are people working on pleroma again and some things have been written down so expectations are more clear.
Pleroma wants to be flexible, so there's no real direction other than what people contribute. Code quality needs to be acceptable, and you have to realise that your changes may affect other people and resolve issues if they arise, but there's no real "end" vision of what pleroma, as a software, must be outside of some generic goals.

Personally I don't consider the people working on it now to be a committee. When someone says committee, I expect elected members, voting, big meetings where decisions are made... Pleroma doesn't have any of that. But I also don't think you can call it a bdfl run project. It's really just a bunch of people who decided they want to work on this project together in a way they can enjoy. At least that's how I see it.