我们有一系列封闭源代码的应用程序和库,我们认为开放源代码是有意义的。
到目前为止,阻碍我们的是在开放之前清理代码库和记录源代码所需的工作。
只有当我们有合理的机会使项目成功时,我们才想开放源代码——即有贡献者。我们相信,大量开发人员会对代码感兴趣。
除了项目的“趣味性”和“有用性”之外,哪些因素决定了开源项目的成功?
例子:
- 代码的清洁度
- 源代码注释的可用性
- 完整或部分记录的 API
- 许可证选择(GPL vs. LGPL vs. BSD 等...)
- 公共存储库的选择
- 投资公共网站
我们有一系列封闭源代码的应用程序和库,我们认为开放源代码是有意义的。
到目前为止,阻碍我们的是在开放之前清理代码库和记录源代码所需的工作。
只有当我们有合理的机会使项目成功时,我们才想开放源代码——即有贡献者。我们相信,大量开发人员会对代码感兴趣。
除了项目的“趣味性”和“有用性”之外,哪些因素决定了开源项目的成功?
例子:
有几件事决定了代码的成功。所有这些都必须实现,以获得最微小的采用机会。
我认为最重要的一个因素是使用您的项目的用户数量。否则,它只是一个写得很好、有用且有据可查的一堆东西,它们放在服务器上做的事情并不多......
要获得贡献者,首先需要用户,然后需要一些不完整性。您需要触发“这很酷,但我真的希望它有这个或以这种方式有所不同。” 如果您缺少一个明显的功能,用户极有可能成为添加它的贡献者。
最重要的是程序要好。如果它不好,没有人会使用它。你不能希望先有鸡还是先有蛋会逆转,人们会认为这是理所当然的,直到它变得好。
当然,“好”仅仅意味着“对相当多的人来说比任何其他实用选择更好”,这并不意味着它严格来说是最好的,只是它具有一些特性,对于许多人来说,它比其他选项。有时该程序在其他任何地方都没有等效项,在这种情况下,几乎没有这方面的要求。
当一个程序好的时候,人们就会使用它。显然,它必须在用户中占有一席之地——一个做没人想要的事情的好程序,不管它设计得多么好,都不是真正的好。人们可以对营销提出观点,但真正好的产品,在某种程度上,倾向于推销自己。推广不好的东西要困难得多,所以很明显,一个人的首要任务应该是产品本身,而不是推广产品。
那么真正的问题是——你如何让它变得更好?答案是一个敬业的、熟练的开发团队。一个人很少能靠自己创造出好的产品;即使他们比其他开发人员要好得多,但多视角对项目的影响也是非常有用的。这就是为什么拥有公司赞助商如此有用的原因——它将其他开发人员(来自公司)的思想放在问题上以给出他们自己的意见。这在开发程序需要社区中不常见的大量专业知识的情况下特别有用。
当然,我说的都是经验。我是 x264(目前最活跃的)的主要开发人员之一,它是最流行的视频编码器之一。我们有两个主要开发人员,社区中提供补丁的各种次要开发人员,以及来自 Joost(维护速率控制算法的Gabriel Bouvigne)和 Avail Media(我有时为他们工作,目前正在招聘合同编码员)的企业赞助添加 MBAFF 隔行扫描支持),以及不时弹出的其他几个。
一个好的开发者不会做一个项目——许多好的开发者会做。这样做的最终结果是一个程序,它比大多数商业竞争对手、硬件或软件,甚至是那些拥有巨额开发预算的竞争对手,都可以更快地编码视频,并且质量要好得多。
在查看这些问题时,您可能有兴趣查看加州大学伯克利分校开源课程的在线版本,该课程名为开源开发和数字信息分发:技术、经济、社会和法律视角。它由 Mitch Kapur(Lotus 创始人)和法学院教授 Paula Samuelson 共同教授。我有很长的通勤时间,去年我把课程的音频放在了我的 iPod 上——他们从一个非常广泛的(虽然显然是学术的)角度谈论了很多关于什么有效,什么无效以及为什么。
已经写了关于这个主题的书籍。事实上,你可以在这里找到一本免费的书: 生产开源软件
真的,我认为答案是“你如何运行项目”。
是的,您的所有示例都很重要,但关键是如何管理开发人员之间的交互,如何处理/接受补丁等,谁“负责”以及他们如何处理该责任等等。
比较和对比(历史不难追查!)Perl 中 Class::DBI 和 DBIx::Class 的开发管理。
今晚我刚刚阅读了一篇关于成功与不成功的开源项目可用性方面的优秀文章。
摘抄:
大量带宽被浪费在争论开源软件/自由软件(以下简称“OSS”)缺乏可用性的问题上。此刻,博客、论坛和 Slashdot 评论线程上的争论仍在继续。有人说可用性差是整个 OSS 世界的通病,也有人说 OSS 可用性很好,但真正的问题是那些心胸狭窄的用户,他们希望每个程序都克隆微软。有人认为 UI 问题是暂时的成长痛,也有人说 OSS 开发模式系统地产生了糟糕的 UI。有些人甚至认为 GPL 间接奖励了难以使用的软件!(为了记录,我不同意。)
只需开源它。很可能,还没有人会开始贡献。但至少你可以在新闻稿上写下你的产品是 GPL 或其他什么。
第一步是人们开始使用它......
也许然后,在用户适应之后,他们将开始贡献。
到目前为止,每个人的答案都很好,但是缺少一件事,那就是很好的疏忽。没有什么比没有某种项目管理更能扼杀开源项目了。不要告诉人们该做什么,而是为您希望吸引的开发人员添加一些结构和任务。
杂乱无章的项目很快就会分崩离析。这不是一只鸟,你只是放手看着它飞走。