I am curious about texts (or any other media) on the end of projects/technologies/communities, both on a practical level (how projects can be ended in a way that is respectful and does reduce harm) as well as sociological and anthropological theories of this process (e.g. grief, rituals, memories, ghosts, transformation…)

#maintainance
#community
#grief

Rather than considering even just once the needs & massive benefits for creators and maintainers, current open source software infrastructure, support tools, but also developer culture itself is completely biased and optimized purely for the benefit of consumers/users. Choosing a non-standard project structure (in my case a mature Google-style monorepo with almost 200 largely independent, but related projects/libraries/tools) is increasingly actively punishing my work and efforts in a variety of ways, e.g.

- non-supportive UIs for improved browsing/overviews of monorepos
- harmed discovery via search & metadata limitations
- wrong, misleading and downgraded project ranking calculations (npm)
- misleading/broken automated project analysis (GitHub)
- lack of support by documentation tooling (TypeDoc)
- lack of support by package managers (Zig) and/or hosting platforms

All of these (and more) factors are actively hurting, disqualifying & even completely nullifying much of my time & energy spent on these projects, making my dream goal of working on open source fulltime increasingly intangible (because the above factors all have an actively downgrading effect which makes these project seem lower quality/relevance). To some extent this is purely because this work is stored in a project structure which is optimized for maintenance & automation. Technically, we're speaking about _one_ additional level of nesting. An extra subdirectory! Otherwise, not any different than a "normal" repo. Still — BOOM — confusion, inflexibility & punishment ensues! 😫😭

So many external aspects and people do not give a damn that a monorepo setup like this and the custom tooling created to automate the maintainance and cross-linking of all these ~360 packages (incl. example projects) are _the only sane way_ for me as a single person to efficiently manage & release a codebase of this magnitude.

I was aware of some misunderstandings about monorepos on purely social/human level, but never saw it coming that the more I was expanding and deepening this work, the more this structure and scope would hurt the project & my goals, because 3rd party infrastructure is just as weirded out by such a "blasphemy" as some people are...

I'd genuinely like to hear ideas what I could/should do to escape the vicious circle created by the above factors, which is a real motivation killer... I really do wonder how other maintainers (esp. would like to hear from indie devs)
handle projects & codebases of this scale without running into these issues...

Thank you for any insights!

Ps. I really seem to have a feeble for "think different" and going against the grain with these things (or maybe being too early?). The first set of 20+ https://thi.ng libraries for Clojure/ClojureScript were mostly written in a #LiterateProgramming format, often combining source code with diagrams & tables — this too led to many complaints and was partially to blame for not gaining much traction, even though these projects were singular offerings to that language community at the time (and funnily only became more popular _after_ 6-7 years, once I'd already left Clojure behind... go figure!)

#OpenSource #MonoRepo #Maintainance #Infrastructure #Documentation #Tooling #SocialCoding #Expectations #NonStandard

https://mathr.co.uk/web/helm.html

> Claude Heiland-Allen. At the Helm of the Burning Ship. 2019. DOI: 10.14236/ewic/EVA2019.74

I updated my page about my #EVA #EVALondon #EVALondon2019 #paper about the #BurningShip #fractals #maths , now with added #reference alternative #archive links.

#maintainance #repair #LinkRot

Ich will was wartungsärmeres als Luft im Fahrradreifen haben. Warum hat das noch niemand erfunden? #maintainance #wartung #fahrrad #luftAufpumpen #bikebubble #fahrradbubble @mastobikes_de

Edit: hach dieses trolling hier😅😅. Ich dachte eher an so Gel oder sowas?