[Sugar-devel] The ARM is near

[Tomeu Vizoso]

2009/8/29 Philippe Clérié <philippe at gcal.net>:
> Your points are well taken and generally I agree with them. Except
> that I never suggested you should "abandon upstream development".
> Sugar is your calling card, your differentiator, your trademark, your
> value added... etc, etc, etc. It's what make you, you. :-) I would
> never think of abandoning it.
>
> I also differ on the question of attracting more people. I think more
> focus is better than less, but I am willing to suspend disbelief.
> But that gives me an opportunity to bring up a point that I find much
> more interesting. I believe Sugar has a peculiar problem to solve.

Yes, I think plurality is something very deep into Sugar Labs (hence
its plural form) and the discussion of instituting different projects
inside Sugar Labs also goes into that direction: every individual
project can define very well its focus and can attract the specific
profiles that it needs.

Sugar itself is also more a platform that supports activities rather
than what the user uses most of the time. SoaS needs contributors with
Linux distro skills but those people don't need to be able to code.
Karma needs web developers but those doesn't need to have any
knowledge of Linux desktop development.

I think that if we keep clear the borders between projects we can
leverage the focus of each one and set an efficient framework for all
the projects to work together.

> You need to somehow bring together educators and developpers around
> a particular philosophy of education. The intersection of those sets
> appears to be a very small set. You need to widen that set. I think
> a dedicated distribution might help. It would be a point of focus.

Yes, now that Sugar is being brought to more school scenarios I think
it will make sense to develop products that make deploying there
easier. For example, Simon is deploying fat clients with LDAP and NFS
in Berlin, the GPA team is deploying SoaS in Boston, Sugar Labs
Colombia is thinking about deploying Sugar based on LTSP, etc.

I'm not sure we can produce a single distro that is optimized for such
different use cases but if we manage to leverage the volunteer
potential of each of those (as of yet) local deployments, we can first
document and later perhaps produce such focused distros.

The problem I see and don't know how to solve is how to preserve and
take advantage of the Sugar brand in such different endeavours.

Regards,

Tomeu

> Cheers,
>
> --
>
>
> Philippe
>
> ------
> The trouble with common sense is that it is so uncommon.
> <Anonymous>
>
> On Saturday 29 August 2009 08:56:39 Tomeu Vizoso wrote:
>> 2009/8/29 Philippe Clérié <philippe at gcal.net>:
>> > Well, I wasn't attempting to solve anything. I thought I was
>> > just brainstorming.
>> >
>> > These past few weeks there have been a lot of discussions about
>> > processes. Meanwhile, I am heading into the classroom with a
>> > somewhat unstable and unfinished platform not to mention very
>> > little guidance as to exactly how to make this thing work. I'll
>> > probably let the kids take the lead.
>> >
>> > Calling Sugar a distribution might not solve anything
>> > (certainly not my own problems), but it might help us focus on
>> > the practical matter of deciding how to put out that
>> > distibution instead of arguing about how to decide what we're
>> > about to do.
>>
>> Ok, so the idea is to focus our resources on the distribution
>> level? I'm not very fond of that because:
>>
>> - we aren't a company that has resources and puts them wherever
>> its management says so. Work is done by volunteers and they work
>> on whatever they fancy. I think that having less focus is useful
>> here because brings more interested people onboard that we
>> otherwise wouldn't have.
>>
>> - polishing a distribution is _lots_ of work. Canonical, Novell,
>> Redhat, etc. are putting lots of resources into there. I think
>> that a small set of people can take one of those distros and make
>> it work better for a specific use case, but we aren't going to
>> outrun the big players in a generic, polished distro.
>>
>> - other organizations are already taking Sugar and distro bits
>> and putting them together for their specific use cases. Maybe no
>> one is doing that yet for your use cases, but I don't think it
>> means that we need to drop whatever we are doing and do that
>> instead. If we have opportunities open and advertise them
>> properly, we may get people to do the work.
>>
>> - if we abandon upstream development, what point is in packaging
>> it?
>>
>> Regards,
>>
>> Tomeu
>>
>> > --
>> >
>> >
>> > Philippe
>> >
>> > ------
>> >
>> >> So is the only problem what we are calling Sugar today? If we
>> >> rename SoaS to Sugar and Sugar to Sucrose, how we would be
>> >> solving anything?
>> >>
>> >> Thanks,
>> >>
>> >> Tomeu
>> >
>> > _______________________________________________
>> > Sugar-devel mailing list
>> > Sugar-devel at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning