Open source languages are part of almost every business these days. In fact, according to Opensource.com, open source will be the driving force behind a great number of technology innovations due to its pervasive use. From development to quality assurance (QA) to DevOps, all kinds of coders have embraced open source languages. In doing so, though, enterprises have given up easier-to-adopt, general-purpose languages in favor of more niche-oriented languages.
Those who are enthusiastic about open source languages have been contributing to open source language projects and building versions of languages including Perl, JavaScript, Go, Tcl, Ruby and Python. There has been a massive shift in the adoption of open source languages and genesis of new ones in the last 20 years. Even large corporations such as Microsoft, Google and IBM contribute to open source projects that are hosted on GitHub, and Spotify, Dropbox and Reddit are among the big names that use Python.
This mainstream adoption speaks to the enormous popularity of open source languages. This has brought about the proliferation of new languages co-existing with older languages, which creates more and more challenges for various stakeholders in the software development life cycle (SDLC)—and more tension.
The tension between these two groups exists because of the gap between their needs. Addressing this tension requires a convergence of the needs of two specific stakeholder groups: coders and the enterprises for which they work. There are ways to fulfill what both coders and enterprises need, create better experiences for coders and make things easier for all stakeholders in the SDLC.
Enterprises require security, control and compliance. Coders need speed, want to create and crave a frictionless environment. Roadblocks and restrictions need to be removed for coders while ensuring the needs of the enterprise are being met.
Strength in Uniformity
What would it look like if you could gain all of the potential benefits of open source languages while still fulfilling coder needs and resolving your enterprise requirements? What if uniform tooling could be provided across open source languages? And what if enterprises could use a single uniform tooling set regardless of open source language? It would solve needs for the coder and the requirements of the enterprise.
Using uniform tooling, an enterprise’s open source languages can be compiled and installed; dependencies found and installed; and code written, tested and updated complete with security and license compliance needs being addressed. However, tooling currently isn’t uniform across open source languages. And the maturity and best practices of tooling wildly vary. Enterprises create a workaround by creating policies to mitigate for deficiencies in tooling. This workaround is sub-par because it happens too late in the SDLC after threats and issues are introduced into your code.
Establishing a Single Ecosystem
The quality that makes open source so useful—its openness—and its lack of controls makes it something of a digital wild west. Fewer restrictions enable faster innovation, but they come at the cost of quality and cohesion for the enterprise. Many of your installed libraries have holes and security threats. Enterprises are faced with time-consuming license reviews to ensure adherence to third-party license rules as well as internal policies restricting certain types of licenses. In addition, license reviews happen at one point in your code’s life cycle versus in an ongoing, automated way. Enterprises are burdened with high administrative overhead and stale information.
However, there is a different scenario possible. What would it look like for a company to have a uniform and high-standard ecosystem for their package management, with no vendor lock-in, all based on open source? What if a company could be guaranteed the same quality and types of packages for every language they use? What if a company could easily have visibility for what is being used across all of their environments, from concept to development to testing to production? It would be easier for the coder and fulfill the requirements of the enterprise.
The wild west quality of open source language ecosystems makes them somewhat unreliable; updates and deletions can occur. And there are different package management solutions with differing degrees of sophistication, complexities and required expertise to use. Today an enterprise can easily end up with multiple package management solutions and have different packages of the same open source programming language. There is no single or consistent source of truth.
Working with a technology provider is an effective way to mitigate your open source language risks and solve your coder need for speed. A provider can offer more than just support, inlcuding:
- The appropriate licenses based on usage and policy requirements
- The right packages for each specific application
- The best notification and remediation based on Common Vulnerabilities and Exposures (CVE) security threats
- The indemnification that fits, based on usage
- The expertise to build you the language distros you need based on usage, environment, security and compliance requirements and applications.
- The right builds, standardized for all of your teams and ready to go out of the box
Thriving in the Wild
Sometimes, using the “right tools” for the job involves coders building many programming languages in an environment. The resulting “polyglot” situation creates benefits as well as challenges. Better products are made, and products are shipped faster, but it’s difficult to build a core competency in a particular programming language. And it’s impossible to centralize support and difficult maintenance requirements.
What’s needed is a single, uniform tooling set that can work across multiple languages. This makes open source languages easier to use and implement in the enterprise, addressing the needs of developers as well as those of the enterprise. Working with an expert advisor will help you not just survive but thrive in the wild and woolly world of open source.
