The Pervasive Nature of Open Source

Question

The Pervasive Nature of Open Source

Steve Jones - SSC Editor

SSC Guru

Points: 736342
More actions
December 7, 2024 at 12:00 am

#4493796

Comments posted to this topic are about the item The Pervasive Nature of Open Source

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

Rod at work SSC-Dedicated Points: 34011 More actions · Answer 1

How I think about open-source software has changed over the years. I used to be an ardent opponent of OSS. Now I'm more open to OSS and have contributed to some OSS.

However, I work for a state government department that is adamantly opposed to using OSS. But it leaves us in a weird position. As a public entity we are always short of cash, so buying commercial software is often impossible, as we can't afford it. My upper management would rather the software companies give us their proprietary software, sort of as a gift. Of course, that isn't going to happen.

Last year I helped migrate our ancient, out of support repositories out of TFS into GitHub. GitHub has a wonderful service called GitHub Advanced Security (GHAS). GHAS would scan our software upon commits to the default branch, for vulnerabilities, etc. But GHAS costs money and my management doesn't want to pay for it. So, it doesn't happen. You can do some of what GHAS does, if you take the time to peruse through the builds. A manual perusal is better than nothing, and I've done them, but they are tedious. Most people don't bother.

You're right, Steve, software is hard.

Kindest Regards, Rod Connect with me on LinkedIn.

Jeff Moden SSC Guru Points: 1004392 More actions · Answer 2

From the article:
And most people rarely upgrade their OSS. They get something that works and don't want to change. I get that, as I feel the same way often, especially in the real world.

Heh... "Change is inevitable... Change for the better is not". This is especially true when the change is not optional and the fact that so many changes break stuff or require learning an entirely different or more complex method of doing the same thing or less.

And THAT seems to be especially in 3rd party non-OSS products.

Seems like the worlds of software and data analysis (or myriad buzzwords for that) have forgotten the we are the "doctors" and we need to get back to "Primum non nocere".

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

David.Poole SSC Guru Points: 76029 More actions · Answer 3

Offerings from cloud vendors seem heavily based on open source albeit customised to some level. Anyone remember HeartBleed, the vulnerability in OpenSSL? I think people have a vague awareness that some of their software relies on OSS but not how much or how much is critical. The percentage critical components is more important than percentage overall.

Internally we tend towards containerised applications as these can be scanned for vulnerabilities. We have a rigorous approach to rebuilding machine images and application images. We have even gone to the extent of building our own images where the official vendor image wasn't what we had hoped. Its worth containerising a vendor app simply so you can scan it. Some enterprise software is frighteningly vulnerable even though patches have been available for over a decade.

Our CICD pipelines run the security scans and a whole host of code quality scans too. If a CICD run fails then the new version of the app or feature simply doesn't get deployed. It can't as the only sys admins can force something through, everyone else has to use the CICD pipeline.

As we use GitHub for our CICD pipelines we also use Renovate and Dependabot to apply patches. This means that the libraries we use are kept up-to-date. The apps are covered in tests to if a breaking change occurs we know about it.

I regard the breaking changes as a cost worth the benefit. An unforeseen benefit is that we visit codebases that would otherwise be ticking away in the background. There aren't many where at least one of us has some knowledge of it.

Another danger in falling behind with patches and versions is that the scale and scope of change can balloon because dependencies have built up over time. There must be vulnerabilities that go unaddressed simply because the cost and scale of the required change has become too large to contemplate

LinkedIn Profile