On Tue, Oct 19, 2010 at 11:50 AM, Tomeu Vizoso <to...@sugarlabs.org> wrote: > Hi, > > for personal reasons have to drastically reduce my involvement in the project. > > Will be leaving maintenance of my modules and unsubscribing from the > mailing lists. My place on the board is vacant from now on and I'll be > adding to the wiki the new vacancies: > http://wiki.sugarlabs.org/go/Vacancies > > Cheers and good luck, > > Tomeu
Sugar Labs lost its lead developer. It is unfortunate that no-one has done a public review of the reasons and implications of Tomeu quiting. Tomeu's leaving is significant enough that Sugar Labs should take a hard look at what is working, what is not working, and how to fix the pieces that are not working. At the risk of angering pretty much everybody.... Sugar Labs has three fundamental problems. Sugar Labs is optimistic to the point of untruthfulness. Sugar Labs is lead by veto rather than vision. There is a lack of accountability to stakeholders. Sugar Labs is optimistic to the point of untruthfulness. The main _symptom_ of this is the current state of Sugar Labs. Sugar is not perfect. Sugar Labs is not perfect. The _disease_ is an adherence to faulty premises rather then the use of the Scientific Method of: Ask a question. Do background research. Construct a hypothesis. Test your hypothesis by doing an experiment. Analyze your data and draw a conclusion. Communicate your results. Premise 1. Sugar is open source, written in python, and the source is easily available. Therefore kids will develop and improve Sugar. What fraction of useful and usable improvements have been committed into sugar by the target users. The key metric is commit ratio. Everyone has an antidote about some budding hacker. As with the patch acceptance process, developing Sugar requires more than solving logic problems. In theory this premise is sound, and desirable, the overall technical capabilities of a nation will improve as more people are exposed to Sugar at an early age. The question become what is the time lag between exposure to Sugar and useful contribution to Sugar? Premise 2. Sugar is open source, written in python, and the source is easily available. Therefore deployments will develop Sugar. What fraction of useful and usable improvements have been committed into sugar by deployments. In theory this premise is sound, and desirable, Sugar deployments and their associated support infrastructure provide a catalyst for building local technical capability. The question becomes, considering the limited resources of deployments, is the benefit of contributing upstream worth the cost? Premise 3. Any problems with Sugar are because the user, teacher, or deployment is not smart or motivated enough. What are the usability concerns of users, teachers, and deployments? How are those concerns being addressed? In theory this is true yet undesirable. A significantly motived person _can_ figure out just about anything. The primary decision making factor for users, teachers, and deployments is marginal benefit. Does using and learning to use the laptop/Sugar prove a marginal benefit over other learning opertunities. Sugar Labs is lead by veto rather than vision. A _symptom_ is the development process. It it easy to have fix commited to Fedora or OLPC. It is hard to have a fix commited to Sugar Labs. When someone sends a useful fix to either OLPC or Fedora, a senior developer takes the patch, review it, fixes it up (if necessary) and thanks the contributor. This provides an incentive and on-ramp for less experienced developers to participate and contribute. Sugar Labs rejects most patches. Once a patch is technically correct, which can take several iterations for a new developer, it is forward to another developer for their vote of approval. The end result is that very few people bother to submitted patches upstream. The _disease_ is a marginalization of anyone who dissents. As a result no one is willing to take a risk. There is an unwritten checklist for participation. 1) Are you a knowledgeable, experienced, and patient open source developer? 2) Is your goal open source advocacy? 3) Are you a strict constructionist? 4).... This results in very low participation in Sugar Labs. There is the lack of accountability to stakeholders. The Board of Directors of an non-profit organization the board reports to stakeholders, particularly the local communities which the nonprofit serves. The Executive Director is responible for carrying out the strategic plans and policies as established by the board of directors. As a starting point for bringing Sugar Labs out its current crisis, I suggest the following plan: 1. Each Oversight board member, or candidate, identify a stakeholder and spend the next 12 months advocating for that stakeholder. Advocating includes: Identify the specif needs and goals of the stakeholder. Identify the resources that stakeholder can contribute to Sugar Labs. Identify how Sugar or Sugar Labs can better meet those needs and goals. Identify how that stakeholder's resources can be more effectively used to improve Sugar and Sugar Labs. Propose and implement solutions for how Sugar Labs can better meet that stakeholder's needs. 2. The Executive Director should modify Sugar Digest to include a 'Meeting Stakeholder Needs' section which describes what tangible steps Sugar Labs has done to meet the needs, as identified by each board member, of various stakeholders. Anyone not willing to take the above responsibilities should reconsider their motivations being a leader at Sugar Labs. david _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep