What do you mean with utilizing sugar shell etc? It seems like that's either porting the GNOME platform to make the current implementation work, or rewriting them using the Android SDK. On Sunday, 10 November 2013, Yioryos Asprobounitis wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div> >very nice analysis, thanks a lot. Let me focus on a couple of points > > >- Sell for 1.99$. I feel that building business around Sugar might be essential for its survival. And I like the idea, it seems like it might even work! (I have no clue about business, mind you :P). >Though I'm not sure this is something Sugar Labs can do at this point. It would start competing with the bits of business ecosystem that have been built around it, and that feels wrong. > >- Porting native Sugar to Android. I probably was not clear when I said "build native sugar to android". </div><div style="font-style:normal;font-size:13.3333px;background-color:transparent;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"> In no way I meant port Gnome/Gtk3 and python, but rather use Android ARIs/SDK. Most activities should be simple. Utilizing Sugar Shell, datastore and telepathy/D-bus under Android are the 3 major issues I guess , but after that should be "simple" Will be a difficult start but in the long run the relatively stable and well documented APIs and the available SDKs should allow focus on content rather than playing catch up to the upstreams.</div><div> > I researched this a bit a while ago... I think it would be a lot work, the GNOME stack is big and not very cross platform, and Android is pretty unfriendly to native libraries porting. It would also most likely be very expensive to maintain, especially since I don't see the GNOME community buying a lot into it. Finally I don't think GNOME has much of a future as a platform, we will need to move away from it at some point anyway. These are the reason we decide to migrate to a cross platform toolkit (html5) first. I also don't see the Sugar community doing that work, it requires skills which are not very common around here. That said, I think a company could hire people and do it, it's not rocket science. > > >On Sunday, 10 November 2013, Yioryos Asprobounitis wrote: > >> >>> Does anyone else want to add their thoughts on: >>> >> >>These are all good for now but without the "safety" of the 2-3 million default users, SL can not just be the "upstream". There are some more fundamental questions now that we need to compete in the "open market". >> >>In a nutshell, whom do we target and which of _their_ needs do we cover better than the competition? >> >>1) Are we targeting (the educational department of) Governments? (ie become OLPC-A) >>2) Are we targeting OEMs? (ie find OLPC-A replacements. Are there any?). If yes, which needs of *theirs* do we satisfy better than the competition? >>3) Are we targeting existing hardware and if yes, only those already running GNU/Linux? (The vast majority of hardware in and out of schools although it can, does not run GNU/linux let along Fedora, and is very likely to stay that way by just adding Android and iOS) >> >>The current html5/js course suggests "door no 3", but I have a hard time thinking of something that runs in Windows XP-8.1, OSX 10.6-10.9, major flavors GNU/Linux, iOS and Android 4.x all at the same time and all well! Not even browsers, let along a UX within a browser. >> >> >>This "open market" course also require some change in the development philosophy. >>Do we still tell people how things should be done (a la Apple - and GNOME lately) or do we listen to their needs, experience and priorities? If yes which ones? Kids, parents, teachers, local/support techs, funding sources, all of the above (can we)? >>Do we place Sugar next/parallel to other edu-apps or the "Sugar Desktop" is "mandatory"? If the latter, do we integrate (fully sugarize) other apps or stick with our native repertoire? >> >>That's a lot of questions with no answers and I can appreciate that these can not be addressed or affect sugar .102 or .104 but they may need to be decided soon for sugar .106 to materialize. >> >> >>I also think that options 1 and 2 need a much stronger political cloud and a political environment of yesterdays to materialize. >>So let me suggest option #4 that I'm sure will "raise some eyebrows" (and hopefully not too much more than that :-) Today handhelds have really provided cheap and energy efficient computing and communications, and their penetrance is increasing rapidly around the globe. >>Thus, build native Sugar for Tablets/Smartphones and *SELL* it for $1.99 through Google Play (and/or AppStore) :-o >>Obviously, provide the code and a way for rooted (or jail-broken) devices to install it for free, but people/organizations that opt for specific quality "locked" hardware and the Sugar software stack QA'ed and supported, must contribute (a token really) to its development. If you think of it is like what RHEL is doing and actually much cheaper. Or what OLPC was doing paying developers to develop software for the hardware that was *selling* to users. >> >>I can appreciate that this "open market approach" is a major shift in the culture (but not the reality) of the community from "educational software politics and policies" to "proven educational software quality". But isn't quality what we primarily want from educational software? >>Although there is plenty of room for improvement, Sugar has this quality and an installed base to support this claim, and should not be afraid of this course. >>A strong market presence and user</div> </div></div></blockquote> -- Daniel Narvaez