Solved Did anybody else notice that FreeBSD 12 only has an 18-month lifespan?

[Terry_Kennedy]

TL;DR - Release Engineering is apparently only committed to supporting FreeBSD 12 for 18 months

Before FreeBSD 12.0 was released, the "Security Information" page (Internet Archive capture on November 22, 2018) said:

Branch Release Type Release Date Expected EoL
stable/12 n/a n/a n/a December 31, 2023 (anticipated) 
releng/12.0 12.0-RELEASE n/a n/a 12.1-RELEASE + 3 months 
stable/11 n/a n/a n/a September 30, 2021 
releng/11.2 11.2-RELEASE n/a June 28, 2018 11.3-RELEASE + 3 months

That page was edited multiple times and currently (12-Dec-2018) reads:

Branch Release Type Release Date Expected EoL
stable/12 n/a n/a n/a June 30, 2020 (TBD) 
releng/12.0 12.0-RELEASE n/a December 11, 2018 12.1-RELEASE + 3 months 
stable/11 n/a n/a n/a September 30, 2021 
releng/11.2 11.2-RELEASE n/a June 28, 2018 11.3-RELEASE + 3 months

In other words, the support commitment went from the expected 5 years to "maybe" 18 months (per TBD in the above table). This is completely un-workable for me - if I wait for a 12.1 release (which likely wouldn't happen for at least 4 months from the release of 12.0), by the time I've built new images for all of my servers, the EoL of 12 will be in a year. I suspect there are others who will be similarly impacted.

Even more disappointing is that FreeBSD 12.0 was released with what was essentially a "We don't know how long we'll support 12, but we'll let you know some time in the future" footnote on the "Supported Releases" page. Note that the 5-year support model was still in place as of November 22nd (the date of the Internet Archive capture above). Google's cache (local PDF capture here) still shows December 2023 (anticipated) although it adds wording about "re-evaluating the 5-year support guarantee".

Over a week ago I sent the following message to re@ and core-secretary@ (core-secretary because they posted the announcement, re because, well, re). Having received no response and seeing the "Supported Releases" page further walk back the EoL commitment, I reluctantly decided to post here to see what others thought about this change.

From: IN%"Terry Kennedy" 3-DEC-2018 00:07:33.57
To: IN%"core-secretary@freebsd.org", IN%"re@freebsd.org"
Subj: Re: [FreeBSD-Announce] Interim support guarantee for FreeBSD 12

TL;DR - Please *DON'T* do this for FreeBSD 12.

Rather than wait for the "opportunity for community feedback"*, I figured
I'd jump in now.

What my company needs is _longer_ guarantees, not shorter ones. Micro-
soft does 10 years (at least until Windows 10, billed as "the last Windows
you'll ever need", but not for the reason they think). Debian LTS is 5
years. Ubuntu just announced an extension of their LTS from 5 years to 10
years.

We were making plans to move our 10.x systems to 12, but the delays in
getting 12 out mean that we're getting "You're using an unsupported re-
lease" warnings. Not to mention certain ports maintainers who seem to de-
light in ripping out support for old versions days after the old versions
are actually out of support (for example, ports/head/net/samba48/Makefile
r483807)

Now we have to re-evaluate our FreeBSD strategy - if FreeBSD 12 is go-
ing to go EoL at some indetermate time before the currently-listed 12/2023
date, we may need to look into alternate operating systems.

Note that we build from source, customize a large number of things, and
generally (at least we used to) jump 2 major releases at a time, so things
like freebsd-update (even if it didn't have the problems noted by a large
number of users) isn't a solution for us. Even if it was, we still could
not handle the downtime and multiple reboots needed - we'd still need to
pre-stage the update on identical systems and swap disks to meed our ser-
vice commitments.

I urge you to reconsider this poorly-thought-through decision, at least
for the 12.X releases. It is grossly unfair to issue 12.0-RELEASE and then
make users wait at least 4 months to find out how long (or short!) the re-
lease lifetime will be (Dec 11, 2018 release, "discussions ... will be com-
plete by Mar 31, 2019" and I assume the announcement of the decision will
not be immediate). Plus, it seems that you're flailing about, with FreeBSD
11 being under the "old" new model (posted Feb 3, 2015) and 12 being retro-
actively under the "new" new model (posted sometime after Mar 31, 2019).

I expect a number of users will be blindsided by this - I haven't seen
the announcement that a change to shorten the support lifetime on the of-
ficial FreeBSD forums, nor in a quick search on the freebsd-stable and
freebsd-current mailing lists for November and December. All there is is
the last 3 lines on the "FreeBSD Security Information" page, and I bet
most people haven't found that change yet.

Sincerely,
Terry Kennedy [company affiliation info removed]
New York, NY USA

* I'm [in]famously known in some circles for saying at an open-mic session
at a DECUS Symposium, after the previous speaker was told "thank you for
your feedback" (translation - "get lost"): "In acoustics, feedback is a loud
squealing noise, and I think that's what you're getting here."

 

[yuripv]

So what are you trying to achieve by posting it here?

Not to mention certain ports maintainers who seem to de-
light in ripping out support for old versions days after the old versions
are actually out of support (for example, ports/head/net/samba48/Makefile
r483807)

I'm not sure what's wrong with "ripping out support" given the "actually out of support" combined with "after".

 

[Terry_Kennedy]

So what are you trying to achieve by posting it here?

Give the community a heads-up, since this doesn't seem to have been communicated anywhere other than the "Supported Releases" page and the generic note to freebsd-announce that changes to the support model were being considered. I certainly didn't see it in the 12.0 announcement or release notes. I want to see if this is actually a surprise to other users, and how they feel about it.

I'm not sure what's wrong with "ripping out support" given the "actually out of support" combined with "after".

They're certainly entitled to do it, but if you read my prior sentence you'll see that I was commenting on FreeBSD 12 being behind schedule, leaving a window where the was exactly one supported FreeBSD release (11.2).

 

[ShelLuser]

I'm going to be very honest here, and I'm well aware that this may come across as a bit harsh but I'm most definitely not trying to "brush you off".

Having said that: you get what you paid for.

For the record: I most definitely agree with you that the changes in the support model have their effect. I'll even state that you're late to the party because I already noticed severe changes during the release of 11.0; current versions are supported "until the next version comes out + 3 months", which is horribly vague. I learned that this more or less boils down to 6 months (give or take).

It most definitely requires an attitude adjustment but it's also not the end of the world (it doesn't have to be anyway).

And to be honest I don't really like your tone and choice of wording. "It's unfair", "my company needs" and "poorly thought through decisions" tell me that it's you who haven't thought things through. This is all about you and your company (which is understandable) yet you don't bother to think about the effect all of this has on FreeBSD itself. You know: the organization which provides you with a fully free of charge operating system?

Or to put this in different wording: you need longer support. So what could you do to help achieve that? If the answer is nothing then... I think that would also points out the problem at hand.

This isn't only about consumers, it's also about what is physically possible for the FreeBSD community itself. I get the strong impression that people (and companies) such as yourself have reached a point where they take the efforts of open source projects for granted. They now expect certain things (like support), for free, without ever wondering what effort went into the whole thing. Wake up call: there comes a time when an organization also has to think about its own needs. And sometimes unpopular decisions have to be made.

But then I once again ask you: what have you done to make things better in the past years?

If you so desperately need support then that's easy: there are plenty of companies who'd love to help you by taking over your system administrative needs. Of course for a fee, probably rolled into a SLA.

Then the issue of Debian & Ubuntu....

Best of luck to you during your next LTS upgrade, because you're going to need it. Desperately.

Ubuntu's LTS only does one thing: it postpones the inevitable. Because although the LTS version continues to be supported, development also continues and new versions will continue to get released. It's been a while since I read up but I think it's once every 2 years?

So after your decade worth of support you'll be looking at having to upgrade across 5 major releases all at once. Ergo: if you're lucky then the upgrade to the next LTS will go smoothly, if you're unlucky you may easily find yourself having to upgrade 5 times in a row using each and every single release in between (and not just blindly hitting "upgrade", you're also going to have to apply possible upgrade instructions as well).

