开源3d模型格式转换_将您的开源业务转换为基于收入的模型时应考虑的因素

开源3d模型格式转换

是否可以通过一组简单的正式语言转换规则将SQL作为一种语言集成并标准化到Java中？ 是的，它可以。

当总部位于瑞士苏黎世的开源公司启动名为jOOQ的新数据库抽象软件项目时， Data Geekery看到了这个想法。 作为创始人兼首席执行官 ，我从一 开始就感到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 许可 使用该产品 。 将我们的产品与商业数据库一起使用的客户可以根据商业许可来使用它。

优点是：

1. 不涉及copyleft。 我们喜欢ASL 2.0，而我们的客户也喜欢它。 我们不需要引入任何法律干扰。
2. 以前的贡献者签署了许可协议。 我们购买了所有商业代码，并且没有冒风险调查的风险，因为大约97％的代码库不会更改许可。
3. 我们的大多数客户理解并切实支持我们的计划，以继续支持他们！ 许多人认为将我们的许可成本与基础数据库的许可成本捆绑在一起对于这种开源业务模型是诚实和真实的。

我们看到了成功。 向双重许可的过渡成功了。 但是，对于我们而言，2013年仍然是艰难的一年。 从一开始我们就希望知道很多事情，因此，接下来我将分享jOOQ的经验教训，任何想将其开源业务过渡到基于收入的模型的人都应该知道。

翻译自: https://opensource.com/business/14/1/how-to-transition-open-source-to-revenue

开源3d模型格式转换