[Sugar-devel] [IAEP] A Fine Tradition...

[David Farning]

On Wed, Jul 29, 2009 at 12:40 AM, Michael Stone<michael at laptop.org> wrote:
> Carrying on a fine tradition of July-based Sugar reflections [1, 2], I'm going
> to offer some mostly unsolicited advice. (Sorry, Tomeu, but you asked me to
> write. :^)
>
>   Dear Sugar Labs,
>
>   In the past year, you succeeded in removing two important barriers to entry
>   for new developers: you have created a distinctive brand and you freed Sugar
>   from the XO.
>
>   What's next? Here's a four-part RFC:
>
>   1. Could we embrace POSIX and the RESTful Web throughout our software [3]?
>
>     POSIX and HTTP are the mother tongues of our ecosystem and developer base.
>     By embracing them, we make our software much cheaper to explore and to
>     modify.
>
>   2. Could we live more within our packaging?
>
>     This way, our packaging gets tested more quickly, we become more
>     expert /at/ packaging, we make friends in our distros, we get better
>     packaging, and our releases become easier!
>
>   3. Could we make ourselves more interesting to be around, for example by
>   saying "maybe we could..." or "I have... (and you can too...!)" more
>   frequently than we say "I can't."?
>
>     Our strengths lie in our big, sexy, /powerful/ ideas. We can't shrink from
>     these ideas; they sparked our desire to contribute and they will do so for
>     others. (Otherwise, we will fade.)

I would temper that to, sugar Lab's strength is its ability to
implement those big ideas, and grow the community of implementers in
such a way that they are useful as learning tools.

Big ideas are great!  But every bar and coffee shop within 5 miles of
a graduate school is full of people talking about big ideas.  In order
to succeed Sugar Labs _must_ create a culture which elevates
contributors who 'implement' big ideas over those who talk about big
ideas.

Saying "can't" is an unfortunate reality of any situation with
unlimited wants and limited resources.  The single biggest indicator
of failure in non-profit, also called public benefit, organizations is
the _inability_ to say no.  I'll say more about 'can't' at the end of
the comment on mentoring.

>   4. We could do more to help one another to develop as may be necessary to
>   advance those big, sexy ideas.
>
>     (Anecdote: I don't think any of us here today started off understanding
>     much about communities, UI design, networking, release management, quality
>     assurance, or large-scale coding; I just see lots of people who looked for
>     people who were smarter and more knowledgable than they were and who worked
>     really hard to catch up. We should do more of that.)

If you look at the characteristics of successful open source projects
development of internal leadership is probably the best leading
indicator of success!

One of the _most_ effective way of developing leaders is through
mentoring.  I feel incredible grateful that people like Greg
Dekoenigsberg, Knut Yrvin, and Mike Milinkovich have taken the time
out of their busy lives to answer my questions.

John Poelstra, the 'feature wrangler' at Fedora has recently offered
to mentor Tomeu and Simon on 'staying sane while being bombarded with
an insane amount of demands on their time.'

Bernie has recently started working as a sysadmin for the FSF.  I
expect to see many of the infrastructure related best practices at the
FSF trickling into Sugar Labs.

The development has grown into the strongest team at Sugar Labs.  This
has not happened because the other stuff is less important.  Rather it
has happened because the platform is the base on which everything else
is built.  The development team is now in a position to serve as a
model for other teams.

This leads to the GPA deployment.  We have a disproportionate number
of very experienced people working on that deployment.  This has not
happened because other deployments are less important.  It is because
I believe that the long term growth of Sugar Labs can be best served
by focusing very heavily on a single deployment which can develop a
series of best practices and processes which we can then scale to
other deployment.  Much of this optimism is base on project staffing

-Caroline.  Caroline has a proven track record of participating in the
community.  She is very implementation focused.  Her MO is to; take
her mission, make a list of things which block her vision from
becoming a reality, work through that list one item at a time.
Working through that list means putting in long hours directly working
the items on the list and identifying and engaging other to share her
vision and work thorough those lists.

-Walter.  Walter is the most visible member and the 'soul' of Sugar
Labs.  Last year he spent a large part of his time on turtle art.
This created a very clear message and culture that working on the 'nut
and bolt issues' is an important task at Sugar Labs.  Walter is a man
who has a lot of options in life:) and he picked hacking on Turtle Art
as the best use of his time.  Now, he is spending a good chunk of his
life working on the GPA deployment. This has several benifits:
1. It raises the visibility and value of deployments in the Sugar Labs
ecosystem.  It is pretty easy to ignore bug reports or feature request
from lesser know people by saying 'they are doing something wrong' or
'they just don't understand.'
2. It raises the importance of working on deployments over talking
about deployments.

-Greg. Greg is very good at bridging that 'gap' between deployments
and developers.  He is so good that there was a session at SugarCamp
Paris about how to clone him:)

