正是如此。在 Linux 方面，我们中的许多人一直在与 Linux 供应商和像 OpenStack 这样的主要项目合作解决他们的移植问题，并在最有意义的地方解决这些问题（无论是将“--py3k”模式添加到 pylint，努力使 Ubuntu 和 Fedora 使用 Python 3 作为主要的系统 Python，还是推动像使 C.UTF-8 语言环境成为上游 glibc 的标准功能这样的更改）。（红帽和 Canonical 实际上都雇佣了许多 CPython 核心开发人员，其他主要的 Linux 上 Python 的使用者，如惠普、谷歌和 Rackspace 也是如此）
当识别出各种移植的技术障碍时，我们要么研究增强 Python 3 本身的方法来解决这些问题（例如恢复对二进制转换编解码器的完全支持和恢复二进制插值支持），要么研究如何使像 six、modernize 和 future 这样的移植工具更容易访问（这是 pip 包安装程序现在默认随 Python 2 和 Python 3 一起发布的一个关键原因）。
在用户方面，中小学教育部门基本上已经切换到 Python 3，并且在 Python 3.5 中包含专门的矩阵乘法运算，正是为了响应分析 Python 社区的反馈（和贡献）。
除了可能对用于更简洁地表达矩阵和向量运算的矩阵乘法运算符感兴趣之外，对于像 AutoDesk 这样的组织来说，目前还没有一个很好的 Python 3 诱因（这很可能是那些不使用 Blender 的 3D 动画社区的引爆点），但正如我在对 Clive 的回复中提到的，我想在某个时候解决当前嵌入的复杂性，这对于目前需要求助于复杂技巧才能使 Python 2 按照他们想要的方式运行的任何人来说都变得有吸引力。
至于挑战 JVM 和 CLR，我同意这是一个非常有趣的领域，我实际上认为 PyPy 社区最适合做到这一点。PyPy 不仅体现了设计 JIT 编译器的创新方法，而且 Armin Rigo 对软件事务内存的实际应用的研究确实具有突破性，并为能够在事件驱动模型中编程 PyPy 托管的应用程序，同时仍然利用所有可用的核心，并且在您碰巧从事件处理程序发出阻塞调用时不会暂停整个应用程序，提供了现实的前景。
我认为这里有多种不同术语的空间，每个术语都强调开放、协作开发的不同方面。例如，“开源”侧重于开源促进组织在开源定义中规定的特定法律要求，而“自由软件”则强调运行、检查、再分发和修改软件的“四项自由”。
“协作开发”将转而关注这样一个事实，即由于复制一件软件是免费的，贡献者可以投入（例如）创建软件所需工作量的 10%，但可以完全访问 100% 的结果。由于每个人都可以访问全部内容，因此贡献使整体变得更好是有意义的，而不是私下维护您自己的添加内容，在那里没有人可以提供建设性的反馈，并且其他人不会有兴趣使用或贡献该项目的假设成为自我实现的预言。提高您自己的贡献水平，然后更有可能让其他贡献者愿意倾听您的意见，从而使您能够有效地倡导比您自己能够实现的更重大的更改。
在这种情况下，“单开发者 FOSS”是否仍然存在是值得商榷的。那些单开发者项目可能依赖于其他开源组件（例如，使用开源语言运行时、部署到开源操作系统或使用开源开发工具），并且反过来被纳入更大的协作开发项目（如 Linux 发行版、OpenStack、开源 Web 服务等）。
我个人喜欢“协作软件”这个术语，因为它强调这些软件开发社区主要面向那些正在寻找共同开发者体验的人 - 那些完全乐于接受改进建议可能会得到“欢迎贡献”回应的人。
如果您只是想要在传统的客户/供应商模式下获得完整、精炼、预集成的产品，那么您真的希望与开源供应商的商业方面打交道 - 将客户的建议和投诉转化为社区可以接受的上游贡献是这些供应商提供的关键服务之一。
还值得注意的是，“协作软件”和“协同软件”都已被用作“群件”的同义词。因此，我在上面使用了“协作开发” - 它不仅避免了与那些现有术语冲突，而且还强调这不仅仅是一个软件特定的概念。协作开发适用于任何输出，其中互联网的创建已将复制的边际成本降低到接近于零，并且存在一个潜在贡献者社区，其中使用最终结果和影响未来变更方向的能力提供了足够的内在收益，以至于不一定需要外在补偿。
正是如此。在 Linux 方面，我们中的许多人一直在与 Linux 供应商和像 OpenStack 这样的主要项目合作解决他们的移植问题，并在最有意义的地方解决这些问题（无论是将“--py3k”模式添加到 pylint，努力使 Ubuntu 和 Fedora 使用 Python 3 作为主要的系统 Python，还是推动像使 C.UTF-8 语言环境成为上游 glibc 的标准功能这样的更改）。（红帽和 Canonical 实际上都雇佣了许多 CPython 核心开发人员，其他主要的 Linux 上 Python 的使用者，如惠普、谷歌和 Rackspace 也是如此）
当识别出各种移植的技术障碍时，我们要么研究增强 Python 3 本身的方法来解决这些问题（例如恢复对二进制转换编解码器的完全支持和恢复二进制插值支持），要么研究如何使像 six、modernize 和 future 这样的移植工具更容易访问（这是 pip 包安装程序现在默认随 Python 2 和 Python 3 一起发布的一个关键原因）。
在用户方面，中小学教育部门基本上已经切换到 Python 3，并且在 Python 3.5 中包含专门的矩阵乘法运算，正是为了响应分析 Python 社区的反馈（和贡献）。
除了可能对用于更简洁地表达矩阵和向量运算的矩阵乘法运算符感兴趣之外，对于像 AutoDesk 这样的组织来说，目前还没有一个很好的 Python 3 诱因（这很可能是那些不使用 Blender 的 3D 动画社区的引爆点），但正如我在对 Clive 的回复中提到的，我想在某个时候解决当前嵌入的复杂性，这对于目前需要求助于复杂技巧才能使 Python 2 按照他们想要的方式运行的任何人来说都变得有吸引力。
至于挑战 JVM 和 CLR，我同意这是一个非常有趣的领域，我实际上认为 PyPy 社区最适合做到这一点。PyPy 不仅体现了设计 JIT 编译器的创新方法，而且 Armin Rigo 对软件事务内存的实际应用的研究确实具有突破性，并为能够在事件驱动模型中编程 PyPy 托管的应用程序，同时仍然利用所有可用的核心，并且在您碰巧从事件处理程序发出阻塞调用时不会暂停整个应用程序，提供了现实的前景。