CGL and the Linux Foundation

[dan@xxxxxxxxxxx (Dan Kohn)]

My name is Dan Kohn, and I'm the COO of the Linux Foundation.  I'm  
going to be representing the LF in our work with the Carrier Grade  
Linux (CGL) workgroup and (if they are willing to collaborate with  
us) with SCOPE.

First, I'd like to apologize for the extreme tardiness of this  
email.  I actually wrote a draft a month ago, but got sidetracked by  
LF integration issues, and was not able to focus on the actual work  
that the LF is aiming to support getting done.  I've carefully  
reviewed the lf_carrier posts for the month, and to address the  
issues raised there, I hope you'll excuse it if I now switch to a Q&A  
format for the remainder of the message.

Q. Does the LF care about CGL or is it letting it "wither on the vine"?

A.  Yes, we want to improve Linux to better meet telecom customer  
needs and to help win sales for network and telecom equipment  
vendors, distros, and system companies.  Serving as a neutral  
collaboration forum and helping shape consensus on critical issues  
are both core parts of the LF's mission.  That doesn't mean that all  
LF members agree with everything CGL has done or published in the  
past, but I can assure you that the LF wants CGL to continue, that  
you can count on me as your contact point for working with the LF,  
and that we are willing to dedicate resources for CGL's success.


Q. Aren't you just going to force everything to be part of the Linux  
Standard Base (LSB)?  Aren't you shutting down former OSDL workgroups  
so that the LF is just a renamed Free Standards Group?

No, although I think Jim Zemlin and I are responsible for this  
misunderstanding based on some of our comments that were taken out of  
context.  In short, we do think some things that CGL wants to see in  
carrier-grade Linux could best be implemented as LSB modules.   
However, there's lots of other work that the LF is supporting that  
has nothing to do with the LSB.  In particular, if we can find  
specific gaps in kernel or package functionality, we would be willing  
to fund developers to write patches that would then be submitted to  
those projects.  None of this would involve the LSB.  Also, any  
requirements or gap analysis, or documentation or whitepapers, would  
also be totally separate from the LSB.


Q. Isn't the LSB just a "bottom-feeding" standard that describes what  
everyone has already agreed on?  Isn't it totally unsuited for CGL,  
which is defining new requirements?

No, just because the LSB isn't required for all CGL work, doesn't  
mean that it can't be useful.  The LSB supports the concept of  
optional modules, where new functionality can be specified that is  
not yet "best practice" -- i.e., is not yet shipping in the major  
distros.  This is described in the LSB Charter <http://www.linux- 
foundation.org/en/LSB_Charter>.


Q.  What's your relevant experience for CGL?

I helped run strategy for several of Craig McCaw's telecom companies  
-- including Nextel, XO, Teledesic, and ICO -- from 1995 to 2000.  I  
was a venture capitalist with Skymoon Ventures from 2000 to 2005, and  
during that time served as the founding CEO of two companies using  
embedded Linux in their products.  Pedestal Networks was a DSL  
equipment vendor that was sold to UT Starcom.  Dash Networks is a  
dashboard navigation system (with onboard GPS, Wi-Fi, and GPRS).   
I've also co-authored several IETF standards, including RFC 3023 and  
the soon-to-be-published Usefor draft, and participated in numerous  
IETF and W3C standards activities.


Q.  Will the LF support registration for CGL 4.0 compliant distros.

A.  Yes, we already do, although it's not glamorous or rigorous.  Any  
distro is welcome to update <http://www.linux-foundation.org/en/ 
Registration> to register their compliance with CGL requirements.


Q.  Will the LF promote CGL 4.0 registration?

A.  It depends on the specific promotional request.   Brand building  
is an expensive endeavor whether it is PR, advertising, trade show  
support, logo development, etc. and we need to understand what the  
goals for the CGL workgroup are here.   If those goals are in line  
with the resources we can afford to allocate to this group, then we  
can consider it.  In most of our work, the LF is more interested in  
certification than registration, which generally means passing a  
rigorous test suite.  For our collaboration work, the large majority  
of our members have asked us to focus on running code (i.e., useful  
patches), and documentation.


Q.  What do you think the CGL should be focused on?

