Date: Mon, 16 Jan 2012 14:28:09 -0800 (PST) From: John Kozubik <john@kozubik.com> To: freebsd-hackers@freebsd.org Subject: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <alpine.BSF.2.00.1112211415580.19710@kozubik.com>
next in thread | raw e-mail | index | archive | help
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".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1112211415580.19710>