I will go on the record here by stating a bold prediction: I'm convinced that when people are finally going to upgrade from Ubuntu 18 LTS (near its EOL) then most will run into a major upgrade hell which, commercially speaking, will have cost them severely where time & effort goes.

THAT is the other side of the medal which most people easily gloss over (or totally ignore) when they talk about LTS. Usually you're going to pay back your savings multiple times during an upgrade.

 

[Terry_Kennedy]

For the record: I most definitely agree with you that the changes in the support model have their effect. I'll even state that you're late to the party because I already noticed severe changes during the release of 11.0; current versions are supported "until the next version comes out + 3 months", which is horribly vague. I learned that this more or less boils down to 6 months (give or take).

In my case, once my systems move to a new release, they track STABLE so they're already at "the next version" for all intents and purposes.

Or to put this in different wording: you need longer support. So what could you do to help achieve that? If the answer is nothing then... I think that would also points out the problem at hand.
[shuffle]
But then I once again ask you: what have you done to make things better in the past years?

I contribute patches when I can, or at least file PR's when I don't have a fix for something (and then provide feedback on the proposed fixes). I provide developers access to dedicated test hardware when needed to diagnose a problem. I send the occasional "hey, your commit broke <thing>, here's a heads-up" (which have always generated a "thanks", never a "so go file a PR"). I was instrumental in getting several commercial packages ported to FreeBSD, both on the advocacy and technical fronts. I'm much less involved in the code these days, but if you go back to BSD/OS or even 4BSD, you'll see my name every now and then.

