Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


It would 10.000 -> up range for sure.


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.


> "buy a feature/bug fix" button.

You could run into a problem with a lot of OSS no-warranty policies this way.


"Sponsor a sprint". No guarantee of success, but if you're paying their salary for the next two weeks, you pick their tasks.


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.


Question is, who will pick it up when the OpenBSD BDFLs are no longer around to carry the flag.


That's a very good question. Every once in a while some new faces pop up, but afaik there isn't a well-defined process to replace core developers.


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.


I agree with the attitude of "if you want it, code it" however I disagree with this point. Gatekeeping does not have to be intentional for it to be the case. Sometimes it can be out of good-will, even.

For an example of the last point, transgender care in the UK -- it takes 2 appointments to get treated (hormone therapy), it can take up to 4+ years to get the first appointment (those are the smaller waiting lists), and another year or longer to get the second before you are finally treated for it. This isn't done out of bad-will, it is done out of intent to not mistreat people. However, the effect of this is that it gatekeeps people who can have access to trans care to those who are able to afford it.

Gatekeeping does not require intent, nor does it require malice. It can simply be the result of a cultural artifact creating what is percieved to be a hostile culture.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: