Do-ocracy. Just because none of those devs want it enough to implement it, doesn't mean they'd turn away somebody who did. If somebody wants it bad enough, they'll do it.
> “Jeez, why does Mary get to decide what everyone eats and when they work? Who put her in charge?” Older and wiser heads will say, “This is a do-ocracy. If you think you can do Mary’s job, and you want to, then get up there and do it. She’ll probably be relieved. If not, don’t be a jerk and make a big stink about it, or else she’ll stop working so hard and we won’t have anything to eat!”
I'm an OpenBSD user and Bluetooth Audio is a non-problem. Creative makes little USB Audio devices that OpenBSD treats as a HID soundcard and Creative handles the Bluetooth itself.
There are larger forms of this but Creative's form factor is very small.
The number of regular OpenBSD users that are not programmers is probably vanishingly thin. If my memory serves me correctly, there are features of modern x86 processors that it straight up doesn't implement on a don't-care basis, so it's pretty safe to say that nobody that has made peace with that is looking to deal with technology as maligned as Bluetooth when they're likely already buying hardware specifically to run OpenBSD.
I'm a fan of OpenBSD's more conservative and structured approach to software development, but in this case I must beg to differ. In the linked CVE, OpenBSD was unaffected because "[it] didn't chase the fad of using every Intel cpu feature." The feature in question was user-space hardware debug register access. Without such access, watch-points are borderline unusable[0].
Perhaps prohibiting access to user-space except GDB would be a reasonable compromise. Also, debug registers are not unique to x86: most (all?) CPU architectures have them. So calling it a "fad [...] Intel cpu feature" is a bit unfair.
You could also pay someone else to write it for you. OpenBSD is a free, community based project - you cant really complain it doesnt do what you want if you arent willing to invest any time or money.
Say I wanted to go down this route and pay someone to implement Bluetooth in OpenBSD - don't you think that'd be a huge project and cost many thousands of dollars?
Figure out some interested people upfront and a rough time (thus cost) estimate.
Then pool resources via a funding platform, get the word out (here on HN, social media, mailing lists) and you may get it done quite soon and also at a low relatively low cost per user.
To be honest, with some other open source projects I've wanted to "pay for someone else to do it".
But like, that's actually _also_ a lot of effort! Especially for projects that are "abandoned" or have no obvious owner, since then you're in "hire a random X programmer to do this for you".
I feel like more OSS projects should go beyond "Donate" and have a "buy a feature/bug fix" button.
Makes sense. “You get what you pay for.” “Don’t look the gift horse in the mouth.” “Take it or leave it.” Sure. But the old trope still feels wrong somehow.
Not really - in the case of Linux you pay the same price as OpenBSD but you get much more.
That's because enough people decided to put enough effort to support as many use cases as possible, until the OS got enough momentum to be hard to ignore.
The BSD approach has instead always been "you want it? then code it yourself and open a merge request". That sounds legitimate, but that's the real reason why OpenBSD has never taken off outside of its small niche of geeks - despite being an amazingly designed OS under the hood.
And I know many of those geeks who are quite proud of being part of a tiny niche that scuffs at Bluetooth, USB 3.0, QHD displays or anything that a "normal user" might want - had it been for them a 640x480 screen with a working session of xterm would have largely sufficed. But that's also the reason why there aren't many "normal people" using their OS.
At some point one should also ponder why we support and contribute to open-source projects (especially considering that we mostly do it in our spare time, that, in the case of developers, is often limited and precious). Is it because we want to make the (IT) world a better place with more free and cool products and attract more people, or is it because we like our own well-curated niche and we don't want to let anybody in?
I disagree that there is any fundamental difference between Linux and OpenBSD, when it comes to supporting new features, around who should do the work. You’ll find plenty of “where’s the patch?” replies in linuxland too.
The difference is that OpenBSD BDFLs (Theo et al.) have not been willing to compromise their vision of what the OS should be and how it should be developed just to chase popularity. Look at how they still use CVS, ship their own httpd and ssl libs, dropped sudo years ago (and then rewrote it)... they prioritise consistency and reliability over ubiquity and “the new shiny”. Chances are that, even if you wrote a BT stack yourself and submitted it, it wouldn’t be merged unless it fits their philosophy.
That’s the real difference: Linus and his generals have been willing to accomodate and support a higher number of features just for the sake of it, because it was cool; they were more accepting of incoming developers; and they were much friendlier towards business interests, accepting binary blobs and so on, which is somewhat ironic (Linux is very hard-GPL “inside” but then gave up when it comes to drivers; OpenBSD is, well, BSD everywhere, but they push super hard for manufacturers to open their drivers).
OoenBSD makes IT better too, but it does it on its own terms, and that’s fine.
You can like your own niche without holding a strong opinion about ‘letting people in’. Not going out of one’s way to be welcoming is not an indication of gatekeeping or any other ill intent.
> Is it because we want to make the (IT) world a better place with more free and cool products and attract more people, or is it because we like our own well-curated niche and we don't want to let anybody in?
Both? OpenBSD's niche is being so secure it (almost) hurts. Curating that is worthwhile in a Research OS sense: How many knobs can we tweak on a POSIX system to increase security while explicitly and loudly not caring about much of anything else? Keeping everyone who doesn't share that vision out is part of the plan.
They can be the security pioneers, and the rest of us can see where they get scalped so we don't repeat their errors.
It’s not a problem, nobody minds if you don’t use it. If it’s in products, it’s not likely you would even find out. Everything isn’t for everybody, after all. A hundred companies and more are running Linux, Theo and a couple dozen people run OpenBSD. It’s hand crafted and if you don’t like it, there’s a big giant circus tent called Linux over there.
There's not a lot of applications where bluetooth is essential. Personally, after several rounds of disappointment with bluetooth mice, the only thing I use bluetooth for is handsfree calling and sometimes music in cars. Even that sometimes doesn't work (my spouse's Nokia 7.2 couldn't connect to her car between July and December, because something in the Nokia firmware was broken; worked fine with my car though).
So, my guess is nobody who works on OpenBSD a lot cares about bluetooth on OpenBSD, because they're not using bluetooth much, and don't see any use cases for it that would help them.