This isn't only about consumers, it's also about what is physically possible for the FreeBSD community itself. I get the strong impression that people (and companies) such as yourself have reached a point where they take the efforts of open source projects for granted. They now expect certain things (like support), for free, without ever wondering what effort went into the whole thing. Wake up call: there comes a time when an organization also has to think about its own needs. And sometimes unpopular decisions have to be made.

I agree that unpopular decisions need to be made. But they also need to be communicated clearly, in a timely manner, to the community, and then the community feedback needs to be taken into consideration. I think we can both agree that this was neither clear nor timely.

If you so desperately need support then that's easy: there are plenty of companies who'd love to help you by taking over your system administrative needs. Of course for a fee, probably rolled into a SLA.

I left my affiliation out of the post because I don't think it is relevant to the larger situation. I can certainly take care of my system administration needs, thank you. I could also back-port patches and selected enhancements to 12 once it goes out of support. A bunch of people did that a long time ago, when Karl and others had the freebsd-eol list created. That list never gained any real traction, though there was a fair amount of activity off-list.

I can understand the previous support model change - there was the possibility of needing to support 3 or 4 versions simultaneously, and the creation of a new point release could arbitrarily extend the lifetime of that major release. I can see how that could rapidly become un-manageable. However, that support model was announced, discussed, and then took effect. This change seems to have reversed the order as it is seemingly in effect now, this thread is probably the first time many users have seen it and are now discussing it, and there doesn't seem to have been any official announcement of what the new support model is, exactly, other than "anticipated", "TBD", "will include opportunities for community feedback", etc.

Then the issue of Debian & Ubuntu....

Best of luck to you during your next LTS upgrade, because you're going to need it. Desperately.

So after your decade worth of support you'll be looking at having to upgrade across 5 major releases all at once. Ergo: if you're lucky then the upgrade to the next LTS will go smoothly, if you're unlucky you may easily find yourself having to upgrade 5 times in a row using each and every single release in between (and not just blindly hitting "upgrade", you're also going to have to apply possible upgrade instructions as well).

Everything I do is built from source, except for some of the commercial applications mentioned above. My deployment of a new major release involves doing an install from scratch on a test box, building the rest of my development environment, then
building test systems for various functions (DNS servers, web servers, etc.) then doing a cut-over to the new systems. That probably affects my outlook on the lifetime of major FreeBSD versions more than most users.

It also means it is not as difficult to move my environment to another OS, or an utterly different incarnation of the same OS - some of my development tools go back to 4.2BSD/VAX and have been though many different environments before I moved to FreeBSD 4 from BSD/OS. But it is still a lot of work to switch OS versions, which is why I've been on the even-numbered FreeBSD major versions (4, 6, 8, 10 and possibly 12) - there had been a guarantee that I wouldn't have to do it again for nearly 5 years (I tracked -STABLE after the x.0 release was branched, and generally deployed from -STABLE a month or two before the x.1 release, once the initial bugs got worked out of the x.0 release).

For the most part, the stuff that happens "behind the curtain" in FreeBSD gives us a well-supported system that just works. You can say I'm taking advantage of that, but so are many, many other FreeBSD users. I think it's safe to say that most free software projects have a small group of very active developers, a larger group that contributes occasionally, a still larger group that contributes as and when they can, and the vast majority who are "just" happy users. It seems quite unusual in the FreeBSD world to have a change like this sprung on us with no notice, precisely because things behind the curtain seem to generally go so well that we take them for granted.

 

