% Sugar: Core Priorities for 2012
% February 15, 2010
% Michael Stone <michael@laptop.org>

This essay describes what Sugar developers should strive to create.

## Speed

Fast feels good. Fast feels trustworthy. People buy fast.

Since we want people to "buy" Sugar, we need Sugar to feel snappy.

The way to get Sugar to feel snappy is to reduce the latency of
operations. To do this, we ought to

  1. incrementally adopt faster tools like C and Lua,
  2. compute only what we need only when we need it, and
  3. make UI changes to speed things up.

The "faster languages" approach is motivated by the realization that
I've never seen a snappy graphical program written in Python. C and
Lua are distinguished for their raw speed, minimal memory consumption,
and prevalence in industrial-strength software. Incremental change is
called for in order to minimize breakage and to permit individual
Sugar contributors to develop the necessary new skills at their own
pace.

The "better laziness" approach is motivated both by my recent study of
datastructures and by my observations of the effects of Sugar's naive
resource handling (e.g., in its use of SVG).

The "ui changes" approach is motivated by my experience improving the
responsiveness of the Sugar UI by removing inappropriate animations
and delays.

## Modularity

Sugar should be smaller and more loosely coupled than it is today.

This is important for a couple of reasons including:

  1. Ease of learning: smaller codebases are easier to approach and to
     understand than larger ones.

  2. Ease of testing: the best way to get more and better testing done
     is to split Sugar up into pieces that can be fully tested both in
     isolation and in composition.

  3. Ease of integration: smaller and more loosely coupled codebases
     can evolve faster than larger and more tightly-coupled ones due
     to the maintainers' increased ability to merge changes without
     breaking things.

  4. Building for speed: to move, incrementally, from today to "fast",
     we need to be able to replace implementations "one piece at
     time".

  5. Symbiosis: the best way to get more help is to make software that
     is useful *both* for Sugar an on regular desktops.

To build improve modularity, we're just going to have to sit down with
the current codebase, write up a list of entry-points that we wish we
could call, and start reassembling the current codebase in its new
form. As we write down each entrypoint, we should also start building
up the test scripts that will tell us when we're done.

To this end, I'll propose a draft list of entrypoints in a subsequent
essay.

## Lower Floor; Higher Ceiling

There are a variety of things holding Sugar back from its next plateau
of usability.

First, there are certain UI affordances which simply failed to
accomplish their intended purpose. These affordances need to be
tweaked or replaced.

Second, there is the matter of content and of "stack fidelity".

In order to have an honestly "high ceiling", Sugar needs to expose
*some* truthful model of the abstractions underlying its construction,
including the file system, the shell, and the network. However, in
order to have a "low floor", it also has to expose these abstractions
in way that is simultaneously unobtrusive, quickly accessible, and at
least marginally discoverable.

  * the filesystem modeling requires four strands of work:

      - Eben's journal redesign, which cleanly separates bundles,
        sessions, and files-with-history

      - Scott's journal2 work, which explains how to smooth over the
        differences between traditional filesystems and the kinds of
        filesystems that Sugar will be producing

      - Scott's olpcfs2 work, which explains how to make the work
        described above interoperate with the rest of the world

      - my work on improving rainbow to provide functionality and
        interfaces appropriate for the previous ideas

  * the shell/command-line idea requires two strands of work:

      - experimenting with specific UIs (like an "advanced"
        QuakeTerm-like UI and an "intermediate"
        dmenu/QuickSilver/AwesomeBar interface)

      - figuring out what to expose at which level

  * the network skein requires two strands of work:

      - pursuing the Network2 agenda of providing highly robust and
        interoperable end-to-end connectivity, internetworking, and
        naming

      - extending the Network2 agenda as needed

## Developer Accessibility

In addition to the quality of modularity described above, there are
several things that need to be done to make Sugar development more
accessible to traditional coders:

  1. Sugar needs to be language-neutral with respect to activities. In
     practice, this means providing sugar functionality via C shared
     libraries and external processes since these are the easiest ways
     to work with external code in most languages.

  2. Sugar needs to be absolutely trivial to build and test from
     source and packages. In practice, this means two things:

       - building and installing Sugar from source should be require
         no more than four lines of code on any modern Linux desktop,
         should depend only on commonly packaged software, and should
         be damn fast.

       - Sugar needs to publish weekly snapshots both as source and in
         unstable distro branches like Fedora rawhide, Debian sid, and
         like the Gentoo unstable overlay.

## Social Approach

