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

[Tomeu Vizoso]

On Mon, Jul 27, 2009 at 19:38, 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.

Agreed.

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

We should measure it and because of the recent work we can do it in a
meaningful way. Any takers?

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

That's not true, she will will have gained useful knowledge in
modifying any other piece of software. The most important skills in
programming are transferable, not tied to a single technology.

> A user who
> has learned pygtk still does not have enough knowledge to modify one
> written in Qt.

Nobody "learns" pygtk and has enough knowledge to modify any possible
activity written in pygtk. Learning needs to happen in each and every
programming undertaking. The API reference is there to be consulted,
not to be "learned".

> We risk creating a Tower of Babel, with components written
> in countless frameworks, all different.

This is true, by having frameworks with overlapping functionality we
make it harder to have a consistent story on documentation.

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

We use Evince, Abiword, Gnash, Hulahop, Vte and Labyrinth: all of that
code comes from GNOME apps. And if we don't have more such as Gnumeric
is because I don't have more time in my hands. It's certainly doable
and has very good results, but we need more people to do stuff.

We also need to explain to developers of desktop applications about
the importance of encapsulating their core functionality in
canvas-like widgets so other people can take their work and put
different user experiences around them.

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

See the apps at http://edu.kde.org/ , are there GNOME equivalents for
all? I must say that the GNOME community doesn't seem particularly
interested in education compared to the KDE one, you don't agree?

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

Agreed, but the important point here is taking out barriers, even if
they are psychological ones. By aligning yourself in the GNOME or KDE
camp you are getting out the radar of a big part of the free software
community.

If OLPC or any country using Sugar where paying some upstream
developers, maybe we wouldn't depend so critical on the software
produced by volunteers, but right now nobody seems to be willing to
spend resources in software development so we need to get good at
getting coders on board.

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

This is true, but we aren't going to jump into _supporting_ Qt right
now. Our only way to scale is to make sure that any burden that
someone brings on the community is, at a minimum, offset by the
resources that are brought in as a consequence. This is a basic rule
in community software maintenance and I hope we stick to it.

Now, what you propose was the original plan and makes a lot of sense
if you have enough resources to push your own strategy forward
regardless of what other people do on their own platforms. But we have
zero resources today, and if by investing a weekend of fun work I can
increase the chances that other people notice the value in Sugar and
make a proposal, why not?

Regardless of what I said, I think your point of increased memory
usage is a valid one and the community should voice its opinions on
this trade off.

Also remember that it's not so black or white, activity developers can
bundle the whole Qt runtime inside their activities in case the
community decides not to include Qt in the Sugar Platform. But if the
value brought by those activities is big enough, I expect the
community to end up saying yes.

I hope we keep having many more discussions like this, hopefully also
involving people who are actually deploying Sugar and tell us what
_they_ need.

Again, all this only works if the people deploying Sugar participate
in the discussions. If they don't want to participate in this
community, they will have to fork Sugar or switch to something else
once further releases don't suit their needs any longer.

Regards,

Tomeu

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