Open source software (OSS) is everywhere—it’s the lifeblood of the modern software ecosystem. Ninety percent of companies use open source¹, 97% of codebases contain open source², 70-90% of the code within commercial tools comes from open source³, and the value of OSS globally is estimated to be $8.8 trillion⁴. At GitHub, we love open source—and we’re so honored to host so much open source code that we famously preserved it in the Arctic.

But in the same way that your office microwave doesn’t just magically get clean and your favorite park doesn’t have self-mowing grass, open source software doesn’t just happen.  

We’re surrounded by human-maintained infrastructure and resources that, in our busy lives, can be easy to take for granted. This is why we started Maintainer Month—a time to thank the open source software maintainers that keep projects healthy. This May marks the fifth annual Maintainer Month, and there are lots of treats in store: new badges, special discounts, events with experts, and more. In addition to the fact that the device you’re reading this on functions–thanks, open source maintainers!

Maintainer Month events and livestreams

There are over 25 events and livestreams scheduled during Maintainer Month, so head on over to the schedule to see them all or add your own!

Everyone is welcome at these events—whether or not you’re ready to call yourself a software maintainer. Here are a couple of our favorites, since they tackle thorny issues: 

• What maintainers need to know about open source licensing, SBOMs and security: May 6, 2025
  Join our colleague Jeff Luszcz from the GitHub Open Source Programs Office as he reviews what every maintainer should know about these topics in the ever-evolving landscape of 2025. We get so many questions about this, and Jeff is the expert!
• The CRA and Open Source: What Maintainers Really Need to Know: May 27, 2025
  Feeling stressed about the European Union’s new Cyber Resilience Act (CRA) regulations? We can help! Come to this stream with the Eclipse Foundation’s Cyber Resilience Working Group, where they’ll talk about resources and practical information for maintainers navigating these changes.

🎁 Meet the 2025 Partner Pack

This year, we’re launching the new Maintainer Month Partner Pack—a bundle of perks, tools, and resources from organizations that truly believe in open source. Think of it as a care package for the folks behind our digital infrastructure.

Here’s just a taste of what’s inside (and it’s available to all maintainers):

• Arachne Digital: Free tailored threat report with steps to defend your project
• Boot.dev: One month of free premium access to backend dev courses
• CNCF: Discounts on select cloud native training (Kubernetes included!)
• DevCycle: A full year of the Developer plan, free for maintainers
• JSConf North America: Special discounted tickets for Maintainer Month
• Linux Foundation Education: 25% off the full course catalog
• Mockoon: Free Mockoon Cloud account to build, test, and mock APIs faster
• Sentry: Access to their open source plan for monitoring and performance
• TODO Group: 20% off the CODE certification for enterprise open source
• Web Summit: Discounted tickets to Vancouver & Lisbon for OSS contributors

…and we’ll be adding more throughout May. 

👉 See all current offers and partners here.

Some partners are offering extra perks for members of our private Maintainer Community—a vetted space to connect, share, and support each other. If you maintain an open source project, you can request to join our Maintainer Community.

Security: a new challenge

Security is kind of a big deal, which is why you hear about it all the time. This is why we’re excited to launch new security guidance on opensource.guide to help maintainers strengthen the trust and resilience of their open source projects. We’ve pulled together practical advice and tools you can start using right away to make your project safer for everyone who relies on it. Because building great open source software isn’t just about what your project does—it’s about how you protect the people who use it.

The new Open Source Guide on Security Best Practices for Your Project will walk you through the basic considerations for software security, including how to:

• Secure your code as part of your development workflow
• Avoid unwanted changes with protected branches
• Set up an intake mechanism for vulnerability reporting

🔒 Security Challenge: Level up during Maintainer Month

Ready to boost your project’s defenses—and your own skills?

This May, take the Maintainer Month Security Challenge, which features three hands-on GitHub security skills while allowing you to snag a voucher for GitHub Advanced Security certification (hello, career boost!).

In just a few hours, you’ll pick up real techniques to protect your project—and show the world you’re serious about security. Let’s build a safer open source together.

Join the Security Challenge >

🔧 How to get involved throughout May and beyond

