The Green Software Foundation was announced at Microsoft’s annual Build developers’ conference this week and will be administered by open source body, the Linux Foundation. It aims to bring software into line by encouraging developers to write leaner and more efficient code so fewer processor cycles will be wasted – helping the industry meet its goal to cut greenhouse gas emissions by 45 percent by 2030, in line with the Paris Climate Agreement.

“We envision a future where carbon-free software is standard—where software development, deployment, and use contribute to the global climate solution without every developer having to be an expert,” said Erica Brescia, chief operating officer, GitHub.

The group plans to publish green standards, and push for voluntary adoption of those practices, as well as pushing for government policies that promote them. As the field is somewhat undeveloped, the foundation plans to support academic research, and grow advocacy for improvements.

Clyde Seepersad, senior vice president and general manager for training and certification at The Linux Foundation, said the 2020 Open Source Jobs Report shows that as more workloads shift to the cloud in the wake of the COVID-19 pandemic, the number of organizations looking to embrace best DevOps practices is increasing substantially. The report finds 70% of respondents are more likely to hire an IT professional with cloud computing skills.

Based on a survey of 175 hiring managers and 900 IT professionals with open source expertise, the report also finds that despite the economic downturn brought on by the pandemic, 37% of hiring managers say they will be looking to hire more skilled IT professionals in the next six months.

The report also finds 93% of survey respondents report difficulty finding open source talent. An overwhelming 81% of hiring managers said recruiting open source talent is a priority for 2020, with 56% looking to recruit IT professionals with open source skills in the next six months. Nearly two-thirds (63%) said their organizations have begun to support open source projects with code or other resources for the explicit purpose of recruiting individuals with open source software skills.

More than half of hiring managers (52%) said they are more likely to hire someone with a certification, while 80% of survey respondents reported providing online training courses for employees to learn open source software. Nearly three-quarters of organizations (74%) are now offering to pay for employee certifications, according to the survey results.

An equal percentage of hiring managers also identified Linux as the most in-demand skill they seek in new hires, while 63% also said they are looking for IT architects who can build solutions based on open source software.

Seepersad said given the difficulty attracting talent many organizations are focusing more on training their existing staff rather than trying to recruit talent in an open market where demand for open source expertise remains high.

The talent pool is more global as more organizations become accustomed to working with staff who are now largely working from home, which, coupled with current economic realities, is limiting how much organizations are willing to pay for IT talent. More organizations are also keen to make sure there is a cultural fit with their organization when hiring, he added.

In general, it’s clear more IT organizations will need to focus on growing their own farm teams with open source DevOps skills rather than hoping to lure away superstars from other organizations. Rather than simply trying to fill open positions, organizations need to think more in terms of acquiring and managing talent in the same way a general manager manages a sports franchise.

Why 5G Needs a Cloud-Native Core

The commercial promise of 5G — ultra-reliable low-latency communications (URLLC), network slicing, edge services, and converged access — depends on more than just new radio hardware. Fulfilling that promise requires telecommunication providers to fully embrace cloud-native architectures and container-based infrastructure.

Nokia has publicly argued that a cloud-native core is the only viable path forward. That position is not unique: research firm ABI Research concluded that enterprise 5G momentum risks stalling entirely without a cloud-native platform as its foundation. The implication for network operators is stark — legacy virtualization approaches are insufficient to meet 5G’s architectural demands.

This is where Kubernetes enters the picture. The container orchestration platform is increasingly being positioned as the operational backbone for 5G infrastructure — automating workload scheduling, scaling, and lifecycle management tasks that previously required significant manual intervention.

From Theory to Demo: Kubernetes at KubeCon

The cloud-native 5G core is not purely theoretical. At KubeCon + CloudNativeCon North America 2019 in San Diego, Loodse demonstrated a cloud-native 5G network on an open architecture using its Kubermatic Kubernetes Platform. The demonstration showed how Kubermatic could act as a standardized compute infrastructure layer across multiple cloud providers, delivering consistency from cloud to core to edge.

