Most practitioners know that support for open-source software can sometimes be a loaded question for an organization. From a usage point of view, there are a few concerns. Organizations worry about compliance with open-source licenses— fearing, for example, that tight integration with internal tools (e.g., creating software that links against underlying libraries) would require them to release their own proprietary code as open source. They worry about support, wondering who will be there to support their usage. They worry about accountability, feeling more confident when a single entity (e.g., a software company) can be held to account.
The question, though, of how much (or even whether) to embrace open-source software is more loaded when it moves beyond usage and turns to creation—meaning deciding whether to release software that has been developed internally as open source. When contemplating releasing software as open source, large organizations worry about liability and productivity considerations; smaller ones often worry that they will not make money by giving away for free what they have invested so much to develop.
The question then is a big one: What are the advantages and disadvantages of releasing software as open source? Considering the business decision associated with releasing a new product as open source can provide an opportunity to explore and attempt to answer this question.
To this end, an in-depth look at Anchore, a mid-market software company that made the decision to release a critical component of its core product offering as open source is warranted. The advantages—and disadvantages—associated with this approach are examined here, focusing on the business outcomes associated with the decision and the business value (and drawbacks) realized as a result.
About Anchore
Anchore is a software company focused on security and compliance validation for application containers. For those unfamiliar with them, application containers are portable, lightweight packages employed for deploying and running applications. For additional information on containers, ISACA’s white paper Understanding the Enterprise Advantages of Application Containerization is helpful.1
These containers include configuration, middleware, software libraries and anything else that the application might require to run. This portability is compelling for developers because it means that they can define, control and unit test the exact configuration under which the application will run in production. Likewise, operations teams find it compelling given that the segmentation boundary is enforced within the operating system itself (in this case, utilizing Linux namespaces and cgroups). This provides higher efficiency and greater data center density given that multiple “redundant” copies of the operating system do not need to be separately maintained as is the case with OS virtualization.
One of the challenges associated with this is related to security—particularly at scale. A typical organization might have thousands or hundreds of thousands of containers. Each of these containers is comprised of software components from a variety of different enterprises and authors. Over time, components within those containers can “age,” for example, vulnerabilities might be discovered in underlying dependencies.
Started by Ansible founder Saïd Ziouani, Anchore is focused on exactly this problem. Anchore Engine scans container images looking for vulnerable components. Anchore Engine is open source. Though Anchore offers a paid enterprise overlay (e.g., allowing centralized administration), it made the decision to release the full-featured scanning engine as open source (Apache License 2.0). The strategy is a direct response to the business challenges and provides some compelling business advantages.
Business Challenges
In looking at the business conditions that prompted the decision, it is useful to note a few things about the container security marketplace. First, it is new and gaining rapid traction. The initial release of Docker (by far the most prolific of container runtime platforms) was in March 2013. Since that initial Docker release, adoption has been significant. One convenient metric to understand not just the number of downloads but actual usage volume, is the number of container images pulled from the central container image repository (i.e., Docker Hub). In just two years after the initial Docker release (2015), Docker Hub reached one billion “pulls,”2 growing to five billion the year after that (2016.) The current count as of 2020 is 130 billion.3 Moreover, Gartner predicted that by 2023, upward of 70 percent of enterprises will have more than two production containerized applications.4 As with most technology, the value of security tools (particularly automated ones) is more pronounced at scale. Because of this “new but rapid proliferation” adoption dynamic, it is only recently that many organizations have realized the need for security solutions (e.g., those along the lines of Anchore’s offerings), as many organizations are only just now dealing with how to operationalize the security of containers.
BECAUSE OF HOW RECENT CONTAINERS (AND CONTAINER SECURITY TOOLS) ARE, TRADITIONAL DRIVERS OF CONTROL-RELATED SPENDING…MAY NOT FULLY REALIZE THE BREADTH OF THEIR OWN CONTAINER USAGE OR THE NEED FOR PRODUCTS THAT HELP SECURE CONTAINER USAGE.
Second, the container security marketplace is crowded. There are numerous products that offer container security solutions, including automated scanning; to list only a few, Qualys, Palo Alto, Aqua, CoreOS (Claire) and numerous others provide options to help find and mitigate vulnerabilities in containers. Even Docker provides tools that help do this.
Lastly, it is a space where the traditional stakeholders who have historically driven security spending dollars have yet to become aware of the full scope of the problem these tools solve. Because of how recent containers (and container security tools) are, traditional drivers of control-related spending—such as risk management teams, information security teams, IT audit teams, compliance and others—may not fully realize the breadth of their own container usage or the need for products that help secure container usage (particularly at scale).
Against this backdrop, Anchore itself had a few challenges to consider:
- Resource constraints
- Engineering
- Support
Anchore, founded in 2016,5 was a new organization at the time it decided to release its technology as open source; it was also a lean one. This meant that resources were constrained. Staff time, budget dollars and even staff attention came at a premium. These constraints operated all across the organization, from marketing to engineering to internal services, such as human resources (HR) and legal.
These resource constraints directly impacted the engineering side of the house. In effect, there are two different problems that Anchore wishes to solve through its offerings. The first involves unpacking containers to find vulnerable software that they may contain. The second is to “scale up” that functionality so that it can be easily operationalized within an organization.
By way of analogy, consider antivirus scanning tools. The actual tool running on the endpoint solves a particular challenge (that of finding malware and taking action), but how useful would a scanning tool be in a large enterprise if there were no enterprise-focused management or orchestration tools (e.g., the ability to ensure that individual workstations are keeping updated, running appropriately)? Finding malware is, of course, an important part of the functionality (it is the software’s raison d’être)—but in an enterprise context, equally important is the ability to centrally manage, respond to events, query status and alert. Extending the analogy to Anchore, this means that engineering resources must, out of necessity, split attention between the actual low-level scanning capability (the Anchore Engine) and the higher-level, enterprise-focused management feature-set.
Lastly, support. As is true with any software product, as usage expands, so, also, do support requirements. Constrained resources meant that, as the install base grew, supporting the existing install base would occupy more and more time, attention and budget. The same engineering resources working on new features would be called in to help address support issues, meaning that their time and energy would become further diluted.
The Open-Source Decision
For Anchore, the decision to release the Anchore Engine as open source happened in direct response to these challenges and the market opportunity existing at the time. The decision to be open source was made from the earliest days. Ross Turk, Anchore’s vice president (VP) of marketing, discussed the different approaches an enterprise might take: “It seems to me that there are three primary categories of open-source business models: One, the organization is founded to create open-source products and surrounding tools (the model of Anchore); two, the organization is founded to create offerings around an existing open-source product (e.g., Automattic); or three, an organization with an entirely different focus releases open source as a byproduct of other activities (e.g., Facebook).”
ANCHORE MADE THE DECISION TO FULLY OPEN ITS CODEBASE BUT TO OPERATE WITH A CENTRALLY MANAGED DEVELOPMENT PROCESS DURING ITS INITIAL RESEARCH AND DEVELOPMENT PHASES.
He went on to describe different models for software development. He posited two dimensions in software development: open or closed codebase (i.e., availability of the source code for the application) and centralized vs. decentralized development organization. On the first axis is availability of the source code. On one hand, there is open code—i.e., open-source software. On the other, there is closed source—a traditional proprietary software product offering. The second axis, the process used in development and management of the source base, is also along a similar spectrum. In this case, though, there is, on the one side, a decentralized, entirely democratized development process. This means that development of the end product is open to all, that each developer has a voice in which features are prioritized above others and any user can contribute code at any time. On the other side, there is a centralized process whereby a core team manages the entire end-to-end development process, and outside contributions, while often welcome, are not actively sought. Plotting this as a matrix, it might look like figure 2.
Anchore made the decision to fully open its codebase but to operate with a centrally managed development process during its initial research and development phases. This comes with advantages and disadvantages.
Disadvantages include reduced appeal to open-source influencers given that development is not democratized; likewise, quality assurance can be more expensive and time-intensive for staff (since there is less incentive for the community to participate in pre-release testing). On the advantage side, though, a centrally managed process offers total control over feature-set, presents less up-front effort in establishing oversight processes over development work and (most important for Anchore) speeds time to market. In short, Anchore decided to dedicate its early resources to research and development as opposed to creation of the governance and infrastructure required to operate a successful, democratic open-source project.
For Anchore, time to market and flexibility were critical. Creating the infrastructure, building governance structures and establishing community norms for an open-source project can be time-consuming. Since the market opportunity was time sensitive, Anchore chose to optimize for maximum development velocity and flexibility. In this case, internal stakeholders believed that external contribution was likely to be minimal on Anchore Engine until a critical mass of adoption had occurred. However, they also wanted to maintain the ability to support and encourage any contributions that were received and build community infrastructure when it was needed. Likewise, short-term control over the product was also an important factor. It allowed Anchore to instantly prioritize or deprioritize the development of critical features based on early customer feedback. Lastly, many customers respond positively to there being a single, accountable entity responsible for the creation of the software (helping to mitigate concerns about the project becoming stale post-adoption.). Ultimately, Anchore sees its process as one that remains open to decentralized and democratized governance for its open-source offerings and, in line with the company’s beliefs, will likely establish more open processes in lockstep with community adoption and interest in contribution.
A WIDER USER BASE ASSOCIATED WITH THE INCREASED ADOPTION OF THE OPEN-SOURCE COMPONENT HELPS CAST A WIDER NET FOR SOFTWARE TESTING.
As one might imagine given the fact that Anchore is funded through venture capital investment, significant time was put into examination and analysis of the advantages/disadvantages associated with the decision to release significant aspects of the Anchore development work as open source. Perceived advantages were determined to exist in three main realms:
- Marketing
- Support
- Customer relationships
In terms of the marketing value, Anchore’s bet is on education of the customer through direct experience. As outlined previously, one of the challenges in the case of a product such as Anchore Engine is that it is a new space and the majority of the addressable market does not yet understand the value proposition offered by the product. One potential strategy for market penetration in this context is to address this issue via direct experience, meaning allowing users to employ the product to demonstrate its value. Open source offers a potential advantage in alleviating this since it creates an accessible “on ramp” for customers who can potentially become paying customers down the road. Additionally, avenues of marketing, such as discussions of the tool organically, at trade shows and in the industry press, that would otherwise be unavailable to a commercial entity are available to Anchore as an open-source project. By looking at usage data (e.g., tracking requests to the organization’s public vulnerability feed service), Anchore gets information about the types of environments that are most in need of what Anchore provides (i.e., information about the potential customer base and addressable market).
“Selling into large enterprises can be time-consuming and costly because succeeding requires creation of a consensus between a large group of people in a distant company,” said Ross Turk. “Having an open-source offering helps us shorten that process by allowing anyone to make an individual decision to adopt our technology. The consensus forms before we begin investing our precious time.”
A secondary advantage is offered in the arena of support. Recall that Anchore creates both the opensource scanning engine (the component responsible for doing the actual scanning of container images) and management components. Releasing the container scanning engine as open source does a few things in terms of streamlining support. First, it creates an ability for the community to help support the most common questions and difficulties that new users encounter. For example, if a new user has a problem with usage or a configuration question, there are community support channels to help them get answers without requiring significant investment from Anchore personnel. Second, it helps them triage and focus support efforts. The community provides usage-related guidance and support to new users and offers configuration-related information, while helping to funnel only important bugs to engineering staff. Lastly, a wider user base associated with the increased adoption of the opensource component helps cast a wider net for software testing, thereby leading to better overall testing of the product. The community can provide more operating system, hardware, platform and other configurations than could ever be tested in Anchore’s quality assurance (QA) lab.
The third primary advantage desired is in the area of customer relationship-building, meaning allowing potential customers an avenue to establish a relationship with Anchore prior to a purchase. Every software company knows that it can be challenging to get the attention of decision-makers, particularly when considering a security tool. However, as a result of its open-source decision, Anchore is able to establish a relationship with customers months or, in some cases, years before they are ready to make a purchase. In a traditional customer journey analysis (i.e., the “sales funnel”), this means that the entirety of the awareness and interest portions of the funnel can occur organically with little or no involvement from Anchore personnel.
Outcomes
So how well did this approach work? Very well, it turns out. Until recently, Anchore has invested minimally in traditional marketing channels. However, it has seen more than 45,000 deployments of the tool overall, more than 10,000 deployments within the last 180 days.6 This includes 165 new deploying domains (i.e., from different organizations) (figure 3).
Customer adoption is great, but what really matters, particularly in terms of the goals Anchore is hoping to accomplish, is “staying power.” Meaning, how many deployments are running at any given time, and how “wide” are those deployments (i.e., does usage expand once customers begin using it)? Again, metrics here are positive. In the last six months, running deployments have increased by 20 percent, with an average of 1.54 hosts per deployment, a metric that has increased since Anchore began keeping track. This demonstrates not only that the software is being used, but that it is used widely, it continues to be used over time, and that customers tend to use more of it upon recognition of the value.
Of course, not all of these users will turn into customers; only a subset of them will. However, these metrics do demonstrate that the initial hypotheses made by Anchore are on target: Releasing its software as open source will help drive adoption, help demonstrate value to customers and help establish customer relationships.
Conclusion
The open-sourcing decision made by Anchore has been examined in detail, looking at the rationale for the decision, the outcomes resulting from it and the salient factors that drove Anchore to make the decision that it did. In this case, Anchore quite successfully concluded that open-source release of a portion of its product set (namely, the scanning engine) provides value to the organization and helps underpin rather than detract from its competitiveness.
While no two organizations are the same, understanding the business trade-offs for a given organization can often help others in similar situations. In this way, understanding the rationale for and the success of Anchore’s experience is valuable to other organizations that might be considering taking the open source plunge.
Endnotes
1 ISACA®, Understanding the Enterprise
Advantages of Application Containerization,
USA, 2016, https://store.isaca.org/s/store#/store/browse/detail/a2S4w000004KoHeEAK
2 Marks, M.; “Docker Hub Reaches Over 1.2
Billion Pulls,” Docker Blog, 6 November 2015,
https://www.docker.com/blog/docker-hub-billion-pulls/
3 Fay, J.; “Docker Knits Together Hub Stats, Says
Pulls Over 8 Billion,” DevClass, 5 February 2020,
https://devclass.com/2020/02/05/docker-knits-together-hub-stats-says-pulls-over-8-billion/#:~:text=The%20total%20number%20of%20pulls,a%20blog%20announcing%20the%20data
4 Christiansen, R.; “More Enterprises Are Using
Containers; Here’s Why,” CIO, 26 August 2019,
https://www.cio.com/article/3434010/more-enterprises-are-using-containers-here-s-why.html#_edn1
5 Crunchbase, Anchore,
https://www.crunchbase.com/organization/anchore-inc#section-overview
6 This period reflects data collected from
March through August 2020.
Ed Moyle, CCSK, CISSP
Is currently a partner with Security Curve. In his 20 years in information security, he has held numerous positions including director of thought leadership and research for ISACA®, senior security strategist with Savvis, senior manager with CTG, and vice president and information security officer for Merrill Lynch Investment Managers. Moyle is coauthor of Cryptographic Libraries for Developers and a frequent contributor to the information security industry as an author, public speaker and analyst.