为什么没有一种为框架付费的文化？[关闭]

最近“精益”初创企业趋势和应用商店时代的副作用之一是，消费者更习惯于为小游戏/产品支付小价。

例如。：

• 每月收费约5美元的在线SAAS（产品的大本营风格）
• 短小，有趣且便宜的游戏（在App Store上的价格为0.99美元

这个市场的定义是“做好一件事情，并为此收费”。DHH of Rails / 37 Signals的名气认为，如果您的网站不赚钱，那就不要打扰。

为什么同一规则不适用于框架？

有许多软件框架项目-许多成熟且功能丰富的项目为开发人员提供了巨大的价值，但似乎并没有为此付出代价的市场或文化。

看来，收费的项目通常是UI组件工具集之类的东西，并且往往被边缘化以支持免费替代方案。

为什么是这样？

程序员/企业肯定会看到回馈给Ruby，Rails，Hibernate，Spring，Ant，Groovy，Gradle等项目的价值（列表还在继续）。

我并不是说这些框架应该对任何想使用它们的人开始收费，但是必须有一个有意义的商业模型，使开发人员从投资开发框架时就可以赚钱。

关于为什么这种模式没有出现/成功的任何想法？

编辑要明确：这不是关于淡化免费开放源代码软件重要性的文章。这是一篇有关询问为什么不存在为框架付费的文化的文章。

在自由/开源软件中绝对存在以价值换价值的伦理。

在大多数经济体中，我们以产品换钱或以服务换钱。这样做非常方便。确实，我们是在经济的商业软件部分这样做的。

但是，我们通常不以金钱换友谊或金钱换浪漫。我们以友谊换友谊，以浪漫换浪漫。

同样，在免费/开源软件中，道德原则是通过以下方式来报偿DHH和Rails的贡献者：报告错误，为其发布补丁，编写/更新/修复该文档的文档，以及对Ruby，Rails，Linux等进行宣传。自由/开源软件项目。这就是我们以价值换价值的方式。

询问为什么“这种模式[为框架付费]尚未出现/成功”类似于询问为什么在友谊或浪漫中却没有这种模式/成功。提供友谊的人不需要钱-他想要友谊作为回报。同样浪漫。同样，在许多情况下，软件也是如此。

我认为这个问题可以由这个问题的答案来回答。为什么程序员要编写封闭源代码的应用程序然后将其释放？。

我会补充一点：

我相信，通过免费提供框架，我们可以使初学者和爱好程序员对严肃的编程产生兴趣。这使他们的道路更容易。我们已经看到，并非免费的平台通常比采用的平台少采用。此外，自由框架通常是由一群希望为社区做出贡献的人们开发的。

它似乎总是归结为两种不同文化之一。有“我用金钱来购买软件”组和“我用时间来购买软件”组。

考虑组织中的IT。假设一家公司想要进行网络监控。它要么是A）关键任务，而且值得向（Openview，Netcool）注入大量资金。或B）预算紧张，请少花点功夫（Nagios，MRTG）。

同样，有些人已经对Microsoft / Apple处理软件的方式“长大”了。您付钱，东西应该起作用。您需要新功能，需要为此付费。另一方面，有些人已经习惯了按时付费。Unix，开放源代码，java等。如果需要更多功能，则可以自己编写或让某人为您修复。

考虑将苹果的应用商店推向Android市场。您可以在iPhone上购买《愤怒的小鸟》，但可以在Android上免费获得（带有广告）。不同的文化在起作用。《愤怒的小鸟》在应用商店上的收费非常低，只有0.99美分，但是他们知道，即使对Android Market收取0.25的费用，其市场份额也很小。

我认为框架是从后者开始的，因此目前是这样。您不能推销奶奶可以使用的成品框架，必须有人花时间使它成为易耗品。习惯于花时间的人不习惯花时间和金钱。

程序员/企业肯定会看到回馈给Ruby，Rails，Hibernate，Spring，Ant，Groovy，Gradle等项目的价值（列表还在继续）。

从我与客户和雇主的经验中，我注意到了几个充分利用开源软件（并通过使用开源软件赚钱或省很多钱）的企业没有尽其所能回馈的原因：

• 不了解开放源代码模型的工作原理，因此对为保持项目强大而需要捐赠的认识不足

• 通常缺乏清晰度捐赠会发生什么

• 税收问题，可抵扣性不确定

• 技术人员难以在开明的管理/控制（“如果我们不必为此付费，为什么我们应该给他们钱呢？ ？我们没有预算。也许是明年“）

我倾向于认为在任何开源项目中都可以在一定程度上解决所有这些问题，但是由于缺乏如何更清晰地沟通的专业知识，而且由于不愿向企业提出更高的要求，所以大多数情况下都无法解决道路。

我喜欢开源社区的“没有钱，没有官僚机构，没有义务”的精神，但我有时会想-如果每个使用OpenOffice而不是200美元MS Office工作场所许可证的企业都向OOo捐赠2美元，或者其他一些开源项目？

使用开源软件的主要风险是没有官方支持。基本上，您拥有代码。虽然起初使用“免费”软件似乎更有利可图，但您必须考虑内部维护成本最终可能超过专有解决方案成本的可能性。一些组织不愿意冒险。

问题的一部分似乎是将框架与为应用程序付费（例如趣味游戏，37种信号产品，在线SAAS）进行比较，但这些都是苹果和橘子。消费者购买应用程序，而开发人员使用框架为消费者构建应用程序。并且可以肯定的是，如果开发人员是用户并购买了应用程序，而他们不是在框架上进行开发，那么您的开发人员可能就是消费者。

在将框架转变为可以出售的应用程序之前，它们什么也没做。

但是，如果我们只是比较开发人员工具，例如框架vs组件集vs RAD套件等，那么我认为关于哪些东西是付费的还是不付费的，有一些很好的讨论。

让我们想象一下，我创建了一个名为“ AwesomeWork”的框架（原始吧？）。现在人们从未使用过它，并且不确定它是否对他们有帮助，并且不想为可能不会给他们带来一点好处（如果他们甚至喜欢它）的东西付钱，所以我免费发布了它。现在，我是不是因为潜在的利润损失而傻瓜，因为我也许能够以5美元的许可价格出售它？不会，因为随着人们的了解，人们开始使用我的框架，现在有一个二级市场正在开放：书籍。我现在可以写一本有关AwesomeWork的书（我们称它为“做[Awesome] Work Son！”，很抱歉必须这样做）。因此，该书的销售情况一直稳定，现在，我决定对AwesomeWork进行一些更新，并在AwesomeWork 2.0下发布它，然后看得出我可以出售“ Do [Awesome] Work Son！

我并不是说上述情况是有人免费发布其框架的主要原因，但这确实表明他们仍然可以从中赚钱。

旁注： 有一些框架负责（尽管它们可能免费提供社区版，但功能有限）。想到的一个是WebSharper，它使网站可以完全用F＃编写。