The demo was developed in collaboration with the Linux Foundation’s LF Networking (LFN) Open Platform for NFV (OPNFV) project — a community framework for testing, iterating on, and validating common NFV infrastructure (NFVi). It also incorporated work from the OPNFV Verification Program (OVP), which verifies labs, infrastructure, and virtual network functions (VNFs).

“Containerization in 5G is not only possible, but it can be here today. The industry is changing and if telcos want to keep up they’d better start examining these technologies.”

Bill Mulligan, Kubernetes Advocate, Loodse (2019)

The VNF-to-CNF Transition

To understand why Kubernetes matters to telecom, it helps to understand the evolution from Virtual Network Functions (VNFs) to Containerized Network Functions (CNFs).

• VNFs run network functions — such as firewalls, load balancers, or evolved packet cores — inside virtual machines, typically orchestrated by platforms like OpenStack. AT&T, for example, has run its 5G and FirstNet services as VNFs.
• CNFs are the next evolution: they run the same networking logic inside containers in a cloud-native environment. This enables faster update cycles, finer-grained resource allocation, and better elasticity than VM-based VNFs.

The open source community formalized this transition with the launch of the CNF Testbed, a joint initiative between the Cloud Native Computing Foundation (CNCF) and LFN. Its stated goal was to demonstrate that the same networking code could run both as a VNF on OpenStack and as a CNF on Kubernetes — providing operators with a migration path rather than a hard cutover.

Industry vendors have moved quickly to support this transition:

• Red Hat and Intel created a cloud-based onboarding service and testbed designed to reduce VNF and CNF deployment complexity and bridge compatibility gaps between the two models.
• VMware partnered with Nokia to expand interoperability testing of Nokia VNFs and CNFs running on VMware’s Telco Cloud platform.

The Language Barrier: Security, Networking, and DevOps Teams

Technical architecture is only part of the challenge. A recurring theme among telecom and cloud-native practitioners is the organizational friction between teams that must work together to deliver production-ready Kubernetes deployments in telecoms.

Scott Sneddon, Senior Director and Cloud Evangelist at Juniper Networks, described the problem directly in an interview with SDxCentral:

“Often times security teams are perceived as the people that slow stuff down, the networking team is often still doing manual process and generally takes a long time to get stuff done, and the cloud and DevOps teams either go into public cloud to get around that, or they’re deploying on top of servers and they’re not asking a lot of the network team.”

Scott Sneddon, Senior Director and Cloud Evangelist, Juniper Networks

Sneddon explained that Juniper’s Contrail software portfolio is specifically designed to give networking and security teams tooling that speaks the same operational language as DevOps teams — enabling network-as-a-service delivery models where security policy is designed in from the start rather than bolted on afterward.

“Once we have a common language, once we have a little bit more understanding of how to deliver a network-as-a-service to DevOps teams, then Kubernetes applications become production ready because the requirements of the network were thought of in advance because security policy was designed in.”

Scott Sneddon, Juniper Networks

Red Hat’s Chief Technologist of Cloud and Virtualization, Azhar Sayeed, echoed this broader challenge: “We have to rethink networking” — a statement that applies as much to organizational process as to technical architecture.

Maturity Concerns and the Kubernetes Ramp

Kubernetes was not originally designed with telecom-grade reliability requirements in mind. Network operators expect carrier-grade availability — historically defined as five-nines (99.999%) uptime — along with deterministic latency, strict regulatory compliance, and support for stateful network functions. These requirements push Kubernetes beyond its default capabilities.

Heather Kirksey, VP of Community and Ecosystem Development at the Linux Foundation, offered a measured perspective: telecom adoption could itself accelerate Kubernetes maturation, because “when telecom adopts a technology it tends to bring a maturity perspective.” The implication is that telco use cases will drive hardening of the platform in ways that benefit the broader ecosystem.

In the meantime, several vendors have invested in managed Kubernetes platforms and edge-optimized distributions aimed at closing the maturity gap:

• Cisco, Red Hat/IBM, and Dell/VMware have launched managed Kubernetes platforms targeting enterprise and telco deployments.
• Rancher Labs, CDNetworks, and Edgeworx have introduced lightweight Kubernetes distributions optimized for resource-constrained edge environments — a critical requirement for 5G edge deployments where compute nodes may have limited CPU, memory, and storage.

