Table of Contents

Date

06 Dec 2017

Attendees

Actions items from previous meetings

Add new action items here.

Agenda

Meeting notes

Aaron Williamson introduced Matt Joseph and Larry Miller from BNY Mellon, who attended this working group meeting to discuss BNYM’s newly approved open source policy.

AW: Larry, could you give some background on the policy and the process BNYM took to get here?

LM: BNY Mellon has had a FOSS governance program for at least 7 or 8 years, and until 2017 it was entirely focused on inbound FOSS licensing. The development community within BNY has increasingly relied upon FOSS in internal development. Increasingly, management in tech wanted to begin making contributions to the open source community—Symphony being one impetus—and it became necessary to expand the policy to contributions. So we had to start researching, reviewing web resources. Engaged Fenwick & West about industry standards for outbound licensing programs. Then created ad hoc working group that’s been working on the policy for over a year. Then it became a process of revising the inbound document to include outbound contributions. Found there were people within BNY Mellon who wanted to make individual contributions on their own time, and had to create a mechanism for that. Have a code of conduct that’s quite pervasive and extends to activities that employees undertake on their own time, including external business activities (like board service at another organization). They have to file a disclosure with Compliance, which gets forwarded to the employee’s manager, who makes the call. From the most extreme point of view, it’s intended to prevent moonlighting. But it’s also intended to ensure that employees are working fulltime for the company, so this gives the manager the opportunity to look into the project and how much time it’s going to take. Previously when inbound only, developers were not permitted to make modifications to the source code. Now we have to recognize that they will be, which requires consideration of the license or contributor agreement. We’re not authorizing modifications to GNU GPL-licensed software.

Tier 1 policies are enterprise-wide, and this is one. The activity was first to get the ad hoc working group to finish the drafting. Then had to go through client tech services. Then two committees (TURC, risk management, and CAO, technology administrative) had to approve it. Then a layer of bureaucracy to make approvals and formalize the document. As the policy is administered, frictions will become apparent, and after the list gets long enough, a revision will be proposed. Or, if enough time has passed since a version has been released, the policy bureaucracy will send an email saying it’s time for a new version. Generally, a new version comes out every couple of years. This one took 18 months to rewrite.

AW: What is the state of your implementing procedures?

LM: Embryonic. We’re currently using a confluence site to document.

MJ: We’ve gone through this process and leveraged the policy to open source one project. Now working with Developer Efficiency Group on automated controls—Github hooks, tracking users, etc.

AW: What sort of interaction do your developers have with Github and how does the bank mediate that?

MJ: We’re working through that now. For the current project, it’s a direct push. Don Raab served as the contributor, but pulled in others as code reviewers. We cleaned up the internal git history before pushing it. I served as the committer to push it to Github via the Github organization.

AW: Does your approval process permit your maintainers to work at the speed of open source development?

MJ: Yes, because approvals are for a whole project, not individual contributions.

HS: What about monitoring, logging, etc. – are you providing team members with company-provided hardware that tracks what employees are doing? Is there room for BYOD?

MJ: We’re doing a few things. There’s the regulatory obligation to monitor & retain communications, so we have that in practice for everything going across our network. For FOSS specifically, there’s an approval process to ensure that FOSS has to be OK’d before use, and automation makes that a lot easier for developers.

AW: How are you surveilling developer interactions with Github?

MJ: This will evolve. We’re looking at it from a broader perspective. Tech employees are expected to engage in online communities, so the question is how you do surveillance in an agnostic format for social media/electronic communications.