NLD10 and GNOME

Hi all,

Just a quick question to anyone who may be in the know. After seeing
the NLD10 videos, it seems the GNOME in there is rather similar to the
mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/

I made a comparison in a blog post at
http://www.jonobacon.org/viewcomments.php?id=637 to outline the point.

Do we know if these radical changes to GNOME have been implemented,
and if so, are the changes coming back to the community?

Cheers,

  Jono

Re: NLD10 and GNOME

On Tue, 2006-02-07 at 10:43 +0000, Jono Bacon wrote:
> Hi all,
> 
> Just a quick question to anyone who may be in the know. After seeing
> the NLD10 videos, it seems the GNOME in there is rather similar to the
> mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/

Indeed, these mockups were made internally at Novell by the UI team
(same guys that brought you betterdesktop).

> I made a comparison in a blog post at
> http://www.jonobacon.org/viewcomments.php?id=637 to outline the point.
> 
> Do we know if these radical changes to GNOME have been implemented,
> and if so, are the changes coming back to the community?

The changes that were implemented were not as radical as the mockups.
Basically what Nat F. showed in Paris is what was implemented.  The code
will be released to the community soon.

-JP
-- 
JP Rosevear <jpr novell com>
Novell, Inc.

Re: NLD10 and GNOME

On 2/7/06, JP Rosevear <jpr novell com> wrote:
> On Tue, 2006-02-07 at 10:43 +0000, Jono Bacon wrote:
> > Hi all,
> >
> > Just a quick question to anyone who may be in the know. After seeing
> > the NLD10 videos, it seems the GNOME in there is rather similar to the
> > mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/
>
> Indeed, these mockups were made internally at Novell by the UI team
> (same guys that brought you betterdesktop).
>
> > I made a comparison in a blog post at
> > http://www.jonobacon.org/viewcomments.php?id=637 to outline the point.
> >
> > Do we know if these radical changes to GNOME have been implemented,
> > and if so, are the changes coming back to the community?
>
> The changes that were implemented were not as radical as the mockups.
> Basically what Nat F. showed in Paris is what was implemented.  The code
> will be released to the community soon.

To ask the obvious question, why not now, and why not discussed
publicly earlier?

Luis

Re: NLD10 and GNOME

Luis Villa wrote:
> On 2/7/06, JP Rosevear <jpr novell com> wrote:
>> The changes that were implemented were not as radical as the
>> mockups. Basically what Nat F. showed in Paris is what was
>> implemented.  The code will be released to the community soon.
> 
> To ask the obvious question, why not now, and why not discussed 
> publicly earlier?

So here's my (ie, not Novell's) answer.

Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
pick.

