[Lf_carrier] CGL and the Linux Foundation
Dan Kohn
dan at dankohn.com
Tue May 1 11:35:57 PDT 2007
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 at dankohn.com>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/> <tel:+1-415-233-1000>
More information about the Lf_carrier
mailing list