How to ensure open-source longevity

< continued from page 17 place if left unchecked There are few gardeners and even fewer supervisors Some gardens are organized, some are chaotic Some have been around for generations, and some are abandoned after a month Maintenance can be invisible and thus not appreciated, until the moment that maintenance disappears,” he said

This doesn’t necessarily mean that open-source components should be avoided After all, Bereknyei points out that proprietary software doesn’t necessarily have guarantees either, as a company could go out of business or change things in a way you don’t like

But it is important to know how the open-source projects you rely on are planning for the future, and it underscores the importance of having trusted maintainers in the pipeline That way, when a top maintainer needs to leave the project, there is someone who has built that trust that can step up and do a good job stewarding the project.

“Being a good reviewer is a lot of work: you have to have a clear vision for a project and make sure contributions are consistent with that, in addition to making sure everything’s tested and documented,” said Jay Conrod, software engineer at EngFlow

The way to handle contributors and maintainers will vary depending on project size and company support For example, Conrod previously worked at Google where he was the maintainer of the projects rules go and Gazelle, and he has also worked full-time maintaining Go

At one point, maintaining rules go and Gazelle was too much in addition to his regular work His plan for transitioning off the project was to invite a group of regular contributors to become maintainers, providing them with write access to the project Then, over the course of a year he met with them regularly to continue solidifying the relationship

“I think this approach of inviting specific people, building relationships with them, and making sure they have the resources they need is important,” said Conrod

The Kubernetes project is a good example of this. According to Eddie Zaneski, software engineer at Chainguard and maintainer of Kubernetes and Sigstore, Kubernetes has a contributor ladder that is designed for helping people grow into leadership roles with the following rankings: l Members, who are active contributors to the project and must be sponsored by at least two reviewers l Reviewers, who are responsible for reviewing code l Approvers, who can review and approve contributions l Subproject owners, who are technical authorities on a specific subproject within Kubernetes

Each of these roles has increasingly strict requirements as you work up the ladder For example, in order to become an approver, you would have had to have been a reviewer for 3 months, been the primary reviewer for at least “10 substantial PRs,” reviewed or merged 30 PRs, and have been nominated by a subproject owner

According to Conrod, another way to ensure that an open-source project is maintainable in the long-term is having contributors from a number of different companies For example, with Go, though the majority of maintenance is done by Google, a few of the big packages are maintained by external contributors.

Conrod also emphasized the importance of building a strong community, in which people are able to ask each other questions, answer questions and just generally help each other out It can even lead to business partnerships or the creation of related projects

For example, EngFlow, is a business built around the open-source build project Bazel, and there are a number of open-source projects built on top of Bazel too Because of this, he believes that if Google ever stopped supporting Bazel, the Bazel community could continue on because there’s already so much existing expertise outside of Google

Chainguard's Zaneski believes that companies that benefit from using open-source technologies should also be committing time back to those projects His company practices what they preach, too, as Chainguard is one of the top contributors to Kubernetes

This would involve actively ensuring that a developer’s workload is such that they have the time to contribute to the projects He believes the bare minimum is enabling developers to spend 20% of their working time on contributions to open source.

Bereknyei also offered the advice to start a support contract with a maintainer if you rely on their project. “This provides a business relationship and goes a long way to ensuring support.” z

< continued from page 17

33%. This trend is uniform across organizations, regardless of their size

“ A s K u b e r n e t e s m a t u r e s , m a n y organizations turn to service mesh technology and those projects in CNCF like Envoy, Cilium, and Istio continue to cultivate large contributor communities to meet the demand,” Aniszczyk added

Other macro-trends observed by CNCF’s Aniszczyk were that the contributor base of OpenTelemetry is expanding, making it the second-fastestgrowing project in the CNCF environment Also, he stated that the usage of GitOps remains vital to the cloud-native environment, with projects such as Argo and Flux continuing to attract numerous followers and recently both achieving graduation from the CNCF

While OSS use is expanding at most organizations, some challenges still persist.

“Clearly, more technical support is needed for open-source technologies, as personnel experience and proficiency is highly ranked again this year as a support concern across organizations regardless of size,” Perez said. “Inhouse support of OSS requires expertlevel knowledge of not just one technolo g y, b u t m u l t i p l e t e c h n o l o g i e s t h a t form software stacks ”

Rod Cope, CTO at Perforce Software, added that open-source communities are not time-bound by any SLAs, which means one could be waiting days or even weeks to get technical support if there are skill shortages in an organization

The security aspect of open-source is number one but that is always going to be the case, Perez predicts “It’s just human nature and no matter what you do they’re going to say that’s the most important challenge,” Perez said

Another challenge is that like most technologies, not every open-source system is created equally, and not every system is as open as it claims to be. When using a “captive open source ” project, an organization runs the risk of being locked into a system.

Captive open-source projects are the projects that were created by a company that now has a tight grasp over

One important project that has quickly moved up the ranks in the CNCF is Backstage, which enables developers to bring together their organization’s tooling, services, apps, data, and documentation into a single UI

“Backstage a year ago barely made this list and continues to grow, solving an important pain point around cloud-native developer experience,” Chris Aniszczyk wrote in a blog post that identified the most important open-source projects in the CNCF and Linux ecosystems last year

The Software Catalog, which is the core feature of the project, makes it simple to create service blueprints that can be shared between teams It also enables teams to keep track of the ownership and metadata of all services within the engineering organization

The project was originally created at Spotify in 2016 and was used as the company’s mission-critical tool for containing software chaos, empowering engineers to work faster and more efficiently It entered the CNCF Sandbox in September 2020 and was eventually voted in as a CNCF incubating project last March

“Software stacks are growing larger and more complex by the day Backstage was built to address issues like SaaS sprawl and cloud-everything which can make the developer experience complex,” said Erin Boyd, CNCF TOC member and project sponsor, in a blog post

Backstage has seen great progress since joining the CNCF, with growth in core components, features, plugins, adopters, contributors, and community engagement This has resulted in updates, refinements, documentation, deprecations, and stabilizations to the Software Catalog, Software Templates, TechDocs, and API Reference z