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 have had the opportunity to observe have not been looking at long term collaboration with the project.  They import FreeBSD source code once, and forget to keep an eye on where things are going.  These are the kinds of mistakes that I have 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 did not feed anything back upstream, and had to redo their patches when they imported 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 would not think of collaborating with your OS vendor.  You would buy their software, either in binary form or as source code, and start using it.  You would not 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 have listed the benefits of taking the long-term view, and have suggested best-practices to follow when collaborating with the FreeBSD project.

This article on the FreeBSD website now: Building Products with FreeBSD.

Read, enjoy, spread the word!