Re: Current status

Joe Shaw <> writes: 
> Most of the members are employed by one of the 3 big GNOME companies (Red
> Hat, Helix Code, or Eazel). The people on the steering committee are
> supposed to represent certain modules. Unfortunately, I don't think this
> has been followed very faithfully and that those members have been more
> representative of their company than of the modules they represent.

Can you give an example of abandoning the community's best interests?
Also, we have at least Dan, James, and Kjartaan who are not employed
by the companies, and John wasn't originally, though I guess he is
now, I'm not sure.

> This
> causes a real conflict of interest. Now, I don't expect people not to
> represent the company they work for, but people who work for the same
> company will likely vote together. If members still represent modules,
> then whomever has the most modules will then be able to dictate policy,
> and I that is a very bad idea. 

Dropping the issue of companies (i.e. pretend for a minute all modules
are maintained by volunteers), it seems to me that _yes_ whoever
contributes the most code should have the most decision-making power.

If this gives too much power to certain companies (I'm not sure it
does, because there are lots of companies that generally disagree
rather than agree, and it appears more companies are joining), then we
should maybe look at mitigating it somehow; but I do think it makes
sense, as a starting point, to look at giving the most representation
to the largest contributors.

> Therefore, I think representation for that
> sort of thing should be done by company. The principle downside to this is
> that it becomes difficult (and unfair) to the individuals who work on and
> are as responsible for building GNOME as the rest of us. How can we
> represent them in a fair manner to both them and the companies?

If I understand you right, I don't think this is practical, because
almost all the key GNOME people are employed, or if not could become
employed at any time.  We can't remove all the key players from the
board because they work at companies; then the board just won't
matter, because the key players won't be on it.

One point: if you try to artificially move the decision-making power
away from those who are writing the code, then it just won't work
anyway, because if you can't follow through on decisions with code,
the decisions are irrelevant. Tying leadership to contributions is a
long-standing free software tradition, and for good reason, because it

> >  - a board of directors (replacing the current steering committee)
> >    would represent the project in discussions with companies and 
> >    that sort of thing. Their only real "power" will be to say 
> >    which modules are part of GNOME.
> >  - the group will be membership-based, where members vote on 
> >    the board of directors and also vote on major issues. 
> >    We will need some way to select the initial membership;
> >    additional members will be added by a vote of the current members.
> Just to clarify: these are two seperate entities, right? (well, obviously
> the people on the board will be members) How many people are we talking
> about for membership? 10? 20? 50? Are we talking hackers here, or others
> as well?

They are separate entitities. The other questions are up for
discussion, I have no idea. What do you think?
> >  - corporations can't be members, but some members may represent the 
> >    interests of corporations. In effect this means that if 
> >    corporations fund major contributors to GNOME, they'll get a 
> >    voice in the foundation via those contributors.
> Hmm. If we do have corporations as members, it might help alleviate my
> fear that the corporations will order the members to vote based on
> corporate agendas rather than on their own beliefs for the GNOME
> community. I mean, I would hope I would be a member, and hopefully if
> Helix Code has its own corporate representation, I wouldn't feel pressured
> to vote along with the company if I personally don't agree with its
> opinion.

This is going to have to be up to the individual company. We can't
make company X not pressure its employees. If a company decides to do
that, there's not really anything GNOME can do about it.

Perhaps worth noting, my impression so far is that the involved
companies are small enough that the hackers themselves are guiding
company policy. Certainly what I'd identify as the Red Hat position is
typically the result of conversations between the Red Hat GNOME

Proposal: Bart's suggestion for selecting the board may be a good
solution to this problem. He suggests that we try to pick a balanced
board that represents a variety of interests (we tried to do that with
the steering committee, mixing representatives from various technical
areas and various companies). Then the membership can vote on a
complete slate for the board. 

The intent here is to let people select a _balanced_ board that they
like as a whole, instead of getting 9 people that are all favored by
the majority faction. I'm not sure exactly how it would work, but this
does seem to make a balanced board more likely.

Another way to address your concerns is to have a relatively large
membership, rather than a relatively restricted one. I guess I'd say
though that the larger the membership, the more powerful I think the
board should be, generally speaking. This is after all a software
project, not a government; and some central power is worthwhile to get
vision and direction, IMO. (In my experience looking at Debian, people
apply government analogies far too often to this kind of thing; it's
not a government, it's an organization designed to get something

Also, with Debian there's no good way to speak only to a restricted
group like the steering committee; which means companies have to talk
either to the project leader only (Wichert), or they have to talk to
debian-private, which is 400 or so people. Wichert can't give them any
real answers or feedback since he's only one guy, and the whole
membership is just too large and public to talk to.


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