FOSS Dynamics: From "Joy of Coding" to Duty and Burdens

Social Experience Design 🎭 SX Challenges
#1

On the Fediverse @nolan@toot.cafe 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:

  1. There is an interesting new technology developer would love to explore (ActivityPub et al).
  2. There is an expressed need (better Mastodon client) for which an audience exists (fedizens).
  3. The developer starts a FOSS side project (Pinafore). Main motivator is the “Joy of Coding”.
  4. The FOSS project becomes popular. This is an extra motivator, and success indicator in FOSS.
  5. Developer, now maintainer, automatically takes on extra duties related to FOSS governance.
  6. As the installed base grows, so grow the duties, chores and responsibilities wrt the project.
  7. As time progresses this shifts the balance in work load from motivating factors to burdens.
  8. Meanwhile interests of the maintainer change, while the user base has growing expectations.
  9. At a certain point maintainer is no longer incentivised enough to keep the project going.
  10. 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
The FOSS reality distortion field
A sustainable Guild: A discussion of Finance, Mental Health, Democracy and Institutionalization
#2

I’ve read the blog article on a feed reader today. I was pleased to see an openness to incorporate feedback to improve the accessibility.

Also noteworthy, that Pinafore challenged the dominant player (Mastodon) and eventually led to change there as well.

The argument regarding trust linked to a person is interesting. That can work out if some sponsors back up the person to allow for paid work on it. See cURL.

Please note also how a change of framework (Svelte v2 resp. Sapper) can have a tremendous influence on the fate of a project. Especially if said framework does not provide a migration path.

1 Like
#3

I tooted to Nolan about this topic, and he replied as follows:

This sounds like an accurate writeup. And yes I do have feelings of loss, but I also feel like I can 1) embrace impermanence, and 2) focus on other enduring outcomes: blog posts, learnings, influence, etc.

And yes, maybe I could have nurtured a community instead of mostly going solo, sure.

I’m not sure though that it’s so easy to pass on projects to new maintainers. As @baldur says in “Out of the Software Crisis”:

“Software is a temporary garden whose fate is inextricably intertwined with its gardeners. […] What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works.”

The quote is from the book by Baldur Bjarnason (which seems like a great read):

(I will dedicate a separate topic to the book).

Trustworthiness may be the better ‘metric’ that’s needed for someone to take over as maintainer.

Trust grows from a dedication to both the project and those interested in it, for longer periods of time. Prolonged trustful behaviour accrues on a ‘balance sheet’ of trustworthiness. Other contributors while acting in ways to increase trust, may still not be trustworthy enough. Will they stick around for the long haul? Are they as willing to help and do all the chores the current maintainer did? Etcetera.

Only time can tell. That is why considering to go from one-man-show to team-led governance should happen as early as possible.

Yes good point, and another axis. Tech stack choices can have big impact on the longevity of a FOSS project. The duty and burdens will inevitably come when a project matures, and using niche technology and languages limits the crowds in which to find dedicated helpers.

Two examples…

openEngiadina is a project I really like. Both for what it wants to establish, namely “Create, share and use open local knowledge” and for the research topics that @pukkamustard is exploring. But at the same time time the tech stack is based on OCaml and protocol is XMPP/RDF (XML-based). In the cross-section of those two alone there isn’t a large developer community, and it will be very hard to establish a good, diverse team.

Solidground that I started, is another example. I started investigating a tech stack based on Golang, but changed to Elixir later on (in part due to Go-Fed being abandoned). I feel Erlang/Elixir is an appropriate choice that fits the product vision, and is also interesting to me for its functional programming and native actor model. But Elixir is a smaller dev community, new to me, and also to @realaravinth who is co-maintainer and has expressed preference to make another language switch. When it comes to popular tech stack maybe a NodeJS / Typescript would make it easiest to find contributors.

Somewhat more off-topic responses…

Yes, it will be interesting to see how Accessibility track is shaping up in Forgejo. In discussion on number of community channels I argued that creating a separate Accessibility chatroom might place a11y on a pedestal for extra attention, but OTOH that channel will only attract people with an interest for a11y filtering out this topic for everyone else, and maybe effectively side-tracking it instead of making it front and center.

Yes, commendable. I am always of the opinion that any FOSS project should do what is most to their interest. In the case of Mastodon they develop a Microblogging app, and - by lack of open standards guidance - can’t be blamed to create their own opinionated, app-tailored ways of doing interoperability.

But OTOH it should be the task of any organization that evolves the “ecosystem / technology substrate” to ignore post-facto interoperability (the dominant leader dictates) and only adopt things that are in the best interest for the ecosystem as a whole. This includes making different, non-compatible choices to The Mastodon Way™ and where these make sense and the ecosystem adopts, this will provide incentives for Mastodon to also fall in line. And a more balanced ecosystem is the result.

If the ecosystem lacks the substrate, then all bets are off, and the dominant leader will take the initiative, having the most ability to act.

1 Like