Theo's initial response to the thread, which may help illuminate the situation, was:

"Except for the fact that it is bullshit.

They started the fork because they got kicked out because one developer (Marco) hired 5 other developers for his startup company, and attempted to hire around 10 other developers in a sneaky and underhanded way. They were told, oh i forget they were "asked", to not tell anyone else in OpenBSD that this was happening, probably because people "including Theo" would be upset.

Funny thing is, I've never been upset about the 20+ OpenBSD and ex-OpenBSD developers who now work for google.

Previously, many of those developers were in critical positions in the development team. As they were suddenly hired with such terms and conditions, they became more scarce in OpenBSD -- perhaps because they suddenly got real busy with work, but also to avoid telling others that this was happening. Various projects lagged. To avoid telling a lie, they instead chose to not tell the truth. It had effects. It was dishonest of them to not tell their co-developers that they were creating vacuums in the development process.

So because of those decisions, they are now gone from OpenBSD. And now they miss it. So now, all these guys who work for the same company have started a fork. And it is directed by the guy who hired them in the first place.

From where I stand, that is the truth.

Yet none of that is in that article, because the truth hurts, doesn't it guys?"

It's much more interesting to compare the development process of the groups, and how the two groups will help each other.

I always thought if OpenBSD had modern development tools and processes they would do really well, but unfortunately there are too many risks. How they're doing it works well for them already. But perhaps this situation with another group working in a different way better again. Since this project can experiment, and anything that is proven can be taken on by OpenBSD.

Hopefully the bitterness surrounding the fork's birth will eventually wash away and the people involved just look at the benefits. And it's not true that the two groups aren't helping each other. Some code does flow between OpenBSD and Bitrig, just as it does between OpenBSD and NetBSD. And there are people who are involved in both, and communicating with developers from both projects.

I just don't understand this attitude. Git and Clang or GCC 4.bleedingedge.something don't write the code for you. Is having to commit to an older VCS really that high a barrier to entry for developers? Because if it is, that makes me suspicious of their skills and focus.

As far as Bitrig is concerned, I don't see the point in it. The FAQ doesn't say anything that makes me want to try it and, although they say they want to support only modern systems, it seems to me that what they are really doing is limiting themselves to what LLVM supports.

Could you point me to the part where that happened? I thought I read the whole thing but I can't seem to find anything like that.

Congratulations on the 1.0 !

Otherwise I do not have any NetBSD stuff in mind. Can't speak for our other developers though. ;)

I would love to have FreeBSD's bhyve on Bitrig. I will dedicate some time in January for that goal. DragonflyBSD is an inspiration for us, too. We have an experimental branch (smpns) for revamping the kernel for decent SMP support.

Pretty much every other major OS out there like GNU/Linux, FreeBSD and Solaris offer some sort of solution like that, but OpenBSD and co sadly do not.

Something like that would give me a good deal of motivation to switch.

> Why is the project named Bitrig? > > The name Bitrig is derived from the Latin "Bitrigus", the name of the software used by the Romans to conquer Europe. Sadly, not having zero among its numerals made traditional computer science difficult for the Romans and the project was put on hold indefinitely. Bitrigus faded into obscurity until it was recently rediscovered at a Viking archaeological site in the modern day country of Iceland. > > The Roman emperor Hadrian is rumored to have sent Bitrigus as far west as a boat could carry it to keep it from the then growing threat of religious fanaticism within the Roman Empire.

OpenBSD is an amazing project and has some of the best code around but some of us are of the opinion that it could use a bit of modernization. OpenBSD is a very security conscious project and, correspondingly, has to be more conservative with features. We want to be less restrictive with the codebase when it comes to experimenting with features.

https://github.com/bitrig/bitrig/wiki/Faq

http://bsd-beta.slashdot.org/story/12/06/13/1645211/openbsd-...

I'm not sure why I would use a fork of OpenBSD instead of just FreeBSD though. I've always seen the primary benefits of OpenBSD as deriving from their obsessive focus on security, but if this fork isn't focussed on that I'm not sure what I gain vs. other BSDs that already have these goals and objectives in place/completed.

It would be interesting though if Bitrig became sort of a DragonflyBSD for OpenBSD, where weird experimental stuff can be tested in a separate playground.

It is you who say "instead", can't it be "in addition to"?

Why wouldn't they start with what they already know, find good, and are happy to work on?

It'd be easier to carefully add specific features to a well-designed and secure codebase such as OpenBSD, rather than try and pare down and audit the huge codebase and large amount of features provided by something like FreeBSD.

Looks to be a desire to leave behind legacy cruft, add a better toolchain, and add virtualization.