The availability of high-quality source code from the FreeBSD project, under its liberal license, is a boon to organizations (particularly startups) creating software products and appliances.
However, most organizations that I've had the oppurtunity to observe have not been looking at long term collaboration with the project. They take in FreeBSD source code as a one-time drop and forget to keep an eye on where things are going. These are the kinds of mistakes that I've seen being made:
- One organization developed a kernel module that relied on kernel threads being non-preemptible (despite PREEMPTION being present in -CURRENT). They had to scramble when kernel preemption appeared in -STABLE.
- One organization started with FreeBSD 5.X and kept fixing bugs that they encountered in their private copy of the code. They didn't feed anything back upstream, and had to redo their patches when they took the next code drop from upstream.
- One organization started an ambitious FreeBSD project but never spoke about it in public. They advertised for candidates, but had a few excellent candidates walk away unconvinced that they would find good FreeBSD work in that company.
Traditionally, you wouldn't think of collaborating with your OS vendor. You would buy their software, either as a binary or as source, and start using it. You wouldn't have the ability to influence your vendors strategy and decision making process (unless you were IBM, of course). While some vendors do let you view their bug-list, bug prioritization remains their prerogative, so if you are hurting because of a nasty bug, you just have to cross your fingers and wait. You would be constrained by your vendor's platform support policies too; they could stop supporting a platform that is unprofitable for them but still profitable for you.
Collaboration with volunteer developed projects is something new, something that is nearly never done in the closed source world. Collaboration is also something that is not possible with every open source project out there (just being "open-source" is not enough). Effective collaboration requires projects to be complete, transparent, to have good engineering practices, and to have fair and tranparent ways for you to contribute and influence their evolution.
FreeBSD has good code, and, perhaps more importantly, follows many practices that make it a solid foundation to develop products on.
So I wrote an article to introduce FreeBSD as a toolbox for product development. I've listed the benefits of taking the long-term view, and examined best-practices to follow when collaborating with the FreeBSD project.
This article on the FreeBSD website now: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/building-products/.
Read, enjoy, spread the word!