Thorsten seemed, clearly to me at least, to imply that these other guys entered into a collaboration where they had equal say, and when they didn't get it their way they ran away and started an alternative - BUT - that they all the while had the same amount of say in the government of it all, that they had a vote like everyone else.
Thorsten actually gave a very concise summary of the decisionmaking process early in the thread and (apparently falsely) assumed it would be read and understood:
It's a volunteer project. Whoever does the work ultimately gets to decide how it is done. I can suggest to you to make your aircraft mouse-control compatible, but no amount of user votes can compel you to actually do it. Even if we all wanted TorstenD to code a certain feature because we all think it's important to have it, Curt could still not order it or have any means of enforcing the decision.
Nevertheless, we need to work together. So we need to understand how the changes we do will affect others. If I plan changes to the rendering framework, I post on the list and in the forum 'People, what do you need?' Sometimes there come requests that can't be fulfilled (though it may be difficult to see), sometimes there's a request which I do (FLIR support, procedural lights, ALS aircraft shadows, landing lights,... are all based on content developer requests rather than my own plans). Same story reversed for AW - there was zero support for it initially, once it grew to the stage that people became convinced that this is a good addition to FG, people started to support it.
On the other hand, if something I plan to do blocks development elsewhere, that needs to be co-ordinated as well - we try not to close each other out.
In these discussions, your voice will matter to others according to how much is FG expected to gain when your need is fulfilled / expected to lose if your development is blocked by something else. If the expected loss is that FG will crash for 50% of users, than it will matter more than if two people have to adapt their aircraft. My voice counts for nothing if I can't argue my case, regardless of my track record.
Since it's a volunteer environment, it also matters a lot how you talk to people. Things which are readily given if you ask nicely might not appear at all if you issue demands.
But like everyone else, you have to argue your case. It's about convincing others of your proposal. If you can convince core developers that by following your suggestion FG will gain a lot, they'll likely do it. If you just state 'I need' and don't explain why, nothing will likely happen.
This summary is pretty much in line with what Curt wrote later. Important factors are:
* volunteers need to be convinced, not ordered
* what counts is making a case
* cost/benefit analysis of changes - whoever is affected and will shoulder extra work gets more of a say
* track record - can people trust that what you say will happen will actually happen?
Case in point - I actually argued for FGAddon being a GIT repository in the said discussion (you can read it all up). However, since at that time I was not an aircraft maintainer, my concerns were (rightfully) seen as secondary and ultimately more weight was given to SVN. It illustrates the above perfectly well - I have a strong track record in some fields (and I don't think there's a rendering-relevant decision made in FG for which I'm not asked) - but that doesn't count strongly where I am not affected.
Back on track - after Thorsten made this concise summary, he later made an analogy. The point of an analogy is that it is
not identical to the thing it's supposed to illustrate, but rather has a few common elements and a few different elements. The common element here is
proper procedure and
respecting outcomes. Like FG, parliamentary democracy requires both to work. It should have been clear that after I described a process in detail and that description does
not contain the word 'vote' a single time and then use an analogy that the common element of analogy is
not voting - I have no clue how someone reading this thread can come to a different conclusion.
Anyway - to answer the actual point: Given my insight into the decisionmaking process I believe any aircraft developers/maintainers
showing up at the discussion before the final decision was taken and
presenting a good case would have been given a high weight in the decision, much higher than my own voice carried in fact,
because they were directly affected by the changes. In fact, one strong point in favour of SVN actually was that some aircraft maintainers expressed that they feel more comfortable with it than with GIT, and there was no strong turnout of maintainers saying anything to the contrary. So showing up in time and making a case for a GIT repository in time would likely have made FGAddon a GIT repository.
What was not up for discussion and would not have changed no matter the number of people asking for it was to set up a repository with commit rights given for literally everyone up-front (aka without an initial review of what kind of material gets committed) - because that's (as pointed out a few times) a recipe for legal trouble and not future-proof. Quicksand - you know?