[IAEP] Sugar Labs or Sugar Daddy

Sebastian Silva sebastian at fuentelibre.org
Thu Dec 18 01:14:02 EST 2008


I appreciate that we're having this conversation openly. Seeing that
we're all in "organizational development" mode and in the process of
defining our respective groups/missions and negotiating our roles, I
agree with Caroline that at this point it would be wise to talk, but
unwise to set things in stone.

I want to share some of my thoughts on this. I hope its not a distraction.
An organization is often portrayed as people having common values and
objectives organizing together to achieve their goals. Sometimes,
however, after people get together and define the "mission", lots of
energy gets wasted on defining the ideal organization/structure to
fulfill this "mission", considering everybody's version of it that is
in the group and making everybody happy.

Sometimes these "cells" become so self-referential that they loose
track of their connections outside. The organization, and thus its
"code" must adapt itself to its environment, concretely, its social
role, in its relations to others, the protocols we use to negotiate
working together. For any given situation, the organization should
adapt itself, even structurally, without losing its sight on its
mission.

Whatever "protocol" SL decides to use to connect outside, it must take
into consideration "outside".
In my mind this includes:
- A large noncommercial sub laptop vendor (largest user base)
                 * barely accessible for grassroots implementors
- A (fast) growing market  for education tech services providers
- Other projects deployers will likely also need to integrate
(GNU+Linux, Moodle...)
- A growing market of netbooks

So considering this "environment" and our "principles" (whatever those
are!) and our "mission", SLOBS should decide (approve/reject)
projects.
These criteria should be explicit, as well as the reasons to reject an
project (with recommendations). Projects should be expected to include
a sustainability statement.

I am convinced this "project-oriented" organization can be made agile enough.

2008/12/17 David Farning <dfarning at sugarlabs.org>:
> On Wed, Dec 17, 2008 at 12:59 PM, Caroline Meeks
> <solutiongrove at gmail.com> wrote:
>> On Tue, Dec 16, 2008 at 1:25 PM, David Farning <dfarning at sugarlabs.org>
>> wrote:
> On the code side, Sugar Labs started with a big chunk of useful code
> from OLPC.  But, yes I agree we are doing poorly on the content side
> of things.  It will take a significant investment of some sort to jump
> start the content side of the project.
>

This is a "project" I think many of us share. It is in the best
interest of everyone around Sugar. We have started discussing the
creation of a team to develop some training materials that we can all
use. Pilar from Colombia, who has already done a workshop, will also
be participating. This will be my main task during January, by the end
of which I hope we have a first release. Once we have some specific
goals and a Roadmap, and have talked with stakeholders involved, we'll
make an announcement. Please feel free to join us if anybody else is
interested in contributing. We'll probably work heavily in spanish (I
hope).

>>>
>>>
>>> I am convinced that the correct business model for Sugar Labs, will be
>>> a combination of licensing the Sugar and Sugar Labs brands to partners
>>> and donations.
(...)

> Branding comes in a number of different varieties. From
> intrusive(think professional sports) to unintrusive (think linux).
> Sugar Labs should be able to find a point somewhere between the two.
> Geographically limiting competition by a band is common is some type
> of business.  It is pretty hard to get permission from McDonalds to
> open a new new franchise next to an existing one.  Exclusivity of
> territory is one of the  promises one gets when purchasing a
> McDonalds.  On the other hand, coke is willing and eager for anyone to
> resell their brand anywhere.

The problem with the Redhat / IBM model, even though they are
technically part of the free software community, in that they develop
free software, is that they cater to a very specific tiny premium
slice of the market. From where I am sitting, at the other end of the
spectrum, RedHat and IBM are not brands, but phantoms of a different
universe. In a small town or rural area (50% of the planet), those
names are obscure, for a good reason. In great contrast with IBM's and
RH's models, we want to empower *every* child to learn to learn.

In this rural environment, we have two models of tech penetration. One
is cell phones, the other is the local internet "cyber" / pirate DVD
shop. The cell phone market is usually controlled by abusive telephone
carriers and the internet shop is used for emailing relatives, writing
documents and gaming.

