FreeBSD has serious problems with focus, longevity, and lifecycle
john at kozubik.com
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.
Between JohnCompanies and rsync.net, 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" 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
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, 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 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. 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.
- 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.
 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.
 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