Atlassian, parent company of popular chat service HipChat, started in 2002 with just two people. Thirteen years later, there are more than 1,300 of us spread around the world. That kind of growth forced the need for us to organize our open source efforts around a single point of contact, establish a rhythm in the company for contributing to open source projects, and encourage contributions to existing projects as well as the creation of new communities.

We learned a few things along the way. Here’s the roadmap we used to get started.

1. Satisfy legal

We weren’t out to create controversy or break legal ground. We just wanted to provide a framework that allowed us to engage and participate in open source communities. We decided to apply the same Apache license to all of our open source software to make project admin easy while addressing the typical concerns a legal department might have: the permitted scope of use, copyleft provisions to be concerned about, and license compliance. If a project wants to consider another license, it’s now handled on an exception basis.

2. Write a code of conduct

To encourage outside participation in our projects, we followed the example set by the Apache Foundation and many other active, successful projects and adopted the Apache-style Contributor License Agreements (CLAs). This allows us to control and maintain our projects, and ensures contributors will maintain ownership of the IP in their contributions. But to encourage diversity and create an environment that welcomes and respects all participants, we created a code of conduct.

3. Do an audit

When we started, we had no idea how many open source projects we had. We looked at every public project hosted under the Atlassian accounts on Bitbucket and GitHub and found more than 250. Many, however, had little to no contributions, issues reported, or downloads in the past six months. And some hadn’t been touched in more than three years. When creating an archival strategy, you need to recognize the difference between projects that have reached the end of their life cycle versus projects that are stable and still being used. Activity alone should not be your only criteria for archival. But making archiving a part of your ongoing routine is essential.

4. Guidelines and procedures

Along with the audit, we established easy to follow guidelines and procedures for using, contributing, and creating new open source work.

• When a team wants to use an open source project, they need to know if the license is acceptable. Identify the licenses that you give your teams the green light to use, the ones they should try to avoid, and ones you don’t accept. State your policy on projects without a license. Each time you review another license, publish the policies regarding that license in a place where all teams can access the results the next time they’re evaluating a library for inclusion in a product. We require all third-party code resides in separate files/directories.
• For projects that have a CLA, Atlassian provides a way for teams to quickly lookup the CLAs we’ve already signed. If projects do not have a CLA, we require a legal review of the terms regarding contributions if they exist. We also want legal approval if there are not any terms for contributions. We ask our teams to avoid forking projects when possible and to consider a plan to return quickly to the main branch when they do create a fork. But most importantly, identify who in your organization needs to review or approve contributions to make sure you are not signing away IP that you want to keep within the company.
• Identify the artifacts that must be in place to create a new project. Some organizations will only open source production ready code. At a minimum, our projects must have clear licensing and a readme or other documentation that provides: a project mission statement, a list of existing/planned features, a list of requirements, install/deployment instructions, and a sharable roadmap for future development. Spell out the approval process that applies to your teams. Provide employees with a policy or statement about personal projects that happen outside of work. And, when applicable, make sure that your policies address employees located in different countries or states.

5. Keep on keeping on

Getting our open source house in order took us six months. But it was the start, not the end.

Our next steps include providing more help to our open source projects in the form of documentation and reusable templates. We’re also looking at ways to help our teams expose their projects to encourage outside participation, and finding ways to participate in the greater open source community by tracking conferences and communities that we believe our teams will find beneficial.

Please join us and get your open source house in order for the new year. Happy open sourcing!