Log4j hack raises serious questions about open-source software? I don't think so!

After reading the Log4j hack article that raised some serious questions about open-source software, it hit me to analyze the author's perspective. Despite being from the Financial Times, the author has been writing IT articles lately.

I get that some of his points are valid, like when he says "the world runs on open source software." But there's a lack of experience and knowledge to understand how open source software is born, grows, and develops. I think it's possible to take a step-by-step approach, considering excerpts from his article. Even though I don't fully agree, I see it as an introductory piece on the subject.

"The world runs on open source software"

Yep, it's true. Statistics (01 and 02) prove that open source solutions are practically everywhere in the IT world. But here's the thing: it's mainly about using them. The world may rely on open source software, but it's still stuck in the mindset of proprietary software. Crafty tactics and market strategies often overshadow the understanding that collaboration is a crucial aspect of open source. And why did this happen? Well, because the world runs on open source, but it's still trapped in the use-only mentality. And guess what? This disconnect from collaboration has come at a cost, which we've been seeing more frequently in the last five years.

Issues with outdated software, lack of maintenance, and security vulnerabilities have become all too common in the IT world. Large companies have adopted the norm of using open source software without contributing back. Hardware manufacturers embed open source software but don't offer collaboration or maintenance to the source code. Software companies use open source solutions or even entire codebases without returning collaboration to the source. Over time, these once-crafted legacies turn into cursed legacies as ongoing maintenance and fixes are intentionally neglected. Why? Because companies think that if the software is free or open source, it's only meant to be used.

The author also mentions that "it’s more than a little alarming to discover that, more than two decades into the open-source era, glaring security holes sometimes surprise even the experts." Why haven't these vulnerabilities been addressed through collaborative development? It's because a significant portion of the IT industry is more interested in using than collaborating. It's that simple!

Furthermore, the author claims that "self-organizing communities don’t always guarantee the wider good." This shows a partial understanding of the free software and open source landscape. Let's look at the maintenance of the Linux kernel code. It's a self-organized community led by a benevolent dictator for life, collaborating on code from all over the world, including developers paid by different companies and many volunteers. Why does this development, guided by a self-organizing community, work so well?

Let's consider some factors:

- Benevolent dictator fo life

Linus Torvalds used to fill this role, but in recent years, we have Greg Kroah-Hartman.

- Companies collaborating on the code that forms the basis of their products

Numerous companies worldwide contribute features and corrections to the Linux kernel's main source code, keeping it constantly updated and maintained. It's too complex to understand? I don't think so.

- Healthy developer turnover

While we still have 'Old School' developers contributing to the Linux kernel, new developers financed by companies join the development every year. This ensures a continuous influx of professionals capable of collaborating.

- Independence of teams when it comes to new features

No developer adds anything to the main source code without careful evaluation and verification. Features that aren't directly relevant to the main codebase are often kept as external patches exclusive to specific companies. This prevents accidental or intentional failures from being introduced to the main codebase. Remember the University of Minnesota incident?

- Funding for companies interested in the main source code

Yo, check it out! The Linux Kernel is like the foundation for a whole bunch of stuff, including different distros, maintained by all sorts of companies and communities. It's like the backbone of all space development, no matter which agency you're rollin' with. And guess what? It's a fact now: when we finally land on Mars, the operating system waiting for us there will be GNU/Linux. Who would say? Me, for sure!

But yo, the Log4j situation just exposes how companies use open source based on their own market logic, not the logic of open source communities. The developers who work on that code do it part-time and are connected to companies like Palantir and Oracle, mostly. This ain't the first time open source projects involving Oracle have had issues, you feel me? Let's dive deeper into this: when Oracle bought Sun Microsystems, they tried to change OpenOffice, which had an active community and constantly updated code, into some unknown thing that they claimed would be "spectacular." That was back in 2010. It led to a code fork and the creation of TDF and LibreOffice, maintained by an independent and self-organized (who would've thought?!) community!

Hold up, Oracle pulled a similar move with MySQL too. One of the creators of MySQL realized it needed fixing, so they launched the MariaDB fork.

But wait, there's more! From Solaris OS came OpenSolaris, maintained by the community, and later served as the foundation for OpenIndiana. All this happened because Oracle tried to change the development process and licensing, triggering subsequent forks.

I could keep on going and talk about other smaller projects, as low-key as Log4j, to prove that some companies just don't learn (and they don't seem to care) that their approach to developing open source software doesn't align with the principles of making quality software. Honestly, companies like that shouldn't even mess with open licensing. They haven't learned how to work with Free Software and Open Source.

Lastly, the original text's final statement shows the author is disconnected from how open source communities operate: "Open-source developers value their independence. But their software now has a central place in business and society, and this world-changing experiment needs to be brought up to date."

Yeah, "their software now has a central place in business and society", developers have always known that, and it's always been the goal.

And yeah, "open source developers value their independence." That's why many open source software examples are global solutions maintained by self-organizing communities, and they're top-notch. The Log4j case, on the other hand, is a different story. It's open source code, but it's nowhere close to the standards set by open source communities. It's not maintained by a self-organized community; it's controlled by just one company that decides when and if they'll bother with maintenance. That's definitely not in line with the open source principles.

And yeah, "this world-changing experiment needs to be brought up to date." Companies that USE open source code need to ACTUALLY COLLABORATE with the development process, not try to lead it based on their own beliefs. Seriously, when has a small group of people analyzing code been superior to a community constantly evaluating its quality? Eric Raymond's idea that software transparency makes it easier to find flaws — "given enough eyeballs, all bugs are shallow" — is only true IF (and only IF) it's part of a community analysis. Developers are way more socially competent than society thinks. Determining whether code is good or bad, and when it should be reviewed or fixed, is a rational, even mathematical, analysis. Embracing it is a straightforward process in a thriving community. In a corporate environment, the best and most correct option isn't always taken. Why? Who knows? Ask Oracle!

Considering so many open source projects genuinely maintained by self-organizing communities, "this world-changing experiment needs to be brought up to date," but it's the companies that need to make the updates. The community has always been ready. Companies need to bring more "eyes" to the project, instead of steering it based on their market strategies.

Believe me, I've been involved in like "2 or 3" open source projects... I think I know what I'm talking about. ;-)

And hey, just so you know I'm not alone in this understanding, I'm sharing some comments from other developers who are also down with open source communities, posted at the end of the original article:

"The tech developer community is kinship based. ... Open source was invented as a way for these tech types to share code and technical expertise amongst themselves without burdensome business and legal chieftains looking over their shoulder at every step. Necessity is a mother of invention here. ... open source is a knowledge sharing mechanism and not a separate monolithic competing with a core product or process."

"Yes, you can get a lot of stuff for free by leveraging open source software but you also have to maintain it. Companies like Red Hat provide supported versions of open source for a fee. When s*it hits the fan, you want to have professionals fixing it for you. And you want to be able to answer questions around risk management."

"Majority of companies that consume, use and rely on open source software do not pay anything for it for contribute in any meaningful way to its security. Often even when a given company internal employees find and fix issues in open source components they use, they are prohibited from sharing and contributing the fixes back. If all companies allowed their employees to spend time on security audits and bug fixes and making fixes public the open source reliability will instantly improve. The issue is with the companies that treat open source software as a one way bargain of consuming & demanding security fixes without ever contributing anything back. We want patches, not money."