Rescuing abandoned modules

All open-source software goes through a life cycle, from conception of the idea to the project’s eventual end of life. Sometimes, that life cycle ends in abandonment. This can happen for a variety of reasons, but it often happens because the developer that originally worked on the project in their “free time” then has life happen — and no one was willing to step in and carry the torch. This is a common situation we see with many of our support clients

Drupal’s security team takes the brunt of the work of policing projects hosted on Drupal.org that are enrolled in Security Advisory Coverage. It is part of their policy to mark a project as “unsupported” if the project maintainers are non-responsive in fixing an issue after multiple attempts to contact them via various means. When this occurs, the maintainers lose access to the project and then the “abandoned projects” policy takes effect

If the issue is not resolved within 30 days after the security advisory that deems the Drupal project unsupported, then the security team reserves the right to post a public issue detailing the security risk, allowing the community to engage in solving the issue

The Four Kitchens Support team is responsible for rescuing several high-profile Drupal 7 projects that have been unlucky enough to have been a part of this project. These include:

• • HTML Title (installed on 5,815 sites)

• • Services Views (installed on 9,839 sites)

• • Feeds JSONPath Parser (installed on 4,303  sites)

Each of these projects included a security issue that must be identified (or attempted to be identified) and then granted access to the team member willing to become a long-term maintainer of the module. Additionally, the team member wishing to be maintainer must have had the ability to opt into security advisory coverage on one or more projects in the past. These requirements prevent the same abandonment scenario from happening immediately after a fix. It is valid, however, to take on a project and immediately ask for co-maintainers

After a team member gains access to the security issue, they are under a strict non-disclosure agreement with the Drupal Security team to not share the details of the security issue until the security team allows a public issue to be created or a release containing the security issue fix has been made. In our case, this also includes other members of Four Kitchens. This team member will be responsible for working with the security team and the original reporter of the security issue to make a fix that will both solve the vulnerability as well as provide a smooth transition during the upgrade process

After the patch is reviewed and accepted, a security team member can opt to assign ownership of the module, or enact the “Request for ownership” policy, which is more involved and gives others the opportunity to be “interviewed” for the opportunity

All of this is time consuming and requires a lot of communication between community members to make progress. Taking the time to fulfill this process, however, rewards the community (and in turn, our clients) with a project that will continue to be maintained—or possibly one final fix to end the life of a well-used project

Sometimes, this results in a continued effort to build a transition from one project to another, such as the case of Feeds JSONPath Parser, where after the security vulnerability was fixed, a migration path to Feeds Extensible Parsers was created to move sites from a module to a more popular alternative with similar features

Let us help you continue the life cycle of open source software. Contact us to learn more about our Support practice today