I’m glad you agree that the important question is about control!
I would also prefer a big community consensus. I would have preferred if the CppLix and Auxolotl groups (plus any that I’ve not heard about) had stuck around for community consensus too. I understand why they didn’t. Call it ‘impatience’ if you want, but I accept that not everyone is going to have the same tolerance for waiting for the best outcome when it seems like it isn’t coming any time soon or when the football has been pulled away one too many times.
So I’m asking you to exercise empathy and imagine yourself actually in the position of the people making decisions at DetSys. Not because I think the community should prioritize their interests—we shouldn’t! But we should, as part of building that big community consensus that you and I both agree is the ideal, be capable of understanding their interests well enough to consider the likely reasons why they would take the actions they’re taking. You’re under no obligation to do this, but at the very least, even if you are unshakably confident that they are hostile, more understanding will make you a more effective strategist against them.
So let’s talk about their actions:
Maybe. Maybe the strategy is to withhold features from Nix and include them in DNix as an incentive to drive users toward their product. But if that were your goal, what would you do to achieve it? Would you leave those PRs open in the upstream project, and continue to push to them as recently as three days ago? Weird strategy if so!
But instead, what if you just wanted those features to ship? What if unaddressed questions were valid reasons for holding up the feature in a project you are not exclusively the owner of anymore, but you believe in them enough that you want to ship them anyway in a project you do control? Would that not better explain the record of actions that we have?
Consider it granted that DetSys has outsize resources at its disposal.
This, though… so what? Yeah, it’s the same language that an open core project, in which both the core and the proprietary halves are controlled by the same entity, would use. But the fact that Nix and DNix are not controlled by the same entity is an important difference here!
It seems like you are concerned that DetSys does, or might, have control over Nix, by virtue of its representatives on the Nix team! That’s a reasonable concern to have! This (and the trademark question) is what I think we should focus on, instead of litigating what third parties do outside of the Nix project! What policy should this community set for circumscribing the entrepreneurial efforts of members of the Nix team? When should the SC exercise its oversight option on technical decisions made by the Nix team? Let’s hear some proposals!
I will own the use of the word ‘silly’, and I should have phrased that more open-mindedly, but I am very skeptical of the hypothesis that DetSys are trying to hold features back from Nix when the hypothesis that getting consensus on complex features in a community project is actually hard is also available. As a member of a maintainer team on other projects, I have also left some of my own PRs open for years, despite believing in them and at times being tempted to YOLO the merge button. Resisting that temptation is a virtue, I think—and at any rate, I believe Eelco would have drawn just as much ire from the gallery if he had done that instead.
‘Fear’, I did not mean in any sort of dismissive way. I described both the community and DetSys as having fears in my post, and I believe both fears to be rational.