A.  At the end of the day, the CGL members need to reach consensus on  
what they want to do.  Hopefully, that will be compatible with what  
the LF can support and we can provide a positive forum for getting  
work done.  As of today, before having been able to speak to all of  
the key members of the group, I would suggest the following:

If SCOPE is willing, CGL should launch a joint effort over the next  
several months to construct a gaps analysis document comparing the  
key requirements from CGL 4.0 (and other critical customer  
requirements that didn't get in the spec) with the state of the  
latest distro releases.  Many of the CGL requirements are already  
handled by the mainline kernel, and so are supported by every recent  
distro release.  Some others are never going to get into the mainline  
kernel or distros, and so whether they are really critical customer  
requirements should be evaluated.  Other requirements are vague or  
are useful for only a very small minority of carriers.

I think a gaps document that succinctly represented what this special  
(and important) class of customers needs from Linux (that is not  
already there) would be an extremely valuable input for the Linux  
ecosystem.  For example, I've spoken separately to both a top Red Hat  
executive and a top kernel developer who agree on the value of a gaps  
analysis on better understanding their customers.  Both have had  
issues with CGL in the past, and yet are now interested in  
participating in the gaps analysis that CGL/SCOPE could undertake and  
then acting on the results of that analysis.

If we can then identify a few specific, actionable gaps that can be  
addressed with a reasonable amount of focused activity, the LF can  
probably fund a developer or two to do specific projects.  We can  
also coordinate among CGL member companies working to improve  
different areas.


Q.  Isn't SCOPE a competitor?

A.  Somewhat, but that's OK.  The majority of SCOPE members are also  
members of the LF.  I have heard from several of them that they  
wanted to break away from CGL because it was too telecom focused,  
while SCOPE could address the needs of network equipment providers.   
Other SCOPE members have different motivations.

At the LF, we understand that trade groups and standards consortia  
are a marketplace.  For any given project, companies normally have a  
choice of several different consortia, or of starting a new one.  We  
see no need for the LF to be the sole consortium for anything  
touching Linux.  Competition makes us more responsive.  We are also  
happy to work with other consortia when it is helpful.


Q.  You're trying to sound flexible, but doesn't the LF impose a lot  
of restrictions?

A.  We are aiming for the LF to be a very easy group to work with.   
We do, however, try to follow these guidelines for all of the work  
that we sponsor:

+ We believe that mailing lists should be publicly accessible and  
that participation should be open to anyone, not just paying  
members.  We think the IETF has shown the value of opening up  
participation to anyone interested.  In reality, it is largely vendor- 
supported engineers who are available to do the heavy lifting, but we  
think there's a big value to transparency and working in the open.   
It keeps the community in the loop, which makes them more cooperative  
when we ask things of them.

+ All code that we produce is licensed under an open source license,  
and all content under an open content license.  Code should be in the  
form of a patch to the latest mainline of the kernel or the relevant  
package.  If we submit a patch, and fail to convince the maintainers  
to accept it, we plan to drop the work.  The Linux ecosystem has a  
methodology that we believe in and want to follow.  That occasionally  
means that valuable work we have performed will be dropped on the  
floor.  That's a reasonable tradeoff for the value of not having to  
maintain a fork.

+ Other reasonable output is an LSB module (optional or required),  
test suites, documentation, whitepapers, or analysis documents.  All  
of these will be published under an open source or open content license.

+ Our aim is to get support from the relevant communities and every  
major distro for whatever work is produced.  That doesn't mean that  
each distro or developer gets a veto, but it does imply a very large  
effort at collaboration with the distros and the relevant kernel  
subsystem or package maintainers.


Q.  When can we talk more about this?

A.  Obviously, here on the mailing list.  But if SCOPE would invite  
me to the meeting in Stockholm next week, I would be happy to attend  
and get a chance to discuss these issues with all of you there.


Q.  What about the LF Collaboration Summit?

A.  It's June 13 to 15 in Mountain View.  All CGL members are  
invited, as are other critical community members on a case-by-case  
basis.  <http://www.linux-foundation.org/en/ 
Linux_Foundation_Collaboration_Summit>.  We'd like to do a CGL  
session on Friday, June 15.


            - dan
-- 
Dan Kohn <mailto:dan@xxxxxxxxxxx>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>