[Sugar-devel] Duplication of Effort: Don't do it.

[David Farning]

On Mon, Jul 27, 2009 at 12:38 PM, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have lately seen a lot of duplication of effort in Sugar.  I think this
> is bad.  The success of Sugar demands discipline and careful planning from
> its developers.

Yes, duplication of effort _is_ undesirable.   It is an inherent cost
in open source projects.

In an hierarchical project, a significant amount of effort is spent by
managers coordinating, directing, and controlling their subordinates.
The goal is to insure that workers are effectively spending their time
on approved projects.

In an open source project their is _no_ way to control the work of
subordinates.  Nor should a project spend its limited resources on
managers instead of developers and educators.  The intelligence is in
the leaves.

The project must establish a culture which attracts participants to
work towards a common mission and vision.  Open source is
evolutionary.  Evolution depends on parallelism.  Good lines survive.
Bad lines die.

We have not moved far enough forward far on the Qt issue for me to
have a stance.

As this, and other, discussions moves forward I would like shift one
of the conversation premises from 'duplication of effort is bad' to
'duplication is a cost which must be managed.'

Projects which succeed, manage these costs.

david

> In particular, I am arguing that supporting Qt or Webkit would be a
> terrible idea, and that neither should be permitted to be a dependency of
> the Sugar platform.  However, my argument is certainly more general.
>
> 1. Bloat is bad.
>
> Efficiency is one of the main goals of Sugar.  Sugar was created to
> fulfill a vision of the original Hundred Dollar Laptop Project:
>
> "We will get the fat out of the system.  Today's laptops have become
> obese. Two-thirds of their software is used to manage the other third,
> which mostly does the same functions nine different ways." [1]
>
> It's true.  99.99% of all deployed computers running Sugar are XO-1's, and
> will soon be XO-1.5's. These are strongly resource-constrained machines,
> and they cannot tolerate inefficiency in the use of disk, CPU, or RAM.
> Outside of OLPC, we continue to target low-end hardware where efficiency
> is key.
>
> If we allow Read to depend on Webkit, but Browse uses Gecko, then to use
> them both, the operating system must load two entirely separate rendering
> engines into memory.  On an XO-1 this may be impossible; it will certainly
> lower the threshold for OOM behavior.  Similarly, loading both the Qt and
> GTK libraries into memory at once dramatically increases memory usage, and
> wastes valuable disk space.
>
> Don't do it.
>
> 2. Technological uniformity is an educational decision.
>
> Sugar, and its activities, are written using a uniform set of
> technologies, centered around pygtk.  This is deliberate.  The goal is to
> crush the barrier to entry, so that a student who learns how to modify
> python activities immediately has enough knowledge to modify Sugar itself.
>  This is the incarnation of "low floor, no ceiling".  It is what enables
> the culture of end-user engineering that we strive to create.
>
> Adding more supported technologies for writing Activities raises new
> barriers to entry.  A student who learns how to modify a Qt-based activity
> does not gain knowledge that will help to modify Sugar itself.  A user who
> has learned pygtk still does not have enough knowledge to modify one
> written in Qt.  We risk creating a Tower of Babel, with components written
> in countless frameworks, all different.
>
> One argument made in favor of supporting Qt is to gain access to existing
> KDE applications.  I don't believe this for a second.  Our entire system
> is built with technologies drawn from the Gnome stack, and yet we have
> almost no Activities that consist of wrapped Gnome desktop applications.
> The barriers to compatibility with KDE are considerably higher, and I
> cannot think of a single application from KDE-space whose functionality we
> do not have, or could not get more easily from GTK-land.
>
> Another argument is that it will help to gain support from developers
> already familiar with Qt.  I think this is quite irrelevant.  When I
> started writing Sugar code, I had never seen a single line of gtk (I was
> familiar with Swing).  I read the docs.  It was easy.  Anyone can learn
> gtk, especially if they are already familiar with another toolkit.
>
> More importantly, there just aren't that many Qt developers.  I am willing
> to accept an argument of this type for improving support for activities
> written in javascript+HTML, because there are certainly orders of
> magnitude more developers of javascript and HTML than of python, or any
> other language we might choose to support.  Qt and PyQt, on the other
> hand, are in a niche even smaller than pygtk's.
>
> The many costs of supporting Qt greatly exceed any theoretical value.
>
> Don't do it.
>
> - --Ben
>
> [1] http://web.archive.org/web/20050324163700/http://laptop.media.mit.edu/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.11 (GNU/Linux)
>
> iEYEARECAAYFAkpt5iEACgkQUJT6e6HFtqQzTgCfTWiSLfg1QBGnxKck8zZul3MJ
> d80AnAnTeT4zIccEPs6kNoiHYkEBjBc8
> =ayiC
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>