No subject

partners and projects is community liaison and is best served through
direct contact, information sharing and negotiation. Should any
distros become motivated to market Sugar to educators (as opposed to
just adding it to their distro), we could of course be very helpful.

But our two biggest ongoing projects, the XO-1.5 refresh and SoaS,
require separate and I believe higher priority marketing strategies.

1. The XO-1.5 refresh.

OLPC has probably not given a lot of thought to XO-1.5 marketing,
although I feel they certainly should, for several good reasons:
* silencing naysayers who talk about the "failure" of the OLPC project
* making clear what the XO-2 strategy and timetable is (in the absence
of this info there will be confusion and speculation)
* sharing OLPC Stories, showing the worldwide impact of OLPC, and not
only in midsize and small developing countries
* explaining unambiguously what the dual default Gnome-Sugar desktop
is, how it works, and what the advantages are
* communicating that a newer improved version of Sugar will be on it
* publishing some deployment numbers so serious journalists will know
what's what
* giving some indication as to what the Windows on XO status is.

They will probably not want to say that the Windows pilots have not
resulted in contracts. However, it's entirely possible that the
updated hardware will allow XP or even Windows 7 to run, which could
still lead to contracts, so I feel it's not something for Sugar Labs
to crow about beyond stating the obvious, that buyers prefer Sugar.
Journalists, analysts and pundits will want to know what's up with
Microsoft though and OLPC will need to address that to avoid
confusion.

For us, the refresh is an opportunity to say that OLPC has made a vote
of confidence by choosing the latest version of Sugar (or "a later"
version, if the refresh arrives after Sept.18th), for the benefit of
hundreds of thousands of Learners to come. The dual desktop is no big
deal since we are positioning ourselves as best-in-class K-6 and it's
natural that older Learners will want to explore free software and
tools beyond Sugar. (By the way, many Intel Classmate projects boot by
default into a locked-down kids' desktop such as EasyBits Magic
Desktop, allowing access to Windows only through a password exiting
tthe desktop.)

It's my wish to work with OLPC on the refresh message, it's their
golden opportunity to reverse the negative associations amongst
journalists and in the blogosphere and pave the way for the XO-2. The
availability of SoaS means interested observers can have the core
experience of the XO-1.5 on any other machine.


2. Sugar on a Stick.

I would venture that the importance of this "distro" far outweighs all
the others, because no one else is marketing Sugar to educators like
we are and SoaS is our project - in its current incarnation it depends
on Sugar upstream and Fedora upstream, a solid partner since Fedora is
an active project with known release dates. Could there be an
alternate SoaS non-Fedora distribution? I feel the answer is yes and
we could certify the name for another, but only if the quality and
ease of use (including stick loader) could match or surpass the
Fedora-based one. The underlying distro should not be visible anyway,
inasmuch as it is in a support role and the distros can't bring any
brand value to teachers and educators at this time.

Sugar on a Stick is a game changer, disrupting the status quo in
bypassing the stranglehold of preinstalled systems (98% of which are
not distros). Its very low cost and very high quality make it a
compelling choice for classrooms. The possibility of relieving kids of
lugging computers around, yet keeping their environment with them, is
an incredible advantage. The next few months are our opportunity to
prepare SoaS for classroom deployments and to find the missing pieces
of the puzzle such as school server, documentation, hardware
compatibility notes including Macs, Local Labs to help with
implementation while school system integrators get up to speed.

Our biggest marketing efforts should be on Sugar on a Stick, and in my
view the ideal release timing
is three months before the new school year (June in the Northern
Hemisphere), giving educators enough time to evaluate, plan, and test
its deployment. However, the actual timing is not as critical as
making sure we can maximize marketing impact; ideally, creating buzz
during or prior to NECC in the USA for example, or another key
educators conference.

SoaS v1 Strawberry F11/v0.84 could very well be SoaS v1.1 Strawberry
F12/v0.86 by the way, if the Learner experience is close enough. In
other words, the numbering/naming should be based on the end-user
experience, and not what techno goes into it. Our wide coverage was a
direct result of positioning SoaS as our first major standalone
release, replacing the complicated numbering system with a simple one
instantly understandable to everyone; it may well make more sense to
plan the v2 "another flavor" for a year from now and not sooner. In
the meantime, we can build the brand value of Sugar on a Stick by
building its ecosystem, learning from the GPA pilot, building the
Activity and ebook offers, and of course repeating our
differentiators.

