作为 MariaDB 推广工作的一部分，我们一直致力于改进开源项目中对 MariaDB 的支持。
我们一直在关注的开源项目，范围涵盖了从 WordPress 或 MediaWiki（维基百科运行于其上）这样知名、可直接使用的项目，到为无数其他开源和私有项目连接软件与数据库的 ORM 等底层解决方案。
MariaDB 是许多项目和用户正在运行的事实标准。随着 MariaDB 发展成熟并逐渐走出与 MySQL 不同的道路，尤其是在后期版本中，仅凭一句“MariaDB 是 MySQL 的即时替代品——众所周知”来回避兼容性问题已远远不够。为了消除用户的疑虑并确保实际的技术兼容性，需要付出更多的努力。
MariaDB 基金会如何才能最好地支持这些项目？我们的工作揭示了一些实用的方法，首先从项目如何传达其数据库兼容性开始：大多数项目将其源代码共享在 GitHub 上，这使得审查其 README 文件和文档变得容易。
许多项目在其要求中同时提及 MariaDB 和 MySQL 及其版本。然而，许多其他项目出于各种原因仅提及 MySQL，这可能使用户对 MariaDB 与项目的兼容性产生疑问。其他项目可能存在不一致之处，在某个地方提及 MariaDB，但在其他地方却没有。
对我们来说，一个好的第一步是简单地在项目的 GitHub 讨论论坛中联系他们，询问“您的 README 或要求中没有提及 MariaDB 是有什么特殊原因吗？”。得到的回答从“是的，我们应该提及，我会批准一个 PR”到更复杂的答案不等。
迄今为止，通过 Pull Request 对 README 或文档进行较简单更新的例子包括 Joomla、 MyBB 和 AlchemyCMS。稍微复杂一些的文档更新例子包括 Bugzilla 和 Ansible。
仅仅在项目要求文档中添加一个等效的 MariaDB 版本感觉缺乏基础，直到有某种技术证明为止——尤其是在 MariaDB 和 MySQL 5.7 之后版本路径开始分化的情况下。我们已经提供了帮助，协助在 GitHub 中使用 CI 工作流设置针对 MariaDB 和 MySQL 的测试，这是确保项目数据库兼容性的最佳实践。
MariaDB 基金会已协助设置的 CI 测试示例包括 Abantecart、 PrestaShop 和 mysqlclient-sys。
在某些情况下，项目没有提及 MariaDB 是因为它们使用了尚未自行记录或验证 MariaDB 兼容性的底层依赖项。有些项目报告了尚未解决的 MariaDB 兼容性错误。这促使我们去探索这些项目，看看能做些什么。
一些修复已在 Doctrine DBAL（+ 3.8.x 快速修复）、 PrestaShop（进一步修复 MariaDB Server 中的兼容性问题）和 FreVa（并修复了 MariaDB Docker 官方镜像）中进行，这仅是其中一部分。
MariaDB 基金会并非总是具备足够的语言技能，也可能无法立即帮助构建 MariaDB 兼容性，但当资源可用时，我们就知道它们可能在哪里需要。
需要进行开发工作的例子有 Diesel Rust ORM 和 Grafana。一个更简单的、待处理的开发工作的例子是 WordPress 中处理 MariaDB 或 MySQL 版本检查的方式，这已在其下一版本中进行了讨论。
随着我们遍历这些项目并改进它们关于 MariaDB 的文档、CI 和偶尔出现的问题，我们不禁想起我们的生态系统是多么脆弱。许多项目只有一两个活跃的维护者，而庞大的用户群依赖于他们。从 xz 到 OpenSSL Heartbleed，多年的开源开发仍然将巨大的负担留给了少数个体。就像 WordPress 的 “未来五分”计划一样，回馈那些为你提供了免费软件的社区是十分重要的。
对于任何寻求修复、文档化和确保项目与 MariaDB 兼容性方面帮助的人，请在 Zulip 上通过 mariadb.zulipchat.com 联系 MariaDB 基金会的专家寻求帮助。