Featured in this edition of Spotlight is Sam Saffron, co-founder of Civilized Discourse Construction Kit, Inc.—better known as Discourse.
Sam is the creator of Dapper and StackExchange's Data Explorer. He lives in Sydney. He likes SQL, writes about performance enhancements in Ruby and can be found hanging out with the community on Meta Discourse.
Q: What was your vision when you started working on Discourse?
Sam: We wanted to improve the landscape of open source community software. At the time, most of the community software (including closed source software) used ancient web practices. Innovation, if any, was happening in closed platforms such as Facebook.
Q: In the early days of Discourse, how did you find contributors? What were some things you could have done better?
Sam: Contributors was very rarely something that we sought-out. People heard about us and tended to simply send pull requests.
The ideal contributions we got over the years were people "scratching their own itch". They had a bug or feature that was impacting their usage of Discourse and submitted a change request to us.
We did tons of stuff right from the beginning, we always had Discourse Meta to discuss various proposed changes. We have always been very welcoming and adopted a code of conduct very early on.
The two things we could have done better in earlier days, that we have since completely rectified:
- Having one manageable space for bug reports and feature requests is very important. Initially we accepted bug reports either on Discourse Meta OR on GitHub. It became very difficult to manage over time. These days we only use Meta Discourse and it works excellently for us.
- Having clear rules and guidelines for contributors makes it significantly easier for contributors to pick up the project. For the first couple of years we did not have clear contribution guidelines. We now do have some great contribution guidelines here.
"The ideal contributions we got over the years were people "scratching their own itch". They had a bug or feature that was impacting their usage of Discourse and submitted a change request to us."
Q: How do you ensure quality—of the platform as well as the tests you run on it?
Sam: Testing is an enormous topic. From the very early days of Discourse we have been very focused on creating extensive test suites and following a practice of continuous testing and deployment. Discourse Meta is always running the last commit that passed our test suite.
6 years ago, I deployed a junk build to production and broke Discourse. I wrote about it in a blog post.
That's when we adopted a simple practice: If you break production, the only thing you are allowed to work on should be the system that stops that kind of break in future.
We also treat our testing code as a first class citizen and ensure we regularly prune out flakiness of our test suite. I talk about this in more detail in this post.
"We treat our testing code as a first class citizen and we regularly prune out flakiness of our test suite."
Q: What were some obstacles you faced while moving to the managed-hosting-as-a-service model for Discourse?
Sam: There is a continual balancing act between focusing internal resources on "hosting infrastructure" vs "product development". I feel that after many years of balancing we found a recipe that works well for us.
Q: What does your average day look like, as a full-time open source contributor? How does it compare to your ‘regular day job’ years?
Sam: I am a full-time manager and, I guess, part-time developer. My day consists mostly around "unblocking" other members of my team so they can work on various tasks unhindered. I spend some of my time contributing to the various open source projects I run and to Discourse.
I would say my day-to-day is similar to how it used to be when I worked for closed source companies. The big difference is that I get to work much more with the general community of developers out there when reviewing pull requests or interacting on Meta Discourse.
Q: How has being involved in open source changed your life?
Sam: I have made lots of friends in the open source community. I feel less isolated. I also know that my work will continue to live on and that a lot more people can benefit from it.
It's provided me with a lot more self-worth. When working for strictly closed source companies I developed lots of cool building blocks that I never had the chance to share properly with the development community. I found it incredibly liberating at Stack Overflow when I was encouraged to open source Dapper and share it with the world.
These days at Discourse the vast majority of code I work on is open source, and I love it.
When working for strictly closed source companies, I developed lots of cool building blocks that I never had the chance to share with the development community. I found it incredibly liberating at Stack Overflow, where I was encouraged to open source Dapper and share it with the world.
Q: What’s your advice to developers who are ‘on the fence’ about contributing to open source—particularly where to begin and how to continue afterward?
Sam: Ideally you can start at work! I am not the kind of person to give advice asking people to put in work in the evenings just so they can get involved with open source.
Find a bug in a framework you are using at work that is open source and contribute a fix upstream. Find a component you use at work you would be happy to share with the world and make it public.
Q: What are some common challenges open source projects face? How can they be solved?
Sam: There are so many, I guess the biggest challenge I think most hobbyist open source projects have these days is simply "being there". There are so many abandoned projects out there, many of which are pretty awesome.
I think one thing that can help a lot is if instead of "creating something new" some of us focus on "adopting something old and abandoned that is awesome".
I find that lots of times a new breath of fresh air can be introduced into an old project when a new, passionate, contributor pops along. I tend to hand over commit rights to some of my projects even years later when a new passionate developer comes along.
Q: How can software companies promote open source contribution—within and outside the organization?
Sam: The first step is actually allowing it. Make it easier for developers to contribute and start projects. Reduce paperwork required every time a developer needs to contribute stuff. If you are making a 2 line commit, but need to fill a 20 page document just to push said commit, you will not bother.
Q: A piece of advice to new developers?
Sam: I guess a few general recommendation I would make to new developers out there would be: learn to touch-type, read lots, learn Vim, be kind.
You can check out more of my stuff at my blog and I am always around at Discourse Meta.
Check out Discourse on GitHub.
(Responses are edited for clarity).
We ❤️ open source. Fill out this form to get free, lifelong access to BrowserStack for your project's testing needs.
