momius - Fotolia
Monitoring open source software is crucial, as enterprise IT shops increasingly fold it into application development and use it to automate application deployment.
It was once rare to monitor open source software, as enterprises would frequently place a blanket ban on software under General Public License (GPL). Nowadays, such a ban amounts to saying, "We're not looking for ways to save money and be flexible," said Jay Lyman, analyst at 451 Research.
Open source software has risen from also-ran to prominence as the DevOps movement grows. Many popular tools used in DevOps pipelines -- such as Chef, Puppet, Ansible, Salt, Jenkins, Travis, Docker, Kubernetes and Mesos, to name a few -- are open source.
Much of modern software development relies on open source software and libraries, and "it's less and less every day about what you write, and more about wiring together pre-existing components," said Jeff Luszcz, CTO and co-founder of Palamida Inc., a San Francisco-based company that offers consulting services for software audits, as well as a software tool for monitoring open source components.
While it's more common to keep a tight leash on open source tools that develop commercial products, IT ops pros are not exempt from the need to monitor open source tools used in their environments.
Sometimes, deployment functions become productized and open-sourced. For example, a utility called The Hub has been open-sourced by FlightStats Inc., a global data service company in the aviation space based in Portland, Ore., now owned by FlightGlobal. The Hub is a utility for distributing data over a global network that was originally conceived by FlightStats' site reliability engineers.
The Hub is only the beginning, said Alex Witherspoon, vice president of engineering for FlightStats. The company has incorporated dozens of other open source projects among more than seven development teams creating more than seven products each.
"I keep a list of over 1,000 open source projects used at FlightStats," Witherspoon said.
For a young software company hoping to get bought, not maintaining awareness of open source components could dilute the value of the company at acquisition time, he added.
Delivery of an application may shift from shipping on a physical appliance to being offered as software as a service, and such changes in distribution or business models can require organizations to hedge their bets with what open source licenses they're willing to use, Luszcz pointed out.
"Sometimes, you don't pay as much attention to things on the back end, and developers can get confused about the distinction between distribution and back-end use," he said.
Understanding open source licensing obligations
With the rising use of open source software, there's increasing awareness of licensing obligations, but not everyone has gotten the memo, Luszcz said.
Internally, Palamida favors licenses that allow it to sell proprietary software built on their components, such as Apache 2.0, with the awareness that under some licenses, such as Lesser GPL and Mozilla Public License, customers can ask for source code. Thus, the company's licensing policy must track code down to the snippet level.
Other license types may require code produced using the open source tool be open-sourced in turn, or enact rigid rules around how to give credit to the open source community; enterprises developing proprietary apps may want to avoid those, Luszcz said. Just as some licenses are too restrictive, others can be too vague: "Take what you will" is an oft-used phrase that can leave enterprises in legal limbo.
"Open source means you are participating in a community development effort," Witherspoon said. "It does not mean free; it also does not mean no strings attached."
Patrick McClorydirector of automation and DevOps, Datapipe
Palamida is one of a number of companies that have sprung up in the last decade or so to help enterprises keep track of open source licensing obligations. Others include Black Duck Software, Sonatype, JFrog, IBM Security AppScan, Veracode, WhiteSource, SonarQube and Synopsys.
One complaint among DevOps pros about such tools is they don't bridge the "deployment wall" very well, said Patrick McClory, director of automation and DevOps for Datapipe Inc., a provider of managed hosting services for Amazon Web Services based in Jersey City, N.J.
"Tools are starting to eke into the dev and staging environments and act as the first set of checks, but I don't think they're oriented to the DevOps workflow very well," McClory said. "They don't run fast enough, they aren't API-driven enough -- it's getting better, but I don't think it's quite there yet."
Monitoring open source isn't just about IP -- think security
Enterprises must know what versions of open source software are running in their environment -- managing different versions leads to added complexity, and it may also be a security vulnerability, as patches are often included in version updates, Lyman said.
During audits, it's often discovered that "the difference between what upper management thinks is going on and what's actually going on is night and day," Luszcz said.
Heartbleed, an OpenSSL bug, is one example of how such a lack of awareness can come back to bite a business. Senior staff expected an instantaneous answer after Heartbleed was publicized about what parts of the IT infrastructure used OpenSSL, but "for some customers, that took weeks or months -- and some customers never got a definitive answer," Luszcz said.
Open source opens the door to security concerns
Get expert advice on software audits
The many faces of open source systems management