But at one point in the email, a question appeared - one that has become a recurring theme in the modern software world: "I notice there haven't been any new releases for about ten months. Should I consider the project abandoned?"

I decided to reply immediately: "No, it’s not abandoned. But it satisfies all my requirements, so unless there are bugs or new needs, I consider it 'complete'."

The person’s response was telling: "What do you mean by complete? Software is either in active development or it's abandoned. I’ve never heard of 'complete' software."

I started reflecting on how the very ideal of "completeness" has totally vanished from our lives. And on second thought, I wasn't surprised.

This doesn't just apply to software; it permeates every corner of our modern existence. There was a time when you bought a car, you owned it. Today, almost everyone leases or uses financing with a final "balloon" payment - often so inconvenient that people find themselves taking out a new loan after just a few years. The result is that we never truly own our cars, and they are constantly plagued by automatic software updates that, in some cases, break things that previously worked just fine.

When we bought an appliance, we installed it. Barring a breakdown, it stayed exactly as it was for the rest of its (often long) life. Today, an immediate software update is mandatory the moment you plug it in. Fail to do so, and essential features won't work. A modern washing machine often comes with only two or three built-in programs; the others must be downloaded from the "cloud" - sometimes for a fee. If you don't, you can't fully use what you already paid for. I don't wash my clothes the way I want anymore; I wash them the way the manufacturer’s questionable cloud dictates. And this continues only as long as the manufacturer decides I am allowed to wash my clothes at all.

Before everything was "always online", the concept of complete software was common. Yes, new releases happened from time to time, but they weren't taken for granted, and sometimes years would pass between them. The premise was clear: software was released to solve a specific problem. Distributing updates wasn't easy, so it had to be reliable from the very first release. It couldn't come out riddled with bugs - that would have meant a loss of face (or even bankruptcy) for the producer.

When a new release or a new product did come out (be it software, an appliance, or a car), the manufacturer had to entice the user by focusing on what was actually new - on what new problem it would solve. Consumable goods eventually need replacing, but for durable goods, the battle for the customer's attention was more complex. I remember buying many books, VHS tapes, CDs, and DVDs during sales, and then spending the following months reading, listening, or watching them. The beauty of today's streaming is choice. The tragedy is that the moment we stop paying, we are left with nothing.

The "disposable" has become the norm for everything. Quality has plummeted - even in our relationships - because we are always searching for something "new". And yes, I say "we" because I include myself in this chase for dopamine - that intense, albeit brief, pleasure of something new. Even when there is almost nothing new about it. Even when I didn't need it.

Just as with my relationships, I like to take care of my things. Making my wife laugh, sending a message to a friend, painting the house. Sometimes I rescue old objects and give them a new life. Behind me sits a cabinet - I bought it for next to nothing, and it's incredibly useful. Ten years ago, with some hours of work, I completely restored it. It’s beautiful, sturdy, and perfect. It had been thrown away by someone who considered it old and outdated, only to replace it with a fragile piece of furniture from a well-known chain. To each their own, sure. But taking care of what you own is an act of respect.

I replied to that email. Yes, the software is currently complete. I will take care of it. I will ensure that bugs are fixed. And if I ever have new requirements, I will resume development. But as of today, it has solved my problem and it works excellently. Why should I add useless "stuff" just for the sake of expanding it? For whom? For what? I gain nothing from it. I don't have to sell it. And even if I did, I would rather sell an effective, working product than a constant, never-ending process of fixing something that is perpetually buggy and incomplete.

Not "continuous integration", but "boring software" that does its job.

And this is perfectly aligned with my business ethos: I would rather stop growing indefinitely and take care of my current clients than start hiring incompetent people just to make numbers and provide a service that doesn't meet my expectations.

As is often the case, I found points where I agreed (at least partially) with the author, and others where I completely disagreed. And that’s perfectly fine.

There was one point, however, where my disagreement was total. I'll quote a part of the article here: “The FreeBSD community is...difficult. What I mean by this is that it feels much like the average Linux community in the early 2000s: it looks down on others (in this case Linux users), it appears rather unwelcoming and at times downright toxic. Any time you mention anything vaguely related to Linux you'll inevitably cause somebody to go on a massive rant about how FreeBSD is better than Linux.

It also seems there's a general dislike for change, even if said change is for the better. It feels like a form of "tech boomerism": change is bad because it's not what we're used to, even if the end result is in fact better.”

