Re: Generating excitement in GNOME

["Elijah Newren" <newren gmail com>]

On 4/17/07, John (J5) Palmieri <johnp redhat com> wrote:
> I am sure you guys are well aware that many people found our last few
> releases boring.  I have argued that boring is actually good as people
> are working on the less sexy bits so that GNOME becomes more stable and
> that the more sexy bits are being work on but have yet to be proposed or
> are just not ready for inclusion into GNOME.

My opinion is that this is mostly a function of lack of "sneak peek"
articles (that Davyd used to make) and a drop in the effort that went
into the release notes.  Compare
http://www.gnome.org/start/2.18/notes/en/ with
http://www.gnome.org/start/2.14/notes/en/.  People aren't going to dig
into GNOME to found out all the differences themselves; they're often
going to form opnions of the new release before even trying it based
on what they read.  If we don't provide them much information, they'll
believe not much was done.

I may be wrong, but that's my (possibly unfounded) guess on the crux
of the problem.

That said, I do think other changes may be helpful too.  So I'll try
to add some other comments.

> That being said I don't think the problem is sexy things aren't
> happening in GNOME but that we just don't advertise them.  Things like
> telepathy, gimme and bigboard.  Many people also fail to start projects
> because they think the rejection from not being in GNOME means they will
> never be part of GNOME.  It also sucks because we land API's in a
> release but no one uses them because they weren't in previous releases
> so no one experimented with them.

Yeah, I think we're on a similar wavelength here.  Going off on a
slight tangent, Dave Neary has been talking for a little while about
making the GNOME tent bigger (which might mean officially including
the sexy closely-related-to-GNOME projects).  He wrote up some of his
ideas at http://live.gnome.org/ReleaseSets (which I just stumbled upon
randomly; I haven't talked to him about it).  I'd like to hear your
thoughts (and everyone else's) on those ideas of his.  There may be
other similarities to what you are proposing below...

> I was talking about this to Keith Packard and jg waiting for a flight
> from Sao Paulo airport and came to the conclusion that we should have
> some sort of RFC module or futures track which proposed applications and
> API's would be able to be part of the release with the caveat that they
> may not be fully adopted or if they are may look completely different
> once they are accepted into one of the other modules.
>
> For instance putting the NetworkManager API's in here would allow us to
> formally put constraints on acceptance into the platform, give the NM
> developers a sign that if they do the right things it will get in and
> give developers a sign that they can optionally depend on it with the
> knowledge that API's may change. We did something similar with D-Bus'
> DBUS_API_SUBJECT_TO_CHANGE macro.  While some people complained about
> changing API's we could just shoo them off by telling them they agreed
> to it.  The benefits of such were that people experimented and everyone
> knew D-Bus would eventually become a household API.  It allowed D-Bus to
> mature much faster.
>
> What do people think?

I'm not sure I follow.  For example, libwnck has such a flag
(WNCK_I_KNOW_THIS_IS_UNSTABLE) and was long ago accepted into the
desktop.  What's the difference between your suggestion and what was
done with libwnck (other than the fact that libwnck wouldn't be in
'desktop' but something else)?  gstreamer is similar too...

Also, your example seems to be covering the future-track-platform side
of things, but I'm not sure how future-track-desktop (i.e. apps
instead of libraries) work.  Could you clarify?  Sorry if I'm missing
anything obvious but I don't feel I'm following your proposal.


It's awesome to see someone thinking about this and trying to tackle it.  :)

Cheeers,
Elijah