> it's also the last thing we need in a position of leadership or even as a consultant.
On technical matters, you are correct; on moral matters it's a different story.
Think about the moral tragedies of history; we didn't need someone saying "maybe we should not be so evil; let's be less evil - not stop, because that's disruptive and I am not an extremist, but maybe dial it down a bit?"
On moral battlegrounds we need someone capable of saying "we have to stop, and no price is too high to pay in order to stop being evil". Someone who is willing to pay the price themselves, and make the price as low as possible for anyone that wishes to follow through. Nothing less than that suffices; "They enslave their children's children who make compromise with sin", to say it poetically.
>On technical matters, you are correct; on moral matters it's a different story.
They are intertwined. 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.
(Stallman thought that making the compiler more modular and extensible was totally unacceptable because it might be possible in theory to write proprietary tools that used GCC to dump intermediate representations. Thus preventing any FOSS tools from using GCC, also).
> 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.
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.
> 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.
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.
> That kind of disruption is at odds with every value FOSS devs claim to hold-- meritocratic, decentralized, etc.
You're mixing things here. :) meritocracy and decentralization are completely orthogonal to free software. They [edit: s/are/could be construed as a/] part of the open-source ethos as explored in CATB & explained by esr, not a sine-qua-non of free software.
The problem in this case is an unspoken governance model where a participant from decades ago showed up, made public accusations about the trustworthiness of the other participants, then declared a time schedule of his own choosing during which he would consult his own private council to judge the veracity of all the public arguments given.
Whatever we want to call that, and whatever the origins of the problem, it is a bad thing.
Hey, I've been thinking and talking in another thread; I just made a comment that is completely relevant for this convo, too; the people in the discussion, as well as you, are looking at things from a different value framework as rms, the gnu project, and the fsf.
Here's the relevant comment: https://news.ycombinator.com/item?id=26809646
We can agree the discussion could be handled better, and the accusations were unwarranted in context; I happily chalk that up to a misunderstanding (rms not seeing other people's lack of awareness of value framework incompatibility as a massive obstacle to conversation, instead assuming interlocutors had better information than they seemed to, in which case their behavior could have been construed as being in bad faith) - which implies 2015 rms should probably dial it down in the strength of his accusations among other adjustments. Communication is _not_ easy.
If a farmer and a forest ranger go into a patch of land, they will see the same scenery, but may have heated discussions about what to do with it. Unless they understand that one of them wants to produce food, and the other to protect the forest. And if one of them has decision-making power over the terrain, even if they have not been in there personally for a while - the argument about how what they want to do fits with the decision-maker's values needs to be made.
Of course, nobody is stopping the developers from going and doing the stuff they want to do in the first place, distributing it and, if the change is as technically important as it seems and the cards are played just right, even becoming the de-facto standard distribution of a piece of software; their changes just won't be merged into the main product for the foreseeable future.
Even so, having say a bare metal server (à la Vultr) can be way cheaper than having a cloud setup in one of the most flexible kinds of providers.
The detail to look at is that flexibility is a feature of the cloud offering, and an expensive one at that. If you don't need it, you need to find a way to not pay for it.
3rd world perspective: They're not far off from the mark.
You'd want to co-locate with ISP who already has infrastructure for continuous services through blackouts et al, or you could have a datacenter if it's small-ish, because you already have some infrastructure to keep operating during blackouts.
Some things you can do in bulk (economies of scale), outsource, schedule, or otherwise automate.
You can create pipelines that save labor - like clients for platforms that make answering common questions / interacting with users way more comfortable and suited to your targeted workflow than the default clients.
On the creativity front, you can also generate random, semi-plausible stuff to inspire you when you're in a rut.
It's not quite about making everything automated, but about leveraging code, systems thinking, and collaborators in such a way that your performance is incredible. It's really feasible.
B stands for benevolent even in that case. The target of that benevolence is the project. His call should be in the best interest of the project (benevolent), final (dictator), and (tongue in cheek) eternal (for life)
