[Themaintainers] Death of open projects and its rituals?

[Jan Dittrich]

Hello Ross,
Hello Maintainers,

> 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".
That is a good point. I just lack another word that implies grief and 
frustration, something that might be less extreme but not too managerial 
(In German, I say "beenden"=end or "abschließen"=close/conclude, but 
these, too, are distanced, matter-of-fact-y). I like sumana’s mention of 
"Sunset" though it implies a regularity and non-agency does not cover 
the perceived disruption – many people seem to have percieved Python 2’s 
maintainance ending not as a regular sunset, despite a lot of effort to 
structure the transition.

Your comment also made me think of the word "project", which is a 
curious one. Most definitions emphasize that a project is limited in 
time, yet a lot of (open) software+community is also called a "project" 
without any "end" being clearly described or a set "finish line" 
defined. The latter seems to clash with cultural norms in particular, I 
assume because it is seen as bureaucractic or managerial to prescribe 
goals, whereas the "emergence" of changes "from the community/code" 
("Stigmergic") is the preferred mode to progress and coordination (I 
worked as UX designer on open source software, and this was a frequent 
point of conflict).

I am curious how open endend, not-having-a-concrete-goal things became 
to be seen as "projects" rather than something else! (*might* be related 
to the idea that everything, including people and their careers are 
"projects")

Kind Regards,
  Jan

Am 07.03.2025 um 08:33 schrieb Ross Spencer:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/themaintainers/attachments/20250307/e117929b/attachment-0001.htm>