How closely are Mac OS X and BSD related?

I read that Mac OS X and bsd are related. How closely are they related. Can Mac OS X software be tweaked and installed on BSD?

Back in the days of OS X 10.4 I spent some time failing to write a VFS for OS X. In those days, of the major subsystems of the kernel, only the network stack and the VFS were still truly BSD. At that time, even the VFS had been partly rewritten to make it more modular (all the BSD VFS data structures became opaque pointers and the API was through what were called KPI functions). I believe the network stack was going the same way. There was also a thin layer at the interface with userland that made the OS look like BSD to userland programs.

Everything else had been pretty much rewritten or replaced: memory management, process management etc came from the Mach microkernel; the device driver subsystem was written from the ground up by Apple.

In terms of userland programming, OS X is very similar to BSD and programs written for BSD should be easily portable. However, OS X has a lot of APIs that aren't available in BSD. These include almost everything to do with the user interface - graphics, sound etc. There are also other interfaces that don't exist in BSD such as the launch API which is the OS X preferred way of launching background processes.

The Wikipedia BSD article is good (and accords with my own understanding, for what that's worth). It says that Darwin, the system on which Apple's Mac OS X is built, is a derivative of 4.4BSD-Lite2 and FreeBSD, and notes that 4.4BSD is the last release that Berkeley was involved with.

So, Darwin is as BSD as you can get (just like all the other BSDs!). OS X refers to those parts of the distribution which aren't open-source, principally the GUI, but including a variety of frameworks, and anything which relies on these won't be portable.

OS X as a whole is a UNIX 03 system. That's equivalent to being a truly POSIX-compliant system (as opposed to being POSIX-like).

As other answers have noted, the userland parts of the OS are unsurprising to anyone with much unix experience, and I've rarely had any difficulty building portable-unix software on OS X.

In contrast, the non-userland parts of the OS are pretty different. Apple seems to be willing to innovate in those areas fairly cheerfully. I think (but I'm not positive) that these changes are formally part of Darwin. One of the most obvious differences is that launchd has replaced cron, at, inetd, and much of the startup infrastructure.

If the Mac software uses Cocoa, Apple's proprietary display library (which it does, if it runs on the Mac with a GUI and does not require starting an X server), then you may have some issues running the code on a normal BSD system.

If your code only uses POSIX-specified functions, it will cleanly port to Linux, BSD, and even Windows.

It is true that Mac OS X and BSD are related. Although they have different kernels, they share a common ancestor and significant userland code. Obviously, I can't quantify "how close" - that's subjective.

Mac OS X is one flavor of BSD Unix. As Borelaid already pointed out, that does not necessarily mean that porting Mac apps to other flavors of BSD would be easy or even manageable, much less so than between other common BSD flavors. Every one of them brings their own specifics, and OS X more than most.

Porting programs from other BSD flavors to OS X also involves work and does not always work (smoothly or at all), but is usually much more straightforward.

It depends on what kinds of apps you are trying to port. If you write POSIX-compatible C/C++ console programs, they will compile and work just fine under any POSIX-compatible system (mostly Linux and BSD flavors), but note that OS X often doesn't implement the newest POSIX functions (e.g. utimensat) which are available in Linux. On the other hand, graphical applications use Cocoa or the older Carbon, which would require GNUstep. Porting graphical applications is quite uncommon because every graphical environment has different design standards and conventions, so graphical applications usually have to be written from scratch for each graphical environment.