[IAEP] Communicating project goals and Roadmap

[Sean DALY]

Tomeo, the essence of what I am saying is: the development team should
chart a course and stay on it (time-based releases seem to be working
well), and the downstream distros (particularly XO-1.5 and SoaS) then
the marketing team should take it from there. Which mustn't preclude
feedback from the field making its way back to the development team
too. It's when the teams aren't on the same page that we encounter
difficulties. Wouldn't consulting with the SLOBs be a reasonable form
of insurance?

What David mentioned was the importance of our big-picture roadmap
being clear. For most people, that will be the launches. For our
partners, that will be the launches + the distros + Sugar. I'm not so
sure yet if the development releases, distro releases, and marketing
launches should be in the same table on the wiki (three tables on the
same page may make more sense), but that may well be the most
effective way to reach agreement on who is doing what in what
timeframe.

We need to be prepared for unexpected events however. An OEM deal for
example would be a fabulous opportunity and would radically change the
marketing launch schedule, and add another distro to coordinate (I
would expect an OEM to bring at least some resources to help adapt
however). Its impact on the development team should be less, but for
that point I'm trying to make: at the critical moment of launch,
everyone can and should help... I feel it shouldn't be only for one
team or another, but everyone... kind of like when several of us man a
booth at a conference, each one of us willing to explain how Sugar can
make a difference in education.

Launches allow great leaps forward in raising awareness, which fuels a
positive cycle of teacher interest, contributor interest, funding
interest, spreading Sugar use in the classroom (and libraries and
homes).

Launches are not only software releases; they are about finding and
configuring and presenting newsworthy stuff, things teachers might
discuss at lunch break. We will surely be preparing content-based
launches centered on Activities, leveraging ebooks and online content,
reporting on deployments, partnerships, etc.

I'd like to be careful not to impose burdens on the development team.
Marketers at proprietary companies are (in)famous for that, usually
because of intense competition. I take "don't overpromise" very
seriously (difficult as it is). I think we can go further by being
smarter, and part of that is not interfering with the free software
way. I do think though that it's worthwhile for us to share
timetables.

thanks

Sean




On Fri, Jul 3, 2009 at 3:27 PM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> 2009/7/2 Sean DALY <sdaly.be at gmail.com>:
>> I don't know Tomeu, what do you think?
>
> I sincerely don't know but I hope that someone will explain what they
> need from the development team to succeed.
>
> Your plan for the marketing team sounds excellent to me, but David's
> proposal goes way beyond that team. And you have chosen to explain the
> marketing roadmap inside this thread.
>
> So, would someone care to explain which are the organizational changes
> that are being requested? I have made more concrete questions before
> in this thread.
>
> Regards,
>
> Tomeu
>
>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>