If we keep our eye creating and communicating best practices and
processes at GPA, we can make some tremendous progress reducing the
barriers to entry for future deployments.

But, I caution against moving to fast towards engaging deployments.
Successfully engaging deployment requires a chain of events:
1.  Feedback reporters.
2.  Feedback translator/triagers -  the feedback must be converted
into something useful to developers.
3.  Feedback implementors - developers must fix the bugs or add the
requested features.
4.  Review - fixes and features must follow back through the release
process into the next release.

Each of these steps requires someone to do the work necessary to turn
'a feedback' into a useful part of the platform. Growing the feedback
process requires growing the entire chain not just the first part of
the chain.

I think of it like a chef spinning a pizza crust into the air.  If you
keep the crust growing in a balanced circle it expands like magic.
Once you lose the equilibrium of a balanced circle, the crust tears or
forms bulges.  The only way to fix the tears of bulges is to roll the
dough back into a ball and start over.  Every time you re-roll the
dough, you must add more flour to keep the dough from getting sticky.
But, adding flour makes the crust tougher.  Ironically, if you need to
stop and re-roll a community many times, the members start to get
frustrated and cynical.

This brings us back to can't.  When _I_ say Sugar Labs can't or
shouldn't do something, I generally mean Sugar Labs can't or shouldn't
do it 'yet'.  I used the word can't instead of yet because yet has no
meaning in a project that has not established a track record of
delivering results.

>   xoxoxo,
>
>   Michael
>
>   P.S. - In the spirit of walking the walk, I'll also share one of my own
>   recent puny efforts in the direction outlined above:
>
>     http://wiki.laptop.org/go/Network2

In the spirit of walking the walk, I would like to present and discuss
a concrete model for thinking about growing Sugar towards the student
over time.  As very rough draft of the plan....

***********************************
One way to think about how to accomplish Sugar Labs  mission is to
break the problem down into identifying and meeting a hierarchy  of
needs.

Student's learning needs.
Curriculum writer's needs.
Teacher's needs.
Deployer's needs.
Distribution's needs.
Developer's needs.

I stole the idea from Maslow[1].  His basic premise was that human
development depended on a meeting a hierarchy of needs.

Self-Actualization
Esteem
Social needs
Safety needs
Physiological needs

He proposes that, in general, deficiency needs must be met first. Once
these are met, seeking to satisfy growth needs drives personal growth.
The higher needs in this hierarchy only come into focus when the lower
needs in the pyramid are met.

While similarly fuzzy, we can look at getting Sugar to the point of
mass deployment as meeting hierarchy of needs.  The idea is that:
1.  Developers were not interested in working on Sugar until we
created a desirable work environment. We are making good progress on
this need.
2.  Distributions were not interested in working on Sugar the
Developers had stabilized the platform.  In progress.  It looks like
SoaS is going to be a game changer
3.  Deployments won't be interested in installing and supporting Sugar
until the Distros ship a stable product.  This is where we are now.
GPA is acting as the tip of the spear.  But it takes Caroline, Walter,
Greg, et. al. to hold up the spear.

Activity developers seem to be making weekly or even daily release to
fix Activity bugs.  It looks like the SoaS team is planning on making
a series of bug fix point release to fix SoaS and Fedora related
issues.  The flow of feedback and fixes is starting to make its way
into the core for inclusion in .86.

4.  It will be difficult to engage teachers until it is trivial for
them or their IT department to deploy sugar.

5.....

The fuzziness comes in the form of early adopters of highly competent
and highly motivated early adopters and growing the lower levels of
the community to support each additional level.

Expanding focus does _not_ ignoring met needs. Earlier, I was using
the term 'shifting focus'.  Caroline pointed out, 'expanding focus'
better clarifies the approach.   In fact as we get closer to meeting
the final goal of student learning, our resources for met needs will
double every six months to a year.

While slow, this approach can be highly effective at breaking the
overall problem into more bite sized bits.

The challenge is that often a layer's needs conflict with the previous
layers. ie Developers like short development cycles; 6 months is
common.  Deployers like long release and support cycles; three years
is common in education.  By approaching one layer at a time we can
significantly reduce the complexity of the problem. Otherwise we get a
giant hairball:(

This meshes nicely with the implement, release, and improve mindset of
open source in general.  If we screw something up--which we will, we
just go back and fix it.

It provides a useful framework for keeping the message consistent
while adopting to the expanding nature of SL.

david

1.  http://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs .


> Regards,
>
> Michael
>
> [1]: http://lists.laptop.org/pipermail/sugar/2008-July/007304.html
> [2]: http://lists.laptop.org/pipermail/sugar/2008-July/007390.html
> [3]: (With suitable hacks under the covers of FUSE and DNS.)
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>