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

[Benjamin M. Schwartz]

-----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.

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-----