当 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 条评论