May we suggest...


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 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:

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?
  • Junted

    How easy would it be for you technically to initially decouple the frameworks you used for security and open source just the engine?
    That would be a nice initial step to get feedback, without compromising the algorithms that you use and the way you store keys.

    • Heya Junted,

      good question. Right now we are in fact in the process of doing that. We had a big monolith codebase which contained all our code. We started last year breaking these apart and building them out as microservices. I’m pretty sure we can eventually open source all those non-critical pieces once they’re stable.

      Decoupling all this is real win-win for a distributed team as we can assign more granular ownership on separate functions of our app. Some recent examples are our scraper for the composer & also a service for resizing images for all networks so they fit correctly.

      And now we can potentially open source it too :)

  • Paul Tucker

    As someone who loves transparency and has been incredibly inspired by Buffer’s intentionality in it, I have one question:

    How does Buffer balance the goal of transparency against protecting the unique nature of their product/service – and the jobs that depend on it? By sharing elements of the product backbone, is there a risk that the Buffer service could be reverse engineered or perhaps lose its competitive edge? If Buffer lost that market niche by over-sharing (albeit so kindly and generously), could it jeopardize the jobs of the amazing people who have worked to create the product and share it?

    OK, so I guess that was way more than one question. :) I’m genuinely interested in your thoughts! I’m pondering through a similar situation regarding the balance between community transparency and protecting the security of our of team’s roles by guarding “trade secrets.”

    • Heya Paul,

      thanks for the great questions. With products like Buffer, and my hunch is with most products, the competitive edge is not so much in the actual code or artifacts itself. In fact there’s been an open source implementation of Buffer for many years now:

      The competitive edge comes from executing well through building great teams/culture and hiring amazing people. It’s the company that can adapt to a changing environment, within the company and outside the company. These are the ones that will last. For a product like Buffer, we also strive to provide something that’s intangible: amazing customer experience. I’m so proud of our Happiness team and this adds immense value to Buffer. We can share those practices and other companies could potentially recreate it, but in the end it’s that magic sauce that’s a combination of all the ingredients combined that makes Buffer special.

      In the end, I’m pretty sure some Buffer competitors have looked at our numbers we share and used that to adjust their own strategies or inform themselves to make decisions. My gut tells me though that the potential loss from a competitive aspect we face here is far less than the value we provide back to the community through being transparent. :)

      Hope that answered your questions :) Thanks again for asking that!

      • Paul Tucker

        Such a great response! I asked a question and got an additional, thought-provoking blog post out of it! Thanks for making the time to craft such a thoughtful response. :)

        Super helpful. That definitely helped explain some of the deeper rational and process behind it all. Thanks again, Niel!

  • There’s a difference between “Open Source” and “Free (Libre) Software”.

    I am working on an open source but non-free project myself, so I get the benefit of open (paid & unpaid) contributions, without the cost associated with somebody cloning what you’re doing and making money for themselves.

    Over time, I’ll extract generic components from this project and be left with a pure core that is nothing other than the domain logic & content itself.

    I hypothesise that such decoupling would be easier to achieve by being open because of fewer abstractions between users and development: your users can be your developers.

    I find it particularly painful when I want to use a service, it doesn’t support a particular piece of functionality, and I have no other choice than simply wait for the feature to come out or be fixed – so I give up. I would not even mind implementing the feature myself, for free. For me this is superior to doing my own thing because I would not be the one maintaining the servers and deployments since that’s the service’s responsibility. I care about achieving my goal, NOT whether someone is profiting off my work – unless profit is my goal.
    This is going into serverless if you see what I mean :-)

  • Joseph Winston

    With the launch of the Galaxy S7 and the S7 edge, people have already started to look forward to the next flagship launch from Samsung, the Galaxy S8. But if rumors are to be believed, work has already started for the next installment of the Galaxy S series, the Galaxy S9. If you want to know more about the device, then you must check out my site Samsung Galaxy S9

  • Get out from all rumors and get exact details about Samsung Galaxy S9

  • Larisa Bejaran

    The Google Pixel 2 XL will have an “LG-made AMOLED display 6 [inch] across at a 2:1 aspect ratio with minimal bezel and rounded corners. Google Pixel 2 Specs

  • Melissa Strawn

    We have been considering going full open source as a company as well to move away from a competitive economy and toward a more collaborative economy. Thanks for highlighting some of the security risks associated with that. I am curious to know how you overcome the security risks with each new code base you decide to open? Do you have someone else take a look? Thanks.

80,000+ social media marketers trust Buffer

See all case studies