[IAEP] Communicating project goals and Roadmap

[Tomeu Vizoso]

On Thu, Jul 2, 2009 at 15:39, Sean DALY<sdaly.be at gmail.com> wrote:
> Now is a good time to work on this, as the SoaS launch is behind us.
>
> My understanding is that Sugar Learning Platform releases such as
> v0.84, v0.86, v0.88 are of interest to our downstream partners and
> projects... distros naturally, but in particular the OLPC XO-1.5 and
> the Sugar on a Stick Fedora-based distribution + tools.
>
> The XO-1.5 is of interest to everyone involved in OLPC projects but
> particularly Learners, who certainly have things to tell us about the
> Sugar they have if they could.
>
> Sugar on a Stick is of interest to everyone in K-6 education:
> teachers, school management and buyers, parents of kids in school.
>
> At this time, the distros do not have the reach or potential impact of
> these two projects. I feel therefore our marketing priority should be
> on these two projects, and especially Sugar on a Stick, here's why.
>
> The enormous OLPC installed base is the source of our credibility and
> adding potentially hundreds of thousands more Learners through SoaS
> makes us news, in particular SoaS running on other large installed
> bases such as Intel Classmates and old PCs.
>
> From a marketing perspective, dialogue and coordination with our
> 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.

I think this is a very good plan for the downstream part of SLs, but
unfortunately plays very bad with my work as an upstream developer. It
makes a lot of sense for you to focus on some ways to deploy Sugar and
thus on one (or two?) distros, but Sugar as an upstream project needs
to nurture an as big as possible downstream community.

Or could you make a case on how I as an upstream developer would win
anything by narrowing the people that can use my stuff?

Thanks,

Tomeu

> thanks
>
> Sean
>
>
>
> On Thu, Jul 2, 2009 at 12:41 PM, Simon Schampijer<simon at schampijer.de> wrote:
>> On 07/02/2009 12:27 PM, Tomeu Vizoso wrote:
>>> On Wed, Jul 1, 2009 at 18:18, David Farning<dfarning at sugarlabs.org>  wrote:
>>>> On Wed, Jul 1, 2009 at 7:14 AM, Tomeu Vizoso<tomeu at sugarlabs.org>  wrote:
>>>>> On Wed, Jul 1, 2009 at 00:40, David Farning<dfarning at sugarlabs.org>  wrote:
>>>>>> 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.  The development team
>>>>>> picked a release date about six months after .82.  The developers
>>>>>> followed the time line pretty well.  Simon did a fantastic just with
>>>>>> just a stick and a handful of carrots as release manager getting
>>>>>> getting the release shipped on time.  The only two external
>>>>>> organizations we worked with closely were Fedora and OLPC.
>>>>>>
>>>>>> With the midterm release of Strawberry, we have seen the importance of
>>>>>> 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.  Several university have express
>>>>>> interested in working with SL.  Several distributions are becoming
>>>>>> more involved. Several new pilots and deployments are participating in
>>>>>> 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  roadmap pages listed.  Over the
>>>>>> next couple of weeks, I would like to work with the development, SoaS,
>>>>>> marketing, infrastructure teams to create roadmaps and goals.  (This
>>>>>> 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,
>>    Simon
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>