|Name||ESCo Role||Organisation||Present / Absent|
|Project Lead||Symphony LLC|
|Project Lead||Goldman Sachs|
|Project Lead||Symphony LLC||Present|
|Project Lead||IHS Markit||Present|
|Project Lead||Credit Suisse||Present|
|Secretary||Symphony Software Foundation||Present|
Actions items from previous meetings
|5 min||Convene & roll call|
|10 5 min||Review action items from previous meetings|
|Open source compliance policy review|
|5 min||AOB & adjourn|
- Quorum not achieved
- Action items:
- Good update from Frank and James
- Lawrence's action items:
- Would like to align with Aaron
- I have not sent out LLC contribution policy yet. I don't have a problem doing that. My comment in the previous meeting is that I'm happy to share the LLC's policy, but it's going ot be much more conducive to look at policies of financial institutions, because our poliocy (like IHM's) is likely more liberal than the big banks.
- POeterl; is therte any reason not tio share it?
- Lawrence: not really, if there's interest fortm ESCo in sharing it.
- Frank: is it based on sopmethikng, os did you create it yourself?
- Lawrne:ce extensively modfifgied verison of Blackrock policy.
- Frank: and that was crafted by Blackrock?
- Lawrence: extensively movidifed
- Franjk: it would be valuable if you took the IHSM poliocy and walked thorugh the diagram, and discussed the differences - what's equival;ent, what's different. themn we can takl about what banks are dealing with that's didfferent. We have to be realistic that as vendors the bars we have to meet might be lower. As we're going through the didcussiosn it would be good to inderstand differences, and if they're substantial then I'd want to see the document.
- Lawrne:ce the biggest difference is that the symphony process id egiend around a policy where most LLC contributions are intended to go into the Symphonynm Foundation. whereas a bank polocy is unlikely to do that (though the foundation may want that! ). I'll dig it up, buty I don't think it's going ot be very useful.
- James: looking at your poliocy, how does it work practically? When you or your team contribute? Once you've been thoruhg some of this dso ytou do contiunous contribiutiokn ,or does each contribution have to be evlauated by an independent 3rd party?
- 55 minute discussion:
- Frank: we have exec level + legal approvel for initial contribution. the idea being that at an IP level are we giving away our assets that generate revenue, opr expose us inways we don't want./ Thart'san exec level ddecisions, wtih an dunderstanding that the contirbution will be mabnagedb y a review bioard that's close to tyhe decveoop[lment activity. That board ioncludes of ther dev lead and legal counsel, and that local review board has access to the actual code to evaluate what's being contributed,. Tgat p[rocess has turned into email trail, post-contriobution. The initial contribution focuses on trying to make sure the contributions are mirrored to a local repository (local git and remote gittub). Udpates are to the distribution list (peer review group) to informt them, that that's happening. On top of that there has to be some level of peee rview of the code that's being contributed on each commit. Realiistically spekaking we review approxiomately monthlu. That's basically iy. Roughly speaking that'd ht perocess we follow.
- JameS: and you don't have nay tooling to support that? Just email & manuakl?
- Frank: yes, though we also use GitLab, which helps a bit with that. We getr notificaityons etc.
- Aaron: is th eopen source review board one, or abvove?
- Frank: it's N on the above, both exec group and project review board.
- Aaron: so it's project specific?
- Frank: yes - we don't want those gropus to be divorced from the project. We don't want some central group that's decoupled from the work.
- Aaron: where do you find your process gets hung up most often?
- Frank: that people aren't aware of it withi the company. We're focusing on this right now, and remastering the document to a wider audience within the componay. Tio fget an exec and legal to look at an initial contributiopn and ensure it's not a liability. that's also very important. Thew other difficult yis having conteributoer sfollowing standard practices we've learnt thorugh the DSymphony foundation (licensing in the source, clean source code, etc.). You can go to the exec board to get approval, but oyu have to go to the review board to sign off the legal ramifications of what you're contributing. You have to have someone on the review board working with you to understand the requirements./ So two difficults:
- Senioer management sign off.
- Getting the right people in the review board, to c are to work with the contirubutor who may not have contributed to open source before and make the approprioate adjustments.
- Aaron: any traiuning for contributors?
- James: loking at the diagram there's one thing that says "developer publishes contirbution". I'm assuming that they can't publish?
- Frank: they can publish right now and there's some language above about the "proxuy contributor",. It's possible to define hwo can contribute, based on the policy, and the "proxy conbtribiuyor" can be defined. there are forms for this that deascribe how you're going to deliver your code into open source - open source contributor vs proxty. Right now it's mostly been individual contributor, not proxy.
- Lawrence: I sent to ESco a PDF of our p[olicy. When you're done Frank I can talk about o90urs.
- James: Is this process mainly for where you're publishing Markit projects? What about contributing to other projects?
- Frank;' it should cover both, and this is something we've been discussing internally. It's not clarified well right now, thoughh the latest version talks about. Idf it is a project that is already existing in the Markit, we will not republish it as a personal project - we'd contribute it to the sponsoring Foundation. If we're4 contributing to our Markit open source repository,. it wil be specific to Markit product - not a patch for some email system somehwre.e Anything publioshed to the Markit repository woul dbe specifif to our products. Anything that is existing project work outside Markikt would be contributed to that repository, ensurihng licensing requirements etc. We also have an open source use poliocy, which prevents copyleft technologies from being used.
- JameS: if you're pacthing something it goes thorugh the same process, but will land in a differernt place?
- Frank: yes. That's our staging git repo and that's where source gets put even if it's unrelated to Markit products. If it's relarted to external code it would still go there.
- James: we're interested in this precise thing and have been talking about it for some time?
- Frank: any questions?
- Nick: is the staging repo priuvatye?
- Frank: correct - it's on our GitLab. We "stole" this from the Linux open source compliance site. Tonnes of material there - templartes etc. We didn't create this on our own.
- James: as I've said before, the process theoretiucally is very similar to what we've deifined, but our big stumbling block has been tooling. We don't have this idea of a staging area, we'd have to set that up. And then setting up rules around how to use the staging srea, and publish from it is hard.
- Frank: rigyht -0 it's very manual right now.
- HJames: indeed, and ours probably would be too. We also have practucal difficulties around firewalls etc. - doing this manually would be almost impossible.
- Lawrence: coes eveyrone have the PDF I sent out?
- LawrencE: first up you'll notice our poliocy is only a 3rd the length of Franks, but iubn seriousness the first comment I'd make is that this document is labeled as ap rociess. In our frameowkr we have something called a polocy, but the p[oliocy itself sends practically nothing - just some general pinrncpiople statements. That's based ioff of how Blackrock InfoSec policies are defined. Part of the rtationale for that is that if someone is doing an audit, and they're only interested in the poliocy docu,emnt, you hamnd them the poliocy document and it doesn't have much in it so you're less likely to get iunto compliance issues. The beef of our "policy" is in the process document, which is the next level down. Our process documenty is most similar to rhwe Mrkit document. This is not base dfon Apache or other stebalished proceduaral document - it's specified to sympohnn.y There are tow types of open source activityies this document is intended to coveR:
- open source coming into Syumphony -= what's the process for managingh the additjoon of open source to th esymphjony code base. The prim ary consideration is: is the license compatible with Apache 2.0. Because if we open sou8rce something with the Foundaiton, it has to be Apache 2.0 compliant (so that we cna contribute it). Second part is ensuring we don't violate the terms of the ioncom,ing open soruce license - e.g. the Affero GPL license which can have unintended viral requirements. It's about giving the developer a flowchart so that if a developer is brinign in open source they can simply check whether the software is inu the lciense whitelist.
- Contributing to copen source. What you'll see here is that this dfocuymenty modely talks about contirbuting to a Foundation op0en source project, ebaceuse that's mosat of the open source contribuyting we do. We also haver asome language about projects that aren't contributed to the Fuodnati9on. But most of the process focuses on contributing to the foundaiton, where we already have a contirbbutor license agreemnent inplace. On page 2 is a flowchart regarding new projcvets vs exiusting prjocets. If it's a new project it has to go to a review board (Thomas Keissling and msyelf) before being contribbted. For existing projects, the way we've handled simplyinf the review porocess. Originally we had aprocess that was imiol;ar to tyhe Markit process - every single ocmmit would theoretically need to go through review. But our procedure and top-legvel approavh we eantwed was a model where we have tnat level of control - no contributions that hacven't been approved. But it's not practical to review every single commit to an open source code bae. Osio we introduced a concept of "pre-approved contributions". it allows thomas and I to say "we are reviewing and pre-approving every change to this project", meaning Thomas an dI don't have to review every single cmomit. It sensures Thlmoas and I understand the boundaries of contributions, and can appoproive changes (e.g. for a given dsprint) in advance. Thew rest of this goes through proceduarally what you do. We've tried to minimse the amount of informatyiopn that a developer needed to provide so that a developer isn't filling out a huge amount of paperwork to do something - we've found develoeprs are raeal;l;y reistsant to that. Thoomas an dmyself probabnly already know, given the size of our organisation, what the devl;oper ois propins.
- James: do youy eview code?
- LawrnecvE: yes for existing code we require develoeprs to provide a link to the codde
- James: do soyu're trusting the devloper to report that?
- LAwrence: lkeet's say we look at the upcoming two sprintgs of Symphony, and those sperints have a known list of functyional changes form PM. We trust that the changes don't go beyond the scope of what's been proposed by the PM. On the other hand, if we had a change that wasn't within the scoper of pre-review change series, we would need an individual approval request, and as part of that we'd hget a description from the developer about what the change is, and (if necessary) od a code review. that's the philosphoy of it.
- James: philosophically that works, but in our organisation that paranoia of losing a trading algorithm via a pre-approval comes in.
- Lawrence: if you go to the review cirteria - these are the criterias we look at to determine if osoemthing is high risk or low risk, and therepre how much scrutiny it needs. If we're looking at any change that falls outside a standing approval, these are the criteria Thomas an Di would apply to determine how much scrutiny to give to the contribution. These are risk factors, not a checklist, but if it looks like a duck and quacks like a duck... It's not to say that something thst falls into the high risk categiory wouldn't be approved - just that it needs more scrutiny
- James: how do you implement this? Do you use GitHub?
- Lawrence: yep. If there were lots and lots of lines of code, that's a high risk thing.
- JameS: can you practically sopt the developes from xcobntributing? Or is it a trust thisng?
- LAwrnecE: I think it's true in every organisatyion that you can't stop your develoers from doing stuff.
- JameS: we've made it really hard for our develoeprs to do anything.
- Nick: thjat's a differten tproblem,! '
- Larwnce: my experience has been if you make it too hard, your developers will just do sopmething else.
- JAmes: we've made it bery ahrd fomr our developer's desk.
- LawrnecE: interesting story about thbis. When Blackrock acquired Merril Lych, we discovered that ML had locked down developers' ernvironment - no C: drive access, no registry access, no software installation,e tc. It was moast impossible to do any development on these machines. And what the devlopers ended up doing is developing on personal laptops!
- James: we've had to shoot a few devel.,opers who did that.
- Lawrence: and those are the only ML develo-per shwo got anything done!
- Aarno: base odn my conversaiotn with GS, their policy is very similar to the LLC's -= tey have the ability to approve these "standing commits". JKames to your point the idea is that once you give tbat authorisation, you're apporoving not aonly the propject and its risk, but you're also scoping the authorisation so that it can't be gamed by the employee.