在最近的苹果全球开发者大会上，苹果宣布他们将“开源其编程语言 Swift 的下一个版本”。这至少意味着他们将使用开源促进组织 (OSI) 批准的开源许可证发布 Swift 的源代码。 仅此而已。
实际上，Klint Finley (@klintron) 的那篇 优秀文章 的最后一段内容是错误的，文章中写道：“但是通过将编程语言和其他核心开发者技术转移到开源领域，像苹果这样的公司可以为开发者提供一些保证，即开发者能够根据自己的需求采用这些工具，而不会面临法律诉讼。” 这完全不是真的。 风险仍然存在。 其他公司仍然可以愉快地起诉任何他们认为侵犯其财产的人。
而且，人们持续误解的不仅仅是社区和法律基础知识。 大大小小的公司仍然令人惊讶地缺乏对商业和经济基础知识的理解。 John Mark Walker (@johnmark) 最近完成了一个精彩的四部分系列文章，概述了通过开源“如何赚钱”的基本方法。 该系列文章的开篇段落是：
“我从没想过我会在 2015 年写这篇文章。 到现在，我认为从开源软件平台获得收入的方式应该是显而易见的。 但遗憾的是，并非如此。 尽管开源软件的成功是无与伦比的，并且主导着全球软件行业，但仍然有太多初创公司在重复过去一千家初创公司犯过的相同错误。 仍然有太多大型公司根本不明白参与甚至领导开源社区意味着什么。”
我鼓励您抽出时间阅读所有四篇文章（链接在文章底部）。 虽然 John Mark 目前在 Red Hat 工作，这是一家深入了解开源业务的公司，但他的经验可以追溯到近 20 年前他在 VA Linux 工作的时候。
公司确实在为以开源许可的软件做出越来越多的贡献。 谷歌正在围绕 Go 构建社区，去年 开始围绕 Kubernetes 构建社区。 Go 确实是一种越来越受欢迎的有趣语言，但 Kubernetes 代表了谷歌在部署、管理和编排应用程序容器方面十年的研究和经验，而此时整个行业才刚刚赶上。 苹果将推出 Swift 并使其受到公众关注。 甚至微软也已经认识到他们必须以不同的方式与开发者互动，并在去年年底发布了 .NET (第二次)。 这不再是像 MSDN 这样的广播式社区。
对于一家共享资产并围绕软件进行协作的公司来说，构建社区是完成工作的关键，而构建社区是一项艰苦的工作。 苹果需要学习并迅速学习一些经验教训。 为了构建社区，必须使其非常容易参与。 如果您希望开发者花费时间，软件需要下载并构建到已知平台上（理想情况下是多个平台）的已知测试状态。 否则，您的项目将变成另一个死气沉沉的软件集合，被扔到 GitHub 或 SourceForge 上，这会让开发者感到沮丧，最终将他们赶走。 有一套众所周知的 模式和实践 可以用来启用和构建成功的社区。 这不是秘密。
而且，早期的社区是敏感且脆弱的。 我曾参与最初在学术研究许可下发布 .NET 的工作。 苹果可以从中吸取教训，了解如何将其“做好”。 我们发布了大约一百万行代码，用于 C# 编译器、基础类库和公共语言运行时（以及完整的平台抽象层和完整的测试工具）。 一旦开发者解压缩源代码存档，只需两行 [简单] 序列即可构建组件，然后在 Windows、Mac OS X 和 FreeBSD 上将其测试到已知状态。 这两页文档主要告诉您如何完成少量工作以达到有保证的已知状态，如何通过运行示例代码来证明这一点，并简要讨论了源代码树，以便人们可以快速开始探索它。（MSDN 上有对 原始项目 的良好描述。）
在 24 小时内，我们收到了我们的第一个合理的补丁。 一个简单的 15 行更改，将即时编译器性能提高了 10%。 我们礼貌地感谢了贡献者，并解释说我们尚不接受更改。 又过了 24 小时，我们收到了第一个可靠的错误修复。 这非常棒。 它包括用于测试套件的额外测试，以证明它已修复。 我们礼貌地感谢了贡献者，并解释说我们尚不接受更改。 而那是最后一次有人做出贡献。 这是经过预谋的。 这令人心碎。 该项目作为编程语言的研究平台仍然是成功的，但它从未成为围绕该平台本身的协作社区。 当时，微软仍然非常担心（并且保守地过度谨慎）学术代码库与主线 .NET 产品空间有多么接近。
所以，我祝苹果一切顺利。 很高兴看到他们更广泛地参与到这个特定领域。 他们在社区建设、正确管理以及思考如何使其为业务做出贡献方面将面临挑战。 幸运的是，当他们加入更广泛的开源社区时，他们可以使用许多优秀的资源。 也许我们甚至会在今年的 社区领导力峰会 上看到来自苹果的人。 因为，正如我们都知道的那样，协作创新是新的参与机制。
John Mark 关于如何从开源平台赚钱的系列文章
1 条评论