Comment by tpmoney

>it doesn't look to me as if the Meson issue was never finished, it looks as if it was held up and then new things were added to the main project, and the Meson build had to catch up, several times

I still don't see evidence that it was "held up" by the Nix author. There's continuous work on it since at least the RFC was filed in 2022, and only recently at a state where both the RFC process is complete, and there's something ready to be merged to the code. The PR in which the Nix author expresses their hesitation does have a comment from 8 days after the PR is filed where the PR author asks whether this is something that's likely to get merged if they keep working on it. They are told they should go ahead and work. There does seem to be a lack of definitive agreement on whether this is going to be merged in the end, but none of that seems to be a case of the Nix author is standing in the way. In fact, they clarify that they're not opposed to the change, just skeptical. In 2021 there appears to be a new flurry of activity, with others expressing their own concerns, but none of that comes from the Nix author themselves. In 2022 the recommendation is that it should be made into an RFC for a full discussion and consensus about how it should be implemented, and the timeline I previously mentioned follows from there.

Certainly there is delay here, and some people definitely don't seem to have examined what was being proposed in depth, but these are all normal software development things. Nothing in this looks extraordinary for any large project with multiple stakeholders, nor does there appear to be any undue obstruction by the Nix author.

>Rather than the PR I am looking at the Discourse link where it says "@edolstra: Not convinced, knows the old build system but not Meson". Note it doesn't say "Meson is bad" or anything of the sort. This is a classic example of someone who wants to stay in control of something, to do so they need to understand how it works. That doesn't benefit the project, it only benefits the person.

Ok, great, they're not convinced. Are they actually holding things up though? If they were someone would have some evidence of this right? And indeed, the actual PR for this is approved for merge as of a few hours ago, with the note that while the Nix author wasn't convinced of it, they also weren't rejecting the proposal. Which is the sort of stuff that happens all the time in large project development.

To be honest, I'm not quite sure I really understand this "the Nix author has doubts, so we're being obstructed" line of thought. A doubt is not a rejection, it is a doubt. And yes, the Nix author by virtue of being the project owner certainly has the ability to unilaterally stop something from happening, we're not given evidence of that, just them expressing their doubts. If a person expressing doubts about a change, even the project author, is enough to make the open letter writers give up I don't see how they would make better project managers.

I worked a position once where the VCS system had been converted from ClearCase to Microsoft TFVC just a few months before I came on board because the project lead was an old Microsoft hand and that was what they were familiar with. I advocated for switching to git (or mercurial) and met with similar levels of skepticism. The project leads did not see the benefits, and certainly not so soon after having done a migration. That skepticism did not mean I should simply give up if I felt there were benefits to be gained (and I did), it meant I needed to provide concrete examples of the benefits and why it was worth the effort and churn to make yet another change and for people unfamiliar with DVCS to learn it. So I set up a side, parallel version control that used TFVC as an upstream, recruited a couple developers with a similar interest in making the change and we ran our system in parallel for a few months. We built up the tooling our process would need to make it work, volunteered to take on hard tasks that git made easier, tried a few different git flows to find one that worked for our stack and documented the process, recorded the pain points that other teams had with TFVC and compared those to the pain points we had in git, we built a process for lossless roll back to TFVC if a change to git proved to be a bad move. And once we had better more concrete arguments with real world use to back it up, we made the case again and this time convinced the skeptical people to give it a go. Some even still remained skeptical, and yet the change happened.

Skepticism is part of working with other people, not everyone will see things the way you do. It's also not obstructionism or bad management for managers to be skeptical. It is part of their job to give a skeptical look over proposed changes to ensure they will bring benefits greater than their costs. If the absolutely mild skepticism of changing build systems expressed by the Nix author is enough to derail that change, then it seems to me the change advocates don't believe the benefits are worth making a stronger case for.

>With respect to the xz stuff I simply don't agree. Are we never adding new maintainers to open source projects anymore until xz is no longer top of mind in a couple of years?

This is the second time you've put the same words into my mouth, and I'll take it as a kindness if you would stop doing so. I have never said open source projects should never add new maintainers. That is patently absurd. There is a vast gulf between adding new maintainers every time people complain things are moving too slowly and never adding a new maintainer. This sort of catastrophic interpretation of mild objections and counter points is an unhealthy trend in online discourse.

>The screenshot is from before the xz backdoor so it definitely wasn't top of mind for them. And they (including Eelco) even agreed in a previous meeting to add more maintainers

I realize that it's from before the xz backdoor, nor did I mean to imply it wasn't. The phrase "in light of X, Y was a good idea" doesn't necessarily require that X happened before Y, it can also express a hindsight view. In this case the xz backdoor gives us a different perspective after the fact on how eager project maintainers should be to hand out access. As for the previous meeting, it's 8 months prior to the linked discussion in the open letter. So what happened in those 8 months? Did "@edolstra and @fricklerhandwerk" not get in touch with any prior contributors like they said they would? Was no progress made on this in those 8 months or did it come up again in 2024-02 because people felt not enough progress was made? Also the meeting notes say that they thought they could at a minimum use more people triaging, yet the open letter's complaint is that the users were "only" given that triaging access. It seems hardly fair to cite a discussion where a solution was proposed, and then be mad that was the solution taken. Further, it's clear from those meeting notes linked in the letter that there were other options to potentially solve the problem other than just adding more people. Just because one's favored solution isn't chosen doesn't mean the project is being mis-managed.

>I see no real reason to doubt that one guy is holding the project back. You are talking about "rampant bad behavior" but that is not necessary to severely frustrate a project.

I do see a reason to doubt that. When an open letter advocates the severing of the owner from the control of their own work, I expect to see a good reason to support such an extreme measure. And let's not delude ourselves here, that is exactly what this letter is asking for, support to strip control of a project from its creator and owner and give it to other people. Whether or not one is happy with how the owner has managed the project, the project is unequivocally their project. Wresting that control away from the owner if it is to be done must be done only on the back of strong evidence that it is both necessary and the correct thing to do.

When that letter further opens with such charges as "exhibits several corrosive social behaviours that have created a culture that directly led to today’s governance problems, which are an existential risk to the continued viability of the project" and "[leadership] deleterious to the project by him undermining authority of others, by him avoiding giving away authority and thereby disallowing community leadership to develop, by ignoring issues which he relitigates after discussion was done, and by holding undeclared conflicts of interest that pose serious risks to the Foundation and the Nix project as a whole.", then I absolutely expect to see more bad behavior than a number of normal day to day software development disagreements that at worst merely rise to "Simply bad leadership".

>I wonder if there is anything except blatant bullying that would convince you that Eelco needs to relinquish his position.

I would think so, but whatever it would be, it would have to be something greater than "simply bad leadership" and that's not this. Maybe the conflict of interests would have been a worthwhile discussion to have, but the letter poisons its own case so badly, I'm disinclined to give the letter authors the benefit of the doubt. They've at best omitted relevant facts and events, linked to inadequate evidence of their charges and at worst misrepresented (whether knowingly or not) the events in question. I have no faith then that they are accurately representing that issue either, and frankly I've already spent more time than I should have so I'm not inclined to spend any more time trying to suss out more fact from fiction.

Maybe Eelco does need to relinquish their position, but if so, the open letter authors have failed to make that case in any substantial way.