FreeBSD has serious problems with focus, longevity, and lifecycle

Mon Jan 16 23:49:56 UTC 2012

I also echo John's sentiments here. Very excellent points made here.
Thank you for voicing your opinion. I was beginning to think I was the
only one who felt this way.

I also have several FreeBSD installations spread across different
development/production systems and it is not feasible to always upgrade
to the latest and greatest. Part of why FreeBSD is difficult to adopt
into more of the commercial/government sectors is because of this fast
paced release cycle and most of the important patches/fixes are not
backported far enough. This is why most of my customers decide to use
Solaris or RedHat and not FreeBSD. (Not looking to start a flame war
about the OS choice/etc just pointing out the Release cycle model). I
would love to push FreeBSD harder but it is becoming increasingly
difficult as of late.

We seem to have lost our way around the release of FreeBSD 7. I am all
in favor of new features but not at the risk of stability and proper
life cycle management.

Are me and John the only people that feel this way or are we among the
minority?

-Will

On Mon, 2012-01-16 at 14:28 -0800, John Kozubik wrote:
> Friends,
> 
> 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 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"[1] have been increasingly 
> subject to the following major issues, listed from most general to most 
> specific:
> 
> 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.
> 
> 
> Suggestions:
> 
> 
> 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
> 
> 
> [1] http://lists.freebsd.org/pipermail/freebsd-chat/2011-September/006630.html
> [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.
> [3] http://blog.kozubik.com/john_kozubik/2009/01/64bit-freebsd-quotas.html
> [4] http://www.rsync.net/resources/notices/2007cb.html
> [5] http://www.freebsd.org/cgi/query-pr.cgi?pr=115623#reply12
> [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".
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"