| 50 min | Publishing an open source project | Aaron Williamson | Aaron led a guided discussion of the process of publishing an internal product as open source software:
- What are the characteristics to look for in a candidate for open sourcing?
- Will establish firm as a thought leader and contribute to recruiter
- Gain respect and trust in developer community
- Projects crying out for standardization
- Crying out for standardization
- Go to those "crying out" to be open sourced rather than searching within the organizations
- No one-size answer: must have an evaluation process and systemic set of questions to get asked of any potential open sourced project
- 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
- What internal policies should govern employees' interaction with the project?
- When and how should unmaintained projects be transitioned or removed?
|