Re: Questions To Answer

[Havoc Pennington <hp redhat com>]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> Ok quick 10 point summary from browsing the archive
> 
> 0.	If your body is limited membership and contains all the core companies
> 	working on Gnome, sets policy and controls progress - isnt it a
> 	Cartel and therefore going to be very illegal if Gnome succeeds.
> 	In the US you need to set up the right kind of body for this. The
> 	LSB hit exactly this issue and you have to do things very carefully.
>

We're going to have to get lawyers to answer that one.
 
> 1.	If the foundation sets release dates does the US or the European one
> 	decide. What if they disagree. There are after all more of us than
> 	you. Perhaps we need an Asian one ?
>

The US organization will be the "GNOME leadership" and Europeans and
Asians will be on the board and in the membership. Affiliate
foundations will be purely for tax/money purposes, or to organize
local events if they want.
 
The problem is that we must have a legal entity that's the GNOME
leadership, for antitrust etc. There is no such thing as an
international foundation, except for a couple special cases like the
Red Cross that the UN has specifically written a treaty for or
something. So, if you have a better idea, then give it - but there's
really no alternative here. Foundations have to be in some nation.

> 2.	If the foundation sets release dates who is going to listen
> 

They are going to have to articulate a release date arrived at by
consensus among the maintainers. They can then flame people who break
the feature freezes. In a worst-case scenario they could punt a
project out of the release. That's about it. I think it will work
fine; it basically works now, with the steering committee.

> 3.	If the body is US based you need to budget for legal insurance
> 	covering everyone taking part in discussions.
> 

Another question for the lawyers.

> 4.	Collab.net is based in the USA. If we wish to involve europeans we
> 	must be sure that collab.net has an acceptable data protection
> 	policy. Brian I guess can provide a legally binding data protection
> 	agreement if collab.net are going to be hired for this.
> 

Question for collab.net.

> 5.	LWE is very US and very commercial. The board of directors should be
> 	put together electronically not according to who is at some crappy
> 	trade show.
>

We won't be assembling the board there; we just wanted to have a final
meeting and make an announcement. Interesting decisions should all be
made in advance on this list.
 
> 6.	The idea that Gnome foundation europe is regional and the US one is 
> 	superior is to say the least offensive to the rest of the world. There 
> 	should be a US and EU and Asian body of equal importance.  You draw 
> 	your board from the three bodies in proportion to membership.
> 
> 	Gnome US == Gnome EU == Gnome Asian == Gnome whatever
> 
>         The board elected across the three is what you need as your true
> 	board for big decisions.
> 
> 	Don't make the thing US centric. Right now its implied that the US
> 	one is superior. Well there are more of us than you ;)
> 

Not possible. The board must be a legal entity. Give us a way to do
that without preferring some nation, and you will have a point. ;-) As
it is, it's just wishful thinking.

> 7.	Your view of the functions of gnome foundation wont work in places
> 
> 	- development is not in control of anyone except those who do the work
> 	  Just ask the Debian people how much anyone actually listens to the
> 	  debian steering bodies
> 

I think the board is more about coordination than control. If you let
everyone do their own thing, a release will never happen, but people
are more or less willing to freeze features at a certain time if
there's a way to agree on the time. (Note that I said _freeze_, since
that date can be controlled, while _release_ can't always be.)

> 	- roadmaps depened on random people and random ideas. At best the
>           body can wave its arms and guess where it is going. It can 
>           definitely help on the API/ABI side.
> 

Yeah, the exact technical stuff that will appear is hard to plan; but
we can plan something like we have been so far, that is, when the
API/ABI can break and such.

>         - a single developer site doesnt work. There are patent, legal and other
>           issues preventing that. Not to mention that a single point of failure
>           sucks. 
> 

What is a "single developer site"?

> 	You need to accept the role of the gnome foundation is to run after
> 	development attempting to guide it from the rear and coping with
> 	whatever random diversions it takes on the way. Think of it as trying
> 	to steer a runaway truck by hanging onto the back bumper [1]
> 
> 8.	The LSB is turning into something intended to be an umbrella for more
> 	than just Linux standards. Someone should talk to Dan Quinlan and 
> 	figure out Gnomes relationship to the LSB. Including for example
> 	specifying binary ABI, compatibility paths for vendors using Gtk/Gnome.
> 

Indeed. This is maybe something the foundation can look at, once it
exists. I've talked with Dan some about an add-on "module" for the
LSB; we could have one desktop-independent module and another for
GNOME specifically.

Unfortunately this isn't going to happen until someone has a _lot_ of
time to devote to it. I can see the foundation funding something like
that.

> 9.	I'm very concerned that is all  Red Hat, Helix, Eazel, 'Mr X'. What
> 	the hell happened to Debian. The LSB made a special case for Debian,
> 	I think since Debian is a major Gnome 'reseller' the same has to be
> 	done here if the vendor members need to pay. Debian are not just part
> 	of 'the community' but something more.
> 

Well, right now there are no corporate members, only individual
members, so Debian is in the same role as all the companies.

If we come up with some more concrete details on the "corporate
advisory board" maybe we can look at how Debian fits in to
that. However in general I think we're talking about how organizations
that contribute to GNOME fit in, rather than talking about Linux
distributions. So we're ignoring commercial distributions that aren't
involved in GNOME also.

Havoc