SQL 作为一种语言，可以通过一组简单的形式语言转换规则集成并标准化到 Java 中吗？ 是的，可以。
Data Geekery 看到这个想法获得了一些关注，当时这家位于瑞士苏黎世的开源公司启动了一个名为 jOOQ 的新数据库抽象软件项目。作为 创始人兼 CEO，我在一开始就觉得 jOOQ 旨在成为一个更宏大愿景的概念验证。我们根据 Apache Software License 2.0 的条款对其进行了许可，并且由于 这个宽松的许可，这个想法获得了一些关注。 jOOQ 成长为面向硬核 Java/SQL 用户的利基产品，到 2013 年每年下载量达到 25,000 次。
这种成功意味着客户依赖于一个核心软件，他们需要针对该软件获得支持、质量保证和担保。SQL 是 jOOQ 所有客户的最终用户应用程序的核心。因此，为了能够继续发展 jOOQ，我们需要开始创业。
我们不得不问自己
- 我们会继续以免费和开源的方式发布 jOOQ 吗？
- 我们是否需要关闭源代码并切换到商业软件？
- 我们可以保持源代码可用，但在商业许可下吗？ 这合法吗？
- 我们现有的客户会接受还是拒绝如此重大的改变？
诚然，许多公司都经历了从闭源到开源的转变，从商业到免费。对于这些公司的客户来说，这种改变是显而易见的，而且显然不会成为问题，因为他们现在可以免费获得以前付费购买的产品。 另一方面，我们正在考虑向客户收取他们以前免费获得的产品的费用。
最终，我们选择了双重许可。 原因如下。
首先，我们坚信我们的利基产品已经成熟到我们无法继续免费提供它并保持质量和增长的地步。
我们考虑过仅基于支持的盈利模式，但在 我们看来，基于支持的盈利模式最适合所有引发“开发运维工作”的产品。 服务器、操作系统、数据库。任何可能因数百种原因崩溃的东西。当它崩溃时，需要专业人员来修复它。
我们的软件是中间件。它很容易理解，它并没有远远超出 SQL 语言建模的范围。“复杂性”位于我们产品“之下”（在数据库中），或“之上”（在 Java 应用程序中）。我们的产品在开发时通过为客户的开发人员在编写 SQL 时提供类型安全、减少错误倾向和提高生产力来增加最大价值。很像 Eclipse、Netbeans 和 IntelliJ（后者是商业许可的）。
从我们的角度来看，商业许可将使我们能够从业务中获利，但我们感到矛盾，因为开源使我们能够
- 更快地成长：我们非常感谢那些热情的早期采用者，他们帮助我们生产出优秀的产品并 достичь 今天的高度
- 更多展示：通过公开我们的源代码，我们可以向所有人展示我们产品的质量
- 更好地工作：专有软件公司必须为 GitHub、Maven 等服务付费。
我们与许多客户、朋友和竞争对手讨论了他们在为软件选择双重许可时的感受。我们还记住了 Sencha 的 ExtJS 发生的事件。对话围绕我们的一些考虑因素展开，例如流行的 AGPL 和 LGPL 许可证。 我们的许多客户认为我们应该投资于新的企业功能，这些功能仅对商业许可证持有者可用，但 jOOQ 已经成熟，并且需要数月甚至数年的时间，我们才能基于“基本版本”和“企业版本”获得任何收入。 其他客户建议我们构建更多的开发工具，例如编辑器、IDE 集成和分析器。虽然我们同意我们最终想要构建这些工具，但我们认为现在产品已经准备好进行更改，而不是以后。
我们的解决方案最终非常简单。我们只是从开源版本的交付件中删除了 DB2/Oracle/SQLServer/Sybase 特定的代码。 使用开源数据库的客户可以在上述开源 ASL 2.0 许可证下访问我们的产品。 使用商业数据库的客户可以在商业许可下访问我们的产品。
优势在于
- 不涉及著作权限制。我们喜欢 ASL 2.0，我们的客户也喜欢它。我们不需要引入任何法律上的混乱。
- 之前的贡献者签署了许可协议。我们购买了所有商业代码，并且没有面临尽职调查的风险，因为大约 97% 的代码库不会更改许可。
- 我们的大多数客户都理解并务实地支持我们继续支持他们的计划！ 许多人认为将我们的许可成本与底层数据库的许可成本联系起来是诚实且符合这种开源业务模式的。
我们看到了成功。向双重许可的过渡奏效了。但是，2013 年对我们来说仍然是艰难的一年。有很多事情我们希望从一开始就知道，所以接下来我将分享 jOOQ 吸取的教训，任何考虑将其开源业务转变为盈利模式的人都应该知道这些教训。
评论已关闭。