Like most tech companies these days, Fastly is heavily reliant on open source software and the ecosystem of services and frameworks that modern software development weaves together. We need to talk about what it means to 'be open,' how we can recognize the broader ecosystem we're part of, and how we're making big changes to improve.

We’re working to make our little corner of the open source world the friendliest, most welcoming, easiest to understand, and most inclusive place it can be. You’ll see the results of that work in three key new parts of our open platform we’re sharing today: an updated code of conduct, a new project directory, and clearly-defined support levels for our open work.

Making open understandable

Recently, we identified a number of problems that made things unnecessarily complicated for users of our open source work. We had a lot of public repositories on our GitHub but few people could easily understand which were active, whether support could be expected and whether contributions were invited. Many of our customers also use Fastly in conjunction with other tools, frameworks and services (like Gatsby, Heroku, NextJS, Vercel, Splunk, New Relic, Wordpress to name a few random ones), and adapters exist to support those interops, but it was often hard to figure out to what extent we support those adapters, whether they work for particular use cases, and who maintains them. This needed to be cleared up.

Making sure you have a good experience

So, it’s not enough to provide a lot of great open source tools — you need to have a reliable, trusted experience when you use them. We started with the basics. GitHub has a very useful tool under Insights > Community standards on each repo, which provides a checklist for community health. This felt like a good starting point to help people understand the intent and support behind our public code:

Then, we took it a step further. We also created a clearly-documented support model to bundle up a bunch of expectations and behaviors into simple, recognisable buckets. Four levels can cover all projects quite well:

• Product: An official part of Fastly's services. Expect complete documentation and support engineers trained to help you out.
• Tier 1 OSS: "Active" projects that we are working on frequently and where you can expect enthusiastic engagement.
• Tier 2 OSS: "Maintenance mode" projects where we keep on top of dependencies and security issues but may not always be able to engage with community interest.
• Archived: Projects that we don't intent to revisit, which may no longer work, and should be considered out of date and likely insecure.

This can be nicely represented in a comparison matrix. You can see this on our new open source directory:

To tie all this together, we made an org profile for our GitHub organization page. There are some great examples of these, like Microsoft and PayPal. For Fastly's, we wanted something friendly and human so we used Imagemagick to create a montage of all the avatars of the Fastly team members who have contributed to the open source projects in our org:

This is also a good spot to link to policies that apply across our open source work, and promote the great work being done by the organizations we support as part of our Fast Forward program. More about that in a minute.

Wow I had no idea we had that!

There's a ton of gold in our public repos, and scandalously, few people know it's there. Sorting through what we've open sourced over the years, we developed a category system, and most things fall into one of these buckets:

• Tools: Stuff you run in your own environment, usually to help you interact with Fastly, like our compute static publisher utility or the Fastly CLI.
• Plugins: Things you use inside third party products to help them integrate with Fastly, like our Wordpress plugin or Terraform provider.
• Demos: Applications that you can run on or with Fastly, demonstrating creative uses of the Fastly platform, like this JavaScript implementation of OAuth 2.0 you can run at the edge.
• API clients: Dedicated adapters to access api.fastly.com in a variety of languages.
• Compute Starter kits: The Fastly Compute platform allows you to run your code on our giant edge network in a variety of languages. Starter kits offer complete example Compute applications that are great for scaffolding new projects.
• Compute SDKs: These run within Fastly Compute apps and allow you to access platform features from your preferred language.
• Compute libraries: Code you can import into Compute apps to make common things easy or integrate with third party services or frameworks, like our adapters for OpenTelemetry or Next.JS.

Not all our open source repos are Fastly related either, Fastly engineering teams have opened up a bunch of things that we've built just to solve problems within low level parts of our stack. For example utilities for dnstap in Rust, or Prometheus instrumentation for Sidekiq.

Do we really need a 9-year old fork of the Linux kernel?

One of the things that stifles openness is noise. Sifting through our public repos, some are very obviously redundant and just distracting. So we started by archiving a whole bunch of them - over half, in fact. We wrote some Google Apps Script in a spreadsheet to import and analyze the state of all our public repos:

This allows for some basic filters to be applied to find the most obvious candidates for archiving:

• No updates in over a year
• No open issues
• Does not have forks
• Primary committer is no longer at Fastly
• Minimal watchers / stargazers

Repos where all these things are true could be archived in bulk, and we reached out to the team closest to the code to give them the opportunity to delete the repo entirely if it was of no use at all. Archiving works well for everything else - archived repos remain accessible and cloneable, so any unknown project that depends on them will continue to work, and it's reversible, so we can change our minds later if we need to. But archiving also sends a clear message that we are not paying attention to this code anymore, so use it at your own risk and don't expect any help!

This captured a lot of fun examples, like a fork of the linux kernel that we last committed to 9 years ago and last merged from upstream 11 years ago 😅. But once these really obvious ones are out of the way, the real work begins.

Code of conduct and responsible disclosure

Once we finished cleaning up our repos, we wanted to add one more essential piece: A code of conduct. As a values-driven organization, we hold ourselves and those we interact with to a high standard of behavior. (That even extends to the kinds of customers we allow on our network because we choose to do business with those who reflect our values.)

But… which one to adopt, or should we write a new one? With so many excellent options, we quickly decided adopting an existing code of conduct would be the best path forward.

The best way to build for our community is to build in collaboration with the community, so we simply asked for input on our community forum. We received so many excellent responses and suggestions from community members and even other Fastly employees. People suggested the Contributor Covenant, the Django Code of Conduct, and Elastic’s CoC.

After reviewing the suggestions against our needs, we chose to fork Python’s Code of Conduct, which is a fork of the example policy from Geek Feminism wiki, created by the Ada Initiative and other volunteers, and is under a Creative Commons Zero license. (This felt particularly fitting, considering Python is among our highest-traffic and longest-standing Fast Forward program members.) From there, we edited the Code to suit our circumstances and community needs. Our version is published on our GitHub profile.

Finally, we needed a working group to help enforce the code of conduct, review possible violations, and determine a plan of action when infractions happen. So we formed Fastly’s OSS governance group, pulling from different backgrounds and disciplines across Fastly, including our inclusion and diversity, legal, engineering, and marketing teams. You can see the members and enforcement policies on our GitHub.

Fast Forward

Fastly is deeply committed to the open internet: we use open source software throughout our stack, contribute to open standards, and encourage employees to participate in and use open-source software.

Given the benefits we derive from open source and standards, we must give back to open source builders and communities. That’s why we created Fast Forward — Fastly’s mission to build the open internet together. This broad-reaching initiative comprises four key programs and policies: Our OSS contribution guidelines, our Customer Community Policy, our contributions to open standards, and the Fast Forward program.

Through the Fast Forward program, we give free services and support to open source projects and the nonprofits that support them. We support many of the world’s top programming languages (like Python, Rust, Ruby, and the wonderful Scratch), foundational technologies (cURL, the Linux kernel, Kubernetes, OpenStreetMap), and projects that make the internet better and more fun for everyone (Inkscape, Mastodon, Electronic Frontier Foundation, Terms of Service; Didn’t Read).

We are always looking for new projects and ways to support the open internet. If you’re an open-source project that needs help scaling and protecting your website or applications, apply to the program.

Looking forward

At Fastly, open source is a part of our heritage, essential to our operations, and central to our future. What’s more, we’re on a mission to build the good internet — whether you're building or browsing, an internet that is accessible and safe for everyone.

Take a look at our open source homepage, Fast forward program, or join us on our community forum!