2019-06-05 OSR WG Meeting Notes

Meeting minutes status: Approved (on 2019/07/24)

Table of Contents

Date/Time

6/5/2019 10AM EST

Attendees

NameOrganizationGithub ID

Aaron Williamson

FINOS
Rob Underwood (Deactivated)FINOSbrooklynrob
Aitana MyohlFINOS
Andrew Aitkenwipro
Former user (Deleted)Morgan Stanley
Colin Eberhardt (He/Him)Scott Logic
Gaurav ParakhWiPro
Gilles Gravierwipro
Hershal Shah (Deactivated)IHS Markit
Jim JagielskiConsensys?
Rich HeironimusFreddie Mac 
Simon HoltJPMC
Sally EllardDeutsche Bank
Aaron Griswold
FINOS
Adam BatkinAQR

Agenda

TimeItemWhoNotes from the Meeting
5 minConvene & roll call
50 minContribution considerationsAaron Williamson and Simon Holt

This discussion focused on the strategic considerations that go into a firm's decision to contribute to an open source project or establish one, with the following list of topics (suggested by Simon) as a framework. (Notes reflect comments made by various participants.)

Topics covered

  • Business case to open source

It's better for a company to host its own project if it's one with significant reputational impact, because it can ensure the quality of the code and that it won't go stagnant. If it's critical that the project attract collaborators, an independent foundation is a better choice.

Another important consideration is whether a project is "generic" enough in its utility to be useful to other firms.

Attracting outside users & contributors is not the only reason to open source something. For example, a consultancy may wish to showcase its abilities.

Companies should ask: How will this benefit the community? What is the problem it is solving? And what are the benefits to the company of open sourcing it?

It's important to have as strong an internal business rational for open sourcing the code as possible. It's hard to build a vibrant open source community, so it's critical that you have the backing and resources to bring it up to speed.

  • Impact to competitive advantage
If a project is close to the core business of a financial services firm, they should be circumspect about whether open sourcing it will cut into their core business. But there are easier cases, such as a good idea re: technology infrastructure -- if your solution is first out of the gate and you can build a community around it, it will be easier to maintain.
With a solution to a common pain point, e.g. managing containers, keeping the project internal may have short-term benefits. But if it solves a problem everyone has to deal with, the industry will eventually standardize around some solution. It's better for you if it's the one you're already using.
The salient question is, should it be standardized? If the answer is yes, someone will.
  • Are there Intellectual Property (IP) concerns or patent requirements
It's not clear that many financial services firms are thinking strategically about why they're acquiring patents and what they're using them for. If it's just a measure of "innovation" or value, or they're for defensive purposes, there's less of a barrier to open sourcing code that embodies the patents.
You need to take into account the identity of your firm and where your value is. Our firm has a committee that looks at this.
We try to ask that question at the time a project is being considered for open source contribution: is it patentable? If no, then clear it. We try to avoid bringing the issue up to IP counsel unless it clears that first check.
How would you assess whether something is patentable?
SH: We ask, is that a unique idea or just enhancing the state of the art? If it's a new idea, we'll do a review with IP counsel.
It depends on the culture within the company. In some, patents are a goal to be attained and a measure of productivity; in others, they're not important so you don't get them.

For firms that patent software partly for defensive purposes, consider looking into the OpenInventionNetwork and the LOT Network, both of which are patent cross-licensing organizations that create patent peace around technology (OIN focuses on open source in particular).

  • Can the firm actually use the software it's looking to contribute to?
We run into licenses with restrictions that are incompatible with our use.
Field-of-use restrictions aren't permitted in true open source licenses.
That's true, but there are a lot of packages on NPM and a lot of projects on GitHub that will appear "open source" to a developer while having license restrictions that are incompatible with the open source definition.
Are there actual examples of non-open-source software getting embedded in open source?
Yes, it happens often, particularly when you're consuming open source at scale. There was a legal case involving an insurance company selling software that it believed to be open source but also included proprietary software.
It's necessary to do code scanning to identify these issues. There are both commercial and open source solutions available.
  • Which Organization will own the repo (short term/long term)
  • Repo long term support resource & budget
  • Who has merge repo privileges;
    • Avoiding collusion 
    • Controls on privileged accounts
    • Reputational risk
  • Legal factors;  
    • Which OSS License
    • CCLA/CLA creation required
    • Signing of other CCLA required
    • Copyright assignment required
    • Repo Membership Agreements (eg FINOS)
  • Configuration Management;
    • main code line
    • code contributions
    • code collaboration
    • managing pull requests and checking code quality
    • continuous development & code conflict resolution
  • Socializing Information through collaboration/forums/events
    • Documents/Wiki
    • Social and Corporate Media Policies
5 minAny other business & adjournment



Decisions Made

N/A

Action Items

  • Sally E. to talk to Plexus Interop product manager about presenting DB's experience open sourcing it

Need help? Email help@finos.org we'll get back to you.

Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.