The ReadME Project is coming to GitHub Universe!

Register for GitHub Universe and set up your schedule now! You can attend in person at the Yerba Buena Center for the Arts in San Francisco or virtually online for free, and you can save your seat now.

Gracefully sunsetting open source projects | GitHub Q&A

The dos and don’ts, and why you shouldn’t ever really take your code down.

There are lots of reasons to sunset an open source project, including time commitments, compatibility issues, and the emergence of better alternatives. Whatever your reasons, you want to end the project gracefully. To help you learn the dos and don'ts of project deprecation, The ReadME Project senior editor Klint Finley gathered a panel of three open source maintainers with experience sunsetting projects:

• Ben Johnson, former maintainer of the now deprecated Go programming language database BoltDB.
• Olga Botvinnik, the creator of the late Python data visualization package prettyplotlib.
• Brett Terpstra, maintainer of over 100 projects, including the note-taking app nvALT, which he plans to retire in favor of a commercial version.

Klint: How did you know when it was time to sunset a project, as opposed to handing it off to new maintainers?

Ben: By the time I decided to sunset BoltDB, the CoreOS team had already created a fork called BBolt. I didn't want to just hand the project over to someone else and the fact that a fork existed made me more comfortable saying I wasn't going to update Bolt anymore. My name and reputation were pretty closely tied to the project at the time. I was the BoltDB guy. I didn’t want to put my reputation in the hands of someone else. It made more sense to me to make a clean break and point people at a fork.?

Olga: First of all, maintaining a project takes a lot of work. When I sunset prettyplotlib, I was in graduate school, dealing with research, publishing, and everything else that was going on with my life. I didn't feel like I had time to keep pushing prettyplotlib forward. I was still using Python 2.7 because I had used it throughout grad school. I wasn't sure how much work it would be to migrate prettyplotlib to Python 3. It was a big unknown. I was feeling guilty about stopping work on prettyplotlib since so many people were using it, but 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.

By that time, another Python visualization library called Seaborn was becoming more popular. In my opinion, the design was better in many cases. prettyplotlib was my first big Python library, so it was rough around the edges in places. I didn't know a lot about packaging at the time. Seaborn seemed more polished. It made more sense to me to use and contribute to Seaborn, and point other people to that, rather than trying to keep prettyplotlib going.

Brett: I always have multiple projects going at once, so projects that require little maintenance tend to fall off my radar. If I start getting bug reports for something I no longer have an interest in developing, I have to make a judgment call as to whether I want to invest in the update. I usually make the decision based on its adoption rate, but also my level of motivation. If I have evidence that more than 50 people are actively using the project, it's probably worth a bug fix, assuming it's not an inordinate amount of work. If I've lost interest, it's a rewrite, and/or less than 50 people are using it, it's probably time to retire it or find someone from the community willing to take it over. Projects that rely on APIs and other outside applications often require more work than is worthwhile once things start to break. Historically, those are the projects that get retired the fastest. Also, there are different degrees of sunsetting. In some cases, I might not actively maintain something, but I still accept pull requests from other people.

Read more about sunsetting open source projects with the full Q&A.

A peek at GitHub Universe?

Featured sessions:

Team Knowledge—Sharing with Cassidy Williams

As your teams grow, so does your collective knowledge of all that you've built together. Managing and documenting that knowledge can be daunting, but it's so important for remembering decisions, creating new ideas without reinventing the wheel, and bringing new teammates up to speed. In this talk, Cassidy will discuss strategies for taking (and finding!) notes as a team.

How to compete with open source—and win with Shawn Wang

Even though open source has been so transformative, it’s still only a little over 20 years old, and there are still many unsolved problems with building, scaling, and funding open source communities. Airbyte is disrupting the previously tightly controlled data integration industry by building—and paying—the largest community of data connectors in the world. If you're a founder or someone looking to get paid to contribute to open source with GitHub Sponsors, this session will give you some highlights of working with React, Svelte, Temporal, and Airbyte in just 5 minutes.

Twitch: A game changer for developers and educators with Dr. Johanna Pirker

We know Twitch mainly from watching others play video games. However, the COVID-19 pandemic has shown how versatile Twitch content can be and in many different areas, this platform can be a game changer. Dr. Johanna Pirker, for example, started streaming her university courses on Twitch and instead of 140 students she had 400 students watching and discussing from all over the world! In this session, Dr. Pirker will discuss the platform’s potential for different areas and applications, and will share Do's and Don'ts.

Featured Roles:

Analyst Relations Manager, Application Security

The right candidate is an experienced communicator, who understands the role industry analysts play as influencers of enterprise technology selection and validating vendor product and GTM strategies. They are driven, focused and a quick study when it comes to complex technology. The candidate must be comfortable balancing strategic thinking with tactical, detailed execution while often working independently.?

GTM Program Manager

Building on the success of the Revenue GTM Program Management partnership and alignment with GitHub’s Product Product focus areas, the GTM Program Manager role would focus on portfolio level communication, highlighting interconnectivity and dependencies across initiatives horizontally. This role would take ownership of cross-product programs such as beta tracking and Revenue release management for GHES. Assist with creating and documenting the infrastructure by which the GTM Program Management team operates.

Customer Success Architect

A Customer Success Architect (CSA) is the technical champion for GitHub customers, who focuses on connecting the technical and business customer activities in partnership with GitHub Customer Success Managers. The CSA will be expected to help customers achieve their business outcomes related to topics such as software development lifecycle, devops, innersource, code analysis and security, product strategy and enablement. The CSA will coach technical champions within customer organizations on how to identify and plan technical strategies to address their most pressing business problems. Common activities include workflow design, deployment architecture guidance, and adoption planning.