[IAEP] Topics & deliverables from Marketing IRC meeting 03-03-2009: Sugar 8.4 launch date set!

[Tomeu Vizoso]

On Fri, Mar 6, 2009 at 13:00, Sean DALY <sdaly.be at gmail.com> wrote:
> Extremely informative Morgan, many thanks indeed. I am confused!
>
> From a marketing & PR point of view (bear with me please) I find it
> very odd that a version used by hundreds of thousands of children is
> still zero point something.

Well, we had this idea of Sugar being an upstream FOSS project, which
means that we ourselves won't try to deliver a finished product to
users, other organizations would take care of that.

OLPC would ship a product containing Sugar on their XOs, Fedora and
Ubuntu would ship Sugar as one more desktop option in their linux
distros, SolutionGrove may maintain images of Sugar on a Stick and
sell sticks and support, etc

Sugar would be something quite similar to GNOME and would relate to
other organizations that distribute software in a very similar way.

But now we seem to have decided to push Sugar as a brand, much
stronger than GNOME has been to date. And we are also selling a
product: Sugar on a Stick.

So perhaps we should stop imitating GNOME and look at the Mozilla model instead?

One immediate issue is that Mozilla is both the company name and the
software platform, but Firefox is the user-facing product. We don't
have these two separate brands, but only Sugar. What can we do here?
Invent one more brand?

Also, Mozilla has big money, offices, dozens of employees, branches
around the world, etc. Do we want SugarLabs to become something like
that? We agreed 'no' some months ago, but perhaps opinions have
changed since?

Anyone sees other interesting models on which to base our strategy?

Regards,

Tomeu

