Is ZODB unmaintained?

[leycec]

The last repository commit was nearly a month ago. Code quality analytics like Lumnify now classify ZODB as in "decline." Long-standing critical issues well-known to cause spurious database corruption have remained unresolved for over a year:

This issue about data corruption is here for almost a year. The patch, that fixes this data curruption, is also there for almost a year: #323. ~ 2 months ago that patch was decoupled from a preparatory step that turned out to be questionable (#323 (comment)). Could we please move on with getting this issue fixed?

Formerly prominent maintainers like Tres and Jim have fled. Both now unconditionally ignore all GitHub pings, pull requests, and issues pertaining to ZODB:

Jim is currently not interested in any ZEO/ZODB stuff, as his day job has nothing to do with these.

In a conference call a couple weeks ago Jim made it clear that he isn't using ZODB for anything right now, and he won't spend time on it anymore. Don't wait for his feedback, it will not come.

Tres (and Jim) are listed as maintainers on many packages that they haven't been using in years. They have moved on to other work and other interests.

No promising new maintainers have stepped up to the plate.

In short, ZODB appears to be dead in all but name. Usage on production servers is an increasingly dicey proposition. I'm disappointed the Zope Foundation let their flagship database offering stagnate to this degree, but here we are. Let's foster healthy community discussion (and ideally remedial action) on the moribund state of ZODB in 2021.

It's not too late to salvage this sinking ship – but it almost is. 🚢

[d-maurer]

Cecil Curry wrote at 2021-5-29 14:23 -0700:

The last repository commit was [nearly a month ago](https://github.com/zopefoundation/ZODB/commits/master).

One could call this "stable". "stable" software does not need constant commit activity.

... [Long-standing critical issues well-known to cause spurious database corruption have remained unresolved for over a year](#318 (comment)):

This is obviously a bug. However, I am not sure it is critical: it affects `DemoStorage` (or other layered storages) only and only in the presence of "delete object" records. The ZODB has been used for at least a decade without explicit object deletion -- it does not seem to be a critical feature. The name `DemoStorage` suggests that its primary purpose are DEMOnstrations: I would expect that those would usually not require explicit object deletion.

... No promising new maintainers have stepped up to the plate.

I think @navytux waits for an approval of his fix to the above problem. Maybe, you step up and review his PR: you seem to view this problem as critical; thus, you should get actively involved to fix it. I did a review but do not want to approve the PR: I would prefer that `loadBefore` is fixed (even though this could cause breakage) rather than a new storage method introduced; at least, it should not get deprecated before major `zopefoundation` projects (e.g. `ZEO`) have been changed to no longer use it.

[jmuchemb]

I don't like auto-prophetic writings, to the point that the idea of deleting the whole issue crossed my mind. When I have such opinion about a project, either I share my thoughts privately or I'm more cautious (so I edited the subject).

To answer your question, ZODB is really alive. Our company has invested a lot in it and we consider it will never die.

ZODB has little activity for 2 reasons:

• it is small software that mainly defines specifications
• it's rock-stable because it had to be from the beginning

In other words, what do you expect to see ? Most ZODB-development happen in ZODB implementations like NEO or in software using it like ERP5.

About #318, we don't consider it critical because it's hard to imagine the affected component used in production.

Code quality analytics like Lumnify now classify ZODB as in "decline."

On your link, I see nothing about code quality.

[bitnom]

I only just became aware of this project. It's awesome. From what I've seen so far, the project isn't unmaintained. I saw in a presentation at a conference (Video) the lead developer (Maybe one of the people replying here) no longer works on the repo full-time.

I've had a look around this and related repos. I came across NEO and newtdb. I was disappointed to see newtdb has been abandoned, and that NEO relies on Python 2. There's supposedly a recode of NEO to golang. Idk how that's going or if there would still be a Python client.

I think these projects were in some sense of ahead of their time. With how much Python is now being used, and some of the things its being used for, these three databases could easily blow-up in popularity. I think there are some missed opportunities happening here.

[d-maurer]

bitnom wrote at 2024-2-10 15:39 -0800:

I only just became aware of this project. It's awesome. From what I've seen so far, the project isn't unmaintained. I saw in a presentation at a conference (Video) the lead developer (Maybe one of the people replying here) no longer works on the repo full-time.

The `ZODB` is maintained, but it is "stable": this means few development in necessary. Occasionally, a bug for rare edge cases is detected (e.g. recently a `FileStorage` bug involving an "undo" of an "undo") and fixed. Such maintenance work does not require a lot work.

I've had a look around this and related repos. I came across [NEO](https://neo.nexedi.com/) and [newtdb](https://newtdb.org/). I was disappointed to see newtdb has been abandoned, and that NEO relies on Python 2. There's supposedly a recode of NEO to golang. Idk how that's going or if there would still be a Python client.

I have worked myself on `ZEO`, providing a ZODB server solution and a Python client. Its most recent releases are Python 3 only, supporting all recent Python versions (3.7+). @navitux is interested in the maintenance of the Python 2 compatible branch. For some other solutions, it might be necessary that you get yourself involved - either with your own development or with funding.