Re: Help Planning For Upcoming AdBoard Meeting

[Brian Cameron <Brian Cameron Sun COM>]

Dave:

> Brian Cameron wrote:
> > The next GNOME Advisory Board meeting will be on December 17th.  The
> > topic of the meeting will be "Upstream/Downstream" and will focus on ways
> > that various distros can cooperate and work better with the upstream
> > communities.
>
> It's an important opportunity, I would say, to figure out what is
> holding any such co-operation back.
>
> Part of what makes it difficult to work with upstream is that people
> think of themselves as "downstream" - having the GNOME guys working for
> Canonical think of themselves as GNOME guys, and submitting work to SVN
> as it gets done, rather than after its release, is important.

Many times, a distro wants to add special features to the desktop that are
somewhat specific to how things work on a particular OS.  Distros often
diverge in areas such as package management, policy management, system
configuration, etc.  I think many of the 10,000 line patches that you
discuss later tend to relate to these sorts of differences.

From my experience, it is often difficult to get distro specific changes
upstream.  So, I think distros can be tempted to develop their own code
rather than working with the upstream community to develop an infrastructure
that is flexible enough to work with different mechanisms.  In many cases,
the upstream community may not see the value in doing work that might seem
to only benefit some users.

While this is probably pragmatic, it does not necessarily encourage distros
to engage in more constructive ways.  If distros find the upstream community
disinterested or unwilling to make the code work in a flexible way, they
could understandably get the feeling that if they need to do anything
unique, why bother trying to work with upstream.

> But that sometimes conflicts with product schedules... if you submit a
> feature upstream and it doesn't get reviewed straight away, or it's good
> enough for you but not for the maintainers, you may not have time to
> make suggested changes in your release planning.
>
> This is something that downstream can work on - it's about creating
> community identity, perhaps to the detriment of corporate identity.  I
> remember the days when it was Ximian vs RedHat vs Sun on most technical
> decisions that were in any way controversial, and we paid for that in
> terms of progress for a couple of years. To make hard choices you need
> to get past gang wars and have a real GNOME identity, and think about
> "we can't ship that" afterwards.

Perhaps it would be educational to dig a bit more deeply into those
past controversies, review them, and better understand what went right
and wrong.  Aside from the controversy around Mono, I am not aware of
any serious controversy that I would think caused us to pay years worth
of progress.  Could you give some examples?

> Attacking this idea from the other end, it must be obvious to someone
> coming from downstream how they become part of the community they're
> interested in, and how they gain the influence they need to do their
> jobs while working upstream.
>
> Increasing the transparency of the governance for various GNOME-related
> products is a good idea - for example, who decides what goes on the GTK+
> roadmap? What is the release management? Who are the maintainers? How do
> I get to be a maintainer? I'm working for Motorola and I have a 10,000
> line diff that implements a dozen features we needed, what is the best
> way for me to go about getting those features upstream, and becoming an
> influencer of the project so that I don't build up another 10,000 line
> diff during the next release cycle?

Transparency is part of the solution, but I think the problem is also
that the GNOME community does not have very strong top-down management.
This may be a good thing in some ways, but when conflicts arise it can
be hard for a distro to engage and work with the community to find a
reasonable compromise.  If, for example, I work for a distro and have
a patch which I want to get upstream and find the maintainer disinterested
in my patch or unwilling to work with me, what do I do?  In the absence
of apparent options, maintaining a downstream patch might seem the only
option.  If such conflicts tend to degrade into flame wars when discussed
on public forums, distros could get the impression that their needs or
concerns aren't really taken seriously by the overall community.

At Sun, these sorts of conflicts tend to get aired and discussed during
our architecture review process.  Having a group of dedicated experienced
senior engineers who oversee and try to keep the concerns of all affected
parties in mind often helps Sun to move forward in a healthy way when
conflicts arise.  The GNOME community does not really have any sort of
proactive review process.  Considering the size of GNOME, it is probably
inevitable that conflicts will arise when engineering decisions are made
without taking full considerations of how they will affect everyone.

I am not sure if such a review process would help the GNOME community in
general, but just to give an example of what I mean by "top-down
management", using Sun's process as an example.

> You can do a lot of work on pretty much every product in the GNOME big
> tent - we have a variety of governance models from committee to
> company-led to individual benevolent dictator - and on top of it all is
> the GNOME release process and governance.
>
> To encourage upstream/downstream co-operation, the doors should all be
> clearly labelled. I'm not saying that we should make it *easy* for
> someone to become a maintainer of a platform library, but that the cost
> of becoming a maintainer should be easy to evaluate.

In general, I think the focus of your email is that the burden of making
things work well is on the downstream participants.  I think this is
mostly true today, and most distros probably do a reasonable job of figuring
out how to make things work for themselves.  However, perhaps we should also
be thinking about how the upstream community could also be more involved and
foster and encourage cooperation, and provide more clear forums that can
address conflicts when they arise in more constructive ways?

Brian