The challenges of community- vs vendor-led open source software

Let the OSS Enterprise newsletter guide your open source journey! Sign up here.

The recently disclosed Log4j vulnerability resurfaced the same old questions around the inherent security of open source software (OSS), particularly software that isn’t supported by squadrons of full-time developers and security teams.

One of the core maintainers instrumental in issuing a Log4j fix has a has a full-time job elsewhere as a software architect, and only works on “Log4j and other open source projects” in his spare time. While this was used by some to assert that community-driven software isn’t secure enough, others proferred that it simply highlighted the need to implement a more rigorous security regimen with any open source software that plays such a fundamental role in critical infrastructure.

But it’s also worth noting that not all open source software is created equally. Sure, there is more than enough evidence to support arguments that many open source projects are woefully under supported relative to their pervasiveness, but on the flip-side countless projects are backed — directly or indirectly — by billion-dollar mega corporations.

Vendor-led

A quick peek at some of the top open source projects out there shows that many got their start at some of the world’s biggest technology companies. Kubernetes, for example, emerged from Google’s engineering vaults in 2014, and while Google remains the most active contributor today, the project counts participants from major companies including Microsoft, Amazon, Intel, and Alibaba. Moreover, the “big three” cloud companies (Google, Amazon, and Microsoft) all now offer “kubernetes-as-a-service,” with the promise of additional support and security.

So while Kubernetes might well be “community-led” under the auspices of the Cloud Native Computing Foundation (CNCF), it is ultimately supported by many big companies with a vested interest in Kubernetes succeeding.

Then there’s open source IT automation engine Ansible, which started out as an independent entity back in 2013, only to be acquired by Red Hat for a reported $100 million. Red Hat itself was then snapped up by IBM for a cool $34 billion, reminding everyone just how valuable open source services and support has become.

Elsewhere, companies built on an open source foundation have hit the public markets in their droves, with the likes of Elastic now a $9 billion publicly-traded company (though it has since moved away from its open source origins). And then there’s HashiCorp, the developer behind popular open source products like Terraform, which has enjoyed a somewhat frosty start to life as a public company since it hit the NASDAQ two months back.

There can be big differences between projects that are maintained by vendors or otherwise have significant corporate support, and community-led endeavors spearheaded by selfless individuals in their spare time.

“The Log4j vulnerabilities have forced customers and users to think about open source with more nuance,” HashiCorp cofounder and CTO Armon Dadgar told VentureBeat. “Just because a project is open source on GitHub doesn’t mean you should take a critical dependency on it. Most customers are realizing that it makes sense to have a commercial partner, especially for critical dependencies. Having a service level agreement (SLA), access to support, and knowing there is a professional approach to security and product roadmap is crucial — especially to enterprises.”

Security aside, vendor-led projects also enable a more long-termist approach to open source software development, due to the simple fact that there is paid staff dedicated to growing a commercial business. This might translate into evolving a software’s architecture so that it’s easier to integrate and work with; improving testing functionality to solve bugs or performance issues; or more generally, applying a standard product management ethos to prioritizing new features.

“By comparison, community-led projects tend to be much more tactical,” Dadgar added. “Most contributors are just solving their specific pain point. They are not interested in evolving the overall architecture or how their issue fits into the greater whole. This can often leave projects with technical debt, lackluster testing leading to bugs or security issues, and an ad hoc approach to the roadmap and evolution.”

On the flip-side, vendor-led projects come with their own unique challenges, such as having to balance community-based contributions with the commercial company’s vision for the project.

“This can be made even more challenging when a project has many different vendors involved, particularly if they have competing visions,” Dadgar said. “You can quickly have elaborate governance and steering structures that are needed which can create a lot of overhead.”

While community-led open source projects can have the exact opposite problem (i.e. a lack of clear leadership), they promise a more flexible and “open” roadmap, which can be useful for exploring very specific use-cases that emerge as the project evolves.

“The community may start to apply the project in a domain and develop the project to better support that use case, even if it was never an expected one,” Dadgar explained. “That type of flexibility can be both useful in solving new problems, but can also be challenging if it leads to scope creep (i.e. a lack of direction or focus).”

