New open source dependency manager on the scene

No readers like this yet.
Business as usual is a dead end

When Daniel Pfeifer gave a talk about dependency management in When dependency hell freezes over at Meeting C++ last year, he said: "Try to complete the following sentence: Python has Pip, Ruby has Gem, Dart has Pub, C++ has... "

Unfortunately, we cannot continue the sentence because there is no solution for resolving and keeping track of dependencies and version compatibilities for C/C++ projects. This is where biicode is trying to fill the gap.

When biicode began, almost two years ago, many risks were taken by both the founders and investors. Our funders invested a lot of money with just a simple prototype in their hands. Our founders quit their safe and well-paying job positions at prestigious universities. The opportunity was huge though, because there are approximately 4 million C/C++ developers, and both languages represent up to almost 20% of the world's code. Moreover, these tools easily become standardized. Once the most popular and reused libraries of a specific programming language are handled with ease and effectiveness by a given dependency manager, this tool naturally becomes the standard.

Given these factors, we moved forward... but decided to keep the code private.


We knew we had a competitive advantage from the beginning: we are a file-based dependency manager, so there's no need to download humongous libraries or packages when you can point to the specific file you want to depend on and get it. We knew too that we were not alone in trying to provide a dependency manager to the C and C++ communities. RYPPL had existed for a while already, and not only is it an open source project, but its contributors are renowned developers.

To be honest: we were jealous.

We have always welcomed competition, and we thought that having such rivals would only motivate us. However, as open source software advocates and users we knew most part of the community would not only be with them but also contribute to that project. But, we keep seeing and noticing that there wasn't a day that went by in which an open source issue wasn't dealt with. Not only that, but a main purpose of the our tool is for rapid prototyping, and we believe in the pillars of the open source way.

By the end of the summer we knew what we had to do: we had to go open source.


By that time, biicode had a supportive and growing community, and we had been featured on the International Organization for Standardization (ISO) committee's site. We were a relevant player in the sector! But, when "going open source" was brought up in our board meeting, it quickly became clear that everyone was not on the same page. It took the best of what we had to show the benefits of participating, building, and contributing to an open source community. We finally reached an agreement with the investors that said that once 10,000 users were signed up, we would release biicode’s code and welcome the community to its mantainement and improvement.

To some this may be a peculiar way to go open source, but maybe you know stories like it?

We are fully committed and have taken this on as a collective challenge. We are all open source users, advocates, and collaborators now.

biicode code contributor Tshirt, Darth Vadar++Some say that C and C++ are old-school programming languages, so we chose Darth Vader++ to represent us; he might be old-school but he has staying power! See what we're all about, join us, maybe win yourself one of our "I am your father" Tshirts for your code contributions.

Jordi Mon kissing a trophy.
Product Marketing Director @ Weaveworks ( Flux, Flagger and more projects donated and maintained at the CNCF. GitOps focus. OpenUK Ambassador. The UK organisation for the business of Open Technology, being the 3 Opens: open source software, open source hardware and open data, across the UK.



Thanks for the great article.

It is very exciting to see dependency tools for C/C++ emerging.
Thanks for sharing the rationale for embracing open source.

May the Force be with you!

Thank you Luis!! We really hope the community backs our project and we are able to move forward with them.

In reply to by Luis Ibanez

I'm completely unconvinced:

What do you do about namespace clashes ?

Ruby, Python, etc are lazy by design. C++ is not. If I need a library, I download it, and place it in my externals (3rd party, whatever). That way I have complete control. I certainly don't let a tool try to resolve my dependencies for me.

Totally respectful. To me that's a slow and inconvinient workflow. But the again, It's up you. I like my libs in the same space and my deps automatically managed.

In reply to by Smit-Tay (not verified)


You bring a good point, that is worth thinking about; but not an insurmountable obstacle.

We don't need to fully relinquish control to the dependency tool. Yet we could get valuable support so we don't need to deal with the trivial dependency cases (e.g. I need jpeg or boost).

Confronted with a namespace clash, a dependency tool could simply report it to you (the developer), so that you can apply your higher-level knowledge of the interplay between libraries and your code. Maybe then you would resolve the ambiguity by providing additional hints in configuration files.

I would already be happy with a tool that resolves 19 out of the 20 dependencies of my code, and that hints me to figure out a way to disambiguate the remaining one that can not be solved automatically.

In reply to by Smit-Tay (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.