<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 9, 2017 at 1:08 PM, Lionel Laské <span dir="ltr"><<a href="mailto:lionel.laske@gmail.com" target="_blank">lionel.laske@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Walter,<div><br></div><div>Thanks a lot for this long proposal. Great to hear you on that.</div><div>I think that it's more a Sugar history than a goal/vision but it's good to read it from a guy that was the major contributor of the history.</div></div></blockquote><div><br></div><div>I don't think it is wise to discuss goals without context. That said, while you say my email is not about goals, the rest of your reply is in response to the specific goals I outlined. Curious.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>BTW I'm not agree with your goals.</div><div>My view is that it's not a good idea to limit Sugar/SugarLabs to makers.  We can't target a so small market:</div><div>- RaspberryPI ? RPI is a great tool. I personally used 2 RPI weekly for my personal usage. But it's a tool for geeks not for learners. It could be a good device as server (we're using it in classroom in France and in Madagascar and it's good for XSCE too) but it's a very poor tools for children: no screen, no keyboard, no mouse, not even a power adapter. It's just a board ! So I don't see the interest of Sugar on it.</div></div></blockquote><div><br></div><div>I think you are failing to see the forest for the trees. I don't know the extent to which you are spending time in education circles, but for example, at EdFoo last weekend, the majority of the energy in the unconference was all about making. The RPi is not a ends in itself but a door into the energy that is current in EdTech. If we can get some pick up, we have a great lever for amplifying and growing our community. That said, the amount of effort required on our end is small -- a GSoC project at most -- to take advantage of this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>- Trisquel ? Probably a nice Linux distribution but how many users ? Not at all a largely distributed distribution like Fedora or Ubuntu.  Why doing effort on it ?</div></div></blockquote><div><br></div><div>I mention Trisquel not because it involves any work on our behalf -- Ruben is doing that work already -- but rather to be able to point to that work as an example of how the FSF and FOSS movement could rally around us. Again, to whatever extent that they have synergy with us and help promote us, this is a benefit. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I can't understand you even mention Windows support in your goals: just 99,9% of the PC market ! So if you're a Windows user you can't be a target for SugarLabs ? Plus, regarding devices: we should be better on touch devices because tablets is the favorite learning tools in classroom today, not PC. It's why Android (80% of the tablet market) and iOS are so important in my mind. We should go where users - children/teachers - are !</div></div></blockquote><div><br></div><div>I don't know where you are getting your data, but I don't believe for a second that Windows controls 99.9% of the school market and even if it were true, the Windows desktop market in schools is waning (not good news for us either). Chromebooks are are the rise. And, to a lesser extent, Android tablets. (Apple is losing market share). It is exactly for these reasons I think we should be putting effort into Sugarizer. It has been discussed -- most recently since Samson's April 1 prank -- that a Windows port is probably not worth the effort given our limited resources. Still open to hearing arguments to the contrary.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>We can't target makers just because Sugar has synergy with them and because we hope they help us to spread the world tomorrow.</div></div></blockquote><div><br></div><div>Why not?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Our goals should be to deploy Sugar as a mainstream solution for everyone not a solution for a bunch of geeks. It's the only way to expand the Sugar community. You told about OLPC: the goal of One Laptop Per Child was to give a laptop to EVERY child, our goal should be to give Sugar to EVERY child too. The marketing effort should be in that way, no need to do marketing for makers, I'm sure they found us themselves.</div></div></blockquote><div><br></div><div>I don't think there is only one path forward. And I see no reason to abandon our GNU/Linux platform as long as we have developers willing to maintain it and users who want to use it. Even if it is never mainstream, it shows the way towards a great learning experience.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>                 Lionel.</div><div><br></div><div>P.S.: Regarding Sugarizer maintainability, it's just your opinion. Not sure it's the opinion for 20 others Sugarizer contributors. I don't think you could judge Sugarizer maintainability only because you've not successfully updated TurtleJS activity inside. I don't have success running TurtleJS on my side and had a very bad experience when trying to Sugarize it, it's not a reason for me to give a judgement about TurtleJS maintainability.   </div></div></blockquote><div><br></div><div>We can continue to disagree about this too. I think that I am not alone in expressing the opinion that the way in which you have structured the git repo for Sugarizer is unwieldy and that there are trivial ways to improve it. It may be well suited for an individual maintainer (and side kick) but it is not modeled after any community project I am aware of. As far as I can tell, the 20 contributors built individual apps but have no easy way of updating them. (It was a huge time sync for me to cherry-pick all of the patches you made in your local copy to ensure I could keep in step with your needs.) As far as your problems with Turtle, that is a fine example of where I think your model fails. Unless I get reports back from you (and your users) about errors, how am I to know about them. The one bug you did report has been fixed. I have seen no other bug reports. I don't have a crystal ball. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> </div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2017-04-09 15:31 GMT+02:00 Walter Bender <span dir="ltr"><<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>As per the discussion in the last Suagr Labs Oversight Board Meeting, I had agreed to write a draft statement of goals for 2017. The document below includes feedback from Samson G. I hope this document can serve to revitalize our discussion from 2016 that never reached resolution.</div><div><br></div><div>Sugar Labs Plans, Goals, Aspirations</div><div><br></div><div>What is Sugar Labs?</div><div><br></div><div>Sugar Labs creates, distributes, and maintains learning software for children. Our approach to learning is grounded in Constructionism, a pedagogy developed by Seymour Papert and his colleagues in the 1960s and 70s at MIT. Papert pioneered the use of the computer by children to help engage them in the “construction of knowledge.” His long-time colleague Cynthia Solomon expanded up his ideas by introducing the concept of engaging children in debugging as a pathway into problem-solving. Their 1971 paper, “Twenty things to do with a computer”, is arguably the genesis of contemporary movements such as the Maker Movement and Hour of Code.</div><div><br></div><div>At the core of Constructionism is “learning through doing.” If you want more learning, you want more doing. At Sugar Labs we provide tools to promote doing. (We focus almost exclusively on tools, not instructional materials.) However, we go beyond “doing” by incorporating critical dialog and reflection into the Sugar learning environment, through mechanisms for collaboration, journaling, and portfolio.</div><div><br></div><div>Sugar Labs is a spinoff of the One Laptop per Child (OLPC) project and consequently it has inherited many of its goals from that project. The goal of OLPC is to bring the ideas of Constructionism to scale in order to reach more children. A particular focus is on children in the developing world. In order to meet that goal, Sugar, which was originally developed for OLPC, was by necessity a small-footprint solution that required few resources in terms of CPU, memory, storage, or network connectivity. The major change on focus from the OLPC project is that Sugar Labs strives to make the Sugar desktop available to multiple platforms, not just the OLPC XO hardware.</div><div><br></div><div>Who develops Sugar?</div><div><br></div><div>Sugar Labs is a 100% volunteer effort (although we do occasionally raise money for paid student internships). Sugar development and maintenance is incumbent upon volunteers and hence we strive to provide as much control as possible to our community members, including our end-users. (In fact, one of our assertions is that by enabling our users to participate in the development of the tools that they use will lead to deeper engagement in their own learning.) Towards these ends, we chose the GPL as our primary license. It has been said of the GPL that it “restricts my right [as a developer] to restrict yours [as a user and potential developer]”, which seems ideal for a project that wants to engage a broad and diverse set of learners. But at Sugar Labs we go beyond the usual goals of FOSS: a license to make changes to the code is not enough to ensure that users make changes. We also strive to provide the means to make changes. Our success in this goal is best reflected in the number of patches we receive from our community. (We achieve this goal through providing access to source code and development tools within Sugar itself. We also actively participate in workshops and internship programs such as Google Summer of Code, Outreaching, and Google Code-In.)</div><div><br></div><div>Who uses Sugar?</div><div><br></div><div>Ultimately, our goal is to reach learners (and educators) with powerful tools and engage them in Constructionist learning. Currently we reach them in many ways: the majority of our users get the Sugar desktop preinstalled on OLPC XO hardware. We have a more modest set of users who get Sugar packaged in Fedora, Trisquel, Debian, Ubuntu, or other GNU/Linux platforms. Some users get Sugar on Live Media (i.e., Sugar on a Stick). Recently Sugarizer, a repackaging of some of the core Sugar ideas for the browser, has been finding its way to some users. There are also a number of Sugar activities that are popular outside of the context Sugar itself, for example, Turtle Blocks, which has wide-spread use in India. Harder to measure is the extent to which Sugar has influenced other providers of “educational” software. If the Sugar pedagogy is incorporated by others, that advances our goal.</div><div><br></div><div>Who supports Sugar?</div><div><br></div><div>When we first created Sugar Labs, we envisioned “Local Labs”—hence the name “Sugar Labs”, plural—that would provide local support in terms of local-language support, training, curriculum development, and customizations. This model has not ever gained the scale and depth envisioned (we can debate the reasons why), although there are still some active local communities (e.g., Educa Paraguay) that continue to work closely with the broader community. There are also individual volunteers, such as Tony Anderson and T.K. Kang, who help support individual schools in Rwanda, Malaysia, et al. An open question is how do we support our users over the long term?</div><div><br></div><div>What is next for Sugar?</div><div><br></div><div>We face several challenges at Sugar Labs. With the ebb of OLPC, we have a contracting user base and the number of professional developers associated with the project is greatly diminished. How can we expand our user base? How can we attract more experienced developers? Why would they want to work on Sugar as opposed to some other project? The meta issue is how do we keep Sugar relevant in a world of Apps and small, hand-held devices? Can we meet the expectations of learners living in a world of fast-paced, colorful interfaces? How do we ensure that it is fulfilling its potential as a learning environment and that our users, potential users, and imitators are learning about and learning from Sugar. Some of this is a matter of marketing; some of this is a matter of staying focused on our core pedagogy; some of this a matter of finding strategic partners with whom we can work.</div><div><br></div><div>We have several near-term opportunities that we should leverage:</div><div>* Raspian: The Raspberry PI 3.0 is more than adequate to run Sugar—the experience rivals or exceeds that of the OLPC XO 4.0 hardware. While RPi is not the only platform we should be targeting, it does has broad penetration into the Maker community, which shares a synergy with our emphasis on “doing”. It is low-hanging fruit. With a little polish we could have an image available for download from the RPi website.</div><div>* Trisquel: We have the potential for better leveraging the Free Software Foundation as a vehicle for promoting Sugar. Their distro of choice is Trisquel and the maintainer does a great job of keep the Sugar packages up to date.</div><div>* Sugarizer: The advantage of Sugarizer is that it has the potential of reaching orders of magnitude more users since it is web-based and runs in Android and iOS. There is some work to be done to make the experience palatable on small screens and the current development environment is—at least my opinion—not scalable or maintainable. The former is a formidable problem. The latter quite easy to address.</div><div>* Stand-alone projects such as Music Blocks have merit as long as they maintain both a degree of connection with Sugar and promote the values of the community. It is not certain that these projects will lead users towards Sugar, but they do promote FOSS and Constructionist principles. And they have attracted new developers to the Sugar community.</div><div>* School-server: The combination of the School Server and Sugar desktop is a technical solution to problems facing small and remote communities. We should continue to support and promote this combination.</div><div><br></div><div>Specific actions: After last year’s Libre Planet conference, several community members discussed a marketing strategy for Sugar. We thought that if we could reach influencers, we might be able to greatly amplify our efforts. There are several prominent bloggers and pundits in the education arena who are widely read and who might be receptive to what we are doing. One significant challenge is that GNU/Linux remains on the far periphery of the Ed Tech world. Although the “love affair” with all things Apple seems to be over, the new elephant in the room—Chromebooks and Google Docs—is equally difficult to co-exist with. Personally, I see the most potential synergy with the Maker movement, which is building up momentum in extra-curricular programs, where FOSS and GNU-Linux are welcome (hence my earlier focus on RPi). (There are even some schools that are building their entire curriculum around PBL.) We can and should develop and run some workshops that can introduce Sugar within the context of the Maker movement. (Toward that end, I have been working with some teachers on how to leverage, for example, Turtle Blocks for 3D printing.) It is very much a tool-oriented community with little overall discussion of architectural frameworks, so we have some work to do. But there is lots of low-hanging fruit there.</div><div><br></div><div>regards.</div><span class="m_-239355847020515411HOEnZb"><font color="#888888"><div><br></div><div>-walter</div><div><br></div>-- <br><div class="m_-239355847020515411m_-4800040608507182295gmail_signature"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div>
</font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
SLOBs mailing list<br>
<a href="mailto:SLOBs@lists.sugarlabs.org" target="_blank">SLOBs@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/slobs" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/lis<wbr>tinfo/slobs</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div>
</div></div>