Although the changes aren't nearly as radical as the original mockups,
they are a big change from the current GNOME panel menu. If we had
proposed the changes on the mailing lists, it would have started a huge
discussion about what people hated about the design ("you can't make the
panel menu depend on beagle!!!") and how it should be different. And
then we could have either (a) completely ignored everyone and done it
ourselves anyway, or (b) had a long conversation about the merits of the
design and then not actually finished the code in time for NLD10.

So we did it ourselves, and now either GNOME will like what we did, in
which case, yay, free code for GNOME, or GNOME won't like what we did,
in which case, no harm no foul for GNOME, and yay, brand differentiation
for Novell. (And anyone who yells "fork" deserves to get one stuck in them.)


An equivalent answer to the question is "because you can't do design by
committee". Everything good in GNOME is good because one person or a
small number of people working closely together made it good. Much of
what is bad in GNOME is bad because lots of people have contributed
without having a single vision of what the end result is supposed to be.
I mean, look at the stuff John Williams has been blogging about the last
week[3]:

    * Evolution's UI blocking on I/O SUCKS. Due to lack of design in the
      early stages of development

    * Evolution's integration with gaim and tomboy RULES. Both of these
      happened because specific people (ChipX86, orph) made them happen.

    * Multimedia integration SUCKS. No one has ever sat down and tried
      to fix the big picture. (Although I think the gstreamer team is in
      the process of doing this now?)

    * Apps not remembering their window size and position SUCKS. Again,
      needs someone to take this problem and make it their own. I
      remember xkahn was trying to fix this a few years ago, but never
      finished.

    * Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But
      as more and more people added more and more features without
      looking at the big picture, it got unwieldy. (But now a small
      team is putting the simplicity back in again.)

    * Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle
      RULES (trow and joe). None of these was done *exclusively* by
      those people, but each of them reflects one person's (or a few
      people's) vision, as opposed to the current state of bug buddy,
      which just sort of happened.

This is just another aspect of the UI "simplicity" thing. We like UIs
that try to do the right thing (metacity, epiphany/firefox, evince)
rather than UIs that try to make every possible user happy
(enlightenment, mozilla, gpdf/acroread). If you try to design something
by committee, you either have to end up with the latter sort of messy
does-everything UI, or you ignore and hence piss off a large chunk of
the committee.

And that's where we are with NLD. There is no way that everyone in the
GNOME community is going to like the changes we wanted to make. But we
did the user testing, and we believe in it, and we want to make the
changes anyway. So we're doing it. Maybe it will turn out good, and
maybe it will turn out bad. Either way, the GNOME community learns from
it. Think of it like this: wouldn't it have been cool if we could have
tried out spatialus on our users, found out that they hated it, and then
reverted back to browserlus, without ever having to actually piss off
our users? This is essentially what is going to happen with NLD10. If
Novell's customers like the NLD changes, then GNOME can adopt them. If
Novell's customers don't like the changes, then GNOME can stand off to
the side and say "yeah well, we never liked that UI anyway. Not at all
like how we would have done it." :-)

But some people will still say "But couldn't you have discussed it with
the community before doing it?" No, we couldn't. If we had, it would
either not have happened, or it would have sucked. It's inevitable. It's
not a problem with the GNOME community, it's a problem with communities
in general. The wisdom of crowds[4] only works in situations where there
are clear right and wrong answers. If you try to apply it to a design
problem, where there are many entirely different right answers, then you
end up with a wrong answer. Always[5].


So to sum up: design by committee is bad, endless debates that result in
code not actually being written are bad, design by very small teams is
good, software with a unified vision is good, trying out cool new UI
ideas is good, free code at least doesn't suck, and of course, for
Novell, not shipping NLD10 is bad. I don't think there's anything we
could have done to get more of the good without also getting more of the
bad.

-- Dan


[1] http://www.unixguide.net/freebsd/faq/16.19.shtml
[2] http://www.userland.com/whatIsStopEnergy
[3] http://gnomerocksmyworld.blogspot.com/, Jan 29 to Feb 6
[4] http://www.amazon.com/gp/product/0385721706/102-7630748-5396113
[5] http://www.diacenter.org/km/usa/most.html

Sorry State [Was: NLD10 and GNOME]

<quote who="Dan Winship">

> Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
> pick.

This is a very sorry state of affairs for GNOME. But it is not only Novell
and its employees who have adopted this commons-sapping, community-tearing,
morally and intellectually lazy approach to open design and development in
GNOME.

In contributing organisations, it is rationalised as a faster approach, a
way to avoid massive discussions about inanities, and top of the list in
these modern times, a way to avoid "design by committee" or "stop energy".
How on Earth *do* we manage design out in the open? It is easier to avoid
that question, in the name of getting things done.

Outside the contributing organisations, it's appeased as something we have
to accept to get the cool stuff, and a side-effect of our ability to involve
contributing organisations, who have their own priorities. It sounds a lot
like, "don't bite the hand that feeds you", whether that hand is delivering
cool drops of code, or your pay packet.

But ultimately, this is *killing our community*.

And it must be fought.

- Jeff

-- 
II OSWC: Malaga, Spain             http://www.opensourceworldconference.com/
 
   "You put on the pants, and the pants start telling you what to do." -
                                    Bono

Design by Community

On Wed, 2006-02-08 at 12:16 +1100, Jeff Waugh wrote:
> <quote who="Dan Winship">
> 
> > Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
> > pick.
[...]

Then Dan said a lot of stuff that I thought was Very Insightful and Wise.

> This is a very sorry state of affairs for GNOME. But it is not only Novell
> and its employees who have adopted this commons-sapping, community-tearing,
> morally and intellectually lazy approach to open design and development in
> GNOME.
[snip]
> But ultimately, this is *killing our community*.
> 
> And it must be fought.

I take Jeff's point as well, although personally I would not have put it
in such emotive terms.

Would a compromise be to design and implement stuff like this out in the
open and send comments/stop energy/suggestions from people on crack
to /dev/null?  

Then, if someone wanted to actually help (addressing Elijah's point, I
think) they would at least know what was going on and how to get
involved with helping (as opposed to criticising)?

Dan and Jeff are both right: design by committee is sub-optimal, and
keeping things secret in the FOSS world is bad form.

Of course, if Novell is taking this course for purely commercial
reasons, the criticism from the FOSS viewpoint will fall on deaf ears (I
suppose).

One more point that deserves to be emphasised: all (okay, "all" may be
an exaggeration) the really cool stuff the the GNOME "community" has
produced lately seems to be the result of hackers being paid to hack on
GNOME, rather than the traditional
hacker-scratching-personal-itch-in-spare-time stereotype (or myth?).  I
am thinking Evolution, DBUS, F-spot, XGL, Gstreamer, etc. here.

Re: Design by Community

<quote who="John Williams">

> I take Jeff's point as well, although personally I would not have put it
> in such emotive terms.

I put it in emotive terms because *someone* has to offset all the hugging
and back-slapping about Dan's mail. All this positivity about a mail that
basically says "this community shit is too hard! fuck it!", and just puts
that meme right back in centre square. Nat and Miguel blogging about it as
if it were an epiphany. Those two form some kind of leadership perspective
in GNOME, and look at what they're cheering about...

Deeply unimpressed.

- Jeff

-- 
FOSDEM 2006: Brussels, Belgium                    http://www.fosdem.org/2006
 
    "From my observation, when it comes to porting Linux to a particular
           device, a point doesn't appear to be necessary." - mpt

Re: Design by Community

> I put it in emotive terms because *someone* has to offset all the
> hugging and back-slapping about Dan's mail.

Er. Yeah well.

Anyway, I just reread Jono's original message and corresponding blog post
again, and it still seems to me that he was talking solely about the GNOME-
UI-related stuff in NLD10 (ie, the new panel menu replacement), and that's
what I assumed we were all talking about when I replied. But it seems to
me now that everyone other than me (and possibly Jono) is actually
talking about Xgl, and I have no comment on that.

(OTOH, if you really were saying that Novell's writing a replacement
for the panel menu was "commons-sapping, community-tearing, morally and
intellectually lazy", then by all means, let me know so I can write a
suitably rude reply. :)

-- Dan

Re: Design by Community

It isn't about "Design by community" but "Design IN the community". The
former assumes everyone has something useful to say, the latter merely
recognizes the value of code review, security checking, third party
input that -may- be valuable, and possibly getting help.

If you design stuff in secret then publish it, it will have no review of
quality, no style checking, no security audit, no extra pairs of eyes
and extra brains on it. Mouths are in oversupply but brains/eyes are
not.

Metacity and Nautilus have had many suggestions made and many of those
went into the bin, but people were able to work on it, to build
complementary tools and to help.

Re: Design by Community

On Wed, Feb 08, 2006 at 12:53:52PM +1100, Jeff Waugh wrote:
> <quote who="John Williams">
> 
> > I take Jeff's point as well, although personally I would not have put it
> > in such emotive terms.
> 
> I put it in emotive terms because *someone* has to offset all the hugging
> and back-slapping about Dan's mail. All this positivity about a mail that
> basically says "this community shit is too hard! fuck it!", and just puts
> that meme right back in centre square. Nat and Miguel blogging about it as
> if it were an epiphany. Those two form some kind of leadership perspective
> in GNOME, and look at what they're cheering about...

You've nailed the issue here, Jeff.

What I don't understand is that even if Novell want to develop new
ideas in house, why does this work take so long to bubble to the
surface?

This is the same as Novell's netapplet: people saw hints that this
piece of software existed in screenshots of desktops &c, but
software was still not released.

You can talk about stop energy, but nothing is stopping you doing
the work. What I don't understand (and this doesn't just apply to
Novell) is why that patch couldn't have appeared in the open when it
was written: "here is an idea we've been tossing around at Novell
for a new panel menu", rather than only finding out through leaks
and screenshots.

