CGL and the Linux Foundation

[timo.jokiaho@xxxxxxx (timo.jokiaho@xxxxxxx)]

Dan, I will talk to SCOPE board today about the next steps. I am sure we
SCOPE would like
to meet with LF, either in our meeting next week in Stockholm or the
following meeting at the
end of June in Paris, two weeks after LF collaboration meeting.

Cheers

  TimoJ, SCOPE Alliance Technical Officer and Board Member



-----Original Message-----
From: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx 
[mailto:lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On 
Behalf Of ext Dan Kohn
Sent: 01 May, 2007 21:36
To: lf_carrier@xxxxxxxxxxxxxxxxxxxx
Subject: CGL and the Linux Foundation
Importance: High

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>

_______________________________________________
Lf_carrier mailing list
Lf_carrier@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/lf_carrier