What are your organization’s open source standards?

What standards does your organization have for open source usage? Are there specific policies surrounding security, licensing, or even maintenance issues for the open source packages used in your codebase?

According to a forthcoming Tidelift survey, less than 20% of organizations have a formal evaluation and approval process for open source in place. And without a formal policy, organizations may be more highly exposed  to the risks of insecure and unmaintained code. But formal evaluation processes have historically been resource-intensive and can slow down development, which is why I want to share how we do things differently at Tidelift.

Like many of our customers, we manage our own catalog of open source components we use in the software we are building at Tidelift. This catalog is the source of truth about which open source packages and versions are approved for use by our engineering team. We define the standards that each component should meet for it to be approved. You can think of each standard as a check that we automatically run on each of our in-use or recently requested package releases.

I wanted to share some of the standards that Tidelift uses for evaluating what open source can be used internally. I’ll also highlight how the tooling and data that come as a part of the Tidelift Subscription simplify the work of upholding these standards over time.

1. All security vulnerabilities are reviewed and handled

Whenever we are alerted about a new security vulnerability on a package release, our engineering team commits to reviewing the vulnerability and making a decision about how it should be handled.

Sometimes we are able to decide the vulnerability is safe to ignore because of additional information provided by the upstream maintainers. In other cases, we choose to upgrade to the closest unaffected release and set a date to ban the vulnerable release. We only make this decision once, and all affected teams are immediately notified and prompted to upgrade before the vulnerable release is denied in our catalog.

There is not much manual work here because we subscribe to recommendations from the Tidelift-managed security-advised catalogs for npm and rubygems. Tidelift partners with maintainers (as part of the Tidelift Subscription) who are tasked with staying on top of new vulnerabilities and writing recommendations for all of our subscribers. Having these recommendations provided by Tidelift and our partnered maintainers dramatically reduces the management burden placed on our own engineering team. And best of all, we aren’t the only ones who get this support from the maintainers—every Tidelift subscriber shares this benefit.

To make use of this standard yourself, you would choose the  ‘security vulnerabilities reviewed’ standard.

2. We only use packages with licenses from our approved list

The ‘license compliance’ standard states that all of the packages in use must use a license from our approved list. At Tidelift, this list is actively managed by our co-founder and lawyer-in-residence Luis Villa. Informed by his work as part of the Blue Oak Council (a group of top open source attorneys), he has created an initial template of all of the licenses that are acceptable and unacceptable for use for various types of software. Whenever a package is requested with a license he hasn’t seen before, we ask him to make a decision on the license before making a decision. 

We know that one of the hardest parts about upholding this standard, for most teams, is accurately identifying the license for each package. Every maintainer denotes licenses differently, which means simply depending on parsed upstream data is not always reliable. 

The Tidelift Subscription eases this burden with license-annotated catalogs for each of our package managers. These catalogs contain standard-format license data that we have verified, either by doing a deeper analysis of the code or by confirming directly with the maintainer.

Best of all, if you don’t have an open source licensing expert on staff (and let’s face it, most organizations don’t) or you don’t have an approve/deny list of licenses in place already, The Tidelift Subscription offers several pre-built templates that you can start with to match your organization’s risk or usage profile.

3. Releases are actively maintained (whenever possible)

The ‘active release stream’ standard that we use states that all approved open source package releases must be on an actively maintained release stream. This is a standard that we uphold whenever possible—but we will often make exceptions if it’s, say, a package that is not used in a production environment or if there are no reasonable alternatives.

Of course, maintenance standards go way beyond active maintenance. Sam Bleckley recently wrote an article about his ideal package repository, which would only include healthy packages. He defines healthy as actively maintained, having a backup maintainer, security disclosure policy and issues resolved rapidly, not deprecated, and (most importantly) “depends only on healthy packages.” We love this list—it is very similar to the standards that we expect our partnered maintainers to uphold on their packages.

With the Tidelift Subscription, you can also enforce the ‘active release stream only’ standard on the open source that you use.

4. Our tech leadership team does a final sanity check

Finally, even if a package lives up to each of the above standards, we still ask our tech leadership team to do one final manual review. Do we already have a package that performs a similar function? Does the package bring along more dependencies than we believe are necessary? This check is a more subjective review and requires some institutional knowledge of our codebase. If it gets the final greenlight, then the package is approved for use.

Not every team has the interest or time to uphold this standard. In those instances, we can automate the review process for requested packages. If a package release doesn’t violate a standard on initial use, then it’s free to enter our catalog of approved releases. Tidelift’s software also does continuous ongoing checks for new standards violations, such as if a new security vulnerability is discovered or if a release stops being actively maintained.

With the Tidelift Subscription, we support either preference as it is up to you whether or not you will use the ‘all packages manually reviewed’ standard with your open source catalog.

--

Keeping our open source catalog up-to-standards may sound like a lot of work. Fortunately, thanks to the license data and active maintenance that comes with the Tidelift Subscription, the process has become routine for our engineering team. Our team now appreciates having clearly defined guidelines on what’s OK to use as well as a transparent process for beginning to use new packages.

What standards do you use within your organization? How are they communicated with the team and how strictly are they enforced? If you need help defining your open source standards or if you need a better process for upholding them, we would love to work with you.