FreeBSD has serious problems with focus, longevity, and lifecycle

John Kozubik john at
Mon Jan 16 22:58:47 UTC 2012


I was disappointed to see that 8.3-RELEASE is now slated to come out in 
March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical 
of a trend towards longer gaps between minor releases.

I also see that undercutting the current release before wide deployment 
and maturity is continuing.  7.0 came (barely) after 6.3, which was bad 
enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.

Finally, the culture of "that's fixed in CURRENT" or "we built those 
changes into (insert next major release)" continues to get worse.  It's 
difficult to escape the notion that FreeBSD is becoming an operating 
system by, and for, FreeBSD developers.

The Problems:

Between JohnCompanies and, we have nearly one thousand full 
blown FreeBSD systems running on three continents.  We've been deploying 
these systems since 2001 and since "the rift"[1] have been increasingly 
subject to the following major issues, listed from most general to most 

1) A widening gap of understanding between the developers and the end 
users.  Not everyone has a fantastic tool chain and build environment that 
allows them to jump around from one snapshot to the next, cost free. 
We've got a thousand of these things, and not only are we going to run 
RELEASE software ONLY, but we're going to do everything we can to match 
that environment up across as large of an installed base as possible. 
The daily chatter on the lists about getting stable and getting current, 
or moving to the next major release reflects a complete disconnect between 
developers and end users.

2) Having two simultaneous production releases draws focus away from both 
of them, and keeps any release from ever truly maturing.  In January of 
2012, we should be on 6.12 (or so) and just breaking ground on 7.0. 
Instead, each release gets perhaps two years of focused development before 
every new fix is applied only to the upcoming release, and any kind of 
support or enthusiasm from the community just disappears.

This means that any serious or wide deployment gets stuck with a bad 
choice every two years - keep running something that's already essentially 
abandoned, or spend all of that time and money on QA, testing, 
documentation, shipping, etc., all over again, just like they did two 
years ago.

Of course the retort will be: "we added ZFS and ULE, etc., and those 
warranted a full release" - and maybe that's true, but since ZFS is only 
now, circa 8.3 (god willing) ready for any kind of prime time 
deployment[2], it would have been just fine to "release" it today, in 7.0.

3) Having two simultaneous production releases draws investment away from 
FreeBSD, because the relevance and longevity of those fixes are unknown. 
I am sure we are not the only organization that either needs new features, 
or needs fixes, that just aren't on others' priority lists.  In the past, 
we've donated time and money[3][4] to try to push some of these things 
forward, but it makes less and less sense when the lifespan of any 
particular fixes are limited to the shorter and shorter lifespans of the 
releases.  Why pay to get this fixed today when it's either "already fixed 
in CURRENT" or is already irrelevant ?  Meanwhile, end users that don't 
have the option to hire contract coders just lose out.

4) New code and fixes that people NEED TODAY just sits on the shelf for 8 
or 10 or (nowadays) 13 months while end users wait for new minor releases. 
Not only does this hurt end users, but it also hurts downstream projects, 
like pfsense and FreeNAS.

Here's a good example:  somewhere around 2007, a great many PCMCIA network 
cards (of interest to pfsense users, like me) just quit working.[5] I 
found that this was still the case in 2010.  I asked Warner about it, it 
got MFC'd, and I donated some hardware towards keeping these devices 
maintained.  So far so good.  But this was in June of 2011 which means 
that 8 months later this still isn't released and certainly isn't in 
pfsense.  Ok, fine - if I'm fiddling with PCMCIA cards in 2011, then 
perhaps "get CURRENT" is a reasonable response ... but be honest, do you 
have a build environment that allows you to take FreeBSD CURRENT and 
generate a new pfsense build from that ?  Do any pfsense end users have 
that ?  I don't.  More frequent minor releases would be a boon here.

5) New code and fixes that people NEED TODAY often get pushed into the 
next major release, since that's what people are working on anyway.

A few years ago we were dying for new em(4) and twa(4) drivers in FreeBSD 
6, but they were applied only to 7 and beyond, since that was the "new 
production" release (as opposed to the "old production" release).  It's 
the same bad choice again:  make major investments in testing and people 
and processes every two years, or just limp along with old, buggy drivers 
and no support.


Here are the specific actions that I think would dramatically improve the 
focus of the project, the experience of real end users, and the ability 
for third parties to truly invest in FreeBSD:

- Stop the trend of FreeBSD being an operating system by and for FreeBSD 
developers.  Think about the processes and costs that large and wide 
installed bases incur.  Think about the logistics of major upgrades and 
the difficulty of running snapshot releases, etc.  Remember - if it's not 
fixed in the production release, it's NOT FIXED.  Serious (large) end 
users have very little use for CURRENT.[6]

- Focus on one production release at a time.  Preferably for a solid five 
years.  In addition, provide actual legacy support for that release for 
another five years after that.  Five years of production and another five 
years of legacy would provide a very stable platform for development and 
investment, and would signal to large, complex organizations that FreeBSD 
takes their needs seriously.

- Release a minor revision every 4 months.  This sounds aggressive, but 
it's a lot easier if the project isn't simultaneously working on a second 
"production" release at the same time.

Thank you for reading this.  I look forward to comments and discussion.

John Kozubik

[2] Thank you for not hijacking the thread RE: production-worthiness of 
ZFS.  Just read freebsd-fs for a bit and you'll be sufficiently wary.
[6] It's worth reminding people that the official stance of the FreeBSD 
project is that *even STABLE* is "not a resource for end-users".

More information about the freebsd-hackers mailing list