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 <div class="gmail_quote">On Mon, Dec 14, 2009 at 1:19 PM, Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> 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. </div>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 <div class="im"> > [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 > > </div><div class="im">> _______________________________________________ > IAEP -- It's An Education Project (not a laptop project!) > <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a> > </div><div class="im">-- ŤSugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.ť - David Farning _______________________________________________ </div><div><div></div><div class="h5">IAEP -- It's An Education Project (not a laptop project!) <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a> </div></div></blockquote></div>