Re: Additional questions for the board candidates

[Philip Van Hoof <pvanhoof gnome org>]

Congratulations. You got my vote.

I don't think there's a lot, in your reply, I disagree with.

On Tue, 2005-11-29 at 14:19 -0600, Federico Mena Quintero wrote:
> On Wed, 2005-11-23 at 18:56 +0100, Philip Van Hoof wrote:
> 
> > How important are desktop standards for you. How will you attempt to let
> > the GNOME developers cooperate even more with the freedesktop.org
> > movement? Or do you dislike that movement? In in general: What should
> > GNOME "do" with fd.org?
> 
> Destkop standards are interesting when they let external developers make
> assumptions.  Can I drop a file in a well-known location, and be assured
> that a launcher for my app will appear in the panel/kicker/whatever?
> Can I, using $foo_toolkit, cut an image to the clipboard and be assured
> that $bar_toolkit will be able to paste it in an application?
> 
> Desktop standards would be *REALLY* interesting if each platform (GNOME,
> KDE, Mozilla, OpenOffice.org, etc.) provided a conformance test suite.
> Any of the GUI test suites based on the accessibility interfaces would
> be *great* for this.  Write an LDTP/Dogtail script to cut an image in
> the GIMP, paste it in OpenOffice, and ensure that it works.
> 
> Desktop standards are not interesting if they are not really implemented
> by the major players, or if they are implemented with too many
> idiosyncrasies or platform-specific extensions.  The MIME spec is a very
> sad example of this.
> 
> Thankfully, freedesktop.org is not about de-jure standards.  What we
> need is more people, in any of the platforms, to identify the issues
> that would benefit from standardization, *and to go ahead and write and
> implement the standards*.
> 
> GNOME should take the responsibility of figuring out what would benefit
> from standardization.  It should do this by establishing close contact
> with other big projects and finding common factors.  And it should help
> the implementation wherever possible.  See my rant on "superheroes"
> here:
> 
> http://primates.ximian.com/~federico/news-2005-06.html#20
> http://primates.ximian.com/~federico/news-2005-07.html#06
> 
> In particular, the second link has a tidbit from Microsoft's infamous
> Halloween Memos, which I'll quote again:
> 
> 	Integrative work across modules is the biggest cost encountered
> 	by OSS teams.
> 
> This is still true, and it is why standardizing things is so hard - no
> one wants to change their code to make use of a standard library.
> Someone has to go and do it for them.  This is why Fontconfig worked.
> 
> > Second question:
> > 
> > What will you do to further enhance cooperation with the KDE developers?
> > Will you invite them to our conferences? Will you pay their travel
> > expenses? Will you let them talk on GUADEC? Will you visit their
> > conferences and will you do a talk about cooperation at their
> > conferences? Or will you simply disregard them and think GNOME is
> > superior yadiyada (in which case I wont vote for you, by the way)?
> 
> We enhance cooperation by participating in the standards process.
> 
> And there's cross-pollination among conferences already, isn't there?
> 
> I cannot disregard them because my employer has a policy of supporting
> both desktops.
> 
> > And D-BUS is moving forward rapidly. This will introduce a lot new such
> > standards. Even D-BUS itself is such a standard of which it hasn't been
> > said that it's "the" IPC for a typical modern GNOME application. Or is
> > it ORBit-2? D-COP? I guess nobody knows.
> 
> D-bus will succeed or fail, just as ORBit/Bonobo did, depending on
> whether people write actually interesting public interfaces that any
> interested application can use.
> 
> Neither D-bus not ORBit are interesting by themselves.  They become
> interesting when I can know that I can search my addressbook with them,
> or when I can tell applications that the network went offline.
> 
> D-bus seems to be well accepted across more than the GNOME platform.  We
> need to publicize the useful interfaces which applications expose
> through D-bus, and see if they would benefit from standardization.
> 
> > I can imagine companies that would like to target the GNOME desktop,
> > while developing solutions for their customers, would like this type of
> > leadership to happen. Yet I can imagine a lot Free Software GNOME
> > developers dislike "any" form of "leadership". It's not a simple problem
> > to solve. Will the GNOME Foundation fill this gap? Or will the GNOME
> > Foundation create a solution? How will you, provided you become board
> > member, address this. Or isn't this important enough for the Board to
> > discuss? Or isn't it the focus of the Board?
> 
> You mentioned Linus as being the leader for the Linux kernel.  Having a
> leader works for Linux because it is constrained in function:  in
> oversimplified terms, and from the viewpoint of applications, Linux only
> has to provide a Unixish API that works.  Linus can then oversee whether
> proposed modifications to the kernel are in line with this goal.
> 
> Would GNOME benefit from a central leader?
> 
> GNOME has become too big a platform for anyone to grasp the whole thing
> in his head.  It has no bounding technical goal.
> 
> We need to keep GNOME from growing simply by accretion.
> 
> The way to grow a large system is to ensure that the different pieces
> are in line with some basic principles.  That is, we have to ensure the
> conceptual integrity of the whole so that the different parts match
> together.  See chapter 4 of "The Mythical Man-month".
> 
> So, how do we ensure GNOME's conceptual integrity?
> 
> >From the API viewpoint, by ensuring that APIs have more or less the same
> form.  From the C viewpoint, that means that objects are
> reference-counted and provide accesors, in order to be friendly to
> language bindings.  From the friendliness-to-developers viewpoint, by
> mandating that the APIs have proper documentation and that they were
> designed with an application in mind.
> 
> >From the user's viewpoint, by following through on the usability
> project.  If a program is not usable, it's not fit for GNOME.
> 
> So, about a central leader - perhaps we just need to lay down our goals
> clearly, write some basic principles (the GNOME Programming Guidelines
> have gotten a bit stale, but they are good starting point), and guide
> people so that they produce software that follows those principles and
> goals.
> 
> > Fourth question (finally a non programmer question! :p):
> > 
> > Because I can imagine it's going to be an important project for the
> > GNOME desktop and infrastructure, how will you involve yourself in the
> > One Laptop Per Child concept?
> 
> I'm quite involved in the performance and memory reduction efforts.
> That will help from the infrastructure side of things.
> 
>   Federico
> 
-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be