For the sake of the community; share, and share alike. Otherwise,
one day there will be no community, there will be only corporates in
competition for mind-share, you will have lost the unified product,
the unified experience and no longer benefit from each other's
successes.

This course of action will create a time when GNOME goes the way of
propriortary UNIX: Tru64, Solaris, AIX, HP-UX, IRIX... imagine a
world with Novell Desktop, Topaz, Java Desktop, the Hatrack Environment:
all competing products... where is GNOME?

--d

-- 
Davyd Madeley

http://www.davyd.id.au/
08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA

Re: Design by Community

On Wed, 2006-02-08 at 12:57 +0800, Davyd Madeley wrote:
> 
> This course of action will create a time when GNOME goes the way of
> propriortary UNIX: Tru64, Solaris, AIX, HP-UX, IRIX... imagine a
> world with Novell Desktop, Topaz, Java Desktop, the Hatrack Environment:
> all competing products... where is GNOME?
> 
not if the changes are not kept proprietary and sent upstream sooner or
later.
-- 
Rodrigo Moya <rodrigo gnome-db org>

Re: Design by Community

On Mer, 2006-02-08 at 12:07 +0100, Rodrigo Moya wrote:
> > This course of action will create a time when GNOME goes the way of
> > propriortary UNIX: Tru64, Solaris, AIX, HP-UX, IRIX... imagine a
> > world with Novell Desktop, Topaz, Java Desktop, the Hatrack Environment:
> > all competing products... where is GNOME?
> > 
> not if the changes are not kept proprietary and sent upstream sooner or
> later.

