Re: About writing new apps from scratch

[Allan Day <allanpday gmail com>]

Tristan Van Berkom <tristan upstairslabs com> wrote:
...
> To answer your concern, this is precisely why we have our module
> proposal period as a very important part of each release cycle.
>
> This means that, while there are always a hand full of alternatives,
> basically only one "video player", "photo manager" or "music player"
> or whatever is ever officially endorsed by the GNOME community as
> the "official" one.
>
> This helps to inspire a spirit of competition - so side projects,
> such as the ones you mention (GNOME Music and Photos) - can always
> challenge and propose their modules as official again and again.

As Fred has already noted, we still have open debates about new
features each cycle - and this includes the proposal of new apps.

Also, I have to say that I don't remember competition through module
inclusion being a major force in the GNOME application space, and
can't recall applications repeatedly battling it out through the
module inclusion process in a spirit of competition. (That actually
sounds quite unpleasant to me, and has none of the spirit of
cooperation and collaboration that I associate with the GNOME
project.)

> Also, through this transparency we attract lots of developers
> and contributors - GNOME is a community run project, decision
> making is not done by some factions in hidden corners and then
> conveniently "announced", but out in the open, every six months
> during our beloved module proposal period here on d-d-l.
>
> This transparency also helps to ensure diversity in maintainership
> and ultimately leadership - since modules which are endorsed as
> officially part of the GNOME release are chosen strictly on merit
> and not because some factions in GNOME have control of a given
> project and so can easily enforce some design decisions in those
> modules.
...

My main issue with the module inclusion process is that it prevented
us from operating in a design-led manner. Back in the day we had a
token usability project clause in the module inclusion requirements,
but in actuality the process encouraged a model where maintainers did
their own design with little coordination or project-wide design. It
also meant that accepted applications had a carte blanche for their
UX. When I compare that to what we have now [1], it is obvious to me
that nowadays we are in a much stronger position. Not only do we have
a high level of coordination, but designs for the core GNOME apps have
generated a lot of amount of activity: I count nine new core
applications in the GNOME 3 era, for example, of which six are
currently maintained by volunteers.

Where I do agree is that the module inclusion process created the
appearance of transparency - in that you could see debate happening on
a mailing list - which was probably reassuring to some parties, and
helped to publicise the open nature of the project (although the
nature of some of those debates probably didn't cast us in the best
light, either, and GNOME has a reputation for internal conflict partly
as a result, imo). The challenge for us right now might be to
advertise the ability for parties to get involved by making the
existing open decision making more visible, without impeding our
ability to move forward, either by reducing our ability to coordinate
or the empowerment of our contributors. I'm not sure what the answer
to that is, but it would be interesting to explore possible solutions.

Allan

[1] https://wiki.gnome.org/Design/Apps/