I'm not sure that conversation is a good example of what you are trying to describe.
Let's see if someone did the following things to the python project:
1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project.
2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the community. No PEPs, no discussion on mailing lists, no communication what so ever.
3#: Ignore current list of new feature being worked at. Community goals are unimportant.
4#: Add code regression! Do not care about maintaining performance.
5#: Demand that the changes get implemented immediately in next official release.
Would anyone expect that to actually work today? Sure, Stallman could be more diplomatic and find (and succeed) with a middle ground solution, but the above steps are not how you join an ongoing software project.
I tried to read that conversation in a neutral light, because I think RMS and JWZ are both kind of ... polarizing personalities, but RMS really came off as a stubborn, ineffective whiner in that whole thread. In particular "you hired away my maintainer" is a pathetic excuse for not releasing something for so long. Anybody could have hired away your maintainer, and you'd have to soldier on; it has no relevance that your maintainer went to a "competing" (in your territorial view) project.
I also read the argument about the redesign of the event system and was pretty flabbergasted. The argument seems to reduce to "lucid emacs decided to design a proper event datatype because having an event be entirely represented by a simple integer keycode both lost information and made it impossible to represent certain keystrokes" versus "but ints are simple and backward compatible!"
Poaching the lead dev to work on your own fork is a hostile move, and in my book, it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately.
The guys at Lucid also barely communicated for long periods of time, making collaboration impossible.
>> it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately
> Huh?!? Open Source model not working or what?
I guess its only illusion and crazy lawyers who like to add anti-poaching clauses in employee contracts. If a company can't handle loosing their top engineers, clearly its the the proprietary model that is not working.
There is one (and only one) other possibility, which is that you and I both read the conversation with flawless objectivity, and that you are wrong. :D
Let's see if someone did the following things to the python project:
1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project.
2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the community. No PEPs, no discussion on mailing lists, no communication what so ever.
3#: Ignore current list of new feature being worked at. Community goals are unimportant.
4#: Add code regression! Do not care about maintaining performance.
5#: Demand that the changes get implemented immediately in next official release.
Would anyone expect that to actually work today? Sure, Stallman could be more diplomatic and find (and succeed) with a middle ground solution, but the above steps are not how you join an ongoing software project.