On the Fediverse @firstname.lastname@example.org tooted about retiring the well-loved Pinafore Mastodon client, after 5 years of maintaining this FOSS project. An interesting retrospective explains reasons for doing so:
The article provides background, technical details and learnings. It also exemplary for some common dynamics and failure modes found in many popular FOSS projects, and which relate to project governance and social factors. It indicates a Challenge to deal with during the lifecycle of any long-term sustainable FOSS project.
To quickly generalize some of the dynamic (distilled from the retrospective), it goes like:
- There is an interesting new technology developer would love to explore (ActivityPub et al).
- There is an expressed need (better Mastodon client) for which an audience exists (fedizens).
- The developer starts a FOSS side project (Pinafore). Main motivator is the “Joy of Coding”.
- The FOSS project becomes popular. This is an extra motivator, and success indicator in FOSS.
- Developer, now maintainer, automatically takes on extra duties related to FOSS governance.
- As the installed base grows, so grow the duties, chores and responsibilities wrt the project.
- As time progresses this shifts the balance in work load from motivating factors to burdens.
- Meanwhile interests of the maintainer change, while the user base has growing expectations.
- At a certain point maintainer is no longer incentivised enough to keep the project going.
- There exists no trustworthy successor to take over, and only responsible action is retirement.
To find best-practices for dealing with this question, the question is: What could have been done differently during the lifecycle of the project to avoid getting to this situation?
Steps 1) to 6) are very common and usually happen when a FOSS project started from the incentive of the “Joy of Coding” is handled well.
In Step 5) the developer / maintainer might be helped by a good awareness of the shifting nature of their project activities. Long-term project governance and other aspects of the FSDL beyond coding require different skills, and developer might have asked: To what extent am I motivated to acquire different skills, and continue to be responsible for doing the related tasks?
This might allow in Step 7) to anticipate and take timely action, like steering towards different project organization and governance model. E.g. to find people that are willing to be involved with community engagement, additional maintainers and more active contributors, improve documentation to ease their onboarding.
Steps 7) and 8) are also to be expected in any FOSS project of a particular size and popularity. For roadmapping the project into long-term sustainability these dynamics should be taken into account.
It may help to realize that Step 9) and 10) are unavoidable if no action is taken. Though the project may have given the developer / maintainer an incredible amount of satisfaction during its lifetime, its retirement (and eventual “demise” as the codebase loses relevance) is likely causing stress and feelings of loss (of years of hard work).
It would be great if a developer / maintainer addresses long-term success early on. But the reality is that this is not always in the interest of the developer. They may like to work alone on the project, having full freedom to do things the way they want.
This Challenge should find Best-practices relating to:
- Long-term Project Governance
- Finding Successors and Handover