[IAEP] SoaS as a Sugar Labs project.

[Michael Stone]

Gary,

I'm tired and sad from talking on this subject but I still don't feel that
I've been understood. (Or, if I have been, I haven't understood the rebuttals
of my position, in which case I apologize for being so dense.) Anyway, here's
one more try:

> Wow, blast from the past :-) Actually I'd strongly disagree here.  
> Having re-read through most of what is listed here, much progress has  
> been made on a large number (dare I say majority) of these items! 

We count differently, so I'll try to make myself understood in a different way.

Other than view source improvements, which I think everyone agrees are
significant, how is Sugar actually better for reflecting, collaborating, and
discovering than it was a year ago? 

Has the "ceiling" gotten appreciably higher or the "floor" lower? 

Are there really noticeably more activities to choose from? 

Can a teacher actually rely on the networking protocols (over wireless
networks) enough to justify spending classroom time on it?

Finally, is Sugar any closer to achieving any of its major technical goals,
like easy code sharing, click-to-translate, interoperability with regular Linux
apps, or real ease of authoring?

Notes:

   * I haven't formed an opinion of silbe's versioning work yet so I can't yet
     say what I think of it other than to mention a degree of limited
     hope based on his decision to avoid addressing the interoperability goals
     that Scott's approach to versioning sought to address.

   * I can see how the toolbar redesign might help with the discoverability and
     low-floor goals. Does it? If so, how much?

   * I can see how the ePub support and support for Flash activities could be
     counted as progress toward "more content". Still, it seems at best
     half-finished without knowing what the content to send with the support...

   * Some people would argue that Sugar's integrated file-sharing support is a
     major improvement. I will agree with these people when they explain why
     they think that this file-sharing technology will function more reliably
     than our current presence and collaboration technology in realistic
     networking scenarios encountered in school-scale wifi-based deployments.

   * I understand that people here have accomplished lots of other hard and
     valuable things in the intervening year; I just really, really, really want
     people to remember which are the problems that we actually set out to
     solve, at least as I have understood them so far, and I want us to be doing
     work that is good enough to retain the interest of the best people in the
     world, in all relevant fields, which I fear that we are not. Are these
     not reasonable criteria on which to base judgments of progress?

> The problem is that you need to to be using 0.84 to benefit from most,  
> with the approaching 0.86 solving a bunch more. The difficulty,
> unfortunately, seems to be much more about getting XO-1 QA'ed release
> rollouts available for deployments. At least 0.84 does seem to be in the OLPC
> pipeline, due to XO-1.5 needs, with volunteers*** pushing on the side of
> existing XO-1 hardware.

Let me share a brief story...

I became OLPC's release manager for a brief time last year because I realized
that all of 

   * Marco's, Tomeu's, Eben's, Sayamindu's, and Simon's hard work on the
     shell redesign, control panel and Browse certificates, 
   * my work on Rainbow, and
   * Scott's work on the activity and distro updaters, 
   * Chris' and Richard's work on power management, 
   * Richard's and Andres' work on touchpad bugs, 
   * Bernie's work on X, 
   * Bert's work on EToys, 
   * Dennis' work on Fedora packaging, 
   * Michailis', Ricardo's, and Marvell's work on new wireless firmware, 
   * Collabora's work on fixing up Gabble and Salut, and 
   * Martin's work on backups

wasn't going to matter a whit unless someone organized a full-blown distro
release (and associated assurance process) in order to deliver this work in a
form usable by the people who might benefit form it.

I still subscribe to this position today, more or less. [1] 

However, to my great sadness, I don't see any changes in the past year (or in
the foreseeable future, though 0.86 brings us somewhat closer) that are
compelling enough for me to encourage or support a serious effort to create and
to assure a deployable distro release to carry changes to XO-based end users.

(Do you see anything that I don't? Do you value things differently?)

> ***F11_for_XO-1 build 5, from Steven Parish, was the last available  
> dev release, and is running pretty well on an XO-1 and an XO-B4 here.

Thanks very much for helping to test it. (Seriously.)

In your testing, have you experienced any notable regressions from 8.2.1 that
will make it hard for deployments to adopt, given the sorts of things that you
see deployments asking about on the Features page that I cited?

Regards,

Michael

[1]: I can imagine how SoaS, Sugar-via-LTSP, and Sugar-on-$DISTRO *could*
conceivably change the economics of this equation but I am also known in some
circles for having an overly active imagination. :)