Skip to main content

The Rhythmic Blog

Why Rhythmic Chooses Open Source

September 6, 2024       Steven Black               Comments  0

Most of us depend on free open source software every day, including most of the web.

  • The web browsers Firefox and Brave are fully open source.

  • Google Chrome is based on the Chromium project, which is open source.

  • Over 90% of web servers run the Linux operating system, a family of related open source projects.

In fact, the list is so extensive that it might be easier to list the software that’s not open source.

At Rhythmic, we not only use it (as if we have a choice!), but contribute back to it. The values that underpin the open source movement—openness, collaboration, meritocracy, and community—are not just abstract principles to us at Rhythmic. They are the foundation of our culture, our projects, and our relationships with our customers. Our core values echo this in a way that’s authentic to Rhythmic’s own ethos.

Why Open Source?

I’d like to take a minute to expound on that last idea—the connection between our core values and those of open source and at the same time, elaborate on the trade-offs that sold Rhythmic on open source.

First, the obvious one. It’s zero-cost. There’s no monetary fee associated with its use. The only “cost” is the opportunity cost, which is the alternative foregone to use the software. In certain cases, this is not trivial. For example, we use Jira because of network effects, in other words, because everyone else uses it.

Second, our engineers can dive into the source code and see how the technologies work. It would be wonderful if we wrote perfect programs every time. That is the case exactly 0% of the time. Sometimes code really is the best documentation. This provides an opportunity to gain a deeper understanding of the software and allows engineers to see how others work.

Finally, it fosters community. Community is something hard to come by in an increasingly atomized world.

Where Can I Find Rhythmic’s Open Source?

GitHub

Rhythmic’s GitHub Page

For Rhythmic, the epicenter of our open source impact is our GitHub organization. For those who aren’t in the know, GitHub has become the de facto home for open source code and hosts the source code for everything from games to operating systems.

Of particular interest to our team are two tools, Terraform and Ansible, which are hosted on GitHub along with vibrant ecosystems of modules and plugins. Our developers use Terraform to define Infrastructure as Code and Ansible to define its configuration. Put them together and you have a recipe for automating the creation and maintenance of entire organizations in the cloud. Our developers have contributed 43 Terraform modules and 14 Ansible roles to the open source community, which can be found on our Terraform registry and our Ansible Galaxy page.

Project Spotlights

Terraform Errorcheck Module

We had a provider for this but advances in Terraform made it possible without any custom code. Using this module, you can use any arbitrary assertion to do plan-time validation. Our particular use case was making sure the targeted environment matches the workspace, but you can use it anywhere you want to make sure two strings match. GitHub Link.

Terraform Module Template

Not all Terraform needs to go in a module, but when it does, it’s nice to have the boilerplate out of the way. This template aims to do that.

Terraform AWS-Okta SSO

Until the recent advent of AWS Identity Center, the way you’d hook AWS Identity and Access Management (IAM) up to your Single Sign-on (SSO) solution was through a federated identity provider. This module takes the Security Assertion Markup Language (SAML) document from your Okta and sets up everything on the Amazon Web Services (AWS) side to get Okta SSO authenticating users to AWS. GitHub Link.

Terraform AWS Backend

This module is for use in a multi-account setup like you’d see with AWS Organizations. If you’re just setting up a single account, allow me to recommend our AWS backend CloudFormation stack that will create a Terraform backend while avoiding the chicken-and-egg problem (where you need a Terraform backend to run your Terraform but to create a Terraform backend you need to run your terraform). This module creates a backend and templates the cloud formation stack to create a role that will allow a role in the parent account to access the backend and assume the role of the child account to make resource changes. GitHub Link.

How Can I Get Involved?

If you want to get started in contributing to open source software, we’d be more than happy to review your pull request!

Code contributions are great, but to make great software, it requires a community documenting it, reporting bugs, and using it.

Leave a Reply