CGL and the Linux Foundation

[ibrahim.haddad@xxxxxxxxxxxx (Haddad Ibrahim-WPFT64)]

Hi Dan, all,

Thank you Dan for the FAQ. Below is some feedback.

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.

[IH]: 

-Helping win sales for NEPs and Distro and platform providers is not the
goal of "a neutral collaboration forum". I hope this is not an
advertised goal of LF.

-The ultimate goal of CGL is to improve Linux capabilities for the
teleco industry and accelerate Linux adoption and development. 

-I am happy to read that LF wants CGL to continue.

[Question]: 

-What are the current resources from which LF is willing to dedicate to
CGL??

--------------------------

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.

[IH]: 

-While it's great that LF leadership has ideas on how to implement parts
of CGL as LSB modules, I am worried if this is in line with members
needs.

-I strongly feel that the membership companies should be a part of this
decision-making process. Otherwise LF risks losing the democratic aspect
that OSDL has always prided itself on. 

-I would suggest to book time in the June F2F for a dialog with LF
leadership on this topic.

--------------------------

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
<http://www.linux-%20foundation.org/en/LSB_Charter> >.

[IH]: 

Again, for me it seems like forcing the LSB model to fit CGL. If it
doesn't look a natural fit, it ain't meant to be.

(CGL charter http://old.linux-foundation.org/docs/cgl_charter_2_0.pdf
<http://old.linux-foundation.org/docs/cgl_charter_2_0.pdf> ).

--------------------------

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/>
http://www.linux-foundation.org/en/
<http://www.linux-foundation.org/en/Registration> Registration to
register their compliance with CGL requirements.

[IH]: 

-The link above is missing instructions on how to register, who to
contact, what is the process, etc. 

-There is nothing in the page related to CGL 4.0 registration. 

-There is no explanation on the difference between CGL 3.2 and CGL 4.0
registration.

-There is no template to follow (as in past registrations)

-As a contact point for CGL, can you please make it an action item for
LF to update the web site to represent CGL 4.0 registration process?

--------------------------

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.

[IH]: 

-Examples of cost-effective ways to promote CGL 4.0 & its registration
process: 

a. improved web site

b. press release that announces CGL 4.0 readiness for registration

c. paper / article that presents CGL 4.0 release, delta with 3.2, etc 

d. presentation at LWE S.F. on CGL 4.0, spec status, cooperation with
SCOPE, ecosystem, deployments, etc 

Many of these were previously handled by Initiative Manager & Marketing
staff under the former OSDL structure. 

- As a contact point for CGL, can you please make it an action item for
LF - LF has a marketing officer on board who can drive these activities
in collaboration with member companies.

-I understand that LF may not want to enforce anything but LSB brand but
this is also debatable. Instead of building on CGL brand, LF leadership
is in fact taking a very aggressive position on branding, which should
be soften a bit and look into ways to leverage CGL brand for the good of
LF.

-As for "the LF is more interested in certification than registration":
CGL members went down this path several times and the result was always
the same: CGL should stay away from certification. In fact this
discussion came up every time there was a new CGL release. This
discussion and the decision of certification vs registration has always
been members-driven in the past, and should continue to be. 

--------------------------

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.

[IH]: 

- I agree that CGL members own the decision on what CGL should focus on.


- CGL already has a joint effort with SCOPE that does exactly what you
say above. 

- As for the requirements that will never get into mainline, I totally
disagree. If we look at earlier CGL versions, such as 2.0 or 3.1 from
2004/2005, the same arguments could have been made. However, today, most
of the reqs defined in 2004 and 2005 are, in fact, mainline. If it is
needed, it will be implemented.

--------------------------

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.

[IH]: 

-SCOPE is a not a competitor to CGL. In fact, if they are, then
following the same logic, SCOPE would be competitor to SA Forum and
PICMIG since SCOPE also publishes ATCA and MW profiles.

-SCOPE look at existing specs that fall under a CG platform architecture
and look for gaps and offer feedback on existing specs to industry and
forums in terms of 'Profile'. In CGL's case, SCOPE published 'Linux
Profile' which offered needed feedback from NEPs on how to improve CGL
specs and make it more relevant. CGL and SCOPE started to work together
(ie joint effort) and much of CGL 4.0 is a result of this joint work.

--------------------------

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.

[IH] = 

-"if it ain't broke, don't fix it": The topic of mailing lists was
debated when OSDL started and the working model was to have 2 types of
mailing lists: one shared only by members and another shared with anyone
who wants to participate. This model has proven successful for over 5
years. It was also discussed in NY early this year and decision was to
continue with what we had before.

-I can not see how applying IETF model for CGL will keep community in
the loop. This is highly debatable so I will skip discussing it.

+ 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.

[IH] = has always been the case. 

+ 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.

[IH] = 

And as much as I agree that a distro or a developer should not get a
veto, I also believe that we don't have to change the world and our
working methods to satisfy a distro ;-) 

--------------------------

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.

[IH]= 

-I would suggest to talk to CGL first before going to SCOPE. The June
F2F meeting is the place for it. Also Glenn is planning to setup calls
to discuss CGL future plans. That's another venue for this discussion
leading to the June F2F.

- Although many SCOPE members are CGL members. + I am not sure what
would be the talk/presentation to SCOPE about, especially that CGL is
already working with SCOPE.

--------------------------

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_Summi
t
<http://www.linux-foundation.org/en/Linux_Foundation_Collaboration_Summi
t> >. We'd like to do a CGL session on Friday, June 15.

--------------------------

 

I hope you find this feedback useful and help stimulate more discussion
on the various topics raised.

I will be on vacation until May 14 so you wont see much response from me
until I am back. My apologies for that...I will be prompt with my
replies as soon as I get back ;-)

With best regards.

Cheers all,

Ibrahim

 
Ibrahim Haddad, Ph.D.
Director of Portfolio Management
Motorola Software Group
Motorola Technology Office 
 
Phone: +1 514 394 7835
Mobile: +1 514 952 7835
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.linux-foundation.org/mailman/private/lf_carrier/attachments/20070501/0c7f9efb/attachment-0001.htm