Before you roll your eyes wondering what the heck is the big deal, let me ‘fess up: it was just a single line of code. In a language (PHP) I know nothing about.
So, why bother? And why write a blog post about it?
Because that single line of code I recently contributed to the GitHub pfSense project has been a real eye-opener for me about open-source software (OSS).
Given my career in the software industry, I’ve seen the effect on commercial products that are commoditized by OSS. Something has gotta give if people can get it for free — and that something was usually doc and “fit-and-finish.” And I always suspected testing wasn’t as thorough, other than maybe crowdsourced usage as a substitute. To me, customers were being head-faked into thinking they were saving money with OSS.
Companies that tried to become economically viable via business models based on support for OSS projects (including my own failure from the late 2000s, Active Endpoints) generally didn’t make it. Red Hat might be the exception that proves the rule but I’ll bet RHEL support subscriptions aren’t as exciting to IBM as OpenShift development and operations revenue are.
But a number of recent things — my interest in DevOps, developer collaboration, the ubiquity of GitHub and naked self-interest (I needed to fix a bug) led me, for the first time, contribute to to a major OSS project.
As you may know, pfSense is a FreeBSD-based router that’s enormously popular among prosumer and small-ish business users. In over five years of use in my network, it’s been stable and performant (especially on the Protectli Vaults I’m so enamored of). There’s very little high-end networking one cannot do with it — IMHO the only real difference between something like Palo Alto Networks or CheckPoint and pfSense is scalability and the skill sets necessary to configure those enterprise systems.
I’d become totally dependent on pfSense.
Then, a little over two years ago, Netgate, which had been developing pfSense and hoping to build a business selling support and appliances abruptly announced a commercial, closed-source version of pfSense called pfSense+. It was shades of my failed start-up’s bad business model all over again. However, Netgate promised it would continue to develop the Community Edition of pfSense alongside pfSense+. Eventually, after an uproar, Netgate relented and allowed non-commercial use of pfSense+. Kinda. Sorta.
It turns out the non-commercial license isn’t suitable for me since it’s actually an evaluation license and I work from home, clearly a production use. So I stuck with the OSS version on my network.
Meanwhile, both my use of pfSense CE and my worries that the project was dying expanded. I wondered how I could ever migrate the complexity in my network — multiple locations, VPNs, AWS and Azure — to some other router software.
So, when pfSense 2.7 was released, I breathed a sigh of relief. A new release defers end-of-life for at least a couple more years.
I was happy with 2.7 until I hit a bug in the PHP code dealing with HAProxy. pfSense CE 2.7 has moved to PHP 8 which has tightened its syntax with respect to strings. While PHP 8 might be big news to PHP devotees, I was blissfully and deliberately unaware of PHP until this week — despite this WordPress blog.
Faced with the possibility that it wouldn’t be fixed whenever — or if — the next release of CE is shipped, I decided to attempt a fix myself. After all, PHP’s just interpreted source code, right? No need to set up a heavy-duty dev machine; I could just hack the code on the router in
So, I did. And after I got something that worked on my system I thought, “Gee, maybe I could contribute this to the project and in a minuscule way keep CE going.”
And so after all that background, here’s the point of the blog post: It was a wonderful experience. One that changed my thinking about community and large OSS projects and their applicability for large enterprise users as well as end users.
As you can see by looking at the now closed GitHub pull request, a pfSense OSS project maintainer welcomed me to the community, increasing my interest and motivation. He educated me on the way they do things. He provided the actual one line of beginner PHP code I should have used, spurring me to make another nearby line more consistent. He corrected my indentation — a not insignificant attention to quality, as any developer knows. If other major OSS projects have maintainers with this level of dedication and developer-management skill, we are in for some great coding.
I’m also aghast at how good the toolset I used (VS Code, git on macOS and GitHub) is for this kind of collaboration. During the three days (!) the maintainer spent tutoring me, the development branch progressed. GitHub notices this even if your pull request originates in a forked copy of the project repo and allows you to merge those later commits into your pull request’s forked repo.
The power here — for free! — is astonishing.
And I think that at least for the major cloud companies, the business model that felled Active Endpoints and the pre-pfSense+ Netgate doesn’t matter any more. What’s changed for those companies is they no longer need to make these software products pay. Their model is usage, not licenses. That’s why even Microsoft has open-sourced .Net and PowerShell and Bicep and on and on….
So, I stand corrected: OSS is the future of enterprise software. And it was a single line of PHP code that made this apparent to me.