Sorry have to disagree. If everyone writes a new replacement secret
suprise panel menu how are you going to merge them all when they come
out. Its too late by then, its forked and if the vendors are wedded to
their style and version its forked for good.

Re: Sorry State [Was: NLD10 and GNOME]

Em Qua, 2006-02-08 ās 12:16 +1100, Jeff Waugh escreveu:
> <quote who="Dan Winship">
> 
> > Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
> > pick.
> 
> This is a very sorry state of affairs for GNOME. But it is not only Novell
> and its employees who have adopted this commons-sapping, community-tearing,
> morally and intellectually lazy approach to open design and development in
> GNOME.
> 
> In contributing organisations, it is rationalised as a faster approach, a
> way to avoid massive discussions about inanities, and top of the list in
> these modern times, a way to avoid "design by committee" or "stop energy".
> How on Earth *do* we manage design out in the open? It is easier to avoid
> that question, in the name of getting things done.
> 
> Outside the contributing organisations, it's appeased as something we have
> to accept to get the cool stuff, and a side-effect of our ability to involve
> contributing organisations, who have their own priorities. It sounds a lot
> like, "don't bite the hand that feeds you", whether that hand is delivering
> cool drops of code, or your pay packet.
> 
> But ultimately, this is *killing our community*.
> 
> And it must be fought.
> 
> - Jeff
> 

I think the process used by Novell is very common in the GNOME community
(and Free Software in general).

For example take metacity. Sawfish was the default window manager, so
Havoc could have started a discussion
"should-our-window-manager-be-like-this-instead". But he didn't; what he
did was write metacity following the design he had in mind in a window
manager. Metacity was included in GNOME because most people adopted it
and agreed that Havoc's design was better for the default window
manager. 

The menu layout we use today is another example. If people had gone on
discussions about which is better - the foot or the "menu panel" -
perhaps things would have gone nowhere. But someone wrote the "menu
panel" and eventually it became the GNOME default.

Ubuntu has also done some changes in the panel, like the 'Add to Panel'
dialog. From what I remember this was first done in Ubuntu and after a
release using that configuration discussion started on the usability
list. Another example is the log out dialog on the right top corner of
the screen in Dapper, which wasn't proposed for discussion on
mail.gnome.org, it was just implemented there when GNOME uses the window
selector for the top right corner.

