[Sugar-devel] Sugar Labs Roadmap. [SD 61;79]

[Daniel Narvaez]

On 10 November 2013 21:03, Yioryos Asprobounitis <mavrothal at yahoo.com>wrote:

>
> >
> >Thanks for clarifying. IMO we should not rewrite Sugar and activities
> using the Android SDK
> >
> >
> >- While Android is nominally free software for it's licence, it seems the
> current development practices (like code drops) gives Google too much
> control on the project direction. I don't want to be locked in that kind of
> ecosystem.
>
> True, but the choice is reaching 2 billion under Google's control or 2
> millions without,
> and actually _having_ an ecosystem
>
>
It's not that black and white. Using html5 would allow us to reach the 2
bilion, while not getting locked into that ecosystem. It had disadvantages
surely, but also other advantages... like being able to run the same
activities on iOS or inside a web browser.

>- Android works only on certain hardware.
>
> True but is way much wider than 99.9% of Sugar's current installed
> hardware (the 4 XO models)
>

We can run on more hardware then the XO, but it's true that it's mostly
just theorical at the moment.


> >- I don't think it would be possible to implement the full UX being
> limited by Android SDK. Think of activities installation etc.
>
> Hard to see why a Sugar specific channel can not be available for
> activities
>

I might not have exactly understood what you are proposing...

I thought it was singe Android application containing both the shell and
the activities. In that case you wouldn't be able to install other
activities inside the Sugar application, would you? Instead, if each
activity is and Android application, how would you implement the shell? I'm
aware you can customize the android shell, but I thought that wouldn't be
something you can just install from google play?

(I'm not an Android expert)


> >- We should keep supporting existing deployments, this would duplicate
> the work completely.
>
> Post .094 Sugar can hardly run in 75% of its installed base (XO-1s), so we
> do not really support the majority of existing deployments.
>

I would very surprised if 0.94 -> 0.100 caused regressions which aren't
fixable with a reasonable amount of effort. Gonzalo work on activities
startup seems to confirm this.


> I can actually fully understand the reluctance of a FOSS project to move
> under Google (or any other company). But is a matter of policies and
> priorities really.
> On software politics I agree with you. The question is, does the 7 year
> run of OLPC/Sugar indicate that are also effective in the olpc goals?
>

What is (not) effective? FOSS software politics?

I honestly don't know. I would like to read an analysis of the efficacy of
Sugar in the field, but I'm certainly not informed enough to write one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131110/f869adfb/attachment-0001.html>