What is an Open Source Office

Every commerical company has a engineering organization. Commerical engineering standard practice is to develop everything in private. However, times have changed and every company has some open source use and/or development going on. The use of open source without formal engineering support causes an unnecessary tug of war for resources. The solution is a group called the Open Source Office, dedicated to supporting the company’s open source work. An Open Source Office within a commercial organization, establishes the open source engineering support. A typical engineering organization focuses on vendors, operations, and possibility software development. Instead, the Open Source Office activities are focused on mitigating risks and supporting developers.

The detailed breakdown of the Open Source Office is into five components:

1. Legal Oversight of Software
2. Security Oversight of Software
3. Commercial Support of Open Source Governance Organizations
4. Sponsoring Open Source Projects and Tools
5. Direct Support of Engineering Contributions to Open Source Projects

1. Legal Oversight of Software

Oversight is about risk mitigation. Every company has risk when using licensed software. Contracts determine how a company can use vendor privately licensed software. Open source licensed software requires a company’s legal department to set the standards of use. These standards of use are set by software license types.

Create a process for developers and managers to request a license be approved for use. Hire at least a part-time Open Source Legal Manager reporting directly to the Open Source Office, to respond to requests and own the process. Use a simple form with some basic questions of how, why, where, and when. Jira, SurveyMonkey, or Google Forms all work very well. Once a license is approved, publish the details where any developer can easily find it. https://developer.yourcompany.com is a good place.

So called permissive licenses like Apache 2.0 and MIT allow the software to be used with a minimum of restrictions and thus are favored. Other projects are using so called copy-left licenses that require more complicated rules. The benefit of the software will need to be balanced with the rules of use. You will need to work with your legal minds to figure out the software benefit risk balance for your company.

I recommend using the OSI and TODO organizations as resources. The Open Source Initiative (OSI) has an excellent reference https://opensource.org/licenses plus mailing list discussions. The Linux Foundation TODO group has a legal workgroup that regularly discusses open source licensing. However, to participate in the TODO group, Linux Foundation membership is required.

Along with the approved open source software licenses, your developers need a clear process for joining, contributing, and creating open source projects. It is common practice to call using an existing open source based software project as Incoming (to your company) and contributing or creating a software project as Outgoing (to your company.) I recommend that once a license has been approved, that any contributions to open source project using the license be blanket approved by legal. You want to remove complexity and overhead.

Clearly document your Inbound and Outbound open source use policies at https://developer.yourcompany.com. I recommend my simple open source IO policies below:

Inbound Open Source Software policy

1. Working with a manager, find an open source project you want to use for company related work
2. Verify that the software license is approved by legal here https://developer.yourcompany.com/licenses/.
3. If the license if not approved or disapproved, request approval through the new license request at https://developer.yourcompany.com/licenses/. Legal will respond within a few days and start working with you on your request.
4. If the software license is approved, review the use restrictions, if any. For questions, request answers through https://developer.yourcompany.com/licenses/. Legal will respond within a few days and start working with you on your request.
5. Join or create your open source project to the software index at https://developer.yourcompany.com/projects/. Developers, users, and managers will use this information for training, mentoring, and hiring.

Outbound Open Source Software policy

1. Based on your own interests or working with a manager, find an open source project you want to contribute to. You can use https://developer.yourcompany.com/projects/ as a guide for existing users and contributors within the company. These people can help you with training and mentoring.
2. Once you find the open source project you want to contribute to, follow the contribution guidelines at https://developer.yourcompany.com/projects/ OR
3. If the project doesn’t yet exist at https://developer.yourcompany.com/projects/, then you need to verify or request the open source software license is approved here https://developer.yourcompany.com/licenses/. Once the open source software license is approved, then add the project to https://developer.yourcompany.com/projects/.

2. Security Oversight of Software

Your legal department sets the software license standards of use. Your security department is tasked with enforcing compliance of those standards. Where it comes to using software, security also wants to reduce the risk of introducing software vulnerabilities. Security covers this for privately licensed software through contract language and penalties. For open source licensed software, your security department needs a software scanner to verify license compliance, viruses, and other security risks are identified before use.

Many organizations use Checkmarx, AppScan, or Blackduck by manually scanning a code repository for security and license compliance. While this accomplishes a one time need to verify the code is compliant, it ignores any ongoing risk. It is a better practice to include the scanning activity as part of your software pipeline (also called Continuous Integration). By adding the software scanning to the software pipeline, any problems can be triaged by the developers during the development cycle, rather than waiting until the last minute. You will need at least a part-time Open Source Security Manager reporting to the Open Source Office, to manage the process and to respond to requests.

Well documented and understood legal, security policies and processes is good governance. Knowing the rules through good governance makes for happy employees

3. Commercial Support of Open Source Governance Organizations

Open source does have overhead. Since open source projects are a public activity, not directly managed by business needs, you need some good governance to help organize and collaborate. Companies using open source need to support the organizations that support the open source community as a whole. These include OSI, OIN, Linux Foundation, OSCON, and OCP to name a few. Supporting these organizations with sponsorships allow volunteers like myself support open source public policy initiatives and mentor new open source leaders on best practices. Hire an VP Open Source to manage the office, personnel, and the governance relationships. It is important that the Open Source Office leader is at a senior level so the policies the resulting policies are followed.

