当 Daniel Pfeifer 去年在 Meeting C++ 的演讲中谈到依赖地狱何时冰封 中的依赖管理时，他说：“试着完成以下句子：Python 有 Pip，Ruby 有 Gem，Dart 有 Pub，C++ 有……”
不幸的是，我们无法继续完成这个句子，因为对于 C/C++ 项目来说，没有解决和跟踪依赖关系和版本兼容性的解决方案。而这正是 biicode 试图填补的空白。
当 biicode 大约两年前开始时，创始人以及投资者都承担了许多风险。我们的资助者仅凭一个简单的原型就投入了大量资金。我们的创始人 辞去了他们在著名大学中安全且高薪的职位。然而，机会是巨大的，因为大约有 400 万 C/C++ 开发人员，这两种语言加起来几乎占世界代码的 20%。此外，这些工具很容易成为标准。一旦某种编程语言中最流行和重用的库能够通过给定的依赖管理器轻松有效地处理，该工具自然而然地就会成为标准。
考虑到这些因素，我们向前迈进了……但决定保持代码私有。
竞争
从一开始我们就知道我们具有竞争优势：我们是一个基于文件的依赖管理器，因此当你可以指向你想要依赖的 特定文件 并获取它时，无需下载庞大的库或软件包。我们也知道，我们并非孤军奋战，试图为 C 和 C++ 社区提供依赖管理器。RYPPL 已经存在一段时间了，它不仅是一个开源项目，而且它的贡献者都是著名的开发人员。
老实说：我们嫉妒了。
我们一直欢迎竞争，并且我们认为拥有这样的竞争对手只会激励我们。然而，作为开源软件的倡导者和用户，我们知道社区的大部分人不仅会支持他们，还会为该项目做出贡献。但是，我们不断看到并注意到，几乎每天都有开源问题需要处理。不仅如此，我们工具的主要目的是用于 快速原型设计，并且我们坚信开源之道的支柱。
到夏天结束时，我们知道我们必须做什么：我们必须开源。
社区
那时，biicode 已经拥有一个支持性且不断增长的社区，并且我们已经登上了国际标准化组织（ISO）委员会的网站。我们是该领域的重要参与者！但是，当在我们的董事会会议上提出“开源”时，很快就明确并非所有人都意见一致。我们竭尽全力展示参与、构建和贡献开源社区的好处。我们最终与投资者达成协议，一旦注册用户达到 10,000 人，我们将发布 biicode 的代码，并欢迎社区对其进行维护和改进。
对某些人来说，这可能是一种特殊的开源方式，但也许你听说过类似的故事？
我们完全致力于此，并将其视为一项集体挑战。我们现在都是开源用户、倡导者和合作者。
有人说 C 和 C++ 是老派编程语言，所以我们选择达斯·维达++ 来代表我们；他可能很老派，但他具有持久的影响力！了解我们的全部内容，加入我们，也许可以为你的 代码贡献 赢得一件我们的“我是你父亲”T 恤。
5 条评论