I wrote the quote in Perry's post, based in no small part on my experience as a developer elsewhere (but not in this project).
Though I didn't make it clear, the mention about downloading and bootstrapping was thinking of the developer ISO in the context of giving early access to those who are conversant with the internals of pfSense. When you first run the developer ISO after installation, a bootstrap process grabs the latest version of the configured FreeBSD and pfSense CVS branches (or HEAD in the pfSense case; you can't use FreeBSD HEAD nor should you want to) and builds a normal ISO.
Whilst you can check out pfSense 1.3, you'll find it almost impossible to build as I don't think there's a publicly available pfSense developer ISO based on FreeBSD 7.0. Upgrading the FreeBSD version in a developer installation is very much non-trivial.
I am sure we will see snapshots and, later on, beta builds of 1.3 - but the code needs to be ready for those builds to be released. Giving early access when it isn't ready for public viewing causes the problems mentioned in my quote. Neither pfSense nor FreeBSD works on a timed release schedule - in a similar vein, there is currently no timescale for FreeBSD 7.1.
As someone who is very familiar with FreeBSD, though not as familiar with the pfSense internals, I thought I'd try to explain some background that will hopefully help silvermage and others in a similar position.
pfSense 1.2.1 is on its way, which is based on FreeBSD 6.3 rather than the 6.2 of pfSense 1.2-RELEASE. The pfSense team have stated that they hope to release 1.2.1 by the end of May 2008, which is the end of life date of FreeBSD 6.2-RELEASE (and the point at which there's no longer any FreeBSD security team support for it).
There are a great deal of improvements in FreeBSD 6.3 - including better hardware support together with various enhancements and bug fixes that were suitable for backporting from the active development in the HEAD of FreeBSD CVS. FreeBSD refers to such backports as MFC - Merge From Current (FreeBSD CVS HEAD is referred to as FreeBSD CURRENT).
Because FreeBSD 6.3-RELEASE was released so long after 6.2-RELEASE, the 6.3 FreeBSD packages are much more up to date than the 6.2 ones. In fact, the FreeBSD 6.3-RELEASE packages are the same versions as in 7.0-RELEASE because the release cycles of the two OS versions were aligned from a ports/packages point of view. (There were a handful of cases where there were security flaws found in packages between the two OS release dates, so a later version might just have shipped in 7.0-RELEASE in that case). This should help pfSense package developers, as work done on pfSense 1.2.1 should hopefully be easy to port to the FreeBSD 7 based pfSense 1.3.
You talked about different Linux distributions (or 'flavours'). There's no such concept with the BSDs - each is a kernel and userland, unlike Linux where Linux is technically only the kernel and it's up to each distribution to come up with a userland. Each approach has strengths and weaknesses - I prefer the FreeBSD approach, but I can see how there are advantages in being able to have an OS distribution that's packaged to suit your intended application.
Of course, there is code sharing between the BSDs and even from beyond the BSDs when licences are compatible. OpenBSD's OpenSSH, in its portable guise, is used in almost every free *NIX operating system, incluidng the other BSDs. OpenSolaris's ZFS has been ported to FreeBSD - though it's still an experimental feature in FreeBSD 7.0.
There are also derivative distributions - from FreeBSD there's the FreeSBIE Live CD, m0n0wall and pfSense amongst others.
There's usually no trickery needed to install software on FreeBSD. If a FreeBSD port is compatible with a particular major OS version, a binary package will be produced for that version. The port itself, in conjunction with the ports framework, deals with the differences between the OS versions.
If the source material for a port is only available as a binary for a particular major OS version, it is usually possible to use that binary on a later major OS version using the compatibility features of the OS and the compatibility libraries, so a package is still possible - if so, this is transparent to the user. The port maintainers and ports committers do all this work for the end users - though FreeBSD PRs (problem reports) with feature requests, bug reports and especially patches are always welcome for any issue you have with a FreeBSD port or package.
Some Linux binaries can be used on FreeBSD via FreeBSD's Linux emulation. There are some examples amongst the ports and packages of this - usually linux appears in the name of the port or package.
As is often said on these forums, FreeBSD is not Linux. Linux shell scripters can get caught out on FreeBSD because bash is not the default shell, /bin/sh is not bash, and bash is not installed unless you install the bash port/package or install bash from source. Similarly, the default make program on FreeBSD is BSD make - if you need GNU make (gmake on FreeBSD), you need to install the gmake port/package or install from source.
If you wish to do any pfSense development, it may pay to familiarise yourself with FreeBSD, its documentation and ports/packages system. A FreeBSD port is simply the recipe to create a binary package - though installing from ports often allows you to tune the port to your requirements.
I've yet to get into pfSense package development, though I'm going to explore the possibility of an apcupsd package. apcupsd has better support for SNMP managed UPSes than nut - my server rack has such a UPS.
I'm grateful for Perry's links - I knew about the devwiki, but the last one is new to me. I wonder if the right way to develop this is to experiment on the version of FreeBSD i386 corresponding to the pfSense version you're developing for, check your work at the shell of a pfSense developer ISO, then start to build the UI and other components required for a pfSense package. That's only a thought from me, however - it's not based on any experience.
