[Sugar-devel] [IAEP] Planning for the future (Samuel Greenfeld)

Sean DALY sdaly.be at gmail.com
Wed Mar 18 10:32:30 EDT 2015

cc'ing the Marketing list - the one everyone forgets as soon as they
discuss marketing.

The MarketLab study we worked on back then confirmed what we already knew -
that Sugar's websites did not accompany teachers interested in Sugar, and
that Sugar absolutely needed a simple installer. They also advised that we
should use visuals of children heavily in our marketing. I myself could no
longer donate thousands of USD to keep marketing going and organize photo
shoots, so we asked the community several times for images. We were unable
to obtain any usable, released images.

Even before the study, we had tried to federate the multiple Sugar websites
under a common menu bar until a more unified website could be created, but
no one was interested in working on that - at the time I remember someone
even said that teachers could "prove" their motivation by finding scattered
information themselves (!)

The biggest problem then, simplifying access to Sugar so interested
educators and journalists could overcome the installation and unfamiliarity
barriers, remains pertinent today. If the community really got behind Sugar
on a Stick or a VM matrix or a Raspberry Pi build - testing, documentation,
"polish" - this "product" could happen. Sugar is both a very different
interface to classic "desktop" analogy GUIs familiar to adults, and (except
for XOs and some Classmates) absent from any machines which could run it.
To be properly evaluated by any interested educator or journalist, it must
be obtained, installed and configured, then understood, and finally
compared with competing solutions. These are enormous hurdles to access
Sugar, and lowering or eliminating these barriers should be top priority.
Are they?

I believe Sugar in a browser, keeping its core values in particular View
Source, is the best way to eliminate the installation and unfamiliarity
barriers. It may also be in the long term the best way to run Sugar.

Free/libre open source software projects are generally awful at marketing,
perhaps because most engineers don't understand it. Great effort is put
into technical professionalism, while most marketing efforts are
breathtakingly amateurish. As someone who has worked as a developer,
journalist, IT director, and the past dozen years in marketing, I like to
think I understand both sides. Marketing is often assumed by developers to
be "recruitment" - certainly important, but our real target is educators.
Grassroots marketing is great - we all do it - however, it isn't sufficient
to bring Sugar to tens of millions of children, through millions of
teachers. We do have the competence to do world-class marketing. What we
don't have is an easy-to-try, stable product, and the necessary resources
(human, financial). A great product or service is at the heart of effective
marketing - even companies with enormous marketing budgets (on average 11%
of overall budget, source The CMO Survey by Duke University Fuqua School of
Business) have difficulty moving a product unsuited to the market.

