Leveraging the Best of Open Source
Open source technologies are everywhere and in almost everything we leverage today across the IT enterprise. That is not a new observation, but something we just accept. My experience in leveraging open source technologies reaches back to the mid 90's where I spent the better part of a year setting up both a rural phone company's ISP and a university’s computing lab leveraging Linux 0.99. In those days, the cost of commercial enterprise operating systems was too high for lean startup activities. Therefore, we were willing to trade time for money. Getting a Linux kernel working with a specific network card was not fun in the early days and often required a bit of trial and error cycled over many kernel builds. However, these types of projects gave us a real appreciation for what the open source community was contributing and what was expected from the user community to benefit. Unfortunately, this support gap kept open source technologies on the fringe for many years. Eventually, this provided an opportunity for the creation of new vendor ecosystems that work closely with the technical innovators while delivering the functionality and support required of enterprise customers. Companies like RedHat have been filling some of these gaps for more than a decade.
What has changed over the past several years is that we are now treating open source solutions as fundamentally the same as commercial offerings. When it comes to building out our Information Infrastructure, we consider both possible options and ask the same key questions:
• Does it meet the functional requirements?
• Does it work in our environment?
• How much effort does it take for provision and maintenance?
• How will we support it?
• Does the roadmap align with where we are headed?
• Is it a cost-effective means to move the enterprise forward?
Given how much open source has grown in the past 20+ years, there is a lot of open source in a nicely packaged product licensed from your key vendors. Companies like Cloudera, RedHat, Oracle, Microsoft, and many others have not only taken on the role of the major contributor but provide their perspective and experience to bring innovative technologies to the enterprise. At the same time, the open source dynamic encourages vendors to move away from proprietary approaches. For Polaris Alpha, this minimizes the risk of solution lock-in.
What has changed over the past several years is that we are now treating open source solutions as fundamentally the same as commercial offerings
Over Polaris Alpha's history, we have been developing and delivering, solutions to the US government for more than 20 years. The foundation of our products has been open source from the beginning. The innovation of open source capabilities/libraries coupled with our organic skills has allowed us to transform open source technologies into systems that meet the rigorous operational and security requirements in support of national security needs. From 2006 to 2010, the US government put significant effort into raising the standards for system accreditation through migration from the DITSCAP to DIACAP methodology. This meant an increase in rigor and much more transparency for vendors supplying GOTS (Government Off The Shelf) solutions. As the supplier to the government, we were required to demonstrate that the solutions we provide meet the standards or the software sits on a shelf. As we were leveraging a large number of open source components, hundreds of libraries at the time, we worked directly with appropriate government personnel to explain how open source components do not undermine system security.
Depending on the component, we either mitigated the vulnerability through appropriate architecture, addressed the shortcoming ourselves, or swapped in another component that was secure. In our opinion, having full access to the source code provides the ultimate assurance that if security issues arise, we have an expedient path to address.
Given a general bias towards proprietary technologies in the government and a lack of understanding as to what is an open source technology, there were times we were met with significant push backs. Fortunately, we had a supportive government program office that understood the value of having open source components in our systems: less investment in custom solutions when a solution already existed and faster time to deliver. Rather than starting from scratch, we incorporated open source components as needed. Having a government sponsor in your corner and understanding the value proposition was often the biggest differentiator when issues arose.
Today we are living in a world where the government openly embraces open source components and encourages their use. Broad recognition of the potential for cost savings, improved security, better adherence to standards, and the ability quickly leverage technology innovation is often cited. Today, RMF (Risk Management Framework) captures the security standard across all government agencies and provides the necessary scaffolding wherein open source is just another piece of the puzzle.
When it comes to leveraging open source solutions for our enterprise, we are fortunate that there is a strong partnership between engineering and IT. This allows us to leverage significant prior experience and knowledge across the company to best identify a path forward. This helps us to know firsthand whether a capability will be high touch, has an active developer community, is secure, has an active support community, or whether the technology is ultimately headed in a direction that supports our long-term strategy. Therefore, when an open source capability is selected to meet a critical enterprise need, we can make an educated decision on whether to embrace a supported/licensed solution or go with the community edition.
In practice, much of our enterprise runs on Linux. Given our customer set, we have the significant in-house expertise and are able to maintain these without the support of an external vendor. The same goes for our Jenkins build system and our use of Ansible for process automation across the enterprise. However, we do make exceptions and run a few licensed RedHat servers that have some unique operational requirements. Given the importance of our code repository, we have elected to go with a licensed version of Git. In this way, we do not have to worry about tracking patching and maintenance issues. We also leverage Jfrog's Artifactory which is a licensed product but supports community plugins. In many ways, this product offers a balanced approach that is a good cultural fit for our organization. It should be noted that we will often try out the community edition just to get our feet wet, testing the capability for fit, and getting some real-world experience… all without having to go through a complicated license negotiation.
Ultimately, we have to decide where to leverage our talented IT staff. Having a range of options from proprietary, fully supported open source to community editions provides us with the flexibility to respond as needed.