Signs that the Open Source Project is Reaching End-of-life
In Part 1 of this blog series, “When and How to Deprecate an Open Source Project,” I provided useful tips and a step-by-step guide for responsibly deprecating an open source project. In this second installment, I’ll delve into the planning stages of a project’s lifecycle and identify four key focus areas that suggest the project’s end may be approaching. By recognizing these signs, you can determine whether to revive your project or deprecate it.
Lifecycle planning is crucial
When envisioning and developing new and necessary business-critical open source projects, developers should include well-defined and detailed plans for the entire life cycle of each project, from its inception to its eventual termination. Such planning is part of a company’s comprehensive open source strategy, which encompasses all projects under their supervision, in addition to responsibility for their users, and the open source community that sustains those projects. When a project becomes no longer valuable to users, an end-of-life plan is essential to ensure a seamless transition for all users.
Warning signs your project is at risk or even dying
An open source project that strives for sustainability exhibits open practices, employs open infrastructure, and fosters an open culture with the goals of becoming more sustainable. Measuring the health of a project can be a complex, difficult, and sometimes daunting task, even for the most experienced community architects. And while multiple factors combine to depict a project’s overall health, there are four obvious indicators that show that the project is unhealthy. These indicators are also closely related to the most common reasons for abandoning a project, which are illustrated at the end of the blog.
1. Inactivity
Are the number of people adopting the project decreasing? Has the community stopped patching or updating the code to resolve vulnerabilities? What’s the date of the last pull request?
Activity metrics provide one of the best snapshots of your project’s health. They depict the latest commit date of a repo, the average time of the first response on a pull request or an issue, and the number of closed issues and pull requests within a certain period. These metrics also show security risks in the lack of regularity of releases and dependencies that need to be updated or could become irrelevant for the evolving use cases over time.
2. Contributor risk
Are contributors no longer willing or able to work on the project? Or are there just not enough of them to sustain it?
By analyzing the contribution percentages of each of the project’s team members, you’ll not only see how the workload is being distributed but get an idea if there’s been sufficient knowledge sharing and mentoring within the community.
3. Governance and availability of proper documentation
Has the project’s governance model been thoroughly documented?
Governance is an evolving process and the documentation – Governance and Maintainers document, along with the Contributing file found in the repository – outlines a clear path for aspiring leaders within the community to move into new roles. It also provides ongoing support and activity, as well as reducing maintainer burnout.
4. Diversity and inclusion
How diverse is your group of code contributors?
A major responsibility of the project leadership is to encourage a friendly and welcoming environment for all community members. Adopting and enforcing an appropriate Code-of-Conduct is one of the first steps that can be easily undertaken, followed by various initiatives to encourage diversity and inclusion.
Learn more about project health indicators in the blog “If You Can’t Measure It, You Can’t Manage It” – Some Thoughts About Project Health.
Why life cycle planning is critical
The graph below introduces some of the most common reasons for abandoning or deprecating open source projects. It’s based on observations of external projects, as well as internal research on hundreds of archived repositories in VMware’s GitHub accounts.
Summary
The analysis of historical data and certain unsuccessful examples can and already have provided many lessons. It is important to incorporate all the observations when approaching new open source projects, avoiding common mistakes but also allowing the freedom to do others. There is a certain portion of all projects that most probably wouldn’t become widely adopted and many of them would be deprecated soon after the start. Knowing and accepting that fact can avoid misinterpretation of the data and will leverage the freedom of the open source enthusiasts to try new ideas.
Being an optimistic person, I’d like to conclude with the reminder to always be prepared for unarchiving and reviving a project (as discussed in Part 1 in this series). If a project holds value, it deserves a second or even third chance, especially if the community is the driving force behind its revival. To reignite interest among contributors and the community, a project needs clear vision, commitments, and above all, a culture of openness and transparency.
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