While in theory, an organization could develop a model for servicing
this other 50% of the world... it would probably not be very good
business for a centralized company.

Now since you mention McDondalds, back in Chile, there is a street in
Providencia Street (I used to work in), that had 3 McDonalds in it. If
there's demand, they'll do it.
On the other hand, I heard McDonalds had to close down its business in
La Paz, I hear because there was an old lady next to it that sold
cheaper, better food.

I am closer to the lady than I am to the McDonalds manager, so I'm
thinking about models that can accommodate her needs, to our
structure. The public school teacher in charge of a computer room is
the old lady for me. The community telecenter ( "cyber cafe internet"
) is another example.

In this other often forgotten 50% of our "market", I want to provide
the mechanisms and models for these people to connect to each other
and organize. So its not just about business partners / Independent
service providers, but its also about community partners and the
fostering of communities of practice.

I wanted to share another, defunct, failed project I was briefly a part of.
Its called UserLinux, some might have heared of it. We had some very
similar discussions related to branding and sustainability models and
relations with service providers, and then Ubuntu came along before we
had something going. This is why RoadMaps are important.

Some highlights from the UserLinux white paper [1]:
<quote>
"We have no problem with payment for service, when service is
rendered. But (...) many customers now pay for [GNU+Linux] goes not
for service, but for a brand and the endorsement of a few application
providers (...)"
"We, the Free Software developers, created this software to empower
everyone, and for everyone to share."
"Trust in a brand will come easier when the brand is one developed for
an industry, by that industry."
"Debian has a fair and democratic structure, an equal partnership
between all participants, and a legal non-profit organization."
"Fedora" is where the community developers are supposed to build Red
Hat's product, while the certifications and vendor endorsements are
held back for the high-priced "Red Hat Enterprise Linux" brand."
</quote>

In between, there is Ubuntu, which came to fill the void UserLinux was
trying to, because it achieved its goals faster, with a simpler
organizational model, a cooler name/brand and an actual product. This
"simpler" organizational structure was: using RH's model, but adding a
reactionary and flaky "ubuntu promise":
- No premium enterprise edition
- Commercial support from Cannonical and partners
- Accessibility & Translations
- Floss (they add clarifying their intent: redistribute at will)

While Ubuntu satisfied the needs of the target users of UserLinux, it
sacrified some of its ideals, that is the emergence of a commercial
ecosystem around this extension of the Debian commons. In UserLinux's
model, there weren't any local official "Regional Userlinux" but,
rather, UserLinux was something third parties provided, a branded,
commercial Debian.

Rather than a product, UserLinux was engineered to become a service.
Customers were treated not as consumers, but as users, thus the name,
as it meant to imply the effort was owned and supported by its users,
like Sugar is supposed to be.

The organizational "code" we use, affects our ability to adapt to a
given "environment". In the UserLinux vs Ubuntu example, Ubuntu had
"better organizational code" than UserLinux for its environment and
mission.

In this sense, we need to be clear about our environment and mission.
Churches are possible because they are organizations based on explicit
principles/values.
>
> Licensing can vary in complexity.  Pay me $100 bucks and I'll give
> you, or anyone else, a certificate of graduation from Dave's school of
> Open Source Theory.  Work to get in, pay $10,000s, take tests every
> couple of week over a four year period and you can get a business
> degree from an credited college.  There is certainly more over head in
> the college route. On the other hand, it is worth a bit more.  Again
> Sugar Labs needs to find a balance.

I see space for both the old lady and the mcdonalds.
Something like
1-"community partner": give the old lady some training, help her
scale, get connected and legal, provide some sanitary standards,
localize and appropriate
2-"mission partner": develop joint projects, in development,
large/medium deployment, special platforms (OLPC), products (mobile
sugar), sugar related services, materials develpment, marketing

Thank you for reading thru all this... I hope I managed to explain
myself constructively.

[1] http://userlinux.com/white_paper.html

-- 
Sebastian Silva
Iniciativa FuenteLibre
http://blog.sebastiansilva.com/


More information about the IAEP mailing list