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!
Hi Joseph,
ReplyDeleteI'm a fan of FreeBSD and prefer it over Linux for many reasons, recently I got laptop and finished installing FreeBSD on it as well.
I'm going to attend FOSS.IN/2005 at bangalore. I'm also planning for distributing FreeBSD copies there may be after your talk :)
Let me know your thoughts on this.
www.VijayKiran.com
Finally, managed to read your doc; a very lucid and good read - thanks.
ReplyDeleteA couple of random points:
1. In the goals/audience sections, you have identified four logical groups for whom it would be quite useful. IMO, not all of them have been addressed with equal vigour in the doc; however, this may be by design; but, in my opinion, if you write a separate doc just covering the reduction of GTM(!) time, risk reduction etc that would be nice (this targetted at the 'manager' level folks); further after summarizing the never ending cute, earthly and useful features_list of FreeBSD, if there are separate sections on how is FreeBSD appropriate for each group of audience, that would be nicer.
In small product companies, they would like to be bothered about solutions and not bother too much about base platform (now this could lead to religious warfare - so gotta do 'management by skirting around') - they merely want to reduce perceived risks, that's all - and so the prospect of spending a lot of energy presumably on a platform choice is the one that drives a few guys away from FreeBSD; have known at least 3 cases in this context, personally.
In any case, even if the product engg/mgmt folks want to go in for FreeBSD as the base platform, they are likely to be most bothered about 'support' and I suppose this can be captured in detail; though there is a list/link in the doc detailing the vendors etc - if there are some suggestions on how a suitable vendor can be identified or the experience of a prod co which went in for this arrangment - these kinds of things would enormously boost the value of the document.
All in all, good effort and may the ink flow more... (or kbd strokes or whatever)...