Tomeu, I think your point is well taken. As a teacher and project manager for a deployment of about 150 XOs and SOAS, I find the students and teachers really interested in making stuff with their devices and software (we are in the middle of some cool EToys science projects at the moment.).
But I think it is another thing to create software. I think being able to propose software and have some contact with developers to realize those proposals would be more a more practical pathway in the meantime. Gerald On Mon, Dec 14, 2009 at 1:19 PM, Tomeu Vizoso <[email protected]> wrote: > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz > <[email protected]> wrote: > > Aleksey Lim wrote: > >> 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 agree. I think this has been a central part of the Sugar design > > philosophy from the beginning. I think your message is very much on the > > right track. > > While I think this is in the spirit of my vision for Sugar, my > experience with how Sugar is being used and deployed _today_ makes it > quite uninteresting and too invasive to consider for the near future. > > The current barriers for people to contribute to Sugar development and > share their work are mostly cultural. We can make the technology a > thousand times easier to modify, but if people still think that they > can be only users, we won't gain anything. > > If we really want more people to realize their power and modify sugar > and share their work, we need to, in order: > > - show how the community can address some of their needs, as perceived by > them, > > - show how they can better address the rest of their needs by working > within the community. > > The rest is just icing on the top, IMHO. > > Regards, > > Tomeu > > > [snip] > >> * 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 > > > > I don't think this part will work as "a regular entity on Activity > > Library", for security reasons. Any "Activity" that hooks so deeply into > > the shell is no longer safe to run. It is running with the full > authority > > of the user and can violate the user's privacy or interfere with the > > user's actions. In orders to encourage users to become doers, Sugar is > > designed to make sure that Activities are always safe to run (thanks to > > Bitfrost/Rainbow protections). > > > > I would of course support an effort to "wall off" parts of the shell in a > > secure fashion, but so far almost no work has been done in that > direction. > > > > --Ben > > > > > > _______________________________________________ > > IAEP -- It's An Education Project (not a laptop project!) > > [email protected] > > http://lists.sugarlabs.org/listinfo/iaep > > > > > > -- > «Sugar Labs is anyone who participates in improving and using Sugar. > What Sugar Labs does is determined by the participants.» - David > Farning > _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > [email protected] > http://lists.sugarlabs.org/listinfo/iaep >
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
