And that's good and well - that's the way things are done: every project strives for their goal as well as they can.
I am very emphatically not making any statements about the technical aspects of gnu software.
The FSF is not the same as the gnu project, even if they share a lot of values - since they're being used mostly interchangeably in this post, let's roll 'em into one.
Whether someone is good or not for an organization can't be evaluated against arbitrary values: they evaluation needs to be made against the organization's values and their current state.
It's the same issue as when people were complaining about the AST not being available to make emacs _customizable_ into a better C++ IDE. Before even thinking about the technical merits of the solution, the questions that need to be answered unequivocally look like: "Are we making it easier to create non-free software from our work if we do this?" or "Are we eliminating leverage that incentivizes people to write free software in this are?"
From the FSF's standpoint, The crucial questions like "Are we enabling amazing software?" or "Are we going to gain market share from this?" are _secondary_.
And much of people's teeth-grinding is because they don't understand that; at least in the AST discussion I noticed that people arguing for the AST didn't appear to see that their priorities weren't the same as the gnu project's, and rms seems to not have noticed the discrepancy (or attributed it to plausible malice) and made some very strong accusations to people who just weren't arguing their side from the appropriate value framework. Appropriate because gcc is a gnu project, therefore its roadmap is decided according to gnu's values.
If you can't see this, you can't understand that some features, desirable as they could be, should not be (from their standpoint) implemented; from their standpoint, pursuit of technical excellence, usefulness, market share, beauty - any other feature that a software project may have - is subordinated to the value of software freedom.
You may or may not agree with that, and that's OK; but an org that has that kind of value framework sure needs someone - not rms specifically, mind you - who shares it, or at least understands it thoroughly and can commit to making organizational decisions based wholly on that value structure.
I am very emphatically not making any statements about the technical aspects of gnu software.
The FSF is not the same as the gnu project, even if they share a lot of values - since they're being used mostly interchangeably in this post, let's roll 'em into one.
Whether someone is good or not for an organization can't be evaluated against arbitrary values: they evaluation needs to be made against the organization's values and their current state.
It's the same issue as when people were complaining about the AST not being available to make emacs _customizable_ into a better C++ IDE. Before even thinking about the technical merits of the solution, the questions that need to be answered unequivocally look like: "Are we making it easier to create non-free software from our work if we do this?" or "Are we eliminating leverage that incentivizes people to write free software in this are?"
From the FSF's standpoint, The crucial questions like "Are we enabling amazing software?" or "Are we going to gain market share from this?" are _secondary_.
And much of people's teeth-grinding is because they don't understand that; at least in the AST discussion I noticed that people arguing for the AST didn't appear to see that their priorities weren't the same as the gnu project's, and rms seems to not have noticed the discrepancy (or attributed it to plausible malice) and made some very strong accusations to people who just weren't arguing their side from the appropriate value framework. Appropriate because gcc is a gnu project, therefore its roadmap is decided according to gnu's values.
If you can't see this, you can't understand that some features, desirable as they could be, should not be (from their standpoint) implemented; from their standpoint, pursuit of technical excellence, usefulness, market share, beauty - any other feature that a software project may have - is subordinated to the value of software freedom.
You may or may not agree with that, and that's OK; but an org that has that kind of value framework sure needs someone - not rms specifically, mind you - who shares it, or at least understands it thoroughly and can commit to making organizational decisions based wholly on that value structure.