Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
On 11 November 2013 05:10, David Farning dfarn...@activitycentral.comwrote: My experience has been that educational software politics and policies have been been the dominate influence within Sugar Labs. If this is the role that Sugar Labs wants to maintain that is fine, as long as they open the door to other organizations focusing on proven educational software quality. The commits stats Gonzalo posted on this thread tells something very different. In the last year Sugar Labs community developers made a lot more more commits than company sponsored ones. Commits are not the most reliable way of measuring contributions of course, but here they reflects pretty well reality IMO. Both approaches have challenges. If Sugar Labs is willing to assume responsibility for quality education software, they will have to adopt a culture and processes which encourage feedback (even negative feedback) and ways to implement solutions to that feedback. I think Sugar Labs is already assuming responsibility for the quality of the software, in the form of contributions to the code base. We are doing what we can to gather feedback too. How many times we asked for testing on 0.100 and we got almost none? I wish we had more feedback from the deployments, but I have not idea of how to do that. Please help out with it? Otherwise they are going to have to accept the lose of control if other organizations such as AC provide that service. I don't think we are afraid of organizations like AC getting involved. All the contrary, I'd say the main Sugar Labs goal is to get more organizations and individuals involved. Please contribute to the project and if you see concrete roadblocks point them out, we will do what we can to remove them. As the bottom line; the Association is good at sales and marketing, Sugar Labs is good and vision and inspiration, and Activity Central is good at support and implementation. The most likely way to success is to figure out how these three, and any other organizations, can work together. Rather than focus on grudges. Well, to set the facts straigths... OLPC is not selling Sugar anymore, as far as I can tell from the comments on this list, some from ex OLPC employees. And implementation has been done almost exclusively by the Sugar Labs community in the last six months. I hope AC will get more involved in the implementation and I'm encouraged by the recent contributions. I'm sure a discussion on how we can concretely help your support work would be welcome. (You might have intended implementation in a larger sense, but the stricter sense I'm using is a big part of it). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
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 endorsement is actually much better than any PR event or political/academic endorsement in enhancing its appeal and removing the 3rd world/class label from the project. So please consider distributing Sugar .106 through GooglePlay/Appstore! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
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. 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. 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
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
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: 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. 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. 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
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
ooops 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. Probably another technically inaccurate term. I mean re-writing but keeping the Sugar UI look and feel. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
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. - Android works only on certain hardware. - I don't think it would be possible to implement the full UX being limited by Android SDK. Think of activities installation etc. - We should keep supporting existing deployments, this would duplicate the work completely. On Sunday, 10 November 2013, Yioryos Asprobounitis wrote: ooops 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. Probably another technically inaccurate term. I mean re-writing but keeping the Sugar UI look and feel. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
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 - 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) - 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 - 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 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? On Sunday, 10 November 2013, Yioryos Asprobounitis wrote: ooops 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. Probably another technically inaccurate term. I mean re-writing but keeping the Sugar UI look and feel. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
- 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 am pretty sure this can be solved. See the thread about performance
in activities.
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?
In all this speculations I don't see _how_ SugarLabs should get the resources
to implement these ideas. How many people do you think is working right now?
These are statistics of commits in the last year:
sugar]$ git log --since=1 year ago| grep Signed-off-by | awk
'{printf(%s %s\n, $2, $3)}' | sort | uniq -c | sort -k1nr
28 Manuel Quiñones
23 Gonzalo Odiard
12 Simon Schampijer
10 Martin Abente
7 Manuel Kaufmann
3 Daniel Narvaez
2 Agustin Zubiaga
2 Walter Bender
sugar-toolkit-gtk3]$ git log --since=1 year ago| grep
Signed-off-by | awk '{printf(%s %s\n, $2, $3)}' | sort | uniq -c
| sort -k1nr
22 Manuel Quiñones
10 Simon Schampijer
8 Gonzalo Odiard
4 Manuel Kaufmann
3 Carlos Garnacho
2 Daniel Narvaez
1 Martin Abente
Of course is not all the activities, but the core (what should be
ported to Android)
We had 7/8 developers contributing core, and 90% was done by half of this team.
Then, without having a way to fund a development team of 2 or 3
developers by at least one year,
is ridiculous make plans. Sorry, but the work will not be done by Harry Potter.
Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
On 10 November 2013 21:03, Yioryos Asprobounitis mavrot...@yahoo.comwrote: 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. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
On 10 November 2013 23:50, Gonzalo Odiard gonz...@laptop.org wrote:
In all this speculations I don't see _how_ SugarLabs should get the
resources
to implement these ideas. How many people do you think is working right
now?
If I understood correctly Yioryos was suggesting the Android application
price would pay for this. Of course someone would need to believe in that
and make an investment.
These are statistics of commits in the last year:
sugar]$ git log --since=1 year ago| grep Signed-off-by | awk
'{printf(%s %s\n, $2, $3)}' | sort | uniq -c | sort -k1nr
28 Manuel Quiñones
23 Gonzalo Odiard
12 Simon Schampijer
10 Martin Abente
7 Manuel Kaufmann
3 Daniel Narvaez
2 Agustin Zubiaga
2 Walter Bender
Dude, only 2 commits by me? No way! :P
I think grepping by Signed-off-by is not quite accurate, we have not been
using it in the last six months or so. But I'm just nitpicking, your point
stands.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
Dude, only 2 commits by me? No way! :P
I think grepping by Signed-off-by is not quite accurate, we have not been
using it in the last six months or so. But I'm just nitpicking, your point
stands.
Buuh, it's your fault for not signing ! :)
Using Author:
sugar-toolkit-gtk3]$ git log --since=1 year ago| grep Author | awk
'{printf(%s %s\n, $2, $3)}' | sort | uniq -c | sort -k1nr
109 Pootle daemon
75 Daniel Narvaez
27 Manuel Quiñones
24 Simon Schampijer
12 William Orr
10 Daniel Drake
6 Gonzalo Odiard
5 Walter Bender
4 Manuel Kaufmann
3 Carlos Garnacho
3 manuq manuel.por@gmail.com
3 walterbender wal...@sugarlabs.org
1 dnarvaez dwnarv...@gmail.com
1 godiard godi...@gmail.com
1 Martin Abente
1 surajgillespie suraj_gilles...@yahoo.co.in
[gonzalo@localhost sugar]$ git log --since=1 year ago| grep Author |
awk '{printf(%s %s\n, $2, $3)}' | sort | uniq -c | sort -k1nr230
Pootle daemon
92 William Orr
89 Daniel Narvaez
47 Manuel Quiñones
34 Walter Bender
31 Simon Schampijer
30 Daniel Drake
26 Gonzalo Odiard
11 Martin Abente
5 Manuel Kaufmann
5 Miguel Gonzalez
4 manuq manuel.por@gmail.com
2 Agustin Zubiaga
1 Casey DeLorme
1 Martin Pitt
1 Suraj K
1 Will Orr
(Author is completely safe, there are commits where Author and
Signed-off-by are not equal,
Author can't identify multiple authors in a commit, and there are a little
more noise with merges.)
Looks better, but still, no Harry Potter...
Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
On Sun, Nov 10, 2013 at 10:29 AM, Yioryos Asprobounitis mavrot...@yahoo.com 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? My experience has been that educational software politics and policies have been been the dominate influence within Sugar Labs. If this is the role that Sugar Labs wants to maintain that is fine, as long as they open the door to other organizations focusing on proven educational software quality. Both approaches have challenges. If Sugar Labs is willing to assume responsibility for quality education software, they will have to adopt a culture and processes which encourage feedback (even negative feedback) and ways to implement solutions to that feedback. Otherwise they are going to have to accept the lose of control if other organizations such as AC provide that service. As the bottom line; the Association is good at sales and marketing, Sugar Labs is good and vision and inspiration, and Activity Central is good at support and implementation. The most likely way to success is to figure out how these three, and any other organizations, can work together. Rather than focus on grudges. 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 endorsement is actually much better than any PR event or political/academic endorsement in enhancing its appeal and removing the 3rd world/class label from the project. So please consider distributing Sugar .106 through GooglePlay/Appstore! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com ___ Sugar-devel mailing list
Re: [Sugar-devel] Sugar Labs Roadmap. [SD 61;79]
Looks better, but still, no Harry Potter... If you want to go down that road, may I suggest to look for J. K. Rowling instead?... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
