Open source is the lifeblood of modern software development, there’s no getting around it. It makes sense that development teams want to get a head-start when beginning a new project and don’t want to have to start from scratch every time. Because open source software is designed and “certified” with public use in mind, it is prevalent throughout the app dev community.
Over the past decade, advancements in static analysis tools from both commercial and open source communities have dramatically improved the detection of developer violations of good coding practices. The ability to detect these issues in coding practices provides the promise of better software quality.
Yet many of these static analysis tools cannot detect the critical violations that exist in multilayer architectures, across transactions and multi-technology systems. These are the violations that lead to 90% of a systems reliability, security and efficiency issues in production.
(Figure 1 illustrates these rules at the Unit and Technology/System Levels.)
CLICK THE IMAGE FOR A LARGER AND CLEARER VIEW.
Thinking about building your own multi-language custom source code analyzer platform using open source components? Sure, the upsides seem to add up: no licensing fees, great customization ability, and an impressive new entry on your resume (making it even shinier). Read that project charter once more before you sign it in ink, because our experience has shown it’s not quite that simple.
Source Code Analyzer: What is under the code?
First, what we mean by “multi-language custom source code analyzer platform” is a platform that analyzes all the source code underlying your critical custom software applications and projects, and:
Delivers consistent and business relevant measurements, trends, and benchmarking
Enables staff to identify and address flaws causing instability and excess complexity
Provides insights on the trajectory of code quality and complexity
Analyzes flaws at both the code and component interaction levels across all technology layers
Anything less would leave your applications difficult to manage, your users unsatisfied, and your management team in the dark.
Thanks to the Heartbleed bug, the code quality of open source software was thrown into the limelight this year as the world realized how unsecure the IT services they use daily actually are. However, while enterprise IT organizations have come to realize the benefits of using open source, blindly trusting the open source community to catch every mistake in the code is not a sound business decision, and quite frankly, unfair towards open source developers.
It’s no shocker that the federal government is turning to cost cutting measures in the middle of a down economy. But there’s a bigger problem looming on the horizon.
The federal government has become very dependent on open source products; which wouldn’t be a problem if open source software was held to the same standard as custom commercial code.
Why does “Free” always seem to have a catch to it?
We know there’s “no such thing as a free lunch,” that “freedom isn’t free” and that if you get something for free, you probably got what you paid for. Even in the tech industry, when we talk about open source software, we immediately think “free”, yet instantly jump to the old caveat of “think free speech, not free beer,” the idea there being that open source is the layer-by-layer developed product of well-intentioned developers seeking to produce high quality software that competes with established applications.
Lately, though, there are some in the industry who are questioning whether or not open source software has lost sight of its mission to produce applications that meet high software quality standards. As Willie Faler recently posted over at DZone:
It seems by the time an open source project has reached some level of mass adoption or awareness, most of the time the projects codebase will have degraded into such a poor state as to where it is completely stagnant, or even worse, unmaintainable.
Could open source contributors be taking advantage of their “free speech” or are they writing code after too much “free beer?”
While Faler admits he has no definitive answer to his dilemma, he offers a list of possible reasons why, in his estimation, open source has taken a nosedive quality-wise recently. He submits the following theories for this downward spiral:
Lack of discipline from core developers in enforcing good practices.
Demands for backward compatibility locking in frameworks into poor, inflexible API’s, unable to refactor away poor past decisions.
Tendency among core developers to let in poor code contributions to appease community members.
Over eagerness to constantly add (sometimes unneeded) features and chase higher version numbers, rather than “sharpen the saw” and improve the core codebase and feature-set.
Just naturally occurring entropy over time and no one dealing with it?
While we would like to believe these things do not happen, we would be fools to ignore them. Complacency, appeasement and entropy are all plagues from which businesses suffer, why not open source, too?
Why? Because it can’t afford to.
Embracing the Relationship
In some fashion, open source really needs to return to its roots where a community of software developers added to and improved upon what already existed. But just as we know “nothing is free,” we also know “you can’t go back.” Unfortunately, that leaves us in a precarious position of trying to identify the issues with open source software.
Sadly, this brings up the old “needle in a haystack” analogy because the average open source application contains roughly 450,000 lines of code (slightly more than your out-of-the-box apps). Trying to find the 100 or so offending lines of code by hand would not only be grossly inefficient, but if you subscribe to Faler’s theories of complacency, appeasement and entropy, it’s unlikely anybody would take the time to bother finding them.
So finding the offending code in that many lines would require some form of automated analysis and measurement platform, but there again lies a problem. Most platforms of this sort are available only to large corporations with generous IT budgets, so its use runs contrary to the idea of “free” no matter how you define it for open source – be it free as in low-cost or free as in free from the encumbrances of “the establishment.”
But this doesn’t mean there is no way to perform a thorough structural analysis of open source software. We are beginning to see structural analysis being made available as a SaaS offering via the cloud. Such a web-based, low-cost (with TCO running at around pennies per line of code) solution would surely agree with open source sensibilities while providing the visibility needed to identify and correct structural issues with the software.
Employing QaaS – “Quality as a Service” – could help re-unite open source with its software quality brother.