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

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

只有当我们有合理的机会使项目成功时,我们才会开放源代码——即有贡献者。我们相信大量开发人员会对这些代码感兴趣。

哪些因素, 排除项目的“趣味性”和“有用性”, 决定一个开源项目的成功?

例子:

  • 代码的整洁性
  • 源代码注释的可用性
  • 完整或部分记录的 API
  • 许可证选择(GPL 与.LGPL 对比BSD 等...)
  • 公共存储库的选择
  • 投资公共网站
有帮助吗?

解决方案

有几件事决定着代码的成功。所有这些都必须实现,才有可能被采用。

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

其他提示

我认为最重要的因素是使用您的项目的用户数量。否则,它只是一堆写得很好、有用且有据可查的东西,位于服务器上,没有做太多事情......

要获得贡献者,你首先需要用户,然后你需要一些不完整性。您需要触发“这很酷,但我真的希望它具有这种方式或以这种方式有所不同。”如果您缺少一个明显的功能,那么用户很可能会成为添加它的贡献者。

最重要的是节目要好。如果它不好,没有人会使用它。你不能指望先有鸡还是先有蛋的情况会逆转,人们会认为这是理所当然的,直到它变得更好。

当然,“好”仅仅意味着“对很多人来说比任何其他实用选择更好”,并不意味着它严格来说是最好的,只是它具有一些功能,使其对许多人来说比其他选择更好。其他选项。有时节目 其他地方没有同等的情况,在这种情况下几乎没有这方面的要求。

当一个程序好时,人们就会使用它。显然,它必须在用户中拥有市场——一个好的程序,做了一些没人想做的事情,无论它设计得多么好,都不是真正的好程序。人们可能会在营销方面提出自己的观点,但真正好的产品,在某种程度上,都有自我营销的倾向。推广不好的东西要困难得多,所以显然,一个人的首要任务应该是产品本身,而不是推广产品。

那么真正的问题是——如何让它变得更好?答案是一支敬业、技术精湛的开发团队。一个人很难凭一己之力创造出一款好的产品;即使他们比其他开发人员好得多,多种观点对项目也有非常有用的影响。这就是为什么拥有公司赞助商如此有用——它让其他开发人员(来自公司)对问题的想法发表自己的意见。当开发程序需要社区中不常见的重要专业知识时,这尤其有用。

当然,我说的都是经验之谈。我是 x264(目前最活跃的)的主要开发人员之一,x264 是最流行的视频编码器之一。我们有两名主要开发人员、社区中贡献补丁的各种次要开发人员,以及来自 Joost(Gabriel Bouvigne,维护码率控制算法)和 Avail Media(我有时为他们工作,目前正在雇用合同编码员)的企业赞助。添加 MBAFF 隔行扫描支持),以及不时出现的其他一些内容。

一个优秀的开发人员并不能创造一个项目——而是许多优秀的开发人员才能创造一个项目。最终结果是一个比大多数商业竞争对手、硬件或软件,甚至是那些拥有巨大开发预算的竞争对手更快、质量更好的视频编码程序。

在查看这些问题时,您可能有兴趣查看在线版本 加州大学伯克利分校的开源课程, ,称为数字信息的开源开发和分发:技术、经济、社会和法律视角。该课程由米奇·卡普尔(Lotus 创始人)和法学院教授保拉·萨缪尔森共同教授。去年,我的通勤时间很长,我把课程的音频放在了我的 iPod 上——他们从非常广泛(尽管显然是学术性的)角度谈论了很多关于什么有效、什么无效以及原因的内容。

关于这个主题已经写了很多书。事实上,您可以在这里找到一本免费的书: 生产开源软件

确实,我认为答案是“如何运行该项目”。

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

比较和对比(历史不难追溯!)Perl 中 Class::DBI 和 DBIx::Class 的开发管理。

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

摘抄:

关于开源软件/自由软件(以下简称“OSS”)缺乏可用性的争论浪费了很多带宽。目前,博客、论坛和 Slashdot 评论线程中的争论仍在继续。有些人说,可用性不好是整个 OSS 世界的通病,而另一些人则说 OSS 可用性很好,但真正的问题是思想封闭的用户,他们希望每个程序都克隆微软。有些人认为 UI 问题只是暂时的成长烦恼,而另一些人则认为 OSS 开发模式系统性地产生了糟糕的 UI。有些人甚至认为 GPL 间接奖励了难以使用的软件!(郑重声明,我不同意。)

http:// humanized.com/weblog/2007/10/05/make_oss_ humane/

只需将其开源即可。最有可能的是,还没有人开始做出贡献。但至少你可以在新闻稿上写下你的产品是 GPL 或其他什么。

第一步是人们开始使用它......
也许在用户适应之后,他们就会开始做出贡献。

到目前为止,每个人的答案都很好,但缺少一件事,那就是良好的监督。没有什么比没有某种项目管理更快地杀死一个开源项目了。与其说是告诉人们要做什么,不如说是为您希望吸引的开发人员添加一些结构和任务。

无组织的项目很快就会崩溃。它不是一只鸟,你可以放开它,然后看着它飞走。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top