Creating an Open Source Guild at Zoosk

Open source software is computer software where the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose. When you take a step back and think about it, it can seem strange that anyone would want to put significant effort into something and then release it for free into the world, but a lot of what I love about the internet and the world today is founded on people and companies doing exactly that.

Here at Zoosk we use a lot of open source software every day to get our jobs done—both internal tools to help write, build, and test code and customer facing software to serve our site. During my tenure here I have seen others contribute back to several open source projects and also put up totally new projects that tend to solve one specific problem or scenario that we were dealing with. However, we had never established any sort of process, guide, or rules on what could be put out into the world or how to do it.

It has always been a goal of mine to contribute back to the open source community that helps make my life so much easier and better. Because of that, I set out to establish an Open Source Guild here at Zoosk that would meet regularly, come up with rules and guidelines, and establish a process for ushering tools we created internally out into the world for free use. I started talking with my boss about creating this guild and together we outlined what the benefits could be, what the risks are, and what it would take to get buy in from those in the company that would ultimately have to sign off on the idea. I also spent a lot of time going back to the open source presences online that I use and like to take a deep look at their style of doing things. Getting approval to set the wheels in motion was actually quite easy and is just one more example of why I love working here.

We had our first Open Source Guild meetup on July 1, 2015. The company pitched in for catered lunch to help me attract as many employees as I could and I discussed what I wanted to do and why. That first meeting ignited a spark that I think had been smoldering for a while as lots of people wanted to be involved. Since that first meeting we have continued to meet about once a month. At each meeting I try to have at least one solid topic for us to discuss and when that discussion finishes I like to open the floor and see if anyone else has anything they want to bring up.

During one early meeting we focused on the question of whether we should keep an open source project we put out purely in a public repo and have that be a single source of truth, or whether we should have an internal only copy of a repo that we also keep a publicly available copy up to date with. One repo certainly seems easier to manage and keep track of. One repo means pull requests only need to be reviewed in one place and there shouldn’t ever be syncing problems. On the flip side one repo also means the potential to accidentally make things public (such as private keys, passphrases, and who knows what else). Two repos means keeping repos and branches in sync, but also the possibility that the repos may have to drift if a pull request that makes sense for the public repo will conflict with the direction that the internal repo goes. Ultimately we decided that the question of whether to maintain one or two repositories shouldn’t be answered generically for all repos but should be decided on a project by project basis. For our first release we decided to maintain two repositories to give us a little more flexibility further down the road.

Another interesting discussion we had was around whether to put out a given project under the official Zoosk Open Source Guild banner versus letting the creator(s) put it out on their own. Again, it doesn’t make sense to have a lot of hard and fast rules to govern this kind of choice but we came up with some questions to ask ourselves before we put things out as official Zoosk releases that included: Do we want to be on the hook for looking through pull requests in a timely manner and keeping the project up-to-date into the foreseeable future. Would we be excited to see a release like this from another entity around our size? How broad would the appeal of this project likely be? Of course the creator of the project would also likely have a preference to put it out themselves or have the greater company put it out and maintain it which should definitely be taken into account. This topic directly led to the Open Source Guild being a repository of knowledge on how to open source your project as a Zoosk employee outside of putting the project out as an official Zoosk release.

It took just under a year to get all of our ducks in a row and release our first project. We released ZENv, a tool for managing and sharing developer environments that basically everyone here uses, on May 25th of this year! You can read about the tool and how to use it here: https://zoosk.github.io/zenv/.

If you are interested in starting your own open source presence I can tell you a little more about some of the details we considered. I think a lot of the benefits in putting out open source software are pretty straight forward:

• Getting to give back to the community.
• Increasing your company’s technical brand.
• Attracting job applicants who fit in with your culture and want to give back like you do.
• Creating resources and a process for individuals in the company who want to create or contribute to open source but don’t know where to start.
• Getting some outside input on your projects that can make them more stable, secure, and pleasant to use.
• Producing and maintaining more well-documented tools, since they will need to be that way to be open sourced.

Some of the possible costs to weigh against all those benefits are:

• Plan to put more work into projects you open source so they will be properly documented, have unit tests, etc. You know, all the things you should be doing already…
• Plan to continue supporting your open source projects as pull requests come in. No one wants to contribute to a project that doesn’t respond to pull requests in a timely fashion.
• Do your research on what license you want to use for your project.
• Put aside some time to meet regularly to go over the state of your open source efforts.