Continuing Sourcetrail / Sourcetrail End Of Life (EOL) about sourcetrail

[mlangkabel]

Thanks @fsimonis for all your support and for this suggestion. We read up on the KDE Incubator process and talked about it. Even if we would initiate the transfer, the project would still need an active team of maintainers, which currently does not exist. Before archiving the project, we will modify the readme to state that we are willing to transfer the project to an interested team that is capable of picking up the project.

[fsimonis]

At the end of the day, this is a question of dedication, time, money and skill.

The required skill set to maintain this code base is problem by itself.
Qt is a huge framework. Indexers are implemented as stand-alone processes and communicate using inter-process communication. Then there are the indexers themselves which are based on LLVM, the Java SDK etc. These in turn have to make sense of configured user environments.
On top of all of this is the cross-platform nature of the project.

Can one new maintainer handle all of this? I am pessimistic about that.

Also keep in mind that this project did not succeed as a commercial product and is not doing too well right now, so there is also not really a financial compensation for the work.

Personally, I am a huge fan of the project, occasionally contributed and was a Patreon for the last years. I would love to maintain Sourcetrail, but I don't have the required know-how, nor the time to maintain this project (as I already develop @precice).

Maybe, a larger group could embrace this project?
Given that Sourcetrail is based on QT, it could fit into the KDE ecosystem alongside Heaptrack, Clazy and the like.
This would probably also simplify a transfer of the domain name (and the running cost thereof).

[dongcarl]

Can't speak for anyone else but I currently use Sourcetrail on an M1 mac and an x86_64 linux machine, continuing support (in the case of M1, adding support) for those platforms would be great!

[fire]

@mlangkabel

Is it possible for your team to start documenting processes and standard operating procedures for the things you do for sourcetrail for future continuity?

[frhun]

I too very much love using sourcetrail, but lack the capabilities to maintain anything in the core codebase. But at least the burden of maintaining a multi platform Project could be partially eased by focusing on platforms with manageable fragmentation. (so containerized environments like snap, flatpak on linux ; idk, if anything similar exists on windows, and macos already is a little more predictable AFAICT)
Of course the multiple languages are also multiple, relatively fast changing, complicated, moving targets.
Are there any statistics of what language(s) currently is the main userbase?