Pinging some people that might be interested: @gingerbeardman @gtsteffaniak

Can we get someone from the forks maybe? https://github.com/gtsteffaniak/filebrowser @gtsteffaniak has done tons of work and improvements.

Hello!

I have stepped down from this project a long time ago, and @o1egl has been maintaining it for years. However, none of us have as much time as we used to have to maintain this project, especially considering how much it has grown in the past years. The last time I opened such an issue (#532), this project had around 3000 stars. Now it's almost ten time as much.

So, we decided to look for new maintainers. Let us know if you're interested.

I think everyone was looking for such a message for months.
This project is clearly a super good one. It shouldn't be nearly dead as it is.
It's a good decision to ask for a handover.
I'm pretty sure many people will be interested in contributing.
Thanks a lot for this message that brings up the light at the end of the tunnel.
Let's ping more people here
@jniggemann @Aetherinox @d-Rickyy-b @sevmonster

Yup. This is exactly all I asked for. A simple message either saying "I need a break" or to hand the torch over to someone.

I already have two big projects I'm dealing with, so I most definitely could not be a main contributor. I wouldn't want to accept and then I get busy and the project goes stale again. I'm sure in the future I can contribute to smaller tasks, but the only thing I ask is to ensure whoever gets handed over to the torch, check out their work first. Because this would be a "ah-ha" moment for someone looking to run through the code, replace the copyright names with their name, and then let it sit for another year. (If you're transferring the project to someone else).

If it's strictly contributors who won't hold ownership of the repo, then just ensure they know Go / Vue. It's a good project, and it deserves to be handled well by people who understand the language and will take it to the next step.

Final thought, if you're going to use the same structure and hold ownership of the repo, and have someone else maintain, please, get rid of that github workflow to mark issues stale after x days, and then close after 5. There are a lot of good ideas that have come through, and that bot has been working overtime to ensure those issues never see the light of day.

He removed the bot.... this is... I have no words for this. It feels like I've been re-born all over again. Thank you. I feel so happy I should go shake my partner awake and yell "The bot is gone!" and then get the death-stare. So I'll celebrate internally.

Hi all, I feel this is an important moment for this project. Filebrowser is widely used and relied upon by tens of thousands - if not millions - of users. Its impact is undeniable, and ensuring its continued development is crucial for the community IMHO.

Suggesting me as a potential maintainer is nice (thank you @M-Paladin), and I couldn't be more thrilled about the opportunity. A handover means fresh perspectives, new energy, and long-standing issues finally getting the attention they deserve. Open-source projects thrive on evolution, and I’m eager to contribute by helping shape the future of this project.

That said, I have to admit: I am not a skilled coder. I can hack together some features and perhaps even some tests, but my strengths lie elsewhere.
I'm happy to help with bug triaging and documentation, so real coders can dedicate their time to create fixes and new features.

@hacdias @o1egl Firstly, I would be happy to help out the community with reviewing and helping get PR's pushed through. It makes sense I would be a candidate since I have contributed more than 50% of all line code changes in history via my fork and have a good general understanding of how it works. I would jump at helping with some badly needed changes like disabling execution runners by default, a critical vulnerability which would be my first priority if given contributor status.

That said, I am not thrilled about the opportunity in the same way. For context, I created my fork 2 years ago because I desired better search and was generally dissatisfied with the state of the project. I have put a lot of effort into making my repo superior in many ways. I recognized it's lacking a couple of features, but not for much longer. I believe this repository will be completely obsolete within a few months.

You can read my thoughts on contributing to this repo, which I see 2 years later is still crippling this repo. This is mostly because of my dissatisfaction with the build process, code structure, style choices, and code review speed of this repo. So, I would love to help get certain needed things added as a contributor, but I don't have the desire or time to sift through the code as a general contributor.

With that context, yes I would love to help change a few small but major things that are badly needed on this project, but I cannot promise much of my attention will be spent on this repo in general.

