On Today’s TSC call there will be a discussion of whether stronger steering from TSC will benefit the community. Following is intended to seed that discussion for those who get a chance to look at it.

In recent TSC calls I have noted two significant developments:

1)      There are members of the community who would like to see stronger guidance (steering) from the TSC.

2)      The TSC charter can be interpreted as supporting stronger steering under responsibilities including best practices and defining release vehicles. (Paragraph from charter pasted at end)

In particular the following areas appear to be ambiguously defined, with the result being disagreements in design sessions:

·         What are requirements for ease of use from the SDN developer perspective? (Hackfests don’t use ODL because it’s too complicated!)

·         What are requirements for ease of use from a non-SDN-developer perspective? (Can app devs get their distributed apps to work?)

·         What are requirements for performance, scale, stability, test-coverage?

I would like to propose that the TSC could provide guidance as follows:

1)      Develop a proposal for the Lithium release that defines requirements for release eligibility for various capabilities (a sort of an RFP for components)

2)      Officially approve this document under the rules of order for TSC

3)      Make release participation/eligibility contingent upon meeting the requirements of the approved document.

4)      Don’t allow release to occur until requirements have been met.

One extreme outcome of this process could be that we are so anxious to release stuff on a particular cadence that we can’t approve any strict language. I doubt that will be the result and suggest that the best way to find out is to attempt to draft and approve something.

I think it would be ideal to get a group of no more than half a dozen TSC members who have time available to urgently work on an initial proposal, which would subsequently be reviewed/discussed by the entire TSC membership.

As an example, the TSC might want to request a SAL component that meets certain “consume-ability” criteria deemed essential to the success of the community. It is clearly not the role of the TSC to design the SAL that is consumable, but TSC may be the only enforcement point that can prevent shipping the unconsume-able.

I won’t presume to lay out a detailed process for proceeding in this email. Before working on the details of the process I want to hear from the rest of the community whether there is support for the idea of providing stronger technical/architectural guidance from the TSC.

On last week’s TSC call it was suggested that the TSC has no ability to direct resources and that any sort of requirements that do not grow organically bottom-up will be ignored by the community.

I have several problems with this view:

·         It would make the TSC completely impotent (Technical Sheep Committee?)

·         It assumes that bottom up evolution with no top-down input yields good results in finite time. Wrong. If we want to evolve over millennia, final result could be excellent. If we want to ship something this year we need to impose some constraints.

·         It ignores the fact that TSC is responsible for releases and that the huge majority of contributors to ODL are paid by member companies with huge commercial interest in seeing ODL releases happen. The TSC doesn’t need to direct any resources, we just need to help people decide where to direct resources by controlling releases.  The member companies will direct to comply.

·         It ignores the fact that ODL is the OSS project that had no community childhood. Organic growth and grassroots goodness are hard to achieve when the project is a mashup of complete commercial projects glued together after the fact with vendor influence front and center from day one.

There is currently much better diversity of representation in the (artificial/appointed) TSC than in any of the critical project leadership.  We have a diverse group of strong, big picture technologists balanced in a way that removes disproportionate single-vendor influence.

It makes total sense for the TSC to provide central leadership and decision making to insure the best interests of the community at large.

We need to figure out how to do so in the best manner possible.

Let the wild debate begin. Let’s hear from all you libertarians who think projects should have zero oversight.

Cut and Pasted from the TSC Charter

Section 5.  Responsibilities of the TSC.  Subject to such policies as may be set by the Board, the TSC is responsible for simultaneous release dates, release quality standards,  technical best practices (including the Development Process), monitoring technical progress, mediating technical conflicts between Committers and project leads, and organizing inter-project collaboration. The TSC will define ODP’s release vehicles.  The TSC will serve as ODP’s liaisons with other consortiums and groups.

-drl

Dave Lenrow

Distinguished Architect

Advanced Technology Group - HP Networking

Hewlett-Packard, Littleton MA

+1 (617)-329-1861 (mobile)

david.lenrow@...

@dlenrow