Skip to main content

QGIS Plugins - Succession Planning

·3 mins

by Em Hain

Nodebo QGIS User Conference 2015

Nodebo QGIS User Conference 2015

Open Source projects often start as the passion projects of individual developers. For many, these endeavours are labours of love. However, there comes a time when sharing the reins becomes necessary, as none of us are immortal. Once a maintainer retires, if they don’t have a successor to continue maintenance, it will usually be thrown out to the community for someone to take over the maintenance OR to find a way to fund the maintenance/bug fixes. Succession planning for individual maintainers means identifying a successor, and granting the successor permission to maintain the release.

When will this start? When you think of it.

It isn’t always straightforward to identify that successor and can require some time for mentoring. Finding the right person—whether they are a recent graduate or someone early to mid-career—who aligns with your vision and style may be crucial. Ensure too that they think about who it is who will continue to carry this when they are finished.

So whilst it may be that finding an elusive successor may be like finding a needle in a haystack, think about the complexities for when it comes to plugins created and maintained by a developer as part of their role within an organisation. Organisations are driven by personalities, and a shift in management that isn’t supportive of open source could jeopardise the future of these projects. To mitigate such risks, it may be wise to create a Plugin Management Plan during the initial development stages.

This plan should ensure that:

  • Maintenance of the plugins is part of the job description and a normal expected work task.
  • There is a policy for training internal talent to maintain the plugins.
  • A clause exists to ensure that the organisation understands that under a GPL, it ensures that ongoing maintenance of the plugin can continue by others, if there are no resources available to undertake this maintenance, with the following options:
    • The plugin may be forked to the new maintainer’s repository and that will be identified as the official repository.
    • The creator of the plugin can continue maintaining the plugin if they wish to.
    • If the creator of the plugin does not wish to continue maintenance, then the community is notified with the intent of finding a new maintainer.
    • If a new maintainer is identified, the organisation is then to support the request to qgis.org to override the maintainer on the plugins site and amend it to the new maintainer.

Have you experienced this in your development of Plugins or in an organisation? Let us know on the QGIS AU email list about your experience.