​If you look for the official definition of open source, you’ll likely stumble upon this outline from the board members of the Open Source Initiative. If you skim through it, you’re sure to find some idea or concept that you feel very aligned with. At its heart, openness (and open source) is about free distribution—putting your work out there for others to use.

It’s really about helping others and giving back.

​When we started to think about open source and how we could implement it at Buffer, the fit seemed not only natural, but crucial to how we operate. In fact, it seemed that in a lot of ways we’d be doing ourselves a disservice if we didn’t start to look more seriously at it.

But what I didn’t quite realize at the time were all the effects that open source would have on me.

Open source has positively impacted me as a developer, as an employee at Buffer, and even as a person. Those are the things I’d love to share with you here—to show you how we stumbled upon open source at Buffer.

Acting on your values

​At Buffer, we’re known just as much for the way we operate as much as our product. We believe that making your values and culture wildly transparent gives you an extra sense of responsibility to act on them. As someone who works at Buffer, I often wonder how I can be a good steward of what we’re all about. How can I promote our ideas, failures, successes and experience in a way that helps other people?

​As a company, we value transparency and put a premium on it. We think it helps us operate, and we hope that other people can look at our data and derive real, lasting value from it. That’s why you can find all of our salaries in a public Google Docs spreadsheet, open up a Trello board and see our product roadmap, or even go to a realtime dashboard showing all of our revenues.

​After thinking about this one day, I came to realize that I wasn’t fully taking advantage of perhaps the biggest opportunity Buffer was affording me to give back: our own code. I spend hours every day writing it, testing it, and thinking about it to make sure the work I do solves real problems for people, and generally makes their life easier or better.

​So why wasn’t I sharing it?

From the top down

​I think values like this tend to flow from the top of organizations. Sharing the code you write daily for a company might be difficult if that company didn’t feel the same way about the code! To that end, our CEO Joel Gascoigne seemed to sense this opportunity, and was also passionate about it. I remember reading an email thread he started a month or two ago, where he raised some strong points in favor of using open source at Buffer.

​Here is some of what Joel had mentioned:

“I’d love to share something that’s been on my mind for several years at Buffer. As you all know, one of our values is to Show Gratitude. Since the very beginning, we’ve been super fortunate to be building Buffer in a time where open source is a big part of the world of software development.

There’s no way that we’d be as big as we are today without open source. In fact, we probably wouldn’t even be here at all. The internet is very much built on the generosity of those who lead and contribute to open source. We are quite literally standing on the shoulders of giants, and in many ways, what we’ve done ourselves is minute in comparison to the incredible technologies we’re lucky enough to rely on and make use of.

I believe that contributing more towards open source as a company is a key part of our future, and almost a duty we have. With our value of transparency, I think it’s something people likely expect and should expect from us.”

​Once I read that, I felt reaffirmed. Getting involved with the open source community felt exactly like the right thing to do for Buffer.

Buffer’s CTO Sunil Sadasivan is also a passionate open source champion. Sunil has the best “big picture” of engineering at Buffer, and was quick to help us get open source initiatives moving at Buffer.

Recognizing the power of open source, Sunil helped us facilitate many important things—from a Slack channel specifically for open discussions, to an open calendar for suggestions, and a habit of leaving comments on our open source documents. Sunil was on board and helping us push forward.

​When the CTO takes time to provide a larger vision for open thinking in a company, developers like me can more easily act on it. It’s a symbiotic relationship, and it takes several of us to execute on the vision we have for open source. And seeing our leadership promoting our open source efforts really was amazing.

Committing to open source was a gut check for all of us. We knew we could be doing better here! Our values tend to promote personal growth, gratitude, and openness. By the same token, the open source community also advocates a lot of the same ideas.

​It felt like a perfect fit for our workplace and culture.

Personal growth

​At that point, I started to think about how I could help. With so much code and opportunity, I realized the challenge really lied within finding the right things to share. I came to the realization that, first and foremost, open source code should help someone. So what is most helpful?​

We could, of course, open source the entirety of Buffer. That would certainly hold true to our values, but it also may not be the most beneficial move for the community. It seemed like the right choice to get started with the open source movement at Buffer would be to release some focused and individualized components.

​As an iOS developer at Buffer, I’m most familiar with our iOS codebase. It’s what I know best, so I started there. Around this time, I’d been working on a modular component to view images easily within our app. It was easy to use and solved a real problem that developers on the platform that developers often face. It felt like the perfect place to start.

​Eventually it was. But first, I experienced an open source reality check: This was code that I wrote, and I didn’t write it thinking that the world would one day examine it. Imposter syndrome and doubt quickly crept in. I started asking myself:

• ​What if this isn’t any good?
• What if there are some mistakes?
• What if people think I didn’t write the best parts (it was based on an existing open source project)
• What if I missed important shortcuts, like using the right APIs?

​In only a matter of hours, I experienced some important growth as an engineer. And that growth stemmed directly from two things:

• ​Working at a company who believed in us to share our code, and that it was the right thing to do
• Open sourcing that code to the world

Sometimes, developing with only your team is easiest. They know you, and they are likely quite familiar with your coding tendencies. There’s much comfort there (as well there should be). Contrast that with coding for potentially thousands of people, and your mental state can quickly change from comfort to doubt.

​I think this experience is an important one for software engineers to encounter. It made me realize that I had an incredible learning opportunity in front of me. As the old adage goes: “Nobody bats 1.000.” There were bound to be mistakes or rough edges, and that was completely okay. So, I shared the code.

Showing gratitude

​That experience directly correlates with the second benefit I derived from open thinking: gratitude. When I posted the open source project I previously mentioned, community reception was very positive. Other developers mentioned some tweaks, made some edits to our readme file—and most of all, they were just thankful we released it!

​This was such an important reminder of how much developing is a community driven task. No single developer has all the answers. There are experts, but I’ve constantly seen those experts point to the fact that the community helped them get where they are.

​Open source helps other developers work and accomplish great things, but inherently it’s also an act of knowledge transfer. I remember when Apple made Swift open source. It was an exciting day for me. I was elated to look through Apple’s code and learn from the industry experts on the language. I picked things up that I may not have otherwise, and learned a lot of what best practices were.

​In short, I was very grateful for that!

Beginning a journey

With open source at Buffer, we are very much in our infancy. We’re still asking some questions to help put us on the right path, things like “What is the most helpful code to open source?” “How do we tell people about it?” and “How do we develop with an open source mindset?”

​Throughout the process, though, we’ve constantly been reminded that the internet is actually a very sharing and generous place. As Joel said, we are only where we are today at Buffer because of the brilliant code of other developers who were kind enough to share their hard work with the world. And what an amazing bar they’ve set.

All I can think about is how I want us to be like that. We want to learn from those people who are doing it so much better than us, and we’ll strive to hit that high bar. We want to give back and help solve problems, too. We want to save other people time. We want to share all of our work in the open.

That’s what lead us to open source, and it’s already had an incredible impact on the way we think about work and culture. I’m excited to see where it takes us next.