Date/Time

5/8/2019 10AM EST

Attendees

Time

Item

Who

Notes from the Meeting

5 min

Convene & roll call

50 min

Publishing an open source project

Aaron led a guided discussion of the process of publishing an internal product as open source software:

Participant-raised topic: innersource hasn't worked at firm because of lack of internal promotion. How do others do it?
- Regular newsletter to group architecture with status update on various open source efforts, including innersource

How should the proposal be pitched internally?
- One approach: comprehensive project onboarding process. Email to put a proposal forward. Have call to go over value proposition and decide whether to move forward. Have them complete an onboarding questionnaire, require CIO & CTO approval. Schedule demo with open source review council. Questionnaire: legal entity contributing, masponsor, materials, how maintained, license, repo URL. Next, Q&A re: business benefits. Legal review of CLA. Risk & control risk review. Raise change request with network policy. Comms: formal announcement.
- Internal Newsletters
- Learning Management Systems; Corporate Universities
Participant topic: how do you evaluate whether the project will produce ROI?
- Other members still testing different metrics for project success
- Ask published projects to report on KPIs
- Must be bespoke to the project because benefits different in each case
- Good documentation is important

How should the value of the product as proprietary IP be evaluated?
- In terms of overall valuation, project developed from scratch for contribution may need to account for dev cost, but for existing projects there's no need to factor in any loss of value
- Guides question of whether the project goes into corporate repo or separate foundation.
- Simpler matter for consultancy: question is whether a customer would pay for it. If not, it's usually a candidate for open source.
- Difficult to evaluate what the support costs will be if it's made open source.

How should the license be chosen?
- Most firms default to Apache 2, MIT, or other permissive license
- Where there's concern of vendor capture, GPL or LGPL are considered

Where should the project be hosted?
- If reputationally significant, might be better to put in the corporate repo.
- If focus is on collaboration between financial services firms, FINOS is a better option
- If there's obvious alignment with another Foundation's focus, that may be better

What should the contribution policy be?
- Most use a CLA
- One firm moved to a DCO because external contributors refused to sign a DCO

5 min

Any other business & adjournment

N/A