> The nontechnical computer-using mind
> historically assumes v1.0 is the first production version, v2.0 adds
> features, and v3.0 reaches maturity with best performance and
> stability. This numbering has served Firefox well for example. And
> OpenOffice. Miro has been marketed like this too. And Audacity, with
> v1.2.x and now v1.3.x.
>
> From 0.82 to 0.84 doesn't sound like much to the nontechnical ear, yet
> I know there has been an enormous amount of work done these past few
> months. At this numbering rate, Sugar will get to v1.0 in six years or
> so, and v2.0 when today's kids are in university :-(
>
> Now, what I am about to suggest might be sacrilegious and bring the
> temple crashing down about my ears, and I don't wish to offend anyone,
> but can we please consider a cleaner, more comprehensible numbering
> system with this release? Parent- and teacher-facing, easily
> understandable? And which could minimize impact on the
> developer/deployment/package side?
>
>
> Let's think about it:
>
> * v1.0 doesn't seem to make sense right now, not only because it may
> not seem justified from a 0.82 -> 0.83 -> 0.84 &c. point of view, but
> because it would be weird to call a new version of an already
> widely-deployed environment v1.0.
>
> * v1.82, v1.84 could seem interesting, but that leaves the the only
> second decimal place change which will still seem minor.
>
> * v2.0 seems presumptuous and if there is more than a new version
> every year, we will too quickly arrive at v5.0 and v6.0 and eventually
> v12 like Corel Draw (and if memory serves, to avoid unlucky v13 they
> went to... vX3 !)
>
> * Or: We could lose the 0.8 and simply replace it with 1. So 0.82 ->
> 0.84 becomes 1.2 -> 1.4. Bugfixes could become v1.4.1, v1.4.2. This
> seems to me a very good solution: the rule for changing the numbering
> developer-side is easy to understand, the 8.2 / 0.82 confusion
> disappears, bugfix releases have an appropriately minor decimal point;
> but best of all, very easy to understand, communicate and market. It's
> intuitive and appropriate that the version be 1.x considering the
> installed base in production worldwide. A major milestone (I am
> thinking in particular of a very robust and reliable Sugar on a Stick
> which will have a major marketing push) could therefore be v2.0.
>
>
> I am aware radical numbering changes are never easy and there are
> surely issues I'm not aware of, such as upgrading XOs, package
> managers, etc. But there *are* historical precedents, the best-known
> perhaps being Word for Windows v2 which went to v6 - because the Mac
> version was developed faster (and had a larger installed base at the
> time) and went through v3, v4, and v5. Word 6.0 was the first version
> called simply "Word", where the Mac and Windows feature sets and
> version number were aligned on both platforms.
>
>
> As a fairly basic user of Sugar on the XO (I G1G1'd these past two
> years), I have never understood the mysteries of version numbering
> aside from the "build number". I am pretty sure I have "build 767" on
> my XOs, but if you were to ask me today what version of Sugar I have,
> I would say it is either 8.2 or 0.82, I don't know which, except
> developers prefer talking about "0.82". I'm really worried now about
> communicating just what version is coming out to teachers and parents.
>
>
> Now, if this proposal seems too radical a change, I'm all ears for how
> to improve what we have and dispel the fog. I think we can agree the
> existing numbering system is very confusing and will leave v1.0 much
> further in the future than it should be...
>
>
> thanks
>
> Sean
> Marketing Coordinator
>
>
>
> On Fri, Mar 6, 2009 at 9:57 AM, Morgan Collett <morgan.collett at gmail.com> wrote:
>> On Fri, Mar 6, 2009 at 09:55, Sean DALY <sdaly.be at gmail.com> wrote:
>>> No, not nitpicking!
>>>
>>> Let's be clear what the version number is.
>>>
>>> I have seen both "0.84" and "8.4" and "8.4.0" and "8.4.1", and for the
>>> nontechnical user the "build" number can be confusing.
>>>
>>> Which is it?
>>
>> 0.84.0. It's a release of software, not a build.
>>
>> The most confusion happened when OLPC released an operating system
>> release called 8.2.0 containing a Sugar release version 0.82.0. We
>> subsequently had a Sugar release 0.82.1, and OLPC's still working
>> towards an 8.2.1 operating system release. The 8's and 2's and 0's had
>> nothing to do with each other and it was an unfortunate coincidence...
>> OLPC's numbering scheme had the 8 referring to 2008, the 2 being the
>> second major release of the year, and the 0 (or 1) as a minor version
>> number, with 8.2.1 intended to be a minor bugfix update to 8.2.0. (Now
>> with 9.1.0 abandoned, 8.2.1 has grown in scope.)
>>
>> Roughly a year ago or so, Sugar packages had version numbers of
>> 0.75.x, probably denoting roughly "three quarters finished" - since
>> version 1.0 is usually a significant milestone for a project, often
>> considered to be feature-complete. While 0.75.x was stabilizing for an
>> OLPC release, new features were landed on a separate branch and
>> released as 0.79.x releases. Only features approved by OLPC for
>> inclusion (due to the semi-code-freeze) were then incorporated in
>> 0.75.x.
>>
>> Since then, we had 0.81.x as a series of "unstable" or "developer"
>> releases - snapshots of code under active development which were not
>> particularly tested, which stabilized and led to the 0.82.0 stable
>> release. This had bugs, some of which were fixed in the 0.82.1 stable
>> release.
>>
>> This set in motion a plan to have odd numbers (0.81.x, 0.83.x) as
>> unstable releases and even numbers (0.82.x, 0.84.x) as stable releases
>> - as various other Free Software projects also do.
>>
>> If there were more developers, we could have continued support of this
>> stable release and produced an 0.82.2 stable release while working on
>> the 0.83.x unstable releases.
>>
>> 0.83.x unstable releases were produced, and once the feature freeze
>> occurred the emphasis was on stabilizing and bug fixing, leading to
>> the 0.84.0 stable release.
>>
>> The plan right now seems to be to work on bug fixes for 0.84.0 leading
>> to an 0.84.1 stable release, which wouldn't have new features, just
>> bug fixes.
>>
>> New features in the pipeline will land in the coming 0.85.x unstable
>> releases, leading to an 0.86.0 release in about 6 months' time.
>>
>> Distributions are welcome to package the odd numbered unstable
>> releases in developer snapshots, alpha releases etc to provide  easier
>> testing of those milestones, but the releases most suitable for stable
>> distro releases are the stable Sugar releases.
>>
>> Phew! I think there's an open spot on the Documentation Team for a
>> Biographer of the project...
>>
>> Regards
>> Morgan
>>
> _______________________________________________
> Marketing mailing list
> Marketing at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/marketing
>