Many python server libraries are out of date

[ghost]

More than half of the python server libraries are out-of-date abandonware, and should be curated more closely so that when newcomers transition into implementation they don't immediately assume "nobody is using JSON:API" and bail.

[freddrake]

Perhaps you should identify specific libraries you believe are abandonware, and why you believe them to be abandoned?

[ghost]

Took a while to collate, but here's a listing.

Maintained:

• django-rest-framework-json-api Commits within last month, hosted docs, 44k downloads last month.
• marshmallow-jsonapi Commits this year, docs are hosted, 56k downloads last month.

Maintained but not used:

• kt.jsonapi External open-source release of a private library, 2 public releases in may 2022. Recently open-sourced. Thorough but unhosted docs. 86 downloads last month.
• safrs Good development cadence (no new releases in 2022), commits this week, 500 downloads last month.
• pyramid-jsonapi Commits in april, good release cadence, only 240 downloads but pyramid is less popular so that tracks.

Semi-Abandonware but used:

• flask-rest-jsonapi Last dev 2 years ago, docs are hosted & not dead, release cadence was good up to 2020 6k downloads last month.
• pydantic-jsonapi No new dev since 2020 1.7k downloads last month.
• flask-restless-ng Hosted docs, active from 2020 through sep 2021. 2.5k downloads last month.

Semi-Abandonware but not used:

• starlette-jsonapi Hosted docs, active from July 2020 thru July 2021. 120 downloads last month

Abandonware:

• hyp Hasn't been updated since it's 1.0 in 2014, trivial amount of downloads
• ripozo No new dev last 6 years, dead website, ~170 downloads last month.
• sqlalchemy-jsonapi Hasn't seen a release since 2018, a 60 downloads last month. Sqlalchemy 2.0 deprecations will kill this if it's not dead already.
• neoapi No new dev last 7 years, no pypi description, some markdown docs in repo, 120 downloads last month
• flump Never hit 1.0, no new dev in 4 years, releases stopped after 4 patch versions, 40 downloads last month.

Never-was-ware:

• jsoongia A 3 commit WIP that never was published to pypi.
• xamoom-janus 60 commits, never published, no docs.

[ghost]

I think it's important to take this context and curate the list of implementations with it. I'd suspect the other languages have a similar problem.

[freddrake]

How are you measuring "not used"? As the author of kt.jsonapi, I know it's used, but the application it's used in isn't public. I expect that's a substantial portion of any library's usage. The docs are hosted on RTD, and the project metadata on PyPI will include the link with the next release.

The level of activity for a library is only tangentially related to whether it can be considered abandoned; rate of downloads might be a slightly better metric, but only slightly.

I agree the "never-was-ware" could stand to be removed, and the "abandonware" category warrants review. Perhaps messages to the maintainers would be warranted to determine status.

[ghost]

Fair remarks, I agree a measure of care is certainly warranted. "not used" was a rough proxy for "has <=500 downloads / month". I included those numbers over the last month in my synopsis, with links to the pypi download stats I pulled them from.

That particular value is not based off anything rigorous, just a level of intuition I thought was appropriate for opening an issue and getting some consideration of the problem from the maintainers of this list of libraries.

The next steps you describe seem a good course of action, but are outside what I've time for. Is there anyone maintaining these lists to take those next steps?

[dgeb]

Thanks for this discussion. It's very difficult to curate the list of implementations, especially since the presentation is static with no metrics of any kind. I'm considering dynamically generating the listings as part of a rewrite so that some current metrics can be associated with each. If the libraries are on github, then we could include # of stars and date of last commit, for instance. It would also be useful to mention support for v1.1 as well as individual extensions and profiles.

Any other general metrics or details that you would find useful?

[jelhan]

It's very difficult to curate the list of implementations, especially since the presentation is static with no metrics of any kind. I'm considering dynamically generating the listings as part of a rewrite so that some current metrics can be associated with each. If the libraries are on github, then we could include # of stars and date of last commit, for instance. It would also be useful to mention support for v1.1 as well as individual extensions and profiles.

Any other general metrics or details that you would find useful?

I created #1633 to discuss this in detail.