There are some people posting mockups of "GNOME 3" and to be honest I
see very little discussion about them. People know (or learn) that
unless they code these mockups or convince someone to do it then most
likely nothing will happen. But if someone comes up with a different
concept for the panel and translates that into code then the community
will review and pick it up or reject it. Spending time discussing the
design first would IMO be a waste of time if the person has it clear in
their head what they want from this hypothetical new panel. The review
process will still happen, just not before the design. The design might
even have small changes after suggestions from the community, but the
basic idea of the original author is what makes this good or bad design.

I'm not sure I agree that "you can't do design by comittee" but I would
agree that a lot of the good design decisions we see in GNOME today came
from only a few coders doing their vision. I'd love to play with the
code as soon as possible but maybe there are other reasons for it not
being released yet. What GNOME can do is encourage the companies making
changes in their development branches to at least commit the patches in
a CVS branch. 

There's also the issue of who you target with the changes. Novell might
find in a usability test that the menu they designed is a lot better for
their target audience but most people in the GNOME community would
reject it in favor of the current panel layout (I'm one for example).
Should that stop Novell from doing what's best for their customers
(people used to Windows but now using GNOME because their company went
with NLD)?

My 2c.

Cheers,
Evandro

Re: Sorry State [Was: NLD10 and GNOME]

On Wed, 2006-02-08 at 04:49 -0200, Evandro Fernandes Giovanini wrote:
> 
> There's also the issue of who you target with the changes. Novell might
> find in a usability test that the menu they designed is a lot better for
> their target audience but most people in the GNOME community would
> reject it in favor of the current panel layout (I'm one for example).
> Should that stop Novell from doing what's best for their customers
> (people used to Windows but now using GNOME because their company went
> with NLD)?

Since everyone must chime in on this thread ;-) and I'm not above a
potshot from the sidelines while not doing any work anymore, my comment
is that deciding the above, community-wide, is a much larger issue than
the one Jeff raises (or than whether we have XGL or panel changes at
all). In fact this question should define a project, rather than
defining a project as a particular set of tarballs and source code.

Is GNOME for UNIX and shell users? Is it for Linus Torvalds? Is it for
ourselves? Is it for American college students? 35-year-old corporate
office workers with an IT staff? And are we willing to tell whoever it's
*not* for to jump in a lake?

The blog thread this weekend brought up the old "are we too dumbed down,
not dumbed down enough, or just right" line of thinking which (apologies
to whoever feels offended) I find to be a shamefully lazy, wholly
misleading, and simply completely broken way to think about software. A
close second, which is the "let's be simple and avoid confusing people"
school of thought, is really just the same limited approach, rephrased
to sound better. Yes I've been guilty of it myself. Doesn't make it
right.

The replacement for this should be:
1) who, specifically, is the software for? (ideally much more specific
even than stuff like "technical vs. nontechnical users")  [1]
2) why, specifically, do they want to use it? what does it help them do
that they want to do?

Helping them do it without being confusing is a hygiene kind of thing,
like code maintainability; but doing something someone wants to do at
all, and knowing the who and what, is the first-order problem. And you
have to do something they want, that they can't already do, *considering
the entire reality of what software (and non-software) they are already
using*.

There's no way anyone can rearrange the panel menus and add eye candy,
in order to convert something appealing to nontechnical college kids
into an enterprise/corporate thing, or convert a
programmer/sysadmin/shell-user desktop into something plausible for
college kids. It's not about surface cosmetics, guys. The overall
direction needs to be in the roots of the project, it answers the
question what should the software _do_. What should it _be_. Should it
be a "desktop" at all? Going back to my blog posts last month, define
the hole, not the drill.

Until the project answers that, it will create building blocks that get
rearranged and reshuffled into other projects, whether NLD10 or Maemo or
Red Hat. The extent of the rearranging can be large or small.
No shame in that, but if that's the plan (as it _definitely_ is for e.g.
the Linux kernel) then suck it up and optimize the project for it.
Lots of times the kernel developers' thoughts and practices very much
assume this. They are writing a component for use by developers, not an
end-user product. And they aren't ashamed of it and they optimize for it
and they do it well.