Key Takeaways for DevOps Engineers in Telecom

For DevOps and platform engineers working at or with telecommunications providers, the 5G-Kubernetes intersection raises several practical considerations:

1. OpenStack is not going away overnight. Most operators have significant OpenStack investments. The VNF-to-CNF path is a migration, not a replacement — hybrid environments running both will be the norm for years.
2. CNF design requires rethinking state management. Containers are ephemeral by default; stateful network functions require careful design around persistent storage, fast failover, and session continuity.
3. Networking and security must be first-class Kubernetes citizens. CNI plugin selection, network policy enforcement, and integration with existing OSS/BSS systems are non-trivial and require cross-team collaboration.
4. Edge Kubernetes distributions matter. 5G edge nodes often run in constrained environments. Lightweight distributions (K3s, MicroK8s, and others) are worth evaluating for edge deployments alongside full Kubernetes for core functions.
5. Organizational alignment is as important as tooling. The cross-team language barrier between networking, security, and cloud-native DevOps teams is a real delivery risk that tools alone cannot solve.

Conclusion

Kubernetes is not a silver bullet for 5G core complexity, but it represents the most credible open platform available for managing the containerized network functions that next-generation networks require. The ecosystem — from CNCF and LFN to vendors like Nokia, VMware, Red Hat, and Juniper — is actively closing the gaps between what Kubernetes provides out of the box and what carrier-grade deployments demand.

The path from legacy NFV to cloud-native CNFs will be gradual, and success will depend as much on cross-organizational alignment as on technology choices. For DevOps engineers entering this space, understanding both the orchestration layer and the telecom-specific requirements it must satisfy is essential groundwork.

A High-Stakes Race for DevOps Dominance

The merger of CollabNet VersionOne and XebiaLabs in early 2020 signaled something important: the race to own the end-to-end DevOps platform market was heating up. With organizations increasingly demanding seamless, integrated toolchains rather than patchwork collections of best-of-breed tools, the vendor that could deliver a credible, complete DevOps platform stood to capture an enormous market opportunity.

But who actually had what it took to win? At the time, the field was crowded—GitLab, CloudBees, JFrog, GitHub, the newly merged CollabNet/XebiaLabs, and others like Chef were all staking claims. None of them had yet delivered a fully realized, end-to-end platform. The question was which would get there first, and which would be left behind.

Why “End-to-End” DevOps Matters

As Sanjeev Sharma, principal analyst at ASG, framed it at the time, organizations trying to achieve true continuous delivery face a fundamental choice: assemble and maintain their own pipeline from best-of-breed tools, or standardize on a single vendor’s integrated platform. In 2020, the pendulum was clearly swinging toward the latter. Teams were fatigued by the overhead of gluing together disparate tools, and the complexity of maintaining those integrations was becoming a productivity drag rather than a competitive advantage.

This shift created a window for platform vendors willing to invest heavily in breadth. The winner of that bet would inherit enormous customer loyalty and switching costs—a powerful moat in an otherwise fast-moving market.

The Key Contenders (as of Early 2020)

GitLab

GitLab entered 2020 as arguably the most ambitious challenger. The company had articulated a sweeping vision: a single application covering every stage of the DevOps lifecycle, from planning and source control through CI/CD, security scanning, and monitoring. Its execution was notable—the team shipped close to 200 new features per month, every month, on a public release cadence that was itself a form of competitive differentiation.

At the time, GitLab had grown to nearly 1,200 employees, had raised hundreds of millions in funding, and carried a reported valuation of $2.75 billion. The resources and momentum were real. The honest caveat, however, was that most GitLab customers were primarily using its Git repository and CI capabilities. The broader modules—security, operations, package management—were still maturing. Acquisitions would likely be needed to close competitive gaps in some areas. Still, with its valuation and growth trajectory, GitLab was a clear frontrunner.

CloudBees

