I don't think so.
I suppose I can understand why people who feel strongly that the OSI definition is perfect (or at least extremely good) are very intent on protecting it, whereas I see it as flawed and am thus less concerned about this fracturing. So I understand your perspective upon reflection, though I honestly have a lot of trouble imagining holding it myself.
A lot of people in this thread have been saying stuff like "just go full proprietary, that's better", and it sounds ridiculous to me every time I read a variant of it
I think it's a common shared understanding and a focal point, and there's huge value in preserving that. Having a different common understanding might be acceptable, and might even be an improvement, but only if people agree on it. Having no common understanding would mean something of great value was lost.
Right now, many different groups who may not all agree on all goals nonetheless gain value by sticking to Open Source, and not a dozen slight variations on additional restrictions. In the absence of that, we'd have the "non-commercial" group, the "educational use" group, the "don't compete with us" group, the "don't use for military applications" group, the "don't use for nuclear reactors" group, the "don't use to develop proprietary software" group, the "don't redistribute unmodified versions" group, the "don't distribute outdated versions" group, a dozen variations on "don't distribute if you disagree with our values" groups, the "don't distribute if you're a large company" group, the "don't distribute if you're a specific company" groups...
Every one of those is a license term I've seen advocated. Every one of those violates the OSD, so it thankfully stays obscure and unpopular, because enough people prefer using and contributing to software with less unusual licensing.
Yeah I guess this just seems like hyperbole to me. It seems good to me that there's a pretty widely agreed upon definition, sure, but I just don't think it matters all that much, in the scheme of things.
Agree to disagree I suppose!
As for the commons, you are aware that the OSD comes from the Debian Free Software Guidelines (it's the same thing but for some minor working changes)? That is the commons that's been talked about, and it's deployed on far more systems than any BSL code is. So moving to completely propriety (note that this doesn't mean it's not Source Available) means that everyone is upfront about what the state is, whereas something like the BSL is leaning into the halo effect under the justification that the code will be open source at some future point.
But this second part of the argument I just don't grok at all. These licenses like BSL provide significantly more of what I want in software I use than proprietary software does. (Namely, the ability to read, modify, and self-host the software of I choose to.)
I think what must be going on is that when you see a license like this you think "there is no point to something like that besides a PR stunt trying to imply proprietary software is open source", and I think "oh this seems like a really useful compromise that allows commercial enterprises to create software with code that I can read, modify, run myself, and contribute to if I want to, without a different company that did none of the work on the software making all the money from it". Just totally different perspectives.
The reason I'm personally annoyed at the attempt to drop the requirement for no restrictions on use is because it is something some academic software does (things like "if you use this code, any results must be shown to me before publishing and require my approval", which as you can imagine isn't great), or with rules around benchmarking (which some DB companies have been known to do), and it's significantly harder to draw the line between something that would allow the BSL, or the above two cases, than it is to require no restrictions on use.