Attendees

AGENDA

MINUTES

Brian Ingenito (Morgan Stanley)

• We have the same policy at MS where we need to always use our work email for GitHub and forums.  For GitHub we further have to mark the email as private and use the noreply route.  This isn’t to hide our identity but to avoid our work email from being added to any lists, etc.  This policy always causes confusion around the terms of services and only having one account and private vs work, etc.

• MS currently allows broad access to GitHub, but that is because limiting it previously broke too much (`git clone`s failed for example); MS will likely revisit this with potential negative repercussions

  • More granular access and control decisions around users, and tools, especially CI. MS already has LDAP groups and roles used to manage permissions on GitHub

• Good process for consuming OSS, but having problems with CDNs and sometimes binaries from NPM; using Artifactory, it allows to synchronise publicly released libraries with an internal artifactory

• Internal process in place to request a project to be open sourced: review needed to avoid releasing competitive content, and peer review to prevent PIIA violations; also needs a senior manager approval

• Signing CCLAs could take a very a long time (months)

• We struggle with (joining and managing) WG activities, since we cannot access Atlassian SSO login

• Proposal for ODP: instead of focusing on building bots and proxies for GitHub, we could tackle the GitHub accessibility and use GitHub Wiki/Issues instead of Confluence/JIRA

• An internal Code Management system is accessible to all devs, but only authorized ones can push; some repositories are synced upstream with GitHub

• Interested to know more on a) GS-OSS and b) how did JPM managed to “relax” any library restriction on developer environments (and only enforce library scanning on staging environments and beyond)

George Grant (GS)

• All GS external interactions/collaborations must be duplicated internally for full auditing/compliance. We solve this currently by requiring a gs.com email address be the notification address for public contributions

• GS cannot access Atlassian Confluence, since they cannot submit any public forum or use any forum of communication that is not provided (or vetted) by GS

• GS uses an internal technology/framework called GS-OSS, which provides surveillance and syncing features to allow GS working on open source projects

• Anyone at GS that participates in open source activities must have followed a training (1 hour long) and pass a test; training covers logistics, what are licenses and how to avoid bad ones and how to behave

• For full open source projects (like relodomo), it takes a long process to get all approvals needed

Neil Slinger (JPMC)

• Awareness of OSS process and capabilities within the firm was a concern

• We're happy with processes for consuming OSS:

  1. any library can be used in a development environment

  2. requests to add libraries to Artifactory (for consumption) is fast (days)

• Re. projects: when it's a new OSS contribution since the beginning, it's a happy path; for internal projects that want to go open, it's a bit more tricky: peer review for machine names, sensitive data; legal checks and license validations

• it's always going to be challenging to access systems like Atlassian Confluence, for 2 reasons:

  1. banks are normally not allowed to access public forum

  2. all systems must be surveilled

• Internal code management system is in place: everyone can pull, only approved users can push; for oss projects, code is synced with upstream GitHub repository (after being reviewed internally)

Jamie Jones (GitHub)

I'd love to get more information on the specific steps (and forms, documents, other collateral you can share) regarding the consumption/approval of OSS as well as the publishing of changes externally. I believe GitHub already has NDAs with most/all of you, but happy to go through additional processes as necessary. Streamlining and improving these flows will benefit the foundation, corporate workflows, and Open Source in general, so i'm really interested in how we can build on each other's shoulders.

Commonalities

• All banks have a process in place for consuming OSS, based on proxying libraries that can be consumed internally

• All banks develop and review code internally, before publishing openly (to GitHub or other code hosting platforms)

• The review process differs, but aims at the same goals: check code for machine names (and other sensitive data), PIIA violations (and other contributor-specific checks), inbound and outbound license validation

• All banks have problems using finosfoundation.atlassian.net Wiki, either because

  1. they cannot reach out the website and/or sign up to it (technical reason, forms may be blocked, URLs may be blacklisted) or because

  2. policies don’t allow employees to access any communication system, unless internal or approved