An OEM deal targeted to education could change this strategy, but at
this time I feel this is the best way forward.

thanks

Sean



On Thu, Jul 2, 2009 at 12:41 PM, Simon Schampijer<simon at schampijer.de> wrot=
e:
> On 07/02/2009 12:27 PM, Tomeu Vizoso wrote:
>> On Wed, Jul 1, 2009 at 18:18, David Farning<dfarning at sugarlabs.org> =A0w=
rote:
>>> On Wed, Jul 1, 2009 at 7:14 AM, Tomeu Vizoso<tomeu at sugarlabs.org> =A0wr=
ote:
>>>> On Wed, Jul 1, 2009 at 00:40, David Farning<dfarning at sugarlabs.org> =
=A0wrote:
>>>>> This thread is an attempt to help clean up a couple of issues that
>>>>> have been cropping up over the past couple of months.
>>>>>
>>>>> There have been a couple of instances of suboptimal communication
>>>>> between different parts of the project.
>>>>>
>>>>> Several times recently, external organizations have been looking for =
a
>>>>> big picture view of what is happening at Sugar Labs.
>>>>>
>>>>> The .84 release was pretty easy to coordinate. =A0The development tea=
m
>>>>> picked a release date about six months after .82. =A0The developers
>>>>> followed the time line pretty well. =A0Simon did a fantastic just wit=
h
>>>>> just a stick and a handful of carrots as release manager getting
>>>>> getting the release shipped on time. =A0The only two external
>>>>> organizations we worked with closely were Fedora and OLPC.
>>>>>
>>>>> With the midterm release of Strawberry, we have seen the importance o=
f
>>>>> improving communication with more internal groups and external
>>>>> organizations.
>>>>>
>>>>> Internally, we have seen the importance of synchronizing development,
>>>>> marketing, and the project as a whole's time lines and goals.
>>>>>
>>>>> Externally, we have seen a significant increase in external
>>>>> organization participation. =A0Several university have express
>>>>> interested in working with SL. =A0Several distributions are becoming
>>>>> more involved. Several new pilots and deployments are participating i=
n
>>>>> Sugar development rather than just consuming Sugar.
>>>>>
>>>>> A first step will be to start working on project and team level road
>>>>> maps which assign dates and champions to significant events.
>>>>>
>>>>> Sugar Labs and each team already have =A0roadmap pages listed. =A0Ove=
r the
>>>>> next couple of weeks, I would like to work with the development, SoaS=
,
>>>>> marketing, infrastructure teams to create roadmaps and goals. =A0(Thi=
s
>>>>> is not to exclude any other teams participation.)
>>>>>
>>>>> Then using iteration and project level goals we can start linking the
>>>>> roadmaps together.
>>>> Sounds great!
>>>>
>>>> Tomeu
>>>>
>>> There is now a very rough draft/outline at
>>> http://wiki.sugarlabs.org/go/Sugar_Labs/Roadmap .
>>
>> First of all, you mention several times a "release" but don't specify
>> what gets released. Also, is the Sugar Learning Platform the upstream
>> project? What about SoaS? Also, what is "Unified SoaS"?
>>
>> "Release dates up to and including .86 have been determined by the
>> development team. Starting with .88, the release schedule will be
>> determined by the Sugar Labs oversight board."
>
> Is this picking a date for the release or deciding what goes into a
> release?
>
> For the date - we have picked it to align to our downstream projects -
> the linux distributions. So far this worked quite well. So the current
> dates are not picked arbitrary.
>
> Features: Depending on the Fedora policy I hacked up this one for
> features: http://wiki.sugarlabs.org/go/Features/Policy
>
> To reduce overhead, like an engineering steering commitee I took out the
> Fesco part. I think for the near future we are fine with such a 'simple'
> policy.
>
>> I didn't knew that the oversight board was supposed to take such
>> day-to-day decisions. In any case, I hope that the date that the SLOBs
>> decide for the Sugar Learning Platform is the same as the development
>> team decides, because otherwise we are going to have a big conflict
>> here.
>
> +1
>
> Regards,
> =A0 =A0Simon
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>