A year ago, we open sourced our documentation, with the hypothesis that it would improve the docs by adding feedback loops and removing barriers that discourage contribution. We also wanted to share what we had learned during the process.
I’m glad to say that so far the results have been good, and the decision to open source our documentation continues to help us improve it as a product.
Where We Are Now
We’ve had 59 different contributors to the docs repo since we open sourced it, with around 15 of those contributors being community members rather than SendGrid employees. Considering we had only a couple contributors before, that’s about 30x growth in the number of contributors.
Makings things open and accessible has had a positive impact on the culture of documentation within SendGrid. People feel empowered to make changes. They start with the perspective that we encourage everyone, including our users, to submit edits and log issues. We’ve been able to take our “trust-first” culture and apply it to a bit of our software, and that’s awesome!
About 6 months ago we added travis-ci builds and set up a continuous deploy process. We were making updates and improvements faster than we could get them deployed. Since automating things, we’ve had 600+ builds and 100+ deploys to production, and the amount of lead time required from other departments when new docs or updates are needed has decreased dramatically. The lesson we learned is that we should’ve gotten continuous deploys working much sooner.
Last year when we made our announcement, I wrote the following:
“Sharing our code is another way to share documentation-related knowledge. The better all of the docs for all of the things are, the better off the developer community.”
I’m glad to say that we’ve seen some positive impact here as well. The best example is actually from this month, when codeship announced their new docs (which are great)! I saw this tweet and it made my whole day:
— Marko Locher (@mlocher) September 11, 2014
Even if nothing else had come from our decision to open source the docs, I would’ve felt like it was worth doing based on this alone.
I believe that documentation, especially developer-focused documentation, should be treated like software. With that in mind, I’m very happy to say that we’ve just hired our first Documentation Developer to join the Developer Relations team. It’s an interesting role that has a mix of process improvement, technical writing, and engineering involved. Having a person who is thinking about how we can improve our documentation full-time is going to be great, and I’m really excited to see what improvements the next year will bring.
And I’m glad you’ll be able to share the ride with us via GitHub.