On Wed, Jul 29, 2009 at 12:40 AM, Michael Stone<[email protected]> 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!) > [email protected] > http://lists.sugarlabs.org/listinfo/iaep > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