CloudBees had been carried to prominence by Jenkins, the dominant open-source CI server. But Jenkins, while ubiquitous, was showing its age—particularly as Kubernetes reshaped how applications were built and deployed. CloudBees had responded strategically: Jenkins itself was contributed to the Continuous Delivery Foundation (a Linux Foundation project), and JenkinsX, its Kubernetes-native sibling, went with it. CloudBees thus freed itself from being defined solely by the Jenkins legacy.

Key acquisitions—most notably Electric Cloud—brought enterprise-grade pipeline orchestration capabilities and expanded the company’s customer base. Smaller acquisitions added modern capabilities like feature flags. CloudBees’ stated strategic direction was a two-product approach: a Software Delivery Management (SDM) layer for business and engineering leaders, combined with its existing CI/CD tooling for practitioners. This was a more focused vision than GitLab’s, but arguably more achievable in the near term.

JFrog

JFrog took a different path to the end-to-end conversation. The company built its business on Artifactory, a universal artifact repository that became deeply embedded in enterprise pipelines. Its open-source-first go-to-market strategy created a passionate, loyal user community. The company then expanded upward: XRay added security scanning for artifacts and dependencies, and the acquisition of Shippable (later rebranded as JFrog Pipelines) gave it a CI/CD layer.

The challenge for JFrog was that its pipeline capabilities were newer and still maturing relative to the competition. Its security story, while solid for artifact scanning, needed further development for a complete DevSecOps narrative. JFrog’s culture of developer-centricity and open-source engagement was a genuine strength. Speculation at the time included the possibility of acquisition by a major cloud provider—which would have represented a win for JFrog investors regardless of the platform race outcome.

GitHub (and Microsoft)

It was easy to dismiss GitHub as “just a repository,” but that framing ignored both its scale and its trajectory. With tens of millions of developer accounts and Microsoft’s financial resources and cloud infrastructure behind it, GitHub was methodically expanding its scope. GitHub Actions had launched and was rapidly becoming a mainstream CI/CD option. The Marketplace offered an extensive ecosystem of integrations. Microsoft’s Azure provided a natural extension point for deployment and operations.

The combination of GitHub’s developer trust, Microsoft’s enterprise relationships, and Azure’s cloud capabilities made it a formidable long-term contender—even if it was earlier in its DevOps platform journey than GitLab or CloudBees in 2020.

CollabNet VersionOne / XebiaLabs (Now Broadcom/Digital.ai)

The newest and least-defined player at the time was the entity formed by the merger of CollabNet VersionOne and XebiaLabs, orchestrated by private equity firm TPG. TPG had acquired CollabNet—a company with roughly 15 years of history in agile and application lifecycle management—and pledged significant capital to build it into a complete DevOps platform. The XebiaLabs acquisition, focused on release orchestration and automation, was intended to fill critical gaps.

The appointment of Ashok Reddy as CEO was seen as a positive signal—a seasoned executive with enterprise DevOps experience at scale. But the merged entity was starting from behind: it needed more functionality (notably a security module), more market presence, and more capital to compete with the other contenders. Whether TPG would continue to fund the buildout, or whether the entity would pursue further acquisitions or partnerships, was an open question in early 2020.

What It Takes to Win the End-to-End DevOps Race

Looking across these contenders, a few themes emerged about what would separate the winners from the also-rans:

• Breadth with depth: Covering every stage of the DevOps lifecycle is table stakes. Each stage needs to be genuinely competitive—not just a checkbox. Weak links in the chain become reasons for customers to look elsewhere.
• Security integration: By 2020, DevSecOps was no longer optional. Any credible end-to-end platform needed to embed security scanning, policy enforcement, and compliance tooling throughout the pipeline.
• Developer trust: Developers adopt tools they like, and they resist tools that slow them down. Platforms that prioritized developer experience—fast feedback loops, sensible defaults, open-source community engagement—had a structural advantage.
• Enterprise credibility: While developer adoption drives bottoms-up growth, enterprise deals require security, compliance, support SLAs, and integration with existing systems. The winners needed to serve both audiences.
• Capital and execution: Building or acquiring capabilities across the full DevOps spectrum is expensive. Companies without sufficient funding or acquisition firepower risked being outpaced by better-capitalized rivals.

