Focus on ONAP - not LFN wide yet... outcome: document the framework for using components and EOL
How to retire a project that has inter-dependencies and the project loses support from the community?
ODL experience: acknowledge the risk when first using the component and identify a method to introduce alternative committers if needed.
Project using the component needs to have the contingency plan should the component support get reduced/dropped
Catherine Lefevre Need to consider cross-dependencies between LFN projects i.e. ODL & ONAP; ONAP VVP/VNFSDK and OVP/CNTT etc.
BTW similar comment considering cross-LFN projects roadmap. I do not think today we have visibility about potential requirements across LFN projects.
Ranny Haiby seems to be some confusion over the purpose of the proposal - original seems to be more focused on technical and now discussion seems to be one of asking communities for ongoing commitment.
Ed Warnicke wants the lowest bar to entry for a project, but it makes sense for one project to ask hard questions about cross-project dependencies.
VM (Vicky) Brasseur it is the responsibility of those that are using a dependency to practice due diligence. That is basic SW dev, not anything specific to OSS.
Mark Beierl OSS already has the equivalent of an escrow for commercial software. Any company can pick it up and maintain it.
VM (Vicky) Brasseur If the problem is companies not understanding OSS, that is a fundamentally different problem.
Several people note that almost all OSS projects have a "no warranty" clause in the licenses; there should be no need for further notices.
In Summary- The responsibility is on the company/project using upstream OSS dependencies