[IAEP] Communicating project goals and Roadmap

[Sean DALY]

I don't know Tomeu, what do you think?

Sean


On Thu, Jul 2, 2009 at 8:09 PM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> On Thu, Jul 2, 2009 at 16:37, Sean DALY<sdaly.be at gmail.com> wrote:
>> OK Tomeu
>>
>> To be clear, I'm making a distinction between marketing (in the
>> spreading the word to regular people sense, not in the FOSS community
>> building sense) and deploying. I fully agree we need to nurture a
>> large and wide downstream FOSS community.
>
> I'm a bit confused, how does this affect the guy who works on Sugar
> and releases source tarballs every 6 months?
>
> Thanks,
>
> Tomeu
>
>> So there's no narrowing of who deploys it, but a prioritization of how
>> we can get the word out to the most teachers and parents.
>>
>> I hope to see Sugar included in distros, but I hope even more they
>> make an effort to get it out to classrooms. To me, such an effort
>> would merit our marketing support. I actually think distros could be
>> much more out in front in the education sector, and Sugar could help
>> distros leap ahead in K-6, an opportunity they should seize. Look at
>> the Dell education netbook: Ubuntu went to the trouble of being the
>> standard OS on it (Windows on option), but they missed the boat on
>> making Sugar a central part of their K-6 offer. I'd like to work on
>> that with them. Dell claims 500 school districts have already ordered
>> the netbooks; rather than write them off, I'd like those buyers to
>> know that they could run Sugar off an SD-Card for each Learner, a
>> nominal expense to obtain the best learning environment for smaller
>> children.
>>
>> Distros are not good at "vertical marketing", something Apple for
>> example excels in and which Microsoft has copied these past few years
>> (look at their medical industry push). There are historical and
>> traditional reasons for that, but the situation is that distros are
>> ill-prepared to make a difference in education without helpers. We can
>> be a helper, in fact we are uniquely qualified to help in K-6. Perhaps
>> a different way to look at it is to enumerate the places where there
>> have been major GNU/Linux projects in K-6 education and concentrate on
>> those?
>>
>> Any model where we can help OEMs sell netbooks is a model that can
>> broaden distros' tiny marketshare. That's no betrayal of our education
>> mission, because we don't exclude running Sugar on an old PC with a $5
>> USB stick, or on a Mac, or even on Windows with virtualization - Sugar
>> can arrive in front of a Learner by many technical means.
>>
>> If breaking out of marginal marketshare is interesting to distros, we
>> can help them do that together. It requires marketing work on their
>> part though, the technical work is a necessary prerequisite but is
>> insufficient.
>>
>> Sean
>>
>>
>>
>> On Thu, Jul 2, 2009 at 4:01 PM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
>>> 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
>>>>>
>>>>
>>>
>>
>