[Themaintainers] Death of open projects and its rituals?

[Adam Wight]

Hi Jan and maintainers,

The side question of why software is seen as a "project" or even "movement" is intriguing and might have some overlap with US trends away from 19th-century labor organizing, into lesser forms like mobilization and lobbying.[1]  (And maybe also the US's political origins in evangelical conspiracism…)

Most open-source projects seem to have a structure similar to political mobilization: a voluntary community is rallied around the need for some tool X, interested people freely associate for a narrow purpose and work together until the goals are fulfilled, then naturally disband again.  In death, this is a life well lived.

I see some healthy aspects such as avoiding the bulk and bureaucracy of zombie for-profit corporations which (in the US again) necessarily exist for the long-term goal of making money for a handful of stockholders, and whose software offerings are nothing but a by-product of the profit motive, maybe reflecting the professionalized, lobbying mode of politics?

But the "project" model also shares some of the drawbacks of political mobilization: that its structure is usually built around a small number of people who are extraordinarily productive in their domain, while in the periphery lurk a sprawling network of part-time contributors whose activity diminishes according to the power law.

The project model with its problematic focus on personalities, charismatic or not, opens itself to another type of death through Founder's Syndrome. We often allow the software to collapse its identity onto a single person, and the project momentum begins to rely entirely on that person's participation.  If they follow a fork, the community goes with them.  If they declare an end to the project, it ends.  In my opinion, these communities may have lost their original purpose: its members are happy simply to contribute to something at all, and the whole thing may take on the air of a cult, full of abuse and in-fighting.

Founder's Syndrome can be avoided of course, with some antiauthoritarian foresight: routinely clarify the group's purpose, actively distribute leadership duties, and trust the next "generation" to carry the torch.

There are two clear paths to this regeneration in the case of software, the first is that leadership of a single project can evolve and adapt to new contexts, for example by encouraging the initiative of newcomers who bring fresh ideas and energy.  The second is that the barriers to creating follow-up projects can be reduced, for example through mid-level architecture documentation and through coding practices which consolidate clear core logic and isolate from large and expensive glue to external systems.

Finally, I wonder about another possibility: that it might be useful to acknowledge the possibility of death.  All software running today will stop forever at some point, and we can hardly predict the time or manner in which it ends.  Recent static around Firefox seems to have rekindled creative conversations about how to escape the entrenched monopoly and monopsony over web browsers, which wouldn't be discussed if we had continued in the comfortable belief that Firefox would go on invisibly providing safe haven to the 2.6% of global web users who have the luxury of choosing it.

Warmly,
Adam

[1] "No Shortcuts: Organizing for Power in the New Gilded Age", Jane McAlevey, 2016.


> Am 10.03.2025 um 15:42 schrieb Ross Spencer <all.along.the.watchtower2001 at gmail.com>:
> 
> 
> Hello Jan,
> 
> This sounds like a very interesting topic and the related submission/edition for Zeitschrift sozialersinn sounds especially related to this group.
> 
> In my experience, and possibly biased toward the English language[1], I haven't seen a word for the end of a project as strong as "death". "Death" might normally imply the ending of a project under extreme circumstances, e.g. loss of personnel, unexpected loss of funding and so on. Otherwise, a project is implied as short-term, or running for a short amount of time where words such as discontinuity/discontinuation, wrap-up, ending might be more idiomatic. Similarly, as a project is ending it might look for stable revenue streams, continuity, or transition, e.g. into business as usual. 
> 
> As for the artefacts of a project that does end, then I think that can get a little messier without identifying an approach to archiving or transfer of the records to a suitable custodian. For software, one probably does need to identify a maintainer but it is complicated as open source software might not even take-off so as to look "alive" or "maintained" but the code might happily live on and work. 
> 
> This is, however, only my experience and perception, and I will be very interested to read other replies to this thread.  
> 
> Thank you for the interesting prompt.
> Kind regards,
> Ross
> 
> [1] Living in Germany I am learning there are a lot of differences between idioms.
> 
>  
> 
>> On Thu, Mar 6, 2025 at 3:45 PM Jan Dittrich <dittrich.c.jan at gmail.com> wrote:
>> Hello Maintainers, 
>> 
>> I recently started thinking about rituals for and memories of the end ("death") of projects [1]. How to send-off that project or idea of a future? 
>> 
>> This was based on some conversations with a colleague in academia as well as this call for papers [2]
>> 
>> In particular, I wondered about the end of "open" projects, i.e. ones that say that their essence is "the code" and/or "the data" like open source software or open knowledge projects. I notices that when these projects are often clearly not "alive" anymore (that is, there is no community around the project that keeps it running or that could be asked),  these projects are not really "dead" either, since they are culturally assumed that someone could just come and continue. Thus, there seems to be a great hesitation to actually declare such projects as ended. However, there imagined end is often used to call for action, both inside such communities ("this feature could be the end of...") and outside of them (like the implied danger to Wikipedia in Wikimedia’s donation banners)
>> 
>> I would be curious if you know 
>> -  interesting alternatives to the metaphors of "alive", "dead" and "grief" in this context (or alternatively, ideas on these metaphors and how they apply!) [3]
>> -  texts about the rituals around ends of projects, particularly ones that have such a complicated relationship to a clear end as the mentioned ideas of open (data/software) projects. 
>> -  texts about the rhetorical use of imagined ends of (open) projects [4] 
>> 
>> Kind Regards,
>>  Jan
>> 
>> 
>> 
>> [1]: Or, instead of projects one could take a larger perspective and, a bit awkwardly say: "the not-happening of a future that seemed attainable by ones activity" (in contrast to "it would be great if things would just magically be so that...")
>> 
>> [2] In German: https://www.soziopolis.de/ausschreibungen/call/aufhoeren-beenden-und-schluss-machen-in-organisationen.html  ("Stopping, ending and breaking off in organizations")
>> 
>> [3] I have thought of ossification, glaciation, weathering and decomposition so far
>> 
>> [4] Might be connected to community appropriate "extreme case formulations" (A. Pomerantz, 1986) and/or my use of the concept in https://www.fordes.de/posts/disappointment_product_community.html
>> 
>> _______________________________________________
>> Themaintainers mailing list
>> Themaintainers at lists.stevens.edu
>> https://lists.stevens.edu/mailman/listinfo/themaintainers
> _______________________________________________
> Themaintainers mailing list
> Themaintainers at lists.stevens.edu
> https://lists.stevens.edu/mailman/listinfo/themaintainers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/themaintainers/attachments/20250314/5152f61e/attachment.htm>