And so successful vendor-led projects often have to traverse a fine line between supporting their own business goals by remaining laser-focused on core features, while giving the community enough slack to “scratch their own itch” through building their own modules and integrations. The upshot of all this — all going well — is a healthy, vibrant open source community that actively contributes to a project.

“The biggest incentive for [external] contributions is that users are solving their own problems,” Dadgar noted. “Rather than filing an issue and waiting for HashiCorp to fix something, they can easily make a pull request, unblocking themselves and contributing back to the project. Often they are using our projects in their startup or large enterprise, so it’s really about solving for their business.”

Testing times

Sergei Egorov is an active participant in several open source projects and communities, as well as being the co-maintainer of Testcontainers — a popular open source Java library for integration testing. As of March last year, Egorov is also the cofounder and CEO of AtomicJar, a company looking to commercialize Testcontainers in enterprises.

While AtomicJar is spearheading Testcontainers’ development, Egorov is quick to stress that the company is really “just another member” of the Testcontainers community. “We see Testcontainers as a community-led project,” he told VentureBeat.

Egorov noted that one of the main reasons that community-driven software often ends up in a perilous position, is by virtue of the fact that it has grown organically from nothing, without a real plan in place should it hit the big time.

“I don’t think anybody successful in open source ever set out to create a successful open source project,” he said. “I think for most — if not all — successful open source projects, the creator had an inkling that this was a useful thing, but they didn’t expect the ultimate degree of success.”

And so with community-led projects there is what Egorov calls an “inverse effect,” where an open source project begins with few expectations, but then those expectations eventually exceed the maintainer’s capacity as it becomes more pervasive and popular.

“There’s no vendor to blame in a community-driven open source projects, meaning security becomes a matter of ‘post factum’ thinking,” Egorov said. “Whereas vendor-driven projects are always concerned in advance about their public face, and how they will be treated should they introduce a security vulnerability.”

Egorov also added that a major advantage that community-led open source projects is that they are typically able to lure contributions from a more diverse group of developers.

“For competitive reasons, it’s sometimes difficult for vendor-led open source projects to attract contributions — that vendor’s competitors are obviously not interested in contributing to the project,” he explained. “Whereas with community-led OSS projects, there are no competitors, we are all driven by the same motivation.”

Partnerships

Whenever a major software security fracas emerges from open source projects such as Log4j and OpenSSL before it, the discussion soon circles back to solutions — how can we all continue to benefit from the flexibility, accessibility, and scalability of community-driven software, without relying on overworked, under-supported maintainers?

The White House recently hosted an open source security summit, which included participation from stakeholders across the public and private sectors who discussed how best to bolster the security of community-driven software. Shortly after, the Linux Foundation-backed Open Source Security Foundation (OpenSSF) launched the Alpha Mega Project, a new initiative supported by the likes of Google and Microsoft that’s designed to secure the software supply chain. This followed another recent $10 million recurring commitment that the tech giants of the world made to the OpenSSF.

It’s becoming increasingly clear that partnerships and collaboration will prove pivotal to any efforts to shore up OSS defenses, with the governments of the world taking a more active role and pushing companies to “give back” to the open source projects they benefit from.

“I think the best way to make it [OSS security] sustainable is to have it be a paid and primary job for the maintainers,” Dadgar said. “This can be done in many different ways, but creating non-profit organizations that can maintain critical projects and funding it through government grants would be one solution.”

Egorov added that he doesn’t believe the private sector can solve the OSS security problem, because the incentives are misaligned in too many ways. “The penalties for losing customer data, for example, are still so relatively trivial, that companies aren’t incentivized to do the right thing,” he said.

One way of securing critical infrastructure and systems at a national level would be to hire more cybersecurity professionals at a governmental level — but it’s difficult to compete with the private sector for talent. And that is why partnerships might well be the name of the game.

“For government’s participation in OSS security, I believe that partnering may be a better approach than hiring,” Egorov said. “There is great talent at many of the world’s cybersecurity companies — and while not many of these security engineers would be particularly excited to work for the government, I believe many would be excited to work with the government on an opportunity to help solve this broader OSS security issue on behalf of citizens.”

Originally appeared on: TheSpuzz