Jeff, you're right that Steve Jobs style "big press release" is
incompatible with community development (though I don't think it's a
moral issue perhaps, I think it's legitimate to make the tradeoff as
long as one is willing to eat the consequences).  But the larger problem
right now is what I described above, the lack of direction; if the
community had that, they would just steamroll over the cosmetics coming
in from the Linux distributions.

And also a lot of "stop energy" would go away, because it usually arises
from lack of agreement on the big picture (which gets expressed through
nitpicking about details).

btw, choosing an audience and effectively making something for them
*will* alienate other audiences, possibly even losing the support of the
Linux distributions. That's the reality. Don't think you can move in a
direction without *not* moving in a different direction.

There _is_ a default audience if a project doesn't find a way to choose
one deliberately, and it's what I've called "by and for developers." If
there's no way to stay out of that gravity, it's better to embrace it
wholeheartedly IMO than to be there de facto and keep poking developers
in the eye. e.g. whether to expose paths in the UI; if most of your
users are shell users, GNOME probably made the wrong call. A developer
orientation could also concentrate on making the project a good building
block for integrators creating custom solutions, whether NLD or Maemo,
by modularizing it, making it customizable, and not flaming about the
customizations.

If you guys want a specific productive suggestion, I think these are two
de facto directions that could just be adopted; one is a kind of
building block platform shared among the GNOME desktop, Maemo, GPE, XFCE
even [2]; it might benefit from becoming explicitly targeted toward
multiple projects? Emphasize fd.org more. I don't know. Two is a GNOME
desktop that is still largely UNIX/shell-user/developer-oriented,
designed for the customers of today's Linux distributions. Focus on this
more and do it better.

If the community wants to go beyond these de facto directions, I think
it's possible, but only if people have the courage to commit to their
chosen audience and recognize that it means not serving some other
audiences. In the past, we lacked that courage for whatever reason.

If I could "do over" on GNOME 2 when I was heavily involved, I'd
advocate much more radically in a direction; would have pushed to either
completely drop the UNIX professional audience, or really design for
them as the primary.

In "The Inmates are Running the Asylum," there's a picture of a mutant
combination truck/sportscar/van/whatever, contrasted with focused car
designs like, say, a sports car or truck. That's what GNOME needs to
avoid. It's cool to make parts used in both sports cars and trucks; it's
cool to make sports cars; it's cool to make trucks; but nobody wants a
sports car with a truck bed on it. That's why you have to pick a
direction and stick to it.

I hate to be sounding all "in my day..." and "here are the lessons of
the past," but hell I'm almost 30.

Havoc


[1] One way to think of this is the old nautilus "user levels" feature
(novice, intermediate, advanced); the fallacy is the same as the "dumbed
down" debate, it assumes there's only one relevant dimension, call it
"1337ness"

In reality there are lots of relevant dimensions, such as age and
interests and personality and nationality and work vs. play and
historical computer usage and whatever. So if nautilus had modes for
"shell user administering UNIX systems," "college kid who doesn't like
computers but is used to Windows and DJs at night," etc., or even more
specific, that would have made a lot more sense, but it also would have
revealed the absurdity of trying to code for all those people at once.
And maybe caused someone to step back and ask which of these groups want
a Nautilus at all, and which might love something else we could write.

The old usability cliche "users are busy not stupid" is exactly right,
because the issue is that they are busy _doing something_ and they will
always only care about things they need to care about to do that thing.
So the relevant question is not whether they find something confusing,
but whether a specific person would _care_ about it at a particular
point in using the software. Much better to talk about "interestingness"
than "confusingness" when deciding what to strip down (not least because
interestingness is more obviously relative to the audience)

[2] This list (Maemo, XFCE, etc.) btw illustrates at least how different
a GNOME tuned to a specific audience would probably be from today's
GNOME. In fact those are still both fairly developer/technical oriented
projects and already feel pretty different.