I can relate to what @gtsteffaniak wrote. I think a good first step would be to discuss areas that need improvement.
How about we create some "space" for us to discuss this and next steps? I'm thinking of a wiki page we all have write permission to or something like that...

Just listing some of my thoughts:

• Collect thoughts / input on the current state of affairs. What's already good and what needs improvement?
  • functional
    • @gtsteffaniak removed the terminal and runners. While I personally never used both, I don't have a clue what our userbase would say. We could poll our userbase ex. using reddit r/selfhosted or r/homelab and get their opinion on this.
    • I'd like to see some EXIF data in the file info
  • development
    • change build process (<- just an example I made up)
  • organizational
    • ...
• Agree on priorities and next steps
• Find contributors to actually do these next steps

One topic of discussion could be: Should potential contributors put work into this fork or would it be better for the community they rather contribute to the quantum fork by gtsteffaniak? (I don't have an idea myself).

@jniggemann Or at the very least, priorities / audit of the current code before throwing a bunch of new features in.

I haven't done a deep deep dive but I forked my own version to Gitea and integrated SAML and OAuth2. They were just personal features I needed so that I could turn off the basic authentication. And sure, I could have used authtentik and a forward proxy, but I just prefer SAML and oauth2 for most authentication. I also needed ShareX / Zipline integration, and Transfer.sh. It was easier to just do it rather than wait (and fight that bot).

There have been a lot of recommendations by users which would greatly enhance this app. The only problem is, that damn rogue bot closed a lot of them. Some were important bug fixes. So they'll have to be hunted down.

@Aetherinox: I fully agree, literal of users were driven away from contributing to this project just because of this damed bot. People took time to report bugs or create feature requests - only to have their work nullified by the bot closing the issues.

RE: @M-Paladin

Let's ping more people here

I'd love to help out, but unfortunately, all the time I can scrape together is already spent on my personal projects and tools. I might be able doing some community management, issue sorting and communication. But since I barely got time to write code for my own projects, I don't think I'd be able to contribute code to this one.

I just created a new repo and a wiki page to track ideas: https://github.com/jniggemann/filebrowser-next/wiki
I added the users from this thread, if I didn't mess up, you should be able to edit the wiki.

You'll have to push a file so that the repo can be starred.

I got the invite, I can star it now.

And a note from your wiki. I don't mind sharing / contributing my SAML and OAuth2 modules. We just need to figure out who is going to take the steering wheel first and if they want it. I'll put in the time to make it a publishable module, I just don't want to invest the time if @hacdias or @gtsteffaniak don't need it / want to go another route.

Makes perfect sense - I just noted this as an example of possible new features. Later, when we've decided on some kind of roadmap, we can perhaps use a tracker to gather feature requests and bug reports. But first things first: Gather ideas on how to proceed, then create consensus, and then work out the rest.

Yeah, just my opinion, but I think an audit of the app's current status should be before new features. Dependencies, ensure there's no vulnerabilities, fix the most critical bugs and sort of get it all caught up to date. Then everyone discuss what new features would benefit the mass user-base and which one seems to be most favorable and work from there.

Whoever takes it I'm sure will put a game-plan together. Just threw my two cents. I'm not going to direct someone on how to drive the ship.

(I will carefully read all comments at the end of next week, as I'm on vacation)

@hacdias why don't you hand over the management of this repo to @jniggemann ? Instead of archiving it, something that will for sure result further fragmentation caused by a bunch of forks?

gtsteffaniak doesn't want to manage it, and I get it.

@TCB13 just like it has been discussed above, @jniggemann would be more focused on triaging issues, which is point 3 of the plan. That can be helpful. However, without an active maintainer actually fixing issues, security fixes, and updating stuff, no long lasting change would be achieved.

And note that I never said that archiving is what is going to happen. I said: in a few months, revisit the situation. If there is still no one interested on doing active development, then archive.

Iterating on what has been said above: @jniggemann if you're up to it, I can give you permissions to help with triaging, which would already be a big help in order to cleanup the backlog. It'd also be great to hear your input regarding the plan I mentioned above.

@jniggemann If you want your new repo to succeed, you should consider a fork at the very least, and maybe triage existing issues in a more condensed manner than the current tracker. Plus a master ticket containing everything you've discussed with a goal roadmap. Plans of action without clear means of implementing said action aren't so useful.
I don't understand - I don't have a repo to contine this project. Perhaps you misunderstood: I just setup something for us to discuss how to go forward, because IMHO issues are not well suited for discussion.

My 2ct on Hector's plan:

1. Feature freeze: the project enters maintenance-mode only. New feature requests and PRs are not accepted This would be made clear in the README, and the issue and PR templates would be updated to reflect this information. Perhaps remove the feature request template completely. This would help reduce the burden from the maintainers, considering that there is no active work on this project. Add a note to the footer of FileBrowser to indicate this.

Maybe we should accept PRs that fix security issues though.
Perhaps prevent non-contributors from openening new issues at all, just for some weeks?
It may also be a good idea to clearly state that running FB on your private LAN / in your homelab isn't as critical as a public-facing instance.

2. Alternatives: provide users with a list of alternatives in the README to projects with active maintenance and accepting new features. This could be done by linking to https://github.com/awesome-selfhosted/awesome-selfhosted#file-transfer---web-based-file-managers for example.

Isn't it a bit too early to actively steer users away? Perhaps we can still get a grip and continue.

3. Triage issues: go through the current issues and PRs and see what's an actual issue and what's not. Feature request PRs are closed, and issues too. Close this as not planned. Maybe closing isn't the best idea. Maybe tags are better for this. Open for opinions. Make the status of the project clear and do not give false hopes.

I think communication is key here. Some may have put significant work into PRs, I think it's important this work isn't lost and the creators know why we're doing this in the first place. I volunteer to do that.

In a few months time, revisit this. If it turns out that there's someone interested in further maintaining the project, revisit this issue. If it still turns out that there's lack interest, work towards archiving the project. Yes, I know it's not what the most desirable solution, but it's still better than giving false hopes. I think it's very important to understand how this project has been born, and that maybe some of the decisions were not the best, and there are maybe better alternatives.

Let's create a broader attention for this by raising awareness, ex. on reddit r/selfhosted. With some luck, we might find new maintainers there?

Iterating on what has been said above: @jniggemann if you're up to it, I can give you permissions to help with triaging, which would already be a big help in order to cleanup the backlog. It'd also be great to hear your input regarding the plan I mentioned above.

I'm in and will do my best :-)

As an anecdote to pass some love, PewDiePie mentioned and advertised this project in his latest video: https://youtu.be/u_Lxkt50xOg?si=SWcL8LxBAr5_2puT&t=889

Hi, i’ve just read this and it’s always sad to hear that a project of this size and open-source nature no longer has active maintainers. But everyone has their reasons, and I don’t judge anyone, I truly wish you all the best in your future endeavors.

I’m not sure what direction the project will take, but people like PewDiePie have mentioned it in one of his videos, and companies like Hostinger.com use it in their backend. Maybe one of them could help spread the word, or even consider maintaining it themselves, I’m sure they have the resources to do so.

That said, I just wanted to wish you all the best.

I have been using this Project for more than 2 years. my installation was 2 years old and there are few bugs i have noticed they never bothered me before i kinda off ignored. but now I am back to actively using fileBrowser.

I will be sad to see this project get archived. I have a lot of free time and hoping to throw in my hat.

But I am a novice programmer, and mostly wont qualify as maintainer.

but if it comes to archiving the project , Please consider me to be a maintainer.

but please don't archive the project.

It'd be interesting for me to help in maintenance this project. Since, I have started usuing this service not long time ago, it takes some time to research it, but I am ready will be one of them who helps.