And pfsense is HIGHLY dependent on source code from it’s plethora of packages. Aren’t they largely down stream “consumers” of all those packages - just like opnsense is to freebsd.
The honest answer is more likely this is the last EASY free FW left standing that is sustainable. And the sun is setting on the free & sustainable combo.
But making this change would choke off opnsense and raise funds to compete with Unifi. A win win for Netgate. Arguably, a necessity for them over the decade to come.
I don’t want a second Unifi, and before I put something like that on the perimeter of my network, I’d use DynFi, opnSense, or even OpenWRT or DD-WRT any day, and should it actually happen that one day there are no more OSS firewalls, I’d have to learn how to do it on plain Linux.
But yeah, I get it, for enterprises and MSPs these centralized management tools like UniFi are a blessing, at least as long as there are no serious vulnerabilities found…
Maybe in the long term (or maybe even the opposite, more on that in the next section), but an existing distribution or product does not suddenly stop working just because upstream development slows down.
Also, while it is true that Netgate provides a large portion of the contributions to FreeBSD that are relevant for security appliances, they are far from the only contributors, and if they were to actually go full closed source and/or leave FreeBSD, it could as well lead to an increased demand for OSS firewall alternatives, at least in Europe, which in turn could lead to companies like DynFi or Deciso (OPNsense), both of which are EU based, and perhaps others, to increase their contributions to FreeBSD.
As I said, this is not what I want at all. I’d rather have fewer features in a firewall, and I certainly don’t want a central network controller on my perimeter firewall that needs a dozen ports open to work.
Less costs for kernel/driver development probably, but there would be increased costs for frontend and middleware development, and additional costs for infrastructure if they really wanted to compete with UniFI.
The demand is there for more open source, but there is a lack of people available that have the skills to deliver on that. There is NOTHING stopping OPNSense or any other companies or people from contributing right now.
The situation with FreeBSD right now and why IXSystems / TrueNAS core is showing exactly what happens as the base OS development starts to slow. No one just jumps in and starts contributing and things project fade away.
Netgate has many highly skilled and highly paid people on their payroll contributing to FreeBSD upstream. They are not doing this in their spare time, they are doing as their job at Netgate. If they had to get a job somewhere else to pay their bills that did not have them pushing code to FreeBSD would they still do it in their spare time? Maybe, but probably not at the same rate.
While I think it would be great if there was a better economic model that allowed for people to just do what they wanted, such as contributing to the projects they were passionate about, that is not the reality of today.
I can’t argue with the general point you made in your post, but I’m not quite as pessimistic as @liquidjoe or you, and would not say that the absence of Netgate in the OSS and/or FreeBSD world would “choke” projects like OPNsense to death, nor would I say, to use your nicer term, it would be inevitable that they will “fade away”.
As for contributions, my thought process was that increased demand would bring more funding to these projects, and with the additional funding they could hire more full-time developers who would then also do more contributions to FreeBSD. But maybe that’s just wishful thinking on my part.
But hey, as of today, the community edition of pfSense is still around, although Netgate’s latest moves and statements don’t necessarily boost my confidence that they’ll keep it around forever.
And in the end, it might make OPN a better product by forcing them to think about how that last 10% can be handled in a different way, even though I know they are working on getting to zero shared code.
It’s not about percentage of things like the user interface, it’s about the core functions such as PF, OpenVPN, Wireguard, IPsec and other functions that make up the platform.
Also, here is Franco from OPNSense pointing out that they are lagging behind on features because they are using FreeBSD 13 and features are not being backported.
haven’t really put an effort into backporting their changes into this stable version
If they don’t have the engineering team to backport code already available in newer versions to the version they are on, then how are they suppose to handle the even more challenging task of creating new code?
These are just the data points of where things are today and to explain why I use pfsense over OPNSense. Maybe none of the data points I have put here matter to you which is fine and why I always say, “Use what makes you happy.”
Well, to me it looks like that a dev called kprovost made a commit to the FreeBSD ports tree in Nov 2023 that introduced the issue in the first place. Then three weeks ago the same dev fixed the issue by introducing a new upstream version of miniupnpd with this commit, but only in the pfsense tree of the FreeBSD ports.
Or, to put it simply, it looks to me like kprovost created a problem upstream that affects all FreeBSD users, and then later provided a fix, but only downstream to one specific “user”, which happens to be Netgate.
I’m not sure if this is the way things should be handled in open source projects, and so I think Franco’s question here is perfectly fair.
Well, I guess OPNsense is just garbage and should be scrubbed from the Interwebs then. They are just leaches sucking off the life from upstream.
I’ll tell you one thing, I would not submit another person’s code back up to main, even if I carefully reviewed it. Just feels dishonest claiming the work as your own (among other reasons). And if you are trying to stay inline with upstream, splintering with a “just for xxx project” fix doesn’t exactly help unless that fix really only does need to be applied to your project due to other compatibility issues. Introducing a bug upstream and then only putting the fix in your project is a pretty poor move, almost like it was intentional.
Which seems like a reasonable thing to do in this case. Anyway, according to this post, it was committed to FreeBSD Ports two days ago.
That Franco would commit the code upstream was never going to happen anyway; he wanted the original author and, as he says, the one who caused the issue in the first place, and who already did commit it to the pfSense tree, to commit the code upstream (who, by the way, is “primarily working on pf”: BSDCan2019: Kristof Provost)
Exactly!
Well, the introduction of this bug was probably unintentional. Whether the fact that the fix was first committed to the pfSense tree, and only three weeks later to the upstream tree, has anything to do with Netgate sponsoring the commit, we may never know