[ShelLuser]

I agree that unpopular decisions need to be made. But they also need to be communicated clearly, in a timely manner, to the community, and then the community feedback needs to be taken into consideration. I think we can both agree that this was neither clear nor timely.

Unfortunately we don't quite agree.

See, as I mentioned in my previous post it was already public knowledge that the support model was changing when FreeBSD 11.0 got released, which was back in 2016. While 10.x and 10.y were both supported for an extended time this changed with 11; now only one (minor) release would be supported and go EOL merely 3 months after the next one.

I mention this because most communication takes place on the mailing lists and I don't even follow those (there are some exceptions); I mainly rely on this forum. And although it has been a while I do recall picking up mention of discussions about the support model back then. I just looked it up, here you can see that things have been brewing even longer: since 2015.

Now, I can't fully comment on discussions due to my absense on those mailinglists but if there has been then that's the de-facto place to turn to (to check and/or participate).

However, that support model was announced, discussed, and then took effect. This change seems to have reversed the order as it is seemingly in effect now, this thread is probably the first time many users have seen it and are now discussing it, and there doesn't seem to have been any official announcement of what the new support model is, exactly, other than "anticipated", "TBD", "will include opportunities for community feedback", etc.

Point taken, and a good one at that. Because I'll be honest: I did assume that things were discussed on those mailing lists and that I simply missed all that (as was the case with the changes you referred to back here).

However... When re-reading the whole announcement again I still think it got discussed, but only amongst those who were directly involved (note: this is an assumption on my part obviously). And that brings me back to my previous comments: it's not always about us, the consumers.

I'm well aware that I may give the FreeBSD foundation a lot of leniency here, but even so I really wouldn't pick it up as unfairly if they don't seek feedback about these changes. Sometimes there's only so much you can do.

Everything I do is built from source, except for some of the commercial applications mentioned above. My deployment of a new major release involves doing an install from scratch on a test box, building the rest of my development environment, then building test systems for various functions (DNS servers, web servers, etc.) then doing a cut-over to the new systems. That probably affects my outlook on the lifetime of major FreeBSD versions more than most users.

Most definitely.

I also fully build my park from source (both base & 3rd party software) and rely on 1 (internal) test server where everything gets build, installed and used internally. After that period (and without notable incidents) the changes are made available to other servers which can then upgrade their software accordingly (using an internal software repository).

We don't rely on pre-made solutions (think about Poudriere and/or Synth) but everything is fully customized.

However... We are still working on a better solution for the base OS (that transition already started last year) due to the changed release cycle & support model.

Which brings me to something which I think is going to be crucial here: PkgBase. Although the support cycle may change in a way which can be less favorable for end users, the support options are also drastically changing.

Right now the only way to push an update onto a remote server (other than building your own installation medium) is to somehow provide /usr/src and /usr/obj. When we're able to fully package the base and provide that as a repository for a remote server it will probably make updating a whole lot easier than it is now. Please note: this is all speculation on my part, I don't have any options to test FreeBSD 12 at the moment, I plan on doing that somewhere around mid-January next year (it is said that FreeBSD 12 already supports (parts of?) PkgBase).

Still, I can't help but wonder if PkgBase was also a reason why the support model got changed.

 

[Barney]

I avoid upgrading whenever possible. When you choose to use an open source project you need to understand that the developers don't care about the entire user base; they only care about their own needs and their corporate sponsors. It's not ideal, but it's better than using Windows

 

[Terry_Kennedy]

I avoid upgrading whenever possible. When you choose to use an open source project you need to understand that the developers don't care about the entire user base; they only care about their own needs and their corporate sponsors. It's not ideal, but it's better than using Windows

I wouldn't be that harsh. When developers are contributing their own time they can work on what they like. Similarly, if their employer is paying them to work on FreeBSD, their contributions will likely be relevant to what their employers do. Even with that, the project manages to create and support a very useful environment (not just kernel + world, but ports, etc.). The FreeBSD Foundation also sponsors work for the general good.

In any event, the decision was rescinded some time ago and 12.x has an expected EOL of June 30, 2024 (and the "TBD" part was dropped as well).

Hopefully future releases will have a support timeframe where the last release X is still supported a little into the release of X+2. 12.0 missed this by a slight margin - the 12.0 release date was December 11, 2018 while 10.4 went EOL October 31, 2018.

 