Credit, Leadership and Vision [Was: Sorry State]

<quote who="Havoc Pennington">

> Jeff, you're right that Steve Jobs style "big press release" is
> incompatible with community development (though I don't think it's a moral
> issue perhaps, I think it's legitimate to make the tradeoff as long as one
> is willing to eat the consequences).

Hmm, so that wasn't a point that I was trying to make, and oddly enough, I
also disagree! ;-) I definitely think there is room for the contributing
companies to make sure they get credit for their contributions. Even with
"in community" development (as opposed to "by community" development, thanks
to Alan for an important clarification), I think it's doable and valuable.

> But the larger problem right now is what I described above, the lack of
> direction; if the community had that, they would just steamroll over the
> cosmetics coming in from the Linux distributions.

We are without coherent leadership. You emphasised having a vision/agenda in
your email, where I tend to emphasise leadership or structure, to aid in the
creation of that agenda.

Is this a chicken / egg problem that we have to solve?

- Jeff

-- 
FOSDEM 2006: Brussels, Belgium                    http://www.fosdem.org/2006
 
    Markets are what you sell bubbly health drinks, fluorescent blow up
                furniture and mobile phone ring melodies to.

Re: Credit, Leadership and Vision [Was: Sorry State]

On Thu, 2006-02-09 at 04:01 +1100, Jeff Waugh wrote:
> <quote who="Havoc Pennington">
> 
> > Jeff, you're right that Steve Jobs style "big press release" is
> > incompatible with community development (though I don't think it's a moral
> > issue perhaps, I think it's legitimate to make the tradeoff as long as one
> > is willing to eat the consequences).
> 
> Hmm, so that wasn't a point that I was trying to make, and oddly enough, I
> also disagree! ;-) I definitely think there is room for the contributing
> companies to make sure they get credit for their contributions. Even with
> "in community" development (as opposed to "by community" development, thanks
> to Alan for an important clarification), I think it's doable and valuable.
> 

Maybe it's my point and not yours ;-) but I don't think you can get the
giant media splash without secrecy (though this is relative; NLD10 got
the trade press, Steve Jobs got Time Magazine).

Credit with the community, sure, that's different. You get _more_ of
that working in the open.

Anyhow; I don't think the Apple/Google technique of hype-creation
through secrecy followed by splashy demo really works with the open
source development model, is all I'm saying. It can work with code that
happens to have an open source license.

> > But the larger problem right now is what I described above, the lack of
> > direction; if the community had that, they would just steamroll over the
> > cosmetics coming in from the Linux distributions.
> 
> We are without coherent leadership. You emphasised having a vision/agenda in
> your email, where I tend to emphasise leadership or structure, to aid in the
> creation of that agenda.
> 
> Is this a chicken / egg problem that we have to solve?

I don't really know the solution to be honest. It's not like I've solved
this.

It might be interesting to try the "no net leap of faith" approach;
immediately make some technical/branding decisions that are so severe
and heretical for direction A that the direction A users and developers
bail out, then go hardcore in direction B because direction A has been
sealed off for good. GNOME 2 made a lot of people threaten to bail out,
but didn't really commit to tossing people overboard.

Number of people you toss out depends on the direction chosen ;-) it
might not be that many.

Either way, why not focus on changing the front page of gnome.org where
it says "GNOME is a Unix and Linux desktop suite and development
platform." Make it say something someone could disagree with, or
something that implies a project direction. A good definition for a
project would not apply to competing projects as well.
http://gnome.org/about/ is pretty lame too, since it applies to almost
any software you can think of, in theory. It's like having the mission
statement "do stuff that's a good idea" or something.

Havoc

Re: Sorry State [Was: NLD10 and GNOME]

