Markdown 成为了我写作的核心部分。它的简单性和灵活性意味着我可以实现一次编写，随处运行的梦想。不过，这确实导致了一些歧义。格鲁伯可能会说这是故意为之。他在整个 Markdown 文档中强调的是 Markdown 的语法，而不是生成的 HTML。例如，他的 Perl 脚本不支持 HTML 类名或 ID，因此您无法将它们添加到生成的 HTML 中。根据原始 Markdown 脚本的逻辑，如果您想完全控制 HTML 输出，那么您需要用 HTML 编写。
这种情况对 Markdown 用户（即作家）来说非常好。但对程序员来说就没那么好了。事实上，这让他们抓狂。程序员不喜欢模棱两可。这违背了编程的本质。作为一名使用 Markdown 的作家，我喜欢我可以选择最适合我需要的特定版本。作为一名程序员，我讨厌在构建某些东西时必须做出同样的决定，而这会影响到所有使用我的成品的人。也许我没有支持他们期望的某些特定扩展，因为他们一直使用相同的 Markdown 解析器并假设该功能可用。
如果这还不够糟糕的话，语法中还存在一些歧义。例如，星号在单数时用于斜体（*像这样*），在双数时用于粗体（**像这样**）。到目前为止一切顺利。但是如果你写**像这样*，会发生什么？应该这样渲染吗？ 像这样？ 或者可能 像这样*? 没有办法知道；无论谁编写了解析器都必须做出这个决定。
此外，与大多数极为成功的代码不同，Markdown 并未公开托管在代码共享网站 du jour 上。它没有数百人为其做出贡献，而且原始 Perl 脚本上次更新是在 2004 年。这也让程序员感到不快。我们是一群小圈子的人；小圈子之外的东西都会受到怀疑。
大约十年 以前，有人试图消除 Markdown 中的歧义，使其符合编码教条。一些程序员聚在一起创建了 通用商标，它做出了原始 Markdown 脚本所没有的选择，并提出了它的创建者认为的唯一正确的方法。
CommonMark 提供了安慰。它在 Github 上。它有一个讨论论坛。它似乎是一个活跃的项目。我个人从未将 CommonMark 纳入任何项目，但它的解析器可以在 Stack Overflow、Github 和 Reddit 等热门网站上将您的 Markdown 转换为 HTML。（例如，为了消除星号的歧义，它建议用下划线表示斜体，用星号表示粗体。）想必 CommonMark 背后的开发人员认为它很成功。
但它不是 Markdown。名字上不是，而且我认为精神上也不是。
在 CommonMark 计划开展的时候，软件开发人员 Dave Winer 告诉我一句话，至今我仍记忆犹新：Markdown 属于使用它的每个人。由于许可证，这确实是真的。但它也让我想起了自由软件的真正意义。我们每个人都有发言权：通过使用它、改编它，甚至分叉它。
无论格鲁伯是否有意如此，Markdown 确实属于所有人，而且没有标准。我使用非常老版本的 Python Markdown。格鲁伯可能仍在使用他的 Perl 脚本。其他人使用其他版本。它很混乱。它很模糊。它是人性化的。
而这，最终就是道路。
