闭源优于开源的七个理由,或者看起来是这样

还没有读者喜欢这篇文章。
Business as usual is a dead end

Opensource.com

作为一家专注于帮助他人通过开源获得成功的公司 OpenLogic 的创始人,我说这话可能显得很奇怪,但事实是,在某些情况下,闭源确实优于开源。

作者:Rod Cope,OpenLogic 创始人

使用闭源……

1. 当出现问题时,你永远不必修复组件。

任何软件都难免偶尔出错。 当开源软件出现问题时,你或者欠你人情的技术人员可能需要花时间调试问题。这需要阅读代码,与开源社区或你的开源支持提供商合作,并应用修复程序。另一方面,对于闭源软件,一旦你确定问题出在供应商的代码中,你就没事了!你所要做的就是提交工单并等待。当然,你可能需要等待几个月甚至几年才能获得修复,有时甚至永远不会到来,但你对此无能为力!只需放松一下,坐等好消息吧。

2. 你不必担心将你的更改贡献回社区。

对于开源软件,人们期望如果你修复了一个错误或进行了改进,你会将你的代码贡献回社区,以便社区可以帮助测试和长期维护它。对于闭源软件,你永远不必向任何人贡献任何东西。当然,那是因为你无法更改代码,因为你无权访问它,但你可以为遇到的问题创建自己的变通方案。当然,你可能不得不一次又一次地解决相同的问题,但至少你永远不必与社区合作,为他人改进解决方案。

3. 你不必考虑开源许可条款和合规性问题。

使用开源软件,你必须遵守你使用的组件指定的许可条款。理解 Apache 软件许可证与通用公共许可证 (GPL) 的条款可能需要一些时间。例如,根据你使用的开源组件以及你如何使用它们(例如,分发给第三方或仅供内部使用),可能会适用不同的许可条款(例如,在你的文档中注明开源组件的来源)。像 OpenLogic 这样的公司使理解和遵守开源许可条款变得容易,但是使用闭源软件,你无需担心任何这些!你的供应商的许可协议剥夺了你对软件的所有权利,并使考虑任何未经你的公司律师明确批准的用法几乎不可能,因此你甚至不必考虑它。当然,你必须处理许可证计数、突击软件合规性审计、随着时间推移而恶化的条款以及几乎难以理解的法律术语,但至少你不必理解你如何使用开源组件。

4. 你不必在每个组件的数十种选项中进行选择。

在考虑数据库、Web 服务器、应用程序服务器、编程语言、GUI 框架等方面时,开源提供了许多解决方案。实际上,在每个类别中,你都可以找到使用各种语言和不同架构方法构建的强大产品。也很常见的是找到针对不同用例优化的类似工具(例如,性能与可伸缩性与简单性)。为了确保工具最适合你的特定用例,请下载并试用它。使用闭源软件,你无需应对如此多的选择。你只需要探索每个市场中的两到三家大型供应商。如果供应商不提供免费试用,或者通过强迫你付费试用或预先签署试用协议来使入门变得困难,则可以节省时间。

5. 你不必到处寻找幻灯片。

为任何软件查找会议演示文稿、架构图、屏幕截图和其他文档可能需要一些时间,但是使用开源软件,你可能需要阅读 Wiki、论坛和电子邮件列表,才能获得你需要的关于特定组件的信息。使用闭源软件,你只需拨打电话,就能在舒适的办公室里获得穿着漂亮西装的专业销售人员提供的精美 PowerPoint 演示文稿。当然,你必须预先提供你的联系信息,并且销售人员会不停地给你打电话,但至少你不必在网上搜索带有精美图形的精美幻灯片。

6. 你不必到处寻找技术支持。

你可以从社区、你自己的工程师或专业的开源支持组织获得开源支持。决定你是否想要像从 OpenLogic 获得的那样具有保证响应时间的服务级别协议 (SLA) 支持,或者你是否觉得可以放心地将问题发布到邮件列表或自己提供支持,可能需要一些时间。使用闭源软件,你永远不必担心在哪里获得支持。当然,你可能永远无法与真正的工程师交谈,但至少你始终知道该给谁打电话。

7. 你可以直接放弃。

使用开源软件,总有办法修复、修补、改进、增强、重构、升级或重写某些东西。没有像闭源软件那样容易放弃的方式。当然,你可以诅咒开发给你带来问题的开源组件的社区,但你通常可以解决问题、从社区或支持组织获得帮助,甚至自己修复问题。但这远不如诅咒商业供应商并一了百了那样令人满意。

所以,这就是你看到的。闭源优于开源的七个充分理由。你还有其他想要分享的理由吗?

最初发布在 OpenLogic Enterprise OSS 博客上。根据 Creative Commons 重新发布。

标签
User profile image.
OpenLogic 是一家企业级工具和解决方案提供商,致力于消除有效软件开发和部署的障碍。

5 条评论

再补充几个 -

8. 我似乎无法用完我的信用卡额度

9. 我有一个光驱并且想使用它

我是高科技领域的新手,但我会通过这些信息丰富的文章快速学习。

谢谢。

不确定从哪里开始说起,但所有七点都是错误的,在许多情况下是大错特错。分享我在这个主题上的经验很快就会变成一篇和文章本身一样长的帖子,因此不太适合在这里作为评论。

然而,一般来说,闭源在许多情况下也需要甚至有必要参与,甚至包括代码贡献。仅意识到这一事实就足以否定第 1、2、3 和 7 点的大部分内容。没有选择,第 4 点,对于少数垄断企业(通常是操作系统和 Office)可能是正确的,对于任何其他软件类别,你同样难以将闭源组件与许多选项组合在一起。对于第 5 和 6 点,很明显作者几乎没有经验。寻找技术支持是不同的,但对于闭源软件而言,绝非更容易或更省时。

[讽刺模式 / 开启]

闭源规则!!

[讽刺模式 / 关闭]

是的,有点讽刺!! ;-)

谢谢 Varun,你让我把咖啡从鼻子里喷了出来。

另外,我同意 Del 的看法。不知何故,作者似乎认为闭源意味着产品的成熟度、可用性和质量,以及卖家帮助我项目成功的承诺。

Creative Commons 署名 3.0 未本地化版本,CC BY 3.0
© . All rights reserved.