[myrmidon]

Not necessarily.

The technical people managing the repos might just be opposed to name changing in general (seeing how a boatload of links, references, documentation would require updating, some of which you don't even control), and meanwhile those people might feel the "misbranding" drawbacks much less (if at all).

[burnte]

I would categorize all those as emotional reasons not to change, not logical reasons.

"It's hard!" So? "It's complicated" So? "Some of it other people control." This will always be the case, you can't let the perfect be the enemy of the good enough.

If the status quo means a worse project, then you're not changing because you don't WANT to, not because it's a good idea. And that's an emotional, not logical ,decision.

[thayne]

> "It's hard!" So? "It's complicated" So?

So it will take valuable developer time that might be better utilized to work on something else. And even if they do rename it, there isn't any guarantee that the other vendors would then agree to collaborate.

[scoopdewoop]

Technical procedural issues don't become "emotional reasons" because you hand-wave them away. This sounds like volunteering other peoples time.

[whateveracct]

now that's an emotional argument

[ffaccount2]

>"It's hard!" So? "It's complicated" So?

So there's no point in wasting time on this, if perceived problems are low or nonexistent. Current maintainers probably look at it from a technical pov "it's just a name, who cares"

[nine_k]

> it's just a name, who cares

This cannot be, naming things is one of the two canonical hard problems.

[technojamin]

I think it's the exact opposite of what you're saying. The maintainers sound like they're only considering the technical cost (and judging it not worth it) instead of factoring in the political consequences of keeping the same naming. I actually really respect those who value the technical over the political, but in a large-scale, public-facing project, some politics must be played.

It seems to me like you're viewing the playing of politics as a no-brainer, which is a very different mindset from a Linux contributor. I don't think people get into kernel maintenance to play politics.

[burnte]

No, I'm not saying the politics is a no brainer. I'm saying there is a logical barrier to the project succeeding, and it is the name. Other people refuse to work with it using the current name, people who would make it a much more useful product. Deciding it's not a TECHNICAL problem is an emotional decision, because you're not reframing it from what it is, a barrier to success, to something it's not, a non-issue. They're deciding not to engage with the hard problem.

[solarkraft]

The ones playing political games dressing them up as technical ones are the worst:

“My approach is technically correct and I won’t change it even though it causes issues down the line”. I’ve seen this a lot in the Gnome/Wayland world.

> I don't think people get into kernel maintenance to play politics.

I’m not a kernel developer and the projects I’ve worked on haven’t even been that big, but even there it was necessary to cater to multiple stakeholders and consider multiple viewpoints. I’d go as far as saying that software development in general gets pretty political pretty quickly, as soon as you depend on somebody else’s work or somebody else depends on yours. Every decision will impact somebody and different options will do so differently - these are political considerations.

I can’t imagine this being less of an issue in the kernel.

[zem]

it's not the exact opposite, saying that the technical aspects are more important than the political ones is an emotional stance, not a logical one.

[myrmidon]

Different people have different perspectives.

My point is that from a developers PoV, renaming is not an evident net-gain at all-- might be seen as pointless branding busywork that leeches ressources from "actual" problems.

That is not "being emotional", it's just different priorities.

[john_strinlai]

i am not sure why you would say that they are "emotional reasons".

comparing the cost (difficulty, complications, etc.) against the benefit of doing something before doing it seems quite logical.

[shermantanktop]

That’s exactly it. So many engineers aspire to build generalized, flexible components that get tons of adoption by being easy to use. The problem is that they have have just volunteered to be disconnected from their users. And this myopic refusal to rename Libwacom is a perfect example.

It’s probably down to one underappreciated Linux dev somewhere who is tired of the debate and spends their time fixing actual bugs.

[nine_k]

Change is painful in general. But it may have a sufficient upside to withstand the pain.

[bandofthehawk]

It seems like it would be simple to just create a fork and archive the old repo. Add a note to the old repo, update a couple of the most important docs and links, and then worry about the rest later. It can be low hanging fruit for new contributors.