[iajrz]

> His moral positions have done incredible damage to GCC at a technical level, and lost huge amounts of marketshare to LLVM as a direct result.

We can take this as a given for the purposes of the discussion.

> They are intertwined

But which has priority?

The main issue with this topic is that it's sometimes hard to see things from an angle we're so unaccustomed to.

The FSF and the GNU project are accidentally technical, morally-driven organizations. Technical superiority is never the argument for Free Software. You may be thinking about Open Source and mixing them up.

Try to see it from that point of view: if an organization exists to prevent "some evil" from happening and make it as easily as possible for "good people" to not commit and not be subjected to "that evil", it makes sense that the organization will sacrifice things that don't seem to make sense because they are avoiding as strongly as they can to make "some evil" easier to commit.

The goal is not market share; the goal is not technical superiority; the goal is not profit; the goal is to "not be evil", help others "not be evil" and not make it easier than it ever needs to be to "be evil".

Look at the "about" pages in the FSF & Gnu project websites and you will notice that it is not a bad choice for them to avoid doing some things "for market share" or "to remain competitive" when those clash with creating free software, making it easier to create free software, and make sure (within the realm of possibility) that their work cannot be used to facilitate the building of non-free software.

From the FSF's point of view loss of market share is an acceptable loss, if the alternative is "be evil". That is why, odd as it may seem, the FSF needs someone who does not compromise on that.

[dralley]

>The goal is not market share

Market share is absolutely a goal, even if it's only a part of the broader goal. GCC used to have significant leverage to advance free software, and now they have almost none.

>From the FSF's point of view loss of market share is an acceptable loss, if the alternative is "be evil". That is why, odd as it may seem, the FSF needs someone who does not compromise on that.

But it's not. Go look through some of the mailing list threads about LLVM, the whining is nearly unbearable. Despite LLVM having been offered to GNU in the mid 2000s (yes the whole thing, even extending to copyright assignment) and GNU having turned it down due largely to their opposition to modularity.

https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

[dralley]

From a recent LWN article about a week ago.

> It restarted, however, when Poimboeuf came back a few days later with another idea for solving his problem: recompiling all plugins when the GCC version changes. This was refused by Yamada, who noted that Ubuntu does not have the GCC mismatch problem, so the problem seemed to be specific to Fedora. Linus Torvalds also disagreed with the proposal, but for another reason. For him there is no technical reason to recompile everything when the GCC version changes, but he expressed his concern on the usage and design of the GCC plugins in general. In a followup message he explained his reasoning in strong words:

>> The kernel gcc plugins _will_ go away eventually. They are an unmitigated disaster. They always have been. I'm sorry I ever merged that support. It's not only a maintenance nightmare, it's just a horrible thing and interface in the first place. It's literally BAD TECHNOLOGY.

> For Torvalds, the right way to implement such plugins is at the intermediate representation (IR) level, but GCC plugins were designed differently for non-technical reasons (out of fear for non-free plugins, which LWN covered back in 2008). People who are interested in plugins should use Clang, as it has a clean IR and easily allows adding similar checks at the IR level, he said.

So here we have Torvalds himself annoyed at GCC's ridiculous plugin architecture.

[iajrz]

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.