In the previous instalment of “Passbolt Lore,” we delved into the genesis of the technical platform, tracing back to the problems that led Kevin to embark on the journey to create what we now know as passbolt. If you missed it, be sure to catch up!
In this instalment, we’re diving into the evolution of passbolt as a product and company. Let’s take a look at how it transformed with the first public launch, establishing the commercial entity, and some of the technical details around passbolt.
From Prototype To Project
In 2011, passbolt, which didn’t have a name back then, was available as a prototype and has been used every day in Kevin’s web agency. As initially anticipated, it quickly found internal adoption among the staff since it was improving everyone’s productivity and collaboration around passwords.
We were so happy with the tool we had developed that we began opening it to some of our customers and partners around the agency, so that we could also collaborate with them and allow them to share their passwords with us within the same tool, which later became passbolt. To our surprise, we quickly realised that we were not the only ones struggling with our password collaboration problems and looking for a solution to replace a static KeeP file to a more collaborative and flexible solution.
People were actually so enthusiastic about the tool we had built that they began to speak about it to other agencies and before we knew it we were receiving emails from these agencies in other countries, enquiring about it and asking whether we could share it with them, which we did.
Following these encouraging early signs of traction, Kevin began to get convinced that passbolt could become much more than an inside tool and be a separate project. But for this, given the ambition of the project (a password manager that matches the privacy and security standards of businesses), it would be necessary to first build a core team with complementary skills in development, product and cybersecurity.
Forming The Founding Team
Fate has a way of bringing the right people together at the right moment. Kevin met a few weeks later with Cedric in Europe, a childhood friend, former business partner and cybersecurity practitioner. As you can imagine, he got pitched the idea soon enough and was convinced of the potential which is why immediately decided to leave his current job and join the project.
The trio was completed shortly after, when Remy (Passbolt CTO), Kevin’s former university classmate, university friend and also former business partner, came to New Delhi to visit Kevin. Sharing a similar vision of the open source and cybersecurity space, he didn’t take long to buy in. Having a strong background in software development, complex project management and infrastructures, Remy could bring a strong technical expertise to the security aspects of the project.
Setting up
The trio decided to set up an office in a place where they could find deep focus to work on the project. India was chosen for multiple reasons: Kevin had a base there, cost of life was cheap which would allow the team to sustain for a long time if needed, and the country provides an incredible pool of engineers which would be much needed to scale the team if needed.
Furthermore, the weather is great, the food is amazing and the people are quite welcoming. In India, the team decided to establish their office in Goa: a little paradise along the west coast and a perfect place to focus on building a new project.
Passbolt’s Rebirth: A Complete Rewrite
Now settled in their own office, the team went back to the whiteboard to define the next steps.
The first version of passbolt wasn’t bad in terms of usability and productivity. However, there was definitely room for improvement on the security and architecture front.
This is why the first thing which was discussed was improving the security model. The first version supported AES symmetric encryption using a single master password for all users – a setup that was far from optimal. Plus, the JavaScript layer relied heavily on jQuery and the encryption libraries were transmitted from the server, exposing it to a range of potential attacks including MTM and script injection.
The vision for passbolt was to build a password manager designed specifically for the needs of businesses and not for individual users so we opted for a security model and architecture that would reflect this. If you design a password manager for individual users, there are a few necessary security trade-offs that need to be done which we didn’t want in passbolt.
This drove us to make what we consider today to be our very first mistake, and a very classic one: instead of improving what was already built and working, we decided to start again from scratch, rebuild the UI, security model, front-end and back-end all at the same time, and as one would expect, this delayed the first public release of the project quite a bit.
Transforming The UI
In its initial version, passbolt’s UI might have seemed excessively intricate, lacking cohesion among its components. The blueprint for the new UI called for consistency – simplicity, intuitiveness, and above all, security. The first versions of the wireframe were made using Google Doc and we later moved to Figma.
If you compare the two UI versions, you’ll realise that despite the addition of the final colour scheme and some components organisation, the overall structure remains more or less the same.
The Core Components
After the comprehensive overhaul of both design and code, passbolt consisted of three primary Git repositories: the passbolt API, a style guide and a browser extension. The passbolt API repository, crafted with CakePHP, houses the logic and data foundation.
CakePHP was selected for its stability (compared to the other frameworks available back then) and we initially selected JMVC (now CanJS) for the front-end part, a jQuery based javascript framework. At that time, JMVC and Angular were equally popular and the choice of JMVC seemed the right one since it was following a MVC architecture which was already there in CakePHP. Unfortunately, JMVC didn’t develop as fast as the other ones and also didn’t provide the same simplicity of use (at that time), which is why we decided later to go through another complete rewrite of our front-end to migrate it from JMVC to React. History a part, thanks to the CanJS team for their framework that supports the early versions of passbolt ❤️.
The browser extension
A central part of our newly designed security architecture was to have a mandatory browser extension which would contain most of the front-end logic after we realised that it was the only way to provide a true end-to-end encryption architecture. Indeed, we wanted to isolate completely the encryption libraries from the server so that in case the server would get compromised, the crypto layer would stay intact. Additionally, we wanted users to have unique and randomly generated encryption keys which could only be stored securely and with the right level of persistence, in a browser extension.
For this browser extension, knowing that back then the two main browsers were Google Chrome and Mozilla Firefox and that they were using different technologies for their browser extension, we decided to develop the Mozilla Firefox extension first. This decision was made thinking that, being an open-source project, it would make sense to first build an extension for an open-source browser and that the community would naturally embrace this choice, which would turn into adoption. Plot twist: we were completely wrong. As the world turned mainly towards using Chrome which we didn’t have an extension for, our adoption growth suffered - and worse, many users complained that they could not use passbolt on their favourite browser.
Why A Complete Rewrite Was An Advantageous Mistake
This pursuit of strengthening the foundations and enhancing security prior to releasing passbolt to the public was commendable, we can now admit – deciding to rewrite everything was a mistake. Any startup founder knows time-to-market is crucial and launching in a timely manner is important. The initial timeline for the rewrite was six months, but the reality of juggling passbolt alongside other commitments made it more like four years. Why do we think that this decision to rewrite a mistake? Because time-to-market is critical for any startup. In those four years of refactoring, we could have been cultivating a thriving community around an existing, tangible project that offered real value. This period could have been a time to gather feedback and insights while keeping the momentum of product development.
On a positive note, the four years spent rewriting was an investment that made passbolt what it is today: a collaborative password manager with very strong technical foundations. It gave ample time to iterate and refine the security model, one of the reasons why passbolt is praised today.
Releasing v1.0: Taking It Public
Jumping ahead to the year 2016, we have a version of passbolt we’re proud of and that is ripe for public launch. The launch strategy was deliberate – an introduction to a modest open-source community to gather initial feedback before a wider outreach. Drawing from our founders’ French roots, we chose LinuxFR as the community for passbolt’s initial launch.
As is often the case with open-source projects in their infancy, early feedback was not overly positive. Luckily, it didn’t last and the tides quickly shifted, as the negative minority made way for a larger, satisfied majority of users.
Monitoring early traction
After 4 long years of development, we had decided that without clear signs of traction after launch we would not continue working on passbolt. It was a make it or break it moment.
To monitor adoption we had decided early on that our north star metric would be the quantity of active users rather than github stars. The reason is that from our perception GitHub stars can be a good way to monitor traction for projects that focus on developers or end-users, but not necessarily businesses, since businesses appeal by default to a smaller community which also tends to be less vocal. On another hand, active users provide an unbiased view of the adoption rate and the user base growth on a weekly basis (WAU: Weekly Active Users).
Monitoring active users is often complicated for open-source projects since it involves implementing telemetry which can be a source of friction between the project and the community (for the right reasons, nobody wants unnecessary tracking). Luckily in our case, since the passbolt architecture was built around a mandatory browser extension, we would get the quantity of weekly active users provided by the browsers market places.
At that point, we only had one browser extension for Mozilla Firefox, which is where we were monitoring our WAU closely. Luckily, the number of WAU grew rather quickly, starting with a few hundred, soon followed by a few thousand.
This surge in users confirmed our decision to pursue the passbolt endeavour and seek out ways to grow it further. It’s worth mentioning that, during this stage, passbolt remained a passion project. We were still doing consulting work to fund our time dedicated to the development of passbolt.
In order to be able to continue the development and devote more time we had to find a more financially scalable solution, something we’ll cover in the part 3 of this article series.
Lessons Learned
Stay lean: start small and iterate
Building a project is hard, and the bigger the scope the harder. In the case of passbolt, deciding to rebuild the project from scratch with a larger scope while we already had a first working prototype nearly killed the project. We were close to giving up a few times. Maintaining motivation over the course of a long period, in our case four years, is hard without small victories along the way. On top of that, launching early allows to grow from the beginning a community, a reputation and a sense of trust - something that takes years to do and that is very often the fuel of open-source project adoption.
3 is a magic number
We have learnt along the way that being three co-founders is great. Think about it this way: at 2 co-founders, in case of disagreement, it’s only you against your co-founder. If both have strong opinions and make a good argument it can become complicated to move forward. However at 3 the dynamic is completely different since in case of disagreement it usually becomes 2 against 1 which creates a de facto majority and simplifies the decision making.
Building an open-source startup is hard and there are almost every day tough decisions that need to be taken where opinions can differ. Being three naturally helped us make decisions in a democratic way while keeping egos aside.
Pick your North Star Metric early
Without a North Star, you can’t navigate. At passbolt we were fortunate enough to pick the right North Star metric early on, something that greatly helped us define whether we were on the right trajectory and make decisions accordingly.