[ralphbsz]

...
the developers don't care about the entire user base; ...

That has to be true by necessity. There are zillions of users, and many are clueless and irrelevant.

But Terry is not your average user. He has been a power user of *BSD and computers in general for a heck of a long time (I've known of him since the 80s or 90s, in the VAX/VMS community, via the INFOVAX mailing list), he does things with FreeBSD that are on the bleeding edge, and he provides lots of support and assistance to FreeBSD. He builds the largest FreeBSD storage servers I know of (excluding NetApp). His opinion has to matter. If FreeBSD loses users like him, it will become a toy for script kiddies on laptops.

 

[Barney]

I wouldn't be that harsh. When developers are contributing their own time they can work on what they like. Similarly, if their employer is paying them to work on FreeBSD, their contributions will likely be relevant to what their employers do. Even with that, the project manages to create and support a very useful environment (not just kernel + world, but ports, etc.). The FreeBSD Foundation also sponsors work for the general good.

In any event, the decision was rescinded some time ago and 12.x has an expected EOL of June 30, 2024 (and the "TBD" part was dropped as well).

Hopefully future releases will have a support timeframe where the last release X is still supported a little into the release of X+2. 12.0 missed this by a slight margin - the 12.0 release date was December 11, 2018 while 10.4 went EOL October 31, 2018.

I didn't say it was bad; it's just what it is. I don't "expect" anything from future developments. "EOL" doesn't matter to me. I don't care if there will never be a Freebsd 11.4. I'm using what I'm using, and I fix what needs to be fixed. Until I run into something I can't fix and have to have, I don't worry about upgrading. For my use, Freebsd 10 was slower and 9, so I skipped it altogether. There has to be a significant reason to upgrade to bother with it.

In the old days, new motherboards wouldn't work unless you upgraded. That problem has pretty much been solved. Now it's just a matter of features. It's cheaper to buy a faster cpu than to go to the effort of upgrading the os, so performance isn't even that much of a consideration. I don't need 32 cpus.

 

[PMc]

I didn't say it was bad; it's just what it is. I don't "expect" anything from future developments. "EOL" doesn't matter to me. I don't care if there will never be a Freebsd 11.4. I'm using what I'm using, and I fix what needs to be fixed. Until I run into something I can't fix and have to have, I don't worry about upgrading. For my use, Freebsd 10 was slower and 9, so I skipped it altogether. There has to be a significant reason to upgrade to bother with it.

I agree. But thats only true for personnel use. if you run a company with money from others, there are aspects of due diligence, and you may get a problem when running unsupported software. Then again, such companies are needed because they may sponsor the project. Thats about where the "fun" starts in crappy capitalism. :/

Otherwise I am perfectly happy with what I get. If I get more, it's great. If I get less, I must see how to cope with that. So the aspect of "more" and "less" needs to be adjusted to. A much bigger problem is imho if the project decides to go into a seriously different direction (e.g. the idea of throwing it all into the mouth of moloch github), which may raise the question if FreeBSD is still suitable to use or if one has to tackle the much more serious action of migrating to a different OS.

 

[CraigHB]

In any event, the decision was rescinded some time ago and 12.x has an expected EOL of June 30, 2024 (and the "TBD" part was dropped as well).

Fortunately things are much easier when using software only for personal use which is my situation. I can run any version as long as I want provided I don't have to update hardware. If I stop getting security fixes I pay my nickel and take my chances.

In a professional environment you have to stay on top of security fixes. That can be a bitch when support for a version is dropped. It doesn't matter to me so much, but I'm glad they rescinded that date.

I agree it would be pretty ugly if major versions were only supported for eighteen months. If they do want to cut it down at all, three years as a minimum sounds reasonable to me. Though I hope the support interval stays the way it's been.

 

[Deleted member 30996]

Hopefully future releases will have a support timeframe where the last release X is still supported a little into the release of X+2. 12.0 missed this by a slight margin - the 12.0 release date was December 11, 2018 while 10.4 went EOL October 31, 2018.

I just updated one of my laptops from 11.2-RELEASE-p14 to 12.0-RELEASE-p10 and have at least one more to do. 11.2 is nearing EOL and recommmends updating within a month. 12.1-RELEASE appears ready to become available sometime in November.

I had been using 11.2 since it came out in June last year without any problems and that's more than a suitable about of time as far as I'm concerned. While not ideal, I'll probably do a full rebuild as always to 12.1-RELEASE when it comes out and get it over with.

 

[Alain De Vos]

I use freebsd on the desktop. So for me it does not matter if the lifespan is one month or ten years.
Is there a theory on what is a good lifespan ?

 

[ralphbsz]

Is there a theory on what is a good lifespan ?

It depends heavily on the upgrade workflow. Let me give you two opposite scenarios, both a little unrealistic. First: software that simple can not be upgraded, but when you want to move to a new version, you do a complete reinstall, which requires moving all your data off and back on. It also means that going back if the new version is not good for you (missing features, or incompatibilities) is really hard. Second: software where upgrades are very gradual, every week or two you run a little upgrade, and like that you stay very close to the most current version. And if something goes wrong, you can back down for a while (for example you can go from N+1 back to N, but not from N+2 to N), which means after every upgrade you have a sensible time period (a few weeks?) to decide whether to go back.

In the first example, you want your lifespan to be REALLY long. I've run 10 or 15 year old software, because upgrading would be too painful. In the second example, the whole concept of lifetime doesn't matter much, but weeks or months are ample.

Neither of the two extreme examples exist in the world of free operating systems, although FreeBSD is pretty close to the second (except for not being able to go backwards easily). In the world of commercial software, rolling upgrade usage models with guaranteed N -> N+1 compatibility and rollback exist.

 

[CraigHB]

For me it's mostly governed by hardware, new hardware, new OS. I've only been using FreeBSD for a couple years, but before that I'd run versions of Debian Linux well past end of life if no hardware changed. My last machine was on FreeBSD 11.2, but that hardware has been retired due to age and a long distance change of residence. The new machine I'm planning to put together will get the latest FreeBSD release. I'll probably run that machine on the major release it starts with until it's replaced.

 

[drhowarddrfine]

When you choose to use an open source project you need to understand that the developers don't care about the entire user base; they only care about their own needs and their corporate sponsors.

This can be said even with no corporate interest. Projects would then be built for the needs and wants of users instead with no interest in what anyone else wants. That's how Linux got started cause Linus wanted it. Python got started cause Guido wanted it.

 

[gessel]

To add a voice here - I've been running FreeBSD on my servers since the mid 90s. There are a variety of reasons for electing to do this over alternative OS options, options that have come and gone, but one of the primary drivers has been stability. Over the decades I've watched enthusiastic developers embrace the latest model/language/process of the month as if it were the future of computing and then quietly flame out. All the while FreeBSD has incrementally improved, become more stable, more useful. I am tremendously appreciative of that. A critical, perhaps the critical, characteristic of FreeBSD that differentiates it is solid, stable, secure performance.

I find Terry_Kennedy's concerns resonate with me. If there weren't security flaws, I'd probably never update. I don't run FreeBSD as an experiment or a hobby, but as a tool to get something done. And while I appreciate the "you get what you pay for" argument dismisses any claims of "rights," it also is extremely dismissive of the commitment of particpatory users. While I'm not suggesting this is actually the core attitude, it comes across as "this is our toy, not yours" and risks alienating users who are peripheral contributors to the FreeBSD ecosystem.

A big part of this contribution is discovering and sometimes fixing subtle flaws or feature omissions, a process that takes years and the use and attention of large numbers of not completely inexpert users who are willing to make the effort to work toward resolution and improvement. I do not see how alienating those users is to the benefit of the project.

I fully appreciate structural changes that have the effect of improving support and reducing any unnecessary overhead for the hard-working developers that make the project successful, but there is a legitimate need for extended support for use cases that have historically been central to FreeBSD's mission. I suggest that need be taken seriously, not dismissed as "what do you want for free," and weighed in the determination of resource allocation to provide appropriate support periods some very dedicated users need.

 

[toorski]

This can be said even with no corporate interest. Projects would then be built for the needs and wants of users instead with no interest in what anyone else wants. That's how Linux got started cause Linus wanted it. Python got started cause Guido wanted it.

And they’re only popular because of significant user base that was/is able to use the software for free, just like the free Internet services. Without meaningful users base, a free or for a fee product or service has only meaning or value to its creator.

Let's learn from history what happened to many Operating Systems and software applications that came and went to nowhere due to lack of significant user base. The end users are the ones that make products or services live or die – for free or for a fee!

 

[sidetone]

As a non-commercial user who appreciates FreeBSD, and doesn't mind upgrading, even if that part can be a hassle, I feel like that you get it for free argument, so this or leave sentiment could apply to me too. At the time, this doesn't apply to me, yet it very easily can get there, and it would also for many others. It makes me think that, I found a way it could be better or an inefficiency that can save hours of compiling time for others, but that I shouldn't be able to appreciate it and give that feedback that makes it better, or write about how to do things that others learn from. I do accept FreeBSD for what it is.

I'm in the middle of opinion for business users. In a way, they're getting a free service, which makes them money, but in another sense, without a significant amount of them, FreeBSD loses users, which it needs users to continue to be successful or popular. That's kind of a purpose for most opensource projects and writings to be useful for a market, but not to the point of give me, and I don't appreciate it, not in this case, just in general. If they need security fixes, and that shouldn't include the latest in the base system, then maybe they should have only 1 release which offers that, that lasts a bit longer, but not too long, or there should be a way for them to pay for that.

18 months may be just barely enough for them. 2 years might be better for a version according to arguments, but I don't see much longer than that (or 2.5 years seems like should be a target or the limit).

I think some people who make money off of FreeBSD don't contribute in making it better or giving back, but like to ask. Those who do give back and contribute, are the ones who should be met half way.

Non-commercial users and commercial users are in different capacities. One has their business model off of it, which they usually would pay a lot for, and not much is better than FreeBSD. Non-commercial users can make money off of FreeBSD, but the system itself is not the core of the business model. I could use another open source OS, but I prefer this one much more. I could use Windows, but I would pay for it, then worry about getting locked out of their operating system, because the one I used required to log in to their servers to use something already installed on the computer itself.

Look at something bigger like Netflix for instance, they receive much more than they contribute to FreeBSD, but that is still a lot that goes in, and it's collective, that FreeBSD receives enough to go on. They are also in a different capacity and role than most commercial users and regular users.

 

[yuripv]

While the concerns are entirely correct, I still think that this forum is a wrong place to express them if you want something changed; you'll get a lot of agreement, but no actions will grow out of that. Mailing lists where the developers actually dwell should be more useful.

 

[CraigHB]

Are we talking about change? Didn't they already backpedal on shortening the support cycle. Whatever the case it's still interesting to hear the users' perspective especially for me where I only use FreeBSD for personal objectives. I do like to hear what the professionals have to say. As a user I find the lists rather cumbersome. So I come here to get a read from other users and find out what's happening with FreeBSD.

 

[LakeCowabunga]

As a user I find the lists rather cumbersome. So I come here to get a read from other users and find out what's happening with FreeBSD.

Same. I think I'm on four of the mailing lists. Most of the time I simply "Mark all as read", then delete all the messages in the "1 month or older" category. But they seem to contain information that's relevant to the developers. And if I can't get past a certain build number, I reinstall from a fresh image. So there's a lot of different ways to use and have fun with FreeBSD.

 

[tingo]

FWIW, "popularity" is different from "installed user base". And "popularity" is (IMHO) not important for FreeBSD at all. After all, anybody who choose FreeBSD because it is popular, will move along to something else next month, or next week.

 

[Barney]

I agree. But thats only true for personnel use. if you run a company with money from others, there are aspects of due diligence, and you may get a problem when running unsupported software. Then again, such companies are needed because they may sponsor the project. Thats about where the "fun" starts in crappy capitalism. :/

Otherwise I am perfectly happy with what I get. If I get more, it's great. If I get less, I must see how to cope with that. So the aspect of "more" and "less" needs to be adjusted to. A much bigger problem is imho if the project decides to go into a seriously different direction (e.g. the idea of throwing it all into the mouth of moloch github), which may raise the question if FreeBSD is still suitable to use or if one has to tackle the much more serious action of migrating to a different OS.

who uses freebsd for personal use? Bearded geeks? I've used FreeBSD in a "company" (and BSDI before) since the mid 90s and I'm always years behind. FreeBSD 5 and 6 literally didn't work (and were slower than 4.7), so we skipped them; what was that, 3 years? You run into MORE PROBLEMS upgrading to "new" software than you do "incompatibilities" with a 2 year old OS.

Customers want stability. New versions of an OS are unstable by definition. I still host on some FreeBSD 9.1 systems. Nobody is demanding we upgrade Apache 2.2 to 2.4. As long as a fairly late version of PHP runs, nobody cares what version of FreeBSD is running on the system