First of all, is there a definition of what Core project is, more detailed than [0]? "Statement of centrality of role" sounds like it may be alluding to some other document.
Here is an incomplete list of project I expect to become good candidates for core projects: odlparent, yangtools, mdsal, integration/distribution, releng/autorelease, releng/builder, integration/test. Example of artifacts overlap: openflowplugin-he vs openflowplugin-li. Example of evolution without overlap: from odl to new yang parser. Example of winner becoming de facto core: MD-SAL over AD-SAL. I can see benefit of keeping Singularity clause in. What is missing is a process how to demote from Core once an alternative functionality appears. And perhaps lines such as "The TSC members are the project leads from the Core projects." [1] should be reformulated. Vratko. [0] https://www.opendaylight.org/project-lifecycle-releases#ProjectTypes [1] https://www.opendaylight.org/tsc-charter From: [email protected] [mailto:[email protected]] On Behalf Of Anil Vishnoi Sent: 16 June, 2016 23:44 To: Edward Warnicke <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [OpenDaylight Discuss] Asking the Board to Remove the Singularity Principle comments inline .. On Thu, Jun 16, 2016 at 11:09 AM, Edward Warnicke <[email protected]<mailto:[email protected]>> wrote: Anil today brought up the issue of the Singularity Principle in the TSC Policy in todays TSC: https://www.opendaylight.org/tsc-policy The TSC Policy contains a statement: "Singularity: To the extent possible, there should be no overlap between the goals of the core projects and artifacts created by them" There were questions raised as to the impact this had as projects because core on other projects, and I was #actioned to start an email conversation on the topic. To me, the singularity clause is troubling because it implies that once a project reaches core, nobody can compete with things that are within its scope, effectively innovation is shut off. In my mind, part of being a truly open source project is being an open innovation regime, and that implies that we do not anoint 'the one true winner' in a particular area, but allow that to emerge based up quality of the work a project produces and its adoption. In the presence of the Singularity clause, core promotions feel to much like picking winners-for-all-time via a political process, rather than allowing winners to emerge via technical merit. So I would propose that the TSC petition the board to strike the Singularity Clause from the TSC policy. I agree with the problem ( picking winners-for-all-time ) but i have a strong objection to the solution proposed in the above line (I would be happy to reduce the strength of my objection as i read more valid argument in favor of the above proposal :) ). I believe the existing text of Singularity clause is very appropriate, because in my interpretation it says that we should not open the "core projects" gate for the projects with overlapping scope until and unless we see a real value to have them as a core project. In my understanding (I may be wrong), main intention of having the project life cycle is to provide a stable platform to the downstream projects on which they can build their innovative applications with certain level of confidence. And to deliver such a platform i believe we need to keep the criterias high (that does not necessarily mean saying "no" to the projects). I believe organizations that are consuming ODL has the same expectation as well. As a ODL project, we need to make sure that projects should feel free to innovate in the ecosystem, but we would also assure that we give a stable platform to the downstream project and TSC plays a critical role here to keep that balance. Allowing project with overlapping scope under OpenDaylight umbrella provides freedom to the project to innovate and project life cycle + singularity clause assures that OpenDaylight deliver the stable platform to their downstream consumer. Rather than striking out the singularity clause, I would suggest that we should have a clause/law/guideline on how an existing core project can be replaced with the project with superior technical merit. Will that solve all the possible scenarios? Probably not, but the current singularity clause does not stop TSC from allowing those project to become core project if having them has a real value to ODL consumers. I am curious to hear the thoughts of others on the subject. Ed _______________________________________________ Discuss mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/discuss -- Thanks Anil
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