How the Landscape Has Evolved

This analysis was written in early 2020, and the market has moved considerably since then. GitLab went public in 2021. JFrog also went public in 2020. GitHub Actions became one of the most widely used CI/CD tools on the market. The CollabNet/XebiaLabs entity was eventually rebranded and absorbed into what became Digital.ai. CloudBees continued to evolve its platform strategy. The competitive dynamics of this market continue to shift as cloud providers, security vendors, and new entrants enter the picture.

The broader lesson from this period is that the end-to-end DevOps platform market did not produce one dominant winner—at least not quickly. Instead, customers found themselves choosing between platforms optimized for different priorities: developer experience, enterprise integration, security, or value stream visibility. The race, it turns out, is ongoing.

Original analysis sourced from devops.com, January 2020.

The Linux Foundation announced a deeper collaboration between telecom and cloud industry leaders that should lead to better cloud-native use cases.

The Linux Foundation’s LF Networking (LFN) is formally working with the Cloud Native Computing Foundation (CNCF) to improve the migration of virtual network function (VNFs) to cloud-native network functions (CNFs).

ONAP, which is a part of LF Networking, and CNCF’s Kubernetes are coming together as operators start to look at how VNFs could evolve into CNFs running on Kubernetes.

“We have seen service providers embrace open source networking in large numbers. Benefits of virtualization and VNFs, coupled with automation platforms like ONAP, are now de facto deployment models,” said Arpit Joshipura, general manager, Networking, the Linux Foundation, in a prepared statement. “As edge, IoT, 5G and AI start using these highly automated cloud platforms, we are excited to see the best of both worlds come together—the scale and portability of cloud coupled with the agility, reliability and automation of telecom.”

Telcos in particular have needed a clearer defination of cloud-native architectures as they start to embrace  cloud enviroments, containers and Kubernetes.

“Many definitions of cloud-native exist, and the essence to me is breaking a function into its more atomic or molecular elements—microservices, which can be recomposed into a variety of user- or operator-defined versions of the original function,” said IHS Markit’s Michael Howard, executive director, research and analysis, carrier networks. “As we learned from Google, etc., the ability to change a microservice at a time, rather than the full function, facilitates DevOps, and much easier, more automated ways to modify software applications on the fly. Many operators tell us that for some applications, VMs are better, while containers are optimal for others.

“On the whole, I laud Linux Foundation and the industry for these collective efforts, as they are steps toward more automated, and even self driving networks.”

ONAP’s first release, Amsterdam, represented the second stage of network architecture evolution by running virtual machines (VMs) in OpenStack, VMware, Azure or Rackspace environments. ONAP’s next release, Casablanca, will run Kubernetes and works on any public, private, or hybrid cloud. ONAP currently supports VNFs on either VMs—running on OpenStack or VMware—or containers running on Kubernetes via KubeVirt or Virtlet.

In June, ONAP’s second software release, which is called Beijing, included the ONAP Operations Manager (OOM), which helps service providers instantiate and bring up all the containers and the microservices of ONAP one after the other. With OOM, service providers can pick and choose the containers that they want to bring up.

Along with OOM, ONAP’s multivirtualized infrastructure manager (VIM) is also one of the cloud-native projects that the are being addressed. OpenDaylight’s Fraser release, which expanded cloud-native NFV capabilities in nine different projects, will also be in the mix of projects that ONAP and CNCF will be working on.

CNCF’s Cross-cloud Continuous Integration (CI) will be used to check the interoperability and cross-cloud deployments of all cloud-native technologies and show the daily status of builds and deployments on a status dashboard. Other elements include Istio, which allows users to connect, manage and secure microservices for both containerized and noncontainerized workloads, and Ligato. Ligato provides a platform and code samples for development of cloud-native VNFs.

“Containerization has been one of the cornerstones of our network transformation,” said Catherine Lefevre, AVP of research technology management, AT&T. “Cloud-native development represents the next level of efficiency as part of the ONAP target architecture and we’re excited to be a part of this initiative. We expect significant benefits from the OOM Project, such as improved scalability and resiliency, as well as additional cost efficiencies.”