Frankly, my own experience has been the complete opposite. The communities around the BSD systems are open, friendly, and extremely approachable - though, of course, everyone has their own personality, and toxic people can exist within these communities as well. When I started becoming more active in the BSD community, I received a completely unexpected welcome. The BSD conferences I've attended have the atmosphere of a family, of close friends. No one shows up to boast, but to discuss, to dialogue. In a word: to build.

But I picked up on two details from the excerpt: “mention anything vaguely related to Linux” and “tech boomerism: change is bad because it’s not what we’re used to, even if the end result is in fact better”. This suggested something to me that was later confirmed when the author mentioned the “three firewalls competing with each other” within FreeBSD.

They don’t compete with each other. They coexist - and that’s a completely different thing. This gave me the key to understanding the previous part as well.

This isn't a battle. We aren't in a ruthless commercial arena where different solutions copy each other to get ahead, hoping to attract "users" (better: paying customers) from the other side. And unfortunately, this is something that has been happening in many "mainstream" Open Source communities for a while now. It's a loss of the Open Source philosophy - of doing something for the pleasure of it, to have something different, and to be open to contributions from others, as well as the idea of making what you create public and free. Whether it's with licenses like the GPL or like BSD, MIT, etc., the spirit is to say: “Here it is. If it’s useful to you, take it. If you want, contribute. Otherwise, you can move on; you have no constraints or obligations.”

I often see curious Linux users arriving in BSD communities, and that’s fantastic. The spirit is almost always positive, exploratory: “What can the BSDs do for me?” And sometimes, that turns into, “What can I do for the BSDs?”

But this isn't a religion - you don't need to choose one - and you can use different OSes based on your needs. I happily use Linux, in its various distributions, for some of my workloads. I'm writing this post on a mini PC running openSUSE Tumbleweed, on btrfs, and it works wonderfully. No BSD, at the moment, has adequate support for this machine. I use Linux, and I'm happy with it.

The purpose of the BSDs, like other Open Source operating systems less adopted than Linux and its distributions, isn't to "win" or to "emulate" but to be themselves. So, arriving in a BSD community and saying "but on Linux..." as if it were an example to be followed, has, over time, become an attitude that is not well-tolerated.

BSD communities value stability - and these communities are much, much smaller than those around projects like Linux and its distributions. It's therefore inevitable that some things will lag behind or that they won't want to embark on projects that might leave something unfinished and malfunctioning. Unfortunately, this sometimes happens anyway. It's better not to seek it out deliberately.

Desktop use for the BSDs has never been a primary focus, particularly for FreeBSD and NetBSD. To judge them on this metric alone is, therefore, extremely limiting and, in a sense, unfair.

So, coming back to the article I read - I understand some of the author's points of view, but calling the FreeBSD community a form of tech "boomers" or "toxic" because it doesn't want to follow Linux's example is, in my opinion, a flawed approach to an autonomous, different operating system.

Let's try to shake off the aggressive, competitive, and monopolistic dynamics when we approach the Open Source world. The plurality of completely autonomous choices is a richness for everyone. Monoculture is always harmful and, in the long run, destructive.

It reminds me of the time when all smartphone manufacturers were trying to copy the iPhone as much as possible. All the phones were the same: either originals or copies, but all extremely similar. How boring.

Like OpenBSD from NetBSD, DragonflyBSD from FreeBSD, or Nextcloud from Owncloud - the examples are endless. It was about freedom, the chance to be part of something or, in some cases, at the very center of something: its development.

To me, Open Source meant having the chance to develop an idea and find other people who shared it, turning what was just a project in my mind into a reality. All without needing big funding, a business plan, or having to risk anything. Just the pleasure of doing it and the joy of seeing it come to life. A waking dream.

Over time, I witnessed many exchanges of opinion - some of them quite heated - that led to hard forks or uncomfortable situations within development teams. People leaving, others taking over - you name it. But, in the end, the software was always at the center. It was an ideological battle over how to implement something (or how NOT to implement it).

This led to some fantastic pairings: Linux, a kernel without an operating system, and GNU, an operating system without a stable and complete kernel. Together, they revolutionized the world, changed the concept of computing, and proved that yes, Open Source works and produces quality software - often of a far greater quality than many of its closed-source, commercial counterparts.