On a side note, commercial open source is a term that has been applied to organizations like OpenStack that are a mostly corporate funded development. This term still works here as I am using it, as I am applying to the need of commercial open source support beyond just the developement projects, but also to the governance organizations that support those development projects. We as open source leaders, need to do a better job of highlighting the requirement of proper governance for success.

4. Sponsoring Open Source Projects and Tools

Beyond developer code contributions, your company needs to sponsor your open source project events as well. As your company supports open source governance through organizations like the Linux Foundation, your public development projects need a similar type of support. At least each open source project will need to get its contributors face-to-face around release time. Planning for the next release is critical to get be completed very close to the release of the current development work.

These events need to be planned, organized, and executed. Events with more than a handful of people over a few days, becomes a complicated, expensive enterprise. To fully support an open source project, you’re contributing company needs to source developers and event sponsorships. Hire at least a part-time Events Manager to be responsible for these activities. A person with marketing experience for the role of Events Manager is a likely fit. Make sure that the Events Manager works closely with the development community, so the events meet the developer’s needs.

Public facing tools require support and management just like the projects. GitHub and other components of the public project Continuous Integration need continuous management and contributions to keep the project development momentum going strong. What is often missed, is the administrative function of keeping the public repositories managed. All too often, an organization’s public GitHub repositories become littered with stale projects that are no longer under active development or supported. This hurts the company reputation, making other public project participation more difficult.

The Open Source Office should not only take administrative ownership of the GitHub organizations your company owns, but take an active role in curating the projects there. If a project is stale, then update the root readme to say the project is not under active development. A GitHub organization that holds stale projects, if there are many, can help as well. The project can always be moved again if it becomes active. Hire a Community Manager to administer the public GitHub organization(s).

5. Direct Support of Engineering Contributions to Open Source Projects

In addition to GitHub, there are many Continuous Integration tools such as Jenkins and Gerrit that can used by public projects. For your public projects, whatever the Continuous Integration tools are, support them as strongly as GitHub. By relying on others to support the infrastructure that make the public project successful, you are outsourcing a critical function. Get involved at least part-time in the project CI infrastructure to ensure no surprises. Your Community Manager will monitor the state of your public project momentum through the project CI infrastructure. As problems arise, the Community Manager will jump in and work to fix the problem or gather people to fix the problem.

Project Data Analytics

As your team contributes, your engineering leadership needs information for scrum retrospectives and employee reviews. Code commits only tell a small part of the project story. Project data analytics fills in the gaps of project activities like patch review quality, time spent on contributions, and patch set history. Understanding these types of developer analytics are critical for any project. Developer analytics on public projects are essential. Development tools like Jira and Aha have some basic reports, but are missing the detailed analysis that can help mentor a junior developer or highlight feature development momentum. There are tools that can fill this gap. I know of three so far, Stackalytics http://stackalytics.com/, Biterga https://bitergia.com/ and GitPrime https://www.gitprime.com/. Biterga and GitPrime can work on public and private repositories. I have been using Stackalytics http://stackalytics.com/ for years, which is specific to OpenStack projects. It doesn’t have everything I would want. Stackalytics does allow for browsing patch review quality and filtered release contributions. Developer analytics has been a very important tool supporting open source projects.

Open Source Developers as Part of your Company Sprints

We have explained all the overhead for open source projects, except the most overlooked and arguably, the most important. Expand your developer support by supporting the public project development process within your internal development teams. To make this happen, your Open Source Office leadership needs to have authority over the product and project management. Dotted line management can work, while making sure open source is part of the annual reviews.

Day-to-day, week to week involvement with your internal engineering teams is critical for open source developers well being. Their public upstream work needs to be part of the internal sprint backlogs. Sprint retrospectives need to review the open source work along side the internal private project work. I have expanded on what is necessary here https://sarob.com/2017/02/open-source-first-project-product/.

Lastly, the most important part of your open source effort are your developers. They will be the beneficiaries the Open Source Office support. Your upstream open source developers will be productive contributing members of your commercial enterprise. Assign open source developers to public projects no differently than to private downstream projects. Do not forget the critical  part of a developer’s well being is good, clear leadership. You will need to have those developers at least dotted line to the Open Source Office leadership. This ensures that come annual reviews, your open source developer will get the proper attention and rewards for their hard work.

Remember that part-time work on multiple projects is possible for someone very senior.  Expect that junior to mid-level developers will need to work on one internal or external project at a time. I have many more details on upstream open source developer productivity here https://sarob.com/2017/01/open-source-first/ and here https://sarob.com/2017/03/project-product-steps/.

The Open Source Office

In conclusion, the Open Source Office establishes the necessary engineering support structure for a commercial company to be successful. The Open Source Office mitigates risk and supports the developers. The Open Source Office responsibilities can be further described as legal and security risk mitigation, supporting open source governance, projects, and their developers. Stop the tug of war for engineering resources within your company and formally recognize your use open source software, by establishing an Open Source Office.