Transparency in Engineering: Can We Open Source Our Whole Code Base?

As a company that already has all of their employees’ salaries online, we often get asked how far we will go with transparency. On the engineering team, this is challenging because we need to balance our value of transparency, with the security of our product and users, so the “how far” question is a tough one to answer.

At our recent Madrid retreat, we asked the question, can we open source our whole code base?

Open source means that we would make some (or in this case, all) of the code that our team has written to build the Buffer app available to the general public. They would be allowed to use and modify the code for their own purposes. Open source software generally evolves more quickly because more people have access to it, more on that later.

It’s a fascinating thought exercise and one that I’d love to explore here. It’s particularly thought-provoking because at Buffer we start out with the assumption that everything should be transparent unless there’s a good reason for it not to be. And, usually, there are lots of good reasons to not make things transparent, particularly when it comes to product security.

We’ve Started Asking “Why Not” When It Comes to Transparency

The question “Can open source our whole code base?” sparked a really good discussion. There was a lot of excitement to keep pushing for more transparency. We challenged engineers to think outside the box, not just in code, but also in how we could be more transparent as an engineering organization.

One source of inspiration that was top of mind was Gitlab, which recently blew us all away by live streaming their attempt to get their production data back in place.

Some ideas that came out the discussion:

• Opening our Github issues so everyone can see discussion on current bugs
• Posting regular reports/change logs
• Live streaming coding sessions

We’ve moved all of these ideas into our pipeline to explore. Naturally, though, the discussion led to code itself, which is something we work on every day.

Open sourcing code is an incredible way to share more with our community. We have amazing advocates on our team for that. Many of us have learned so much through other folks open sourcing their code. There’s a sense of gratitude among our team for that.

So when we asked about open sourcing our code, we were not asking “Why transparency?” but rather “Why not?”

And sometimes there are really valid reasons.

Building a Transparent and Open Company, Securely

One memory was still top of mind for some of us, and it remains a key reason to be very cautious with making more of our code and product transparent: Buffer was hacked in October 2013.

A hacker had gained access to two of our hosted services: MongoHQ (now Compose.io) and Github. The hacker could not do anything by having access itself but rather the danger was in having access to certain information contained within these services. We left certain keys/passwords unencrypted. We assumed no one would ever gain access. It was a very hard lesson to learn.

However, our code was not open to begin with. We thought we’d be safe, and we were wrong. Since then we’ve adopted the approach that even if someone gains access we should aim to be safe.

Even with the recent Cloudbleed hack we were extremely cautious. Our 2013 hack taught us that unlikely scenarios, no matter how rare, have the possibility to cause huge impacts. It was a Black Swan Event, “an event that comes as a surprise, has a major effect, and is often inappropriately rationalized after the fact with the benefit of hindsight.”

With the experience we gained, we know that even with the smallest of chances we should assume a malicious actor can exploit it.

And so the tradeoffs stands: even though we have taken big measures to improve our security, making our code base transparent could lead to unforeseen security risks.

We take all risks very seriously, no matter how small. Especially considering the trust that our amazing customers are putting into us.

We Are Open Sourcing More and More Code Every Day

As it happens, open source code is generally more secure than code that isn’t open. The more eyes you have on your code, the more vulnerabilities one can detect due to the diversity of all the input. It’s almost like an immune system that gets stronger through more exposure to the environment.

Our main hesitation is that it would take quite a few resources for us to become fully open source because we aren’t security experts, which itself is a big domain in computer science.

We have not disagreed to open source our whole code base; in fact, we are open sourcing more and more code every day. Here are some examples:

• Buffer UI Components – Our collection of React components used in production
• Micro RPC – Async RPC microservices made easy
• Chronos – JS library to interface with the browser timing API.
• Simple Bottom Navigation for Android
• iOS Image Viewer

We are heavily inspired by companies like Artsy and Gitlab that take an open source by default approach, but even they have good reasons to keep certain parts of their code base closed.

Challenging Assumptions: The Future of Transparency and Security

In a truly perfect world, one could be forthcoming with any information and not have that be used against you.

However, we do know that there are some bad people in this world who could cause harm with certain knowledge. That’s one of the reasons why privacy is still a strong part of our existing culture.

Bit by bit though, we should challenge our assumptions of what can be really be acted on or what is driven by irrational fear.

When we published our salaries online for the first time it was an interesting moment. We had questions on whether it would be harmful if people knew how much you earned. In the end, our fears weren’t at all realized and, in fact, we saw unexpected positive results: a big spike in our job applications and future accountability for equal pay.

Security is still tricky to balance with transparency.

We are excited to challenge our assumptions with the right care and mindfulness that they deserve. Trust is created through transparency, but if we lose it, then it would have been for naught.

Over to You

I’d love to hear your thoughts about transparency in engineering, and feel free to ask any questions about transparency in engineering in the comments!

• Do you have any experience with Open Source code at your company?
• What do you think about the balance between transparency and security?