[cgl_discussion] CGL

Mika Kukkonen mika at osdl.org
Mon Jan 26 09:43:53 PST 2004

Well, you have invoked the name of "CGL" on this mailing list, so
speak of the devil ... 

Seriously, one thing that has annoyed me beyond reason is that people
keep telling me that "CGL is evil because I read it somewhere", but when
I try to find where they read it, I almost always fail.

So may I suggest, that if you have any issues about CGL you want to 
discuss, you would CC cgl_discussion at osdl.org and/or me, or is that
too much courtesy to ask?

I am going to reference Jes's email, as it seems to be most on topic
of all items so far on this list:

> Let me try to make a long story short. Keep in mind that this is how I
> saw the whole CGL process perform, people who were closer to it might
> have a different view.

yes, I do :-)

> Basically how it went on was a closed forum with people from various
> industry groups sitting down behind closed doors writing a large spec

Let me give you some history: CGL and it predecessors existed way before
it was announced to be an OSDL working group January 2002, and before
that it _was_ a very closed and selected group of companies having the
same itch (namely use of Linux and OSS in telecom industry) and 
wondering how to scratch it. So it is no wonder, that it has taken some
time to transform the mind set of some management people to a more open

> of 'we want this this this and this' and then publishing it with a
> 'please implement all this for us'. Because it was done in the closed
> there was little to no communication with the kernel community, in

The CGL V1.0 doc reads like a shopping list, _because_ it is a shopping
list! It really was made with the mind set that it is a list of
requirements the telco companies would like to see the distro companies
to implement. 

You know, "implement these in your distro and we'll buy it" type
of thing. There _never_ was an expectation that the people in CGL were
hoping to get these features for free, and in fact around that time we
felt we would do many of those features ourselves (aka TLT/CGLE ...).

What comes to communication, it is a two way street, and we are all 
aware how ... interesting discussions on controversial topics can get
on LKML, and really, if you look at the _kernel_ features in V1.0, there
really is not much to write to LKML about in first place.

> particular a lack of discussions about what is feasible and realistic

Please feel free to give me some examples of priority 1 features that 
you feel are unfeasible and unrealistic.

> and in the little interest in adapting the spec once it was finally
> published (presumably due to the we already spent a lot of time
> wheeling dealing internaly over it, we don't want to change now). This

Now you totally lost me there; "adapting the spec" to what? What I do
agree with is that every committee type of work group (like CGL) has
more latencies than a group lead my a single dictator (you know, review
and voting stuff), but from the beginning we have been pining for some
real feedback from anybody out there, and as far as I recall there has
not been much technical feedback, just "we hate you, go away". The one
exception I remember is HCH's feedback on LKML, and that was 
professional and good.

> resulted in some pretty serious flaming from the community once the
> spec was finally out to the point where CGL is almost a swear word
> amongst developers.

And this still puzzles me; why you people feel so threatened and 
insulted by CGL? I mean all we have produced so far is couple documents
that you, the kernel developers, can just ignore. So why all this hate?

> Even for the people who wanted to try and contribute constructively,
> it was extremely painful, one had to deal with silly silly paper forms
> and snail mail just to get access to an 'Open Source' project.

The CGL Participation Agreement was created because OSDL felt that there
needs to be an agreement that makes sure that all documents CGL creates
are "free" of IPR problems, and it was also OSDL's idea to require this
on paper. I'll let Tim to go into more detail on that, if he wants.

> Ben really hit it smack on with his comment: "The whole 'closed
> working group from big companies' thing makes me sick".

Again, why? AFAIK, some of you people write NDA's to be able to work
on drivers, and some people work for distribution companies which also
have to deal with these big companies, which btw are called "paying 

I think it is OK to make fun of big companies and the stupid things
they do because of stupid middle managers who do not understand 
anything, but a sad fact of life is that a _lot_ of people get their
salary either directly or indirectly from these companies, and my
personal goal (as I still feel I am Linux advocate) is to direct some
of that money these companies to the "Linux ecosystem", so that this
wonderful thing called Linux and Open Source can continue to grow and 
flourish. If that makes me an evil guy in your eyes ... oh well.

> So sorry if this sounds a little harsh, however I believe that this is
> how a lot of people in the community feels about doing development
> this way. It just doesn't work. Even if you have a brilliant spec once
> you're done, you a likely to face a lot of resistance when you publish
> it as the community in general dislikes to be told what to do.

On the other hand, does it feel nice to hear that some people like your 
project and want to use it, and maybe in progress of doing it give you
some feedback and even contribute patches back. What you people do not
see is that there is _a_ lot of more in CGL than just me and bunch of
people that participate in CGL meetings. A lot of people in the member
companies are working on Linux and OSS related projects because of CGL
existence. Of course it can always be argued that projects like OpenHPI
(http://openhpi.sourceforge.net/) would exist even without CGL, but my
point is that most of the CGL member companies are working on Linux,
they just do not do it under CGL banner because of it's negative brand.

So one more time, it is very easy to say something is wrong, but it is
much more difficult to say how it should be fixed and then do it. I am
all ears for your ideas on CGL.


More information about the cgl_discussion mailing list