Re: Question on community to the candidates.

[Josh Triplett <josh joshtriplett org>]

On Mon, May 25, 2015 at 09:16:02PM -0700, Sriram Ramkrishna wrote:
> It is my impression (and I state impression because I am providing no
> data) that GNOME has more reliance on people paid to work on GNOME
> than community.  I do not question the passion and dedication to those
> who are paid on GNOME, I know that they would do it as a community
> even if they were not paid.
>
> If you agree with my impression, what actions do you think would help
> increase participation in GNOME?  Participation in the core parts of
> GNOME is not trivial, and requires an enormous amount of time and
> dedication to get to become familiar with the huge codebase that we
> have, as well as gain the trust of the maintainer of the module you
> are interested in.
>
> If you disagree with my impression, what makes you believe that it is
> not the case? How would you change my mind?  I did not bring any data
> points, so you don't have to either.  I'm more interested in giving
> you a biased opinion and I want to know how you would react to it.

I do agree with your impression, though I don't necessarily consider
that a bug.  I think it's a feature that many people get paid to work on
GNOME.

However, I do think one of the incredible strengths of Free Software is
that anyone can contribute, regardless of who they work for.  And I
think it's critical that GNOME retain that property.  A project that has
an extensive set of paid contributors but alienates its community
contributors can rot from the root upward without fresh minds and
viewpoints joining in.  (If nothing else, where does one hire new paid
contributors *from* if not the comunity?)  I do not believe GNOME
systematically suffers from that problem, but I have seen signs of it
here and there.

The biggest thing I would suggest that GNOME do: ensure that
development, planning, and design of *all* GNOME projects occurs in the
open.  It's not enough to push commits to a public repository if taking
part in a project requires being part of the right private meeting.
Projects considered part of GNOME should ensure that the community has
visibility into where those projects are going, and an opportunity to
influence that direction.

That doesn't mean projects need to support incessant bikeshedding, nor
does it mean projects must follow a Linux-kernel-style "wherever the
contributions may lead us" evolutionary policy, but whatever vision a
project follows should be transparent to all prospective contributors.
If one or more companies are driving the development of a project and
are not interested in participating in an open development process, they
can host their periodic-code-drop project on their own site and not call
it part of GNOME.

Related to that, any project considered part of GNOME is ultimately a
collaborative part of the GNOME community, and not the personal fiefdom
of an individual maintainer.  The primary job of a maintainer is to
apply good taste, which *does* mean saying "no" quite often, but there
should always be a reason, and it should never be "because we're working
on something behind the scenes that we can't tell you about or let you
work on, go away".

I'm not going to point fingers at any particular project here, but I
have heard from many people who have become frustrated trying to
contribute to nominally GNOME projects due to problems like those.

- Josh Triplett