在过去的几个月甚至几年里，Ubuntu 和 Canonical 经常因开发软件和桌面组件而没有与自由软件社区的其他团体进行交流而受到批评。我不想对这个话题发表评论，但我看到创建一个“专有”解决方案来使用像 Unity 这样的启动器显示指标和进度条时出现问题。
在自由开放的桌面环境世界中，我们经常尝试标准化部件和库或编写规范以增加不同桌面之间的协作。我们拥有http://freedesktop.org的工具，并且主要桌面环境正在实施许多规范。
在这种情况下，为这些指标提出一个标准将是朝着更好的桌面之间的互操作性迈出的重要一步。
这些指标代表了 Linux 桌面上的一个很棒的功能，我相信其他项目，如 AWN、Docky 等，也会采用它们。
凭借 Ubuntu 的巨大市场份额，Canonical 可以将其作为标准提出并鼓励项目实施它。
提前谢谢你，塞巴斯蒂安·比劳德尔
我是 libunity 背后的邪恶策划者，其中许多东西将被实施:-)
标准有一个固有的问题——即它们是标准:-) 如果你把它们固定在石头上，你必须坚持它们，如果它们值得写在纸上。如果结果证明它们有不可预见的缺点或设计问题，您就有麻烦了。您可以扩展并拥抱它，也可以做一些完全不同的事情。无论如何，您都会在某个地方因您的选择而受到抨击。
也就是说，我认为你不会发现很多人会反对这样一个事实，即一个写得很好的、经过深思熟虑和经过验证的标准是一件好事。问题到了这一点。
对于 Ubuntu，我们有一些非常快速的功能开发周期，如果我们首先就 FDO 协商一个标准，然后实施它，我们根本无法以我们现在的速度交付功能。
我们现在采取的方法主要是在实践中尝试一些东西，然后当我们对某些东西感觉很好时，我们可以将它们起草为标准。但是，如果我们看到我们自己每个周期都在改变规范，如果我们把人们拉到标准化讨论中来，那可能只是在浪费每个人的时间，你不觉得吗？
所以原则上我很确定我们同意:-) 问题是如何在不危及用户体验的情况下到达那里。
另一种看待这个问题的方法是不一定强制要求“标准”是 DBus API 或书面规范。API+ABI 稳定库在我的书中同样出色。那么标准不是人类可读的单词，而是机器可读的二进制指令。
抱歉回复太长，但这是一个复杂的问题:-)