Sugar has great branding, just no brand awareness. We tried to improve this
in XO countries by placing a Sugar logo in the OLPC splash screen, and
asking OLPC to mention Sugar in their PR (the anti-Sugar people pushed back
against this). The slickness of our graphics chart has even worked against
us - the Marketlab people found that we were perceived as a for-profit
startup, which is why we play up the "nonprofit" in our PR since the study.
OLPC (outside the countries with large XO deployments) has no brand
awareness either. We don't have the funds to do market studies, but I would
wager that unaided awareness of the OLPC logo in educators doesn't top 5%.
OLPC's real brand is the XO itself, which is why even today you see
Pantone-361 green and white objects everywhere (for example:

So yes, we need "more marketing", just like we need "more developing",
"more packaging", "more testing", "more documentation", "more feedback from
educators & children", and "more outreach". Lack of resources has been a
critical factor in slowing Sugar, but I believe that in order to convince
charitable givers, we need a plan that the community supports, and to
demonstrate that we have the necessary skills to pursue the roadmap with a
chance of success.


On Wed, Mar 18, 2015 at 12:47 PM, Gonzalo Odiard <godiard at sugarlabs.org>

> Thanks Sam. I never read that.
> Have good points.
> Gonzalo
> On Wed, Mar 18, 2015 at 8:21 AM, Sam P. <sam.parkinson3 at gmail.com> wrote:
>> I just found this interesting powerpoint from a few years ago.  Slide 25
>> is basically a summary of this discussion:
>> https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxtYXJrZXRsYWJzdWdhcnxneDo0Y2U3ODFjZDczMmU1Mjlh
>> Thanks,
>> Sam
>> On Sun, Mar 15, 2015 at 7:16 AM Gonzalo Odiard <godiard at sugarlabs.org>
>> wrote:
>>> Thanks Sameer, very good points,
>>> a few comments/questions below
>>> On Fri, Mar 13, 2015 at 5:53 PM, Sameer Verma <sverma at sfsu.edu> wrote:
>>>> Interesting thread. I'll reply to Lionel's post, but my reply is more
>>>> of my own set of ideas and understanding.
>>>> Putting on my business school researcher hat:
>>>> 1) The eventual goal of this project should be to influence the
>>>> adoption of Sugar across the world. A person's attitude, combined with
>>>> subjective norms, forms his behavioral intention
>>>> (https://en.wikipedia.org/wiki/Theory_of_reasoned_action). To
>>>> influence adoption, we have to address the attitudes of the potential
>>>> adopter, and the subjective norms. Should Sugar be a part of that
>>>> ecosystem (such as a school's curriculum) or apart from it?
>>> Do we have a option? I don't say the school is the only channel to reach
>>> kids,
>>> but is the more massive channel without doubt.
>>>> 2) Role of marketing:  Most of what I've seen thus far is focused on
>>>> the internal producer view of OLPC/Sugarlabs. This is natural, given
>>>> that that's the world view we are most familiar with. The role of
>>>> marketing is to take this internal view, and adapt its value to make
>>>> it attractive to the consumer. If this adaptation fails, we end up
>>>> with over-engineered products that the market rejects. This adaptation
>>>> is largely dependent on addressing the perceptions of the consumer.
>>>> This is one of the reasons why shiny products sell - we associate
>>>> shiny with expensive, be it chrome polished plastic or iPads. At this
>>>> point if you are saying to yourself "we don't care for marketing or
>>>> consumer" you are sorely mistaken.
>>> We need more marketing without doubt.
>>>> 3) Vision and Mission are important for the project: Vision is an
>>>> inspirational, directional, future state description. Mission is
>>>> largely how we get there. Both should be referenced on the basis of a
>>>> time frame. So, vision and mission for now + 5 years is a good target.
>>>> These might appear cheesy, but FOSS projects are usually non-strategic
>>>> by design, because we are all busy writing small bits and pieces,
>>>> hoping someone will stitch it all together eventually. We "scratch our
>>>> own itch" in a piecemeal fashion, by writing scripts for battery
>>>> stats, frame icons, Journal data and such. FOSS projects strive for
>>>> operational excellence. Then, we hope that all this gets weaved into a
>>>> fabric that can be used by someone (kids). The same applies to Apache,
>>>> Ubuntu, Drupal, Linux, etc. In all those cases, there is a foundation
>>>> or association or company that puts resources (time and money) and
>>>> provides strategic direction, because the project isn't designed to do
>>>> so by itself. Apache Software Foundation, Canonical, Drupal
>>>> Association, Linux Foundation play that important role (I am on the
>>>> Board of Directors of the Drupal Association, and some of this
>>>> thinking is from my observations there). Vision, Mission, Goals,
>>>> Objectives etc. should come from somewhere for Sugar/olpc. For a while
>>>> it came from OLPC, but right now, I don't see any of it in an
>>>> organizational manner.
>>>> 4) In the free and open source world, the consumer is also sometimes
>>>> the producer. So, instead of treating the consumer as someone with
>>>> limited feedback (as may be the case with Windows or MacOSX) the
>>>> consumer can switch roles and become a producer (like Ignacio or
>>>> SamP). http://www.oecd.org/sti/inno/37450155.pdf This can lead to a
>>>> myopic view of the target population being only people like Ignacio or
>>>> SamP. Should all kids open the hood to peek into Sugar and become
>>>> developers like Ignacio and SamP? Can we get into schools where they
>>>> have locked down Windows machines with no admin rights?
>>>> 5) Sugar is not a product. Sugar is a project, that keeps evolving as
>>>> time goes by. A product is when we take a snapshot and polish it with
>>>> QC, QA and package it for delivery. OLPC's build for the XO platform
>>>> is a product. Sugarizer is a product. Suagr is NOT a product. This is
>>>> just like Fedora is NOT a product. It's a project. RHEL is a product.
>>>> Or for that matter, take the Ubuntu phone. The phone delivered by BQ
>>>> is a product that took Ubuntu 14.09 and made it RTM (release to
>>>> manufacturer) and ran it through QC and QA and produced the phone with
>>>> the polished stack on it. Customers buy products, while developers
>>>> work with projects. It is imperative that we understand the difference
>>>> and treat the two as different.
>>>> I'm pretty sure Rangan Srikhanta has a strategy for
>>>> OLPCAU/OneEducation. So does Rodrigo Arboleda for OLPC Inc. I think we
>>>> (Sugarlabs+lowercase olpc) need a strategy going forward to address
>>>> Vision, Mission, etc. We also need to operationally pick approaches
>>>> (such as Sugar Web) to build for multiple platforms. Android,
>>>> RaspberryPi, Ubuntu are prime targets. Low-hanging fruit. How do we
>>>> build for Android, but also reuse it for RaspberryPi and Ubuntu? On
>>>> Android, stuff should be in the Google Play Store. On Ubuntu, it
>>>> should be a simple install via apt-get or in their Software Center
>>>> (the current builds are horribly broken). On Rpi/Rpi2, build a
>>>> completely workable version for the 5 million units out there. Heck,
>>>> people should be able to buy a SD/microSD card on Amazon to run a full
>>>> Sugar desktop on the Rpi! Way back, I had a chat with Mike Lee, and I
>>>> even proposed a name for this - sweetie pi. Remember, marketing is
>>>> key, and branding a huge part of it. Speaking of branding,
>>>> Sugar/Sugarlabs has none. It is still a vestige of OLPC, which
>>>> continues to enjoy a high brand status around the world (good, bad,
>>>> it's all publicity).
>>>> This may be a lot to digest, but unless we address of these issues,
>>>> this project will go nowhere fast.
>>> Our final users need a product, not a project. While I love have kids as
>>> Ignacio and Sam joining the project, if we want reach million of kids,
>>> we need assume 99,99% of them will not join the project,
>>> and will be happy users. In the end we say Sugar is to learn,
>>> no to earn to use a computer.If olpc is not available
>>> to distribute that product we need find a way to do that.
>>> Maybe we need a SugarLabs Foundation.
>>> I agree 100% about the need of a strategy and update our vision and
>>> mission,
>>> and I have tried in different ways to move that for many months,
>>> but couldn't find a way to do that.
>>> Gonzalo
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
> --
> Gonzalo Odiard
> SugarLabs - Software for children learning
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150318/8d7a754b/attachment-0001.html>

More information about the Sugar-devel mailing list