[IAEP] Future of Zero Sugar

[Aleksey Lim]

Hi all,

(be careful, pathos content:)

I'm going to post about my sugar vision(not only about technical cases)
which I'm going to implement during 0.88 release cycle(though non of
these points are tight to sucrose releases).

The major point of some of my proposals to 0.88 sucrose has social
context(how I understand sugar's social benefits). One of idea I had in
mind from beginning about sugar is that sugar is not a "product"(like
GNOME for example) but permanently changing tool which lets its (not
users)doers create masterpieces(including sugar itself).  So, I have
strong intension to switching development focus from core team,
which develops sucrose - glucose(core) and fructose(some core
activities) to wide range of developers/doers thus some kind of
decentralization of development process.

I think I've found proper way - instead of decentralising technical
aspects in core development, decentralise method of sharing changes
between users/doers - here Zero Install[1] integration[2] - integration
not to shell UI or other technical aspects but to sugar community.

Someone can say that this decentralization splits sugar community but
see previous text about "product", only "product" producer cares about
centralizing(mostly about centralizing profits:) but I'm strongly for
many forks/(re)implementations/etc of sugar, in my mind this situation
meets the final target of sugar - constructive thinking of (not
users)doers.

What I'm personally going to do in previously mentioned process is
taking part in Zero Install[1] integration to SL services like Activity
Library[3], bugs tracker, files servers etc.

Technical benefits of Zero Install integration:

  * let activity developers include not only Sugar Platform[4]
    GNU/Linux distribution dependencies, 0install let(will, after
    PackageKit integration, I'm planing to complete this week) install
    such dependencies by demand

  * exclude binary blobs from .xo bundles at all,
    proper dependencies could be installed 1) from native packages 2)
    from 0install binary packages 3) and finally could be build on user
    side from sources

  * having non sucrose shared libraries(like sugargames) that develops
    won't have to bundle to .xos and benefit from 0install updating
    process

  * one of consequences of previous case is that now its possible to
    start switching to service provider model for sugar core[5], when
    activity developers should not be stuck to particular sucrose
    release(which has 6 months cycle - too short for field deployments)
    and be stuck to API of services they use. Sufficient services could
    be installed/updated by demand via 0install infrastructure.

Also social benefits:

  * I'm planing to implement sucrose release agnostic library(which will
    be a service installed/updated via 0install) to launch sugar
    activities(w/o any support from activity developers) in non sugar
    environment. So, this feature will merge non sugar and sugar
    communities - if teacher wants use TurtleArt activity in
    existed(nont-sugar) environment in classroom, he can just
    install(via 0install) TurtleArt from Activity Library and will get
    the same activity like it looks in native sugar

  * I hope to see many shell forks with implemented features like new
    sugar themes(wallpapers support, new icons etc.), Actions view
    implementations from non-core development/doers. The benefit they
    will have after 0install integration is more useful method to share
    these forks - just a regular entity on Activity Library that brings
    new shell to user environment(new shell Instance won't remove system
    installed shell, so users will have easy method to back switch to
    previous shell) 

[1] http://0install.net/
[2] http://wiki.sugarlabs.org/go/Zero_Install_integration
[3] http://activities.sugarlabs.org/
[4] http://wiki.sugarlabs.org/go/0.86/Platform_Components
[5] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose

-- 
Aleksey