Here are some changes which would help make Sugar's social approach
more satisfying to engage in and which I intend to follow in any
development work that I do on Sugar:

  1. I coordinate by email. Therefore, if you want to talk to me or if
     you want me to examine your work, please email me. I'll write
     back.

  2. I look for people who take the position, as I do, that "if
     something was important enough for you to build, then it's
     important enough for me to offer feedback on and, if I like it,
     to merge it."

  3. Like anyone, I occasionally get swamped. Keep poking me gently
     and I'll get back to you soon.

  4. Experiments are good. We need to do more of them, they need to be
     better reported, and they need to be more rigorous.

  5. In general, if we have two serious ideas for how to do something,
     we are better off working together to *try them both* than we are
     dismissing the second idea. We'll learn more, and we need the
     practice.

  6. We need to be more willing to fix old mistakes, even at the cost
     of breaking software. The promise that we should make is to work
     together to fix the broken software. We *must* fix our mistakes.

  7. We need to worry less about making regular releases than about
     making software that delivers our intended user
     experience. Continuing to release bad software helps no one,
     damages us, and damages our brand.

## Conclusion

If, as Walter quips, we learn by doing and learn best when motivated
by love (rather than duty) then it would behoove us to make Sugar
development as lovable and active as we can.

I've begun this work for myself in [my Sugar clone][m_sugar]:

  * by unifying the many separate Sugar source repos (currently
    including sugar, sugar-toolkit, sugar-base, sugar-artwork,
    sugar-datastore, and sugar-presence-service) into one,

  * by "autoliberating" the build system (replacing it with a single
    short ./configure script and Makefile), and

  * and by merging some outstanding patches from Wade and Quozl which
    greatly speed up my testing cycle

Finally, I look forward to receiving your comments, questions, and
patches!

## References

[m_sugar]: git://dev.laptop.org/git/users/mstone/sugar
[deeply]: http://lists.sugarlabs.org/archive/sugar-devel/2008-July/007441.html
[skeptical]: http://lists.sugarlabs.org/archive/iaep/2009-July/007415.html
[network2]: http://wiki.laptop.org/go/Network2/Paper
[activity-development]: http://dev.laptop.org/~mstone/draft-sugar-activity-development-00.txt


## Requests for Improvement of draft-sugar-love-duty-00.txt

0. cscott has epic (line-by-line!) suggestions which are too detailed
to summarize other than by saying "good first try; now rewrite in
terms of one Big Idea".

1. cjb requests justification of the rewriting and language change suggestions
in the note on speed.

2. cjb requests more information about how to replace bad code and what to
replace it with than about what code is bad.

3. martin_xs requests more emphasis on "Polish and Compelling Features".

4. martin_xs is very focused on short-term improvements for sugar-0.84 and
would like to know how that might fit in here.

5. mstone needs to say more about the motivation provided by Gary's list of
unappreciated efforts:

    Manu's "SocialCalc on Sugar - Developers' Guide and Opportunity for Developers and Content Creators"
    Bert's "Low-level Activity API" (needs a hand fixing up wiki move)
    An email ticket from Sayamindu about a gettext issue with the Clock activity Gary adopted
    Martin's "Touchpad accel, spirals and xset"
    Sascha's "Try out version support NOW"
    James "Several chapters of "Make Your Own Sugar Activities!" ready for review, feedback"
    Justin's "File Share Activity" (still needs more feedback and better design)
    Michael's "ANN: rainbow-0.8.6 release." along with the wiki pages for installing
    Simon's "Opportunity: Getting involved, maintaining the Write Activity" Gary: should backport old toolbar support
    Bernie's "PATCH: add a delete all function to physics" Gary: I'm getting a little behind on physics work
    Simon's "...labyrinth...a verb?" thread, still no decision so will likely let this slip
    Sascha's "Examples in Journal (#1585)"
    Simon's "Fructose - What is it? What should it be?" seems to have fallen off the 0.88 radar
    Wade's "[ANNOUNCE] Sugargame v1.0" need to test and give feedback
    Wades "#1447 NORM: Display a message when an  activity fails to start" this really needs to ship!
    Lucian's "Keep offline for Browse (offline bookmarks)" patch
    Richard's "OOM conditions" (see if Maemo's kernel patches can help us)

6. mstone needs to say a word or two about Lua's virtues. Notable
virtues include:

  a) Lua goes big (Blizzard WoW, Adobe Lightroom) as well as small (OpenWRT:
     4Mb of flash!). People who have used it in anger (like the tech lead for
     Lightroom recommended it strongly for further use.)

  b) Lua JITs well: http://luajit.org.

    LuaJIT beats the pants off of Python:

        http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=python

    and does well vs. C:

        http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=gcc

    Also, it's good enough that Google is independently ponying up to support
    the author of LuaJIT.

  c) Lua is the only mainstream programming language that originates from
     South America. (Brazil, in this case.)

7. dilinger points out that C often has coupling problems of its own.

8. bemasc points out that Network2 doesn't have much to say about presence. It
has particularly little to say about what activities need to do to participate
in presence exchanges.