Gauging open source project health

Back in February, I had an opportunity to speak at the O’Reilly Software Architecture in New York City. I was excited to have the chance, and I didn’t know at the time that this would be the very last O’Reilly conference amidst the onset of the COVID-19 pandemic. 😢

Despite the sadness to see the end of an era, it was really fun to present to a room of enterprise architects and senior engineering leaders about a topic that means a lot to me—open source project health! 👨‍⚕️

My talk was intended to be an introductory discussion about understanding and using open source in enterprise development environments. I also shared some tactical advice on how to integrate diligence around your open source dependency management into your software development lifecycle.

As I described at the conference, making good choices about which open source packages to use is a business critical decision. Why? Because bad package decisions will cause your development teams heartache and pain.

We call this “installer’s remorse.” 

Installer’s remorse: The feeling you get when you download a package, it becomes a critical piece of your application, and then at some point when you least expect it a year or two down the road, something bad happens because of it.

It might be that a security issue is discovered, and the maintainer is no longer actively maintaining the package, so you have to figure out how to patch it yourself (and then you end up owning the patch). Or you need to upgrade another package, which breaks this one, and because the maintainer has disappeared there is no way to get it working again, unless you are willing to own it yourself. 

How can you avoid installer’s remorse? 

Step 1: Build a shortlist of packages you’re considering using.

Start with the community package managers, where you can search for different components—often by keyword—to identify libraries that suit your needs.

Just as importantly, tap into the past experiences of your team and your organization. These should play heavily into your shortlisting process, as your team will be the folks ultimately using the package you decide on. If there is an Enterprise Architecture team within your organization, perhaps you can consult them for additional guidance.

Step 2: Assess the quality of the packages you’ve shortlisted. 

This can include looking at where the package is hosted (typically GitHub) and checking if the package is in a private repository or if it has its own organization. This can be a key indicator of project maturity.

Also look at more subjective criteria, such as the contributor base, the frequency of releases, and how the project addresses community issues. A project with multiple lead contributors, regular releases, and a healthy and respectful dialogue around issues is a great sign.

Step 3: Make your decision! 

Sometimes the package you want to use is perfect and you can install it and get to work right away!

But it’s rarely this easy. When it’s not a perfect fit, you’re faced with some options. 

You can choose to use the package as is, even if it doesn’t solve all your needs. Alternatively, you could write all your own custom code to solve the problem. 

And if you want some in-between options, you can choose to fork the package and either customize it locally, or contribute your changes back upstream. None of these options are right or wrong, so you should decide what’s best given your context.

One caveat: adding a new open source package to your app is rarely this easy. Typically, an organization will have security, legal, and enterprise architecture hoops to jump through. If that’s the case at your org, consider speaking with our team about the challenges you’re facing!

If your team is just beginning to think about how you’re managing your open source dependencies, a good first step is to become cognizant of when you’re changing or updating your underlying dependencies. That awareness alone will level up how you think about consuming open source.

One way I chose to illustrate is through GitHub Actions. GitHub Actions enable you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository. 

That means you can easily create a series of actions or tests or events that fit into a GitHub deployment workflow. I suspect there are a whole bunch of uses for this, but I wanted to demonstrate how you can use GitHub Actions to notify your development teams when a new dependency is introduced during a pull request.

You can see a screenshot of this below, where a label titled “new-dependency” has been automatically added to a pull request when GitHub Actions detects that I’ve added a new library to my package.json file.

This is just one example of how you can bring more awareness to your open source dependency usage, integrated directly in the continuous integration process. 

But I would encourage you to think: how could this work in your deployment process? Many development teams do not use GitHub, so could you bring this sort of awareness to your software development lifecycle in a different way?

Perhaps more importantly, what is the ideal developer experience for your team? If a developer is bringing in a new dependency, would you like to be notified at the CI/CD phase? If so, would you like this to happen earlier in the development process? What context would be best for you? The command line? The IDE?

These are all challenging questions about how to choose and manage open source packages well, and they’re challenges that we’re confronting at Tidelft every day. 

If you face these challenges as well, and would like to learn more about how we handle them at Tidelift, please get in touch.