Is this project dead ?

[jackton1]

Seems there's a backlog of issues and PR's that haven't been merged/reviewed.

With the last activity over five months ago

[sww314]

@jackton1 No I use this app in production as do many others.

Many of the issues and PRs can easily be overridden locally if you need customization.

[uhbif19]

@sww314 Project surely is used in production and has new commits. But (from my quick glance) I have a doubt what writing issues/PRs on this project will have effect, because I am not sure why some PRs are stale for years (for example).

For example, I had some minor issues with not documented S3 settings and would like to contribute on that. But some similar PR is stuck since November, so I am not sure that I should try. https://github.com/jschneier/django-storages/pull/956/files

[jschneier]

It's the classic tale of open source. I was fairly gung-ho about the process and such when I first acquired this library but have grown my responsibilities and interests to the point where finding the time or motivation to look at code and pull requests is difficult. The little I do is mostly to assuage a sense of guilt I feel which I don't find entirely logical.

I never found this project particularly interesting but it was enough. It is also weighed down by mediocre code and a lack of rigor around its testing practices. The codebase that I inherited was surely in worse state than now but very few people get out of bed with fire in their belly to clean up cruft, especially untested cruft -- the code does not come close to meeting my personal standards.

The forays into merging things has left me with an only increasing burden. The Dropbox backend, for example, was added only after assurance that it would be maintained by the original contributor. Instead, I ended up fixing bugs to interact with a service I have never used in my life. It has gone similarly with adding additional maintainers. I don't blame people for this, they are in the same position as me.

I have considered trying to move this library to something like Jazzband, but I believe the testing and code quality preclude that move. I do think it is the eventual natural resting point for this library.

I have most of a roadmap around what I think needs to be done and some ideas of time that would take in addition to many, many users. Given those two truths, I thought it would be interesting to attempt to find a grant that would allow me to pay to see the roadmap executed and a new (pair of?) maintainer(s) onboarded. Alas, the only brief overture I made to Mozilla turned out to be at a particularly bad time while they went through layoffs. I think this library is not sexy enough to qualify for a lot of the various grants but it is important and foundational to people. If anyone knows of any I would be much obliged because I do not want to see the work replicated and the community splinter.

Realistically I can give something like 30 - 90 minutes a week to open source but there will definitely be extended periods of time where I'm simply not available.

[onekiloparsec]

Thanks @jschneier for your honnest description of the situation. I would definitely go for attempting a transfer to Jazzband. To me, the amount of work for such transfer is very low, if not null, for what I see in their website.

[terencehonles]

I'd definitely vote to possibly move this to jazzband, I'm starting to help maintain django-redis with another, but my worry about jazzband is that there is not enough admins in the project (raised here jazzband/help#196, and this is an instance where it went sour 😕 iMerica/dj-rest-auth#197). It does seem like the project itself may need a little more decentralization, but I understand that might be hard with GitHub's permissions (I have not explored them close enough).

[LincolnPuzey]

In my opinion, trying to support 7 different backends in one library is setting the bar way too high for any volunteer maintainer. Both in terms of workload and the knowledge required to know each backend is using each providers API effectively and securely.

With a quick glance at the code, there seems to be ~150 lines of code shared between the backends, so there doesn't seem to be much economy of scale in having all the backends in one library.

This might be extreme, but this library could be split up into one library per backend. Not saying that @jschneier or any one person should do all that work. Ideally there would be a different maintainer for each backend/library.

For example there is already
https://github.com/etianen/django-s3-storage
They say:

It was originally written to support Python 3 at a time when the future of django-storages was unclear. It's a small, well-tested and self-contained library that aims to do one thing very well.