On Wed, 2006-02-08 at 11:28 -0500, Havoc Pennington wrote:
> If you guys want a specific productive suggestion, I think these are two
> de facto directions that could just be adopted; one is a kind of
> building block platform shared among the GNOME desktop, Maemo, GPE, XFCE
> even [2]; it might benefit from becoming explicitly targeted toward
> multiple projects? Emphasize fd.org more. I don't know. Two is a GNOME
> desktop that is still largely UNIX/shell-user/developer-oriented,
> designed for the customers of today's Linux distributions. Focus on this
> more and do it better.
> 
> If the community wants to go beyond these de facto directions, I think
> it's possible, but only if people have the courage to commit to their
> chosen audience and recognize that it means not serving some other
> audiences. In the past, we lacked that courage for whatever reason.

Good thinking, as always.

However, if we decide to target a niche audience, on a niche operating
system, that's niche squared. I doubt if that's sustainable.

Jon K�

Re: Sorry State [Was: NLD10 and GNOME]

On Wed, 2006-02-08 at 21:54 +0100, Jon K Hellan wrote:
> However, if we decide to target a niche audience, on a niche operating
> system, that's niche squared. I doubt if that's sustainable.
> 
Didn't say niche, I said specific. The group can still be large. There
are many, many well-defined subsets of the world's billions of people
that still contain a hell of a lot of people.

And the whole point here is to remove the nicheness of the software
(whether it's an OS, I don't know), by appealing strongly to a specific
group that wants to use it.

Would you expect a sports car with a truck bed to appeal to more people
than a regular truck or regular sports car? I would not.

Not choosing an audience doesn't mean you appeal to everyone. It means
you appeal to everyone in some ways *and* make everyone hate you in some
ways, so nobody really likes you overall. What you want to do is be sure
some group of people likes you in *almost all important respects*.

The fallacy is to think that indecisiveness avoids the decision and
leads to universal appeal. It does not. It leads to either a de facto
decision (best case), or a totally incoherent piece of software (worst
case).

Sure, the trick is in picking a group that's specific enough but not too
niche, and in trying to appeal to multiple "similar enough" groups,
while not breaking your appeal by chasing overly-dissimilar groups. But
life is full of judgment calls, no?

Havoc

Re: NLD10 and GNOME

So if Fedora, Ubuntu and every other Gnome using distribution also start
doing tons of private development then trying to jam it all in CVS
afterwards how do you expect Gnome to develop when all these variants
suddenely try and get merged and all overlap and clash.

Do you want to have situations where people play games like releasing
one day earlier than the other so they can check their stuff into
CVS/Subversion/whatever to block the 'opposition' ?

Nor does the committee argument stand up. It is perfectly possible to
post in advance that "we are going to do this, we've created a temporary
alternate repository for the work and if you want to join in or help
merge stuff back as it meets acceptability please sign up"


Alan

Re: NLD10 and GNOME

Alan Cox wrote:
> So if Fedora, Ubuntu and every other Gnome using distribution also start
> doing tons of private development

(Excluding Xgl, there was hardly "tons" of private development.)

> then trying to jam it all in CVS
> afterwards how do you expect Gnome to develop when all these variants
> suddenely try and get merged and all overlap and clash.

We don't. A lot of people have assumed that we're expecting to force the
new menu code into the GNOME mainline at some point, which I guess is a
reasonable assumption given what happened with Ximian Desktop, etc, but
that was never the plan here. At the moment we're not even planning to
ship it in SUSE 10.1 (which is 90% the same codebase as NLD10). The new
menu is something we did for NLD, and if the community wants it too,
then great, but we didn't do it with the expectation that they
necessarily would. It's like Industrial was.

> Nor does the committee argument stand up. It is perfectly possible to
> post in advance that "we are going to do this, we've created a temporary
> alternate repository for the work and if you want to join in or help
> merge stuff back as it meets acceptability please sign up"

Yes, I shouldn't have suggested that secrecy was a necessary part of the
mix. The secrecy doesn't necessarily help. But how does it actually
*hurt*? Yes, there are integration issues in some cases, but not in this
case. Yes, there are code review issues as you mentioned in another
message, but it's not like the GNOME community and/or Red Hat is
reviewing the work we do on YaST or iFolder or any of dozens of other
non-GNOME things, so that argument also feels weak. Novell has also been
doing tons of GNOME work in the open, so it's not like we're trying to
get a free ride off GNOME. So what exactly have we done wrong?

-- Dan