相关内容

随着我们将Hibernate知识产权转移到Commonhaus基金会的实际操作进展，我们欢迎除了我们历史赞助商和团队成员雇主Red Hat之外的个人专家和其他公司对帮助Hibernate社区及其项目发展的兴趣。

多年来，社区成员做出了非凡的贡献，但大型公司参与进来更为复杂。我们已经从SAP HANA和Oracle数据库团队获得了出色的贡献，并从Cockroach Labs那里得到了一些兴趣。将迁移到基金会的一个目标就是进一步激发这种合作。

特别是，MongoDB Inc.的团队现在已伸出援手，渴望为Java生态系统开发一个改进的中间件层，以Hibernate API为基础与MongoDB数据库集成。

这很可能是一个新的项目，灵感来源于我们现有的Hibernate OGM，但不一定相同：细节待定。它可能是Hibernate OGM的重启或略有不同；具体细节将由负责此项目的人来确定。

几年前，我们决定停止维护Hibernate OGM。这不是一个容易的选择，但作为一个小型团队，我们认为需要更多地关注其他项目。

维护Hibernate OGM的努力，尤其是跟上各种NoSQL存储之间的所有差异，尤其耗费精力：有时候，差异很明显，但有时它们变得模糊；然而，在我们的领域，任何小的细节都可能需要重大的范式转变，这意味着要重写系统的一致部分：不同的一致性保证、与事务的集成以及因此预期的业务逻辑设计，或特定的并发控制细节，需要对这些每个存储进行大量研究和专业知识，而且它们往往发展迅速。

再加上Hibernate OGM高度耦合于Hibernate ORM 5，而Hibernate ORM 6带来了一个全新设计、性能大幅提升的内部引擎。再加上将所有内容迁移到Jakarta API的需求；这对我们这个小团队来说工作量太大，无法在保持对JVM、JPA规范和NoSQL存储演化的关注的同时完成。

我们只收到了很少关于Hibernate OGM的价值和有效性的反馈。不幸的是，对于库开发者来说，快乐的用户分享他们的想法是很不寻常的。我们更常听到投诉，所以当我们只收到一些时，我们会怀疑项目是否太好以至于人们找不到缺点，或者根本没有人使用。下载量看起来相当不错，但很难确定它们是由于人们尝试原型设计还是在大规模生产环境中使用该软件。具有讽刺意味的是，下载统计数字不受这样大规模部署的影响，因为它们通常有各种形式的缓存。

总之，我们收到的反馈很少，而且几乎没有志愿者愿意帮助维护这个复杂的项目。希望这能成为我们亲爱的社区的一个教训！

但是，既然我们已经明确表示不再维护Hibernate OGM，许多用户——包括我们不知道他们存在的大型生产用户——都站出来表达了对缺乏更新的担忧。

有些人最终站出来，因为他们感到升级到Jakarta API的压力：最新的Hibernate OGM仍然基于javax.persistence API，而没有支持jakarta.persistence的OGM版本，这也意味着与任何现在与Jakarta EE 10及以后版本对齐的库都不兼容。

所以我们最终了解到，许多实际生产用户都对前进的道路感兴趣；其中一些用户正在使用MongoDB后端，因此，MongoDB Inc.小组非常慷慨地介入来帮助恢复项目。然而，由于他们不会支持我们曾经支持的其他NoSQL技术，Hibernate OGM的继任者可能看起来有点不同。

为了MongoDB公司能够介入并帮助，他们打算从我们的社区中聘请一些专家。

以下我将直接引用他们的信息；请帮助传播这个独特的机会，开始一个新的项目。