Language agnostic 哪些因素决定了开源项目的成功？

我们有一系列封闭源代码的应用程序和库，我们认为开放源代码是有意义的

到目前为止，阻碍我们的是在开放之前清理代码库和记录源代码所需的努力

只有当我们有一个项目成功的合理机会，即有贡献者时，我们才想开放源代码。我们确信，大量开发人员都会对这些代码感兴趣

除了项目的“趣味性”和“有用性”，哪些因素决定了开源项目的成功？

示例：

• 代码的清洁度
• 源代码注释的可用性
• 完整或部分记录的API
• 许可证的选择（GPL与LGPL与BSD等）
• 公共存储库的选择
• 对公共网站的投资

---

真的，我认为答案是“如何运行项目”

你所有的例子都很重要，但关键是如何管理开发人员之间的交互，如何处理/接受补丁等，谁“负责”以及他们如何处理责任，等等

---

比较和对比（历史不难追溯！）Perl中Class:：DBI和DBIx:：Class的开发管理。

我今晚刚刚读了一篇关于成功与失败的开源项目可用性方面的优秀文章

摘录：

许多带宽被浪费在争论开源软件/自由软件（以下简称“OSS”）缺乏可用性上。这场辩论目前仍在博客、论坛和Slashdot评论帖子上继续。有些人说，糟糕的可用性是整个OSS世界的普遍现象，而另一些人说，OSS的可用性很好，但真正的问题是思想封闭的用户，他们希望每个程序都能克隆微软。一些人认为UI问题是暂时的成长烦恼，而另一些人则认为OSS开发模式系统性地产生了糟糕的UI。有些人甚至认为GPL间接奖励了难以使用的软件！（作为记录，我不同意。）

---

控制代码成功的因素有很多。所有这些都必须实现，以获得最微小的采纳机会

• 市场-你的开源项目必须有市场。如果你的项目是一个太空橙汁机，我怀疑你会非常成功。您必须确保您的项目在用户和开发人员中得到广泛采用。如果你能让其他公司也采用它，那么成功的可能性是原来的两倍
• 文档-正如您之前提到的，文档是关键。本文档包括注释代码、体系结构决策和API注释。即使您的文档中包含bug，或者关于软件的bug，也可以。记住，透明度是关键
• 自由——你们必须让你们的代码“自由”——我的意思是言论自由，而不是啤酒自由。如果您觉得您的市场是其他公司的图书馆，那么BSD许可证是最佳选择。如果你的软件要在台式机上运行，那么GPL就是你的选择
• 透明度-您必须在透明的环境中编写软件。一旦你开始开源，就没有隐藏的秘密了。你必须解释你所做的一切，以及你在做什么。这会让开发人员非常恼火
• 开发者社区-需要一个强大的开发者社区。这必须是存在的。只有大约5%的用户为项目做出了贡献。如果有人注意到已经有一年没有发布任何版本了，他们不会认为“哇，这件软件已经完成了”，他们会认为“开发人员必须放弃它。”让您的开发人员继续工作，即使这意味着他们要花您的钱
• 沟通-你必须确保你的社区能够沟通。他们必须能够归档bug，讨论解决方法，并发布补丁。没有反馈，开源项目是毫无意义的
• 可用性-使代码易于获取是必要的，即使这意味着要激怒律师。您必须确保您的项目易于下载和利用。您不希望用户必须跳过18个nag屏幕并签署合同才能做到这一点。你必须让事情变得简单、干净

---

我认为最重要的一个因素是使用您的项目的用户数量。

---

否则，它只是一个写得非常好、有用且有很好文档记录的服务器上的一堆东西，做得不多…
要获得贡献者，首先需要用户，然后需要一些不完整性。您需要触发“这很酷，但我真的希望它有这样的功能，或者在这种方式上有所不同。”如果您缺少一个明显的功能，用户极有可能成为添加它的贡献者。
最重要的是程序要好。如果它不好，没有人会用它。你不能指望鸡和蛋会逆转，人们会认为这是理所当然的，直到它变好
当然，“好”仅仅意味着“对很多人来说比任何其他实用选项都好”，这并不意味着它严格地说是最好的，只是它有一些特性，使它对许多人来说比其他选项更好。有时，该程序在其他任何地方都没有等价物，在这种情况下，在这方面几乎没有要求
当一个程序好的时候，人们会使用它。显然，它必须在用户中有一个市场——一个能做任何人都不想要的事情的好程序，无论设计得多么好，都不是真正的好程序。人们可以对市场营销提出自己的观点，但真正好的产品在一定程度上有推销自己的倾向。推广不好的东西要困难得多