Re: Questions To Answer

Jim Gettys wrote:
> I think there are two thingsbeing confused here: we touched on this at
> Usenix...
> There is:
>   1) technical governance of the gnome project... Releases,
>      standardization of key API's, what gnome is/isn't, all that
>      stuff...
>   2) What various companies may want/need to be able to cooperate
>      in furthering Gnome (e.g. joint marketing arrangements, etc.).
> I think it very advisable to keep these two problems very separated.

Yes, exactly. IMO "project governance" should be focused on developers
and other interested parties (testers, documentation writers, etc.)
considered as individual contributors to the project (not as
representatives of any companies who might happen to employ them). The
end goal of project governance is to help ensure the technical success
of GNOME as a project.

OTOH "project marketing" (for lack of a better term) should be focused
on companies and individuals leveraging GNOME in some commercial
context. The end goal of "project marketing" is to help ensure the
commercial success of GNOME and GNOME add-ons and spinoffs.

> 1) is the harder problem: here we have ducks to heard, but we don't have
> large amounts of funds needed.... I personally think there is alot that
> can be learned by how the IETF gets run here.  Any organization should
> by its nature be international in scope (as the IETF is).

Understood and agreed. However there's a distinction here which is IMO
relevant to the previous "US/non-US" discussion: "Formal governance
structure" is not identical to "incorporated legal entity". As I
understand it, the IETF formal governance structure is international in
scope, but organizationally the various IETF bodies (IESG, IAB, etc.)
are chartered by the Internet Society, which is a nonprofit organization
chartered in the US:

So the IETF per se is not US-based, but ISOC as a legal entity
ultimately is US-based (although ISOC may also have acquired some formal
international legal aspect as well by now -- others may know more than I
in this respect). However ISOC being a US-based entity does not prevent
ISOC from having board members or officers who are located outside the
US, or from having offices outside the US. 

Now in the case of GNOME I think it's an open question whether the
developer governance bodies (the GNOME equivalents to the various IETF
bodies) need to be rooted in a formal legal entity. The Apache project
does this; are their reasons for doing so also applicable to GNOME?

And per Jim Gettys' comments about separate issues, I think the issue of
having a legal entity underlying GNOME project governance is a separate
question from the issue of having a legal entity underlying the GNOME
"project marketing" functions.

> 2) is something the vendors can/should do among themselves: to avoid U.S.
> anti-trust law, there are consortia arrangements possible of various sorts
> possible, and I expect the big companies know alot more about how this
> gets put together than the hacker community concerned with problem 1).
> Potentially large amounts of money gets involved here, and there gets
> to be lots of heat involved due to the money involved

In the case of the "marketing" functions, I think you can definitely
make a case for having a formal legal entity.

> I think it a mistake to mix the two: the two were mixed in the X consortium,
> are mixed to some degree in the Web consortium; some of the reasons, (quite good
> at the time) for this in the X consortium case DO NOT apply anymore, as
> the Internet has allowed a fundamentally new style of software development
> to take place; the unintended consequences of this were very bad to X in
> the long run...

My primary experience has been with a project (Mozilla) that started out
as a completely corporate effort and had to struggle mightily to get to
a point where it had some credibility as an independent and open project
(and it's still not all the way there), so I'm quite sensitized to the
potential dangers of corporate involvement in an ostensibly
non-corporate development project. That's why I too would recommend a
separation of functions and structures.

The fact is that there are plenty of ways that corporations will be able
to influence the technical direction of the GNOME project: They can hire
GNOME developers, they can fund GNOME development internally or through
contractors, they can make their needs and wants known to the various
GNOME development teams, etc. However at the end of the day I think the
project will be best off from a technical and developer point of view if
its long-term technical directions and day-to-day development-related
decisions are made by developers acting as developers. The "project
marketing" structures should provide a way for corporations to interact
with GNOME developers and other contributors in a formal and hopefully
productive way while respecting contributors' independence and authority
within the development project itself.

Frank Hecker            work:        home:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]