And yet, there were the "distro wars" - and I didn't understand them. And if I didn't understand the distro wars back then, the situation today seems even more extreme. I appreciated the variety, the different ideas, and the different approaches, but never the fanaticism. I was a strong supporter of Debian, but I couldn't understand those who openly attacked alternatives (like Red Hat, at the time, or Suse). I thought: use what you like, contribute if you want but... hey, it's Open Source, you don't pay for it, you're not forced, just choose what you like best! If you're happy, tell the world. If you're dissatisfied, switch (to different software) or change THE software (meaning, implement what you think is necessary). But why wage war on others, on those with different ideas who made different choices? Is it the general polarization fueled by social media? Is it because Open Source has become more mainstream, bringing with it users who have a "consumer" mindset rather than a "collaborator" one?

And yet, there are still positive examples out there — quiet, solid, and often overlooked. The BSD projects, for instance, show us that it's still possible to diverge in philosophy and approach without descending into hostility. FreeBSD, OpenBSD, and NetBSD took different paths. And yet, there are no "wars" between them. Their communities may disagree on technical choices, but they coexist with mutual respect. You rarely see a FreeBSD user shouting "OpenBSD must die!" or a NetBSD developer trolling others on social media. The tone is sober, the work is steady, and the focus remains on the code and its quality - not on brand wars or personal egos.

This is the spirit I fell in love with: different ideas, mutual respect, and the shared goal of building something useful and free. We may not all agree on everything, but we can still build in parallel, learn from each other, and avoid turning diversity into division.

Lately, all of this is becoming truly extreme. I read, for example, sharp and violent opinions from Wayland users against X11 (Xorg, etc.) - "it must die!" But, I wonder, why this violence?

I use Wayland on Linux and X11 on FreeBSD - both on the same computer, both with satisfaction. Why should I hate one of them? If I don't like it... I simply don't use it.

The world is becoming increasingly polarized and bitter, making people less and less inclined towards dialogue or tolerance for those with different ideas or positions. But, I ask myself, why should this be happening in the world of Open Source?

We are all in the same boat. We have the tools, the freedom of choice, and it costs us nothing. If we don't like a solution, we can say so and choose something else. Why this violence? Cui prodest? Who benefits?

When we fight violently over Open Source software, when we lash out with intolerance against a solution we dislike, the entire Open Source world loses an opportunity. The opportunity to reduce the chances of ending up in a computing monoculture, the opportunity to have a choice, the opportunity for someone to listen to our well-reasoned observations and learn from them.

It's up to us, every day, with every comment and contribution, to decide whether we want to build bridges or raise walls.

I stumbled upon an email from an old friend I had lost touch with around that time. That email is the last trace I have of him - in which we promised to catch up soon - so I decided to reach out. Instinctively, I searched on Google, social media, etc., but found nothing. He wasn't tech-savvy, so I wasn't surprised. The only lead I had was this email address, which I had set up for him on a free mail server he used for school.

I decided to give it a shot. I replied with a simple line: "We promised to catch up soon. Is 25 years long enough? :-)" - fully expecting the email to bounce back as "unknown recipient" or "mailbox full" (of spam).

No errors. To my immense surprise, two hours later, I received his reply: "After 25 years, one email isn't enough; we need to meet for at least two days. We have 25 years of life to catch up on."

Here's the reflection that struck me: after 25 years, I could read and reply to an email without a hitch. The open and decentralized standard of emails ensured its longevity and compatibility.

What would've happened if all I had of my old friend was a "PIN" from BlackBerry Messenger? Or any other proprietary and closed communication tool, perhaps now defunct or bankrupt? Take, for instance, Adobe Flash. Once the backbone of interactive web content, it's now almost unsupported. Countless creative works, animations, and interactive experiences crafted in Flash face the risk of vanishing, becoming mere digital memories.

In light of this, it's essential to understand the value of open standards. Throughout history, open standards have proven to benefit users by ensuring accessibility, longevity, and compatibility. Whether it's the HTML that powers the web or the SMTP protocol for emails, they stand the test of time and evolve with our needs, ensuring that our digital footprints aren't lost to proprietary systems.

Are we truly certain that, in 25 years, WhatsApp, iMessage, Telegram, Discord, Slack, etc. will still be active and accessible?

In an era where control over information and data has become central, it's even more crucial to rely on open, decentralized, interoperable standards.

More Matrix and less Discord, more Fediverse and fewer closed social networks, more Mastodon and less Twitter (or rather, X).