• Explore the Partner Pack: maintainermonth.github.com
• Join the Maintainer Community: maintainers.github.com
• Want to contribute an offer? Email us at maintainermonth@github.com
• Share your story: Tag #MaintainerMonth on social media to help us celebrate the humans behind the code!

The post Welcome to Maintainer Month: Events, exclusive discounts, and a new security challenge appeared first on The GitHub Blog.

Maintaining an open source project can be a big responsibility. But it’s not one you’re obligated to bear forever. Maybe usage has declined thanks to a better solution. Maybe technology has evolved to the point that it’s easier to start over with a new project than adapt an old project to a new ecosystem. Sometimes it’s time to move on, even if that means deprecating a project.

Brett Terpstra, a front-end developer, maintains more than 100 GitHub repositories and has had to retire more than a few. “Projects that rely on APIs and other outside applications often require more work than is worthwhile once things start to break,” he explained in a Q&A. “Historically, those are the projects that get retired the fastest.”

Whatever your reasons, you want to sunset the project gracefully to protect your reputation and do right by your users. Here are some insights from maintainers who have navigated the process about what you should and shouldn’t do when it’s time to deprecate a project.

Don’t: Keep maintaining something for too long

The one thing Olga Botvinnik, a computational biologist, would tell her younger self is that she should have sunsetted her Python data visualization package prettyplotlib sooner. She didn’t want to abandon the project, but she had started it as part of her PhD work, felt like updating it to support Python 3 would be daunting, and was interested in moving on to other projects. Besides, another Python visualization library called Seaborn was becoming increasingly popular. 

“Even if I’m immediately done working on a project, I leave the 30-day window open to take care of issues and help users transition.” – Brett Terpestra, front-end developer

Botvinnik thought Seaborn was better in some ways, and more polished. So she made the decision to deprecate prettyplotlib and spend her time contributing to Seaborn instead. “One of my mentors told me that knowing when to end a project is just as good as finishing it,” she says. “That made me feel a lot better about letting it go.”

Do: Leave the door open for someone else

That said, you shouldn’t deprecate a project without considering other options, like handing it to another maintainer. Terpstra has deprecated many projects, but he always looks for someone else to take them over first. “There are different degrees of sunsetting,” he says. In some cases, a project is so simple that it doesn’t need much maintenance. In that case, you can just make a note that you don’t often update the project while leaving the door open for new contributions.

Of course it’s not always appropriate to hand off a project to another maintainer. Ben Johnson, maintainer of the SQLite recovery tool Litestream, opted to retire BoltDB and point people towards a fork called BBolt rather than have someone take over the original. “My name and reputation were pretty closely tied to the project at the time,” says Johnson. “I was the BoltDB guy. I didn’t want to put my reputation in the hands of someone else.”

Don’t: Pull the plug without notice

Terpstra gives at least a month’s notice before retiring a project. “Even if I’m immediately done working on a project, I leave the 30-day window open to take care of issues and help users transition,” he says.

“One of my mentors told me that knowing when to end a project is just as good as finishing it. That made me feel a lot better about letting it go.” – Olga Botvinnik, computational biologist

Once you’ve made the decision to deprecate a project, you need to let users know and, if possible, suggest alternatives. “I spread word through a blog post and a tweet announcing that I wasn’t going to actively fix bugs anymore and pointed people to Seaborn instead,” Botvinnik says.

Do: Keep the code online

Instead of deleting your project, it’s almost always best to archive it instead. Archiving a project makes it read-only and communicates to users that it’s no longer maintained. Everything from issues and pull requests to milestones and permissions become read-only. But you can always unarchive a project if you later decide to work on it again.

Deleting your project could have unintended consequences. “Anyone thinking about taking their software offline should consider whether they might be creating reproducibility problems for people in science and academia,” Botvinnik points out.

Keeping it online means that even if you couldn’t find someone to take it over before you deprecated the project, someone else could come along later and fork it—or at least find something useful to reuse.

That said, if you believe your code is actively harmful, it might be best to take it offline. For example, software with dangerous security vulnerabilities that put users at risk.

Take this with you

Ultimately, open source projects are living entities—born from passion and sustained by community. Knowing when and how to let go is not just good stewardship, it’s an essential part of the open source lifecycle.

The post Dos and don’ts when sunsetting open source projects appeared first on The GitHub Blog.