Re: OLPC/Marvell Press Release
Doubtless it would be painful... but... openjdk _is_ open source. Jython? On Fri, May 28, 2010 at 11:21 AM, rihowa...@gmail.com rihowa...@gmail.comwrote: You are correct. Android development is Java based. It is based on a subset of Java functionality with the android API built on top of that. If you want a QT based environment look at Meego http://meego.com/developers. On May 28, 2010, at 7:20 AM, Peter Robinson wrote: On Fri, May 28, 2010 at 1:10 PM, Walter Bender walter.ben...@gmail.com wrote: Putting some kittens at risk, it would be useful to have some analysis of both the work involved and potential benefits to an Android port, a Qt port, etc. I am not suggesting we divert our current efforts, as we are quite lean, but a better understanding of these options would be useful in defining our future roadmaps. Isn't Android application development Java based? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: journal is hard (was Re: notes from the field - Mongolia)
Elana Langer wrote from Mongolia: basically when teachers and students try to find their work (write, record, etoys) in the journal it is hard for them to locate it - especially if it is more than a few days old. This is why everyone is desperate to save their projects on USB keys. This could be made much easier if Sugar apps prompted the user for tags when shutting down an application. I know it is a goal to require as little text as possible. And I'm not sure what images could universally convey the message correctly... but basically: Would you like to tag the state of this activity? Y/N ...followed by a prompt for the user to enter tags. cheers, Garrett ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: journal is hard + sugar and the digital age
On Fri, Oct 10, 2008 at 1:53 AM, Albert Cahalan [EMAIL PROTECTED] wrote: Edward Cherlin writes: On Thu, Oct 9, 2008 at 7:15 AM, Carlos Nazareno object404 at gmail.com wrote: Could you please elaborate on the difficulties that people have when using the journal? I've experienced the same problem. Items tend to clutter up in the journal over time, it's like viewing your entire web browsing history. Its current implementation simply leads to information overload with the accumulating number of entries. How about the Gmail method, in which you archive messages when you are done with them, but you can tag messages, set filters, and search easily? tags: useless filters: useful only for automated deletion of incoming spam search: useful only for plain text An alternate positive opinion: tags++ I use them all the time. I like the idea of being able to apply multiple tags of varying granularity. And sometimes it is useful to file things away in more than one place. I.e. not just adding more specific qualifiers... And I'd like give a cscott++ to his proposal which would allow ordered sets. Because sometimes sets _are_ ordered. filters++ I often use filters to automatically apply tags. Not just as a kill file... archive++ I tend to tag what I want to remember, delete stuff I don't, and archive everything which I don't need to keep immediately on hand. Long vs short term memory To me, unarchived = short-term memory and archived = long-term. If is tagged, then I expect it will remain archived forever... It will be easy to search and find. If it is archived but not tagged, I'd be useful to me, if anything older than a month would be deleted. I.e. Stuff is there long enough that I can trawl though and find it if I really want to, but not so long as to create the proverbial needle in a haystack. cheers, Garrett P.S. Congrats on 8.2. Now if only I can find time to get off the bench on the sidelines... Fortunately, the vast majority of my email is text. The journal is expected to handle lots of non-text data. The email comparison is a good one. Just like an inbox, there is an unrelenting torrent of spam that must be dealt with. The main difference is non-text data, which makes the search and filters ideas unworkable. What you're lacking can be summed up like this: I put my data HERE, where I can expect to find it later. There is no HERE in the journal. Imagine storing 100% of your household goods in a giant concrete mixer that rotates whenever you look away. You'd never be able to find anything. Now imagine that your neighbors like to empty their trash into your concrete mixer. (spam problem) If you hadn't given up on finding your stuff already, you will now! It's easier to buy new stuff (start a fresh document) whenever you need it, and you might want to keep your most beloved possessions in your desk at work (copy them to a USB key). When the concrete mixer gets too full, you toss in a lit match (kids in Uruguay rf -rf the datastore) to keep the neighbors from complaining that they have no place to empty their trash. None of the recent suggestions, even if perfectly implemented, would fix these problems. That's not even considering the issue of compatibility with non-Sugar systems and user expectations. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Trac: release management
On Thu, Jun 5, 2008 at 6:57 PM, Martin Dengler [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 04:25:53PM -0400, Garrett Goebel wrote: ... I'll write you a query which will give all the non-closed tickets which have never been changed by the owner. Are you hoping to get OLPC management more justification for hiring more people from this metric? Or convince others that OLPC is overworked? I'm hoping to: o make the state of inactive tickets easier to see and distinguish between tickets which have had: - no human interaction - no owner interaction - no activity for over a given period of time o make trac more useful for release planning and scheduling It won't be perfect. Each problem to be solved is unique. Each programmer different. But if we use running aggregates based on the last n months of historic data, we can finesse those back of the envelope guesstimations until they're more than just guesses. At which point using time based estimations and FTEs will give the release manager the ability to do more than just guess at when X, Y, and Z can be delivered. Which is a nice position to be in, when you have to explain to upper management why new feature 'B' which they want to put at the head of the queue is going to push back the features already in the works. Especially when 'B' touches a lot of other code and is going to require a lot of FTE hours. And it is nice when you can turn around and point to historic data and which shows that tickets which have impacted more than 1 or 2 other subsystems and required over 40 hours to complete have historically resulted in an average of 1.5x the number of FTE hours in new defects. Whatever you want to call it, you might find it useful to track the scope and complexity of the changes required to fix an issue. Priority doesn't get at that. It would allow you to collect historic data which could be used to project how much time tickets will take to be implemented and how many bug hours you'll get per change. Do you know of any situations where this type of information is usefully collected? It sounds like trying to do a number of chained correlation exercises (complexity/scope estimate, complexity/scope actual, time to fix estimate, time to fix actual) that are based on partially subjective, known-hard-to-observe/predict data and expect to come up with something useful. More power to you if you succeed - you will be able to make millions consulting / selling your software to project management-focused groups. Have you ever done this analysis before? For the past 10+ years where I work. It has been one of my hats, to customize our issue tracking system and generate web based reports per my boss' needs. In that time we've grown from 4 to ~30 developers. We've gone back and forth between what makes for the lightest weight system which is useful for release and internal management of the development team, and how to mine the issue tracking system in order to help in discussions with upper management, so that explanations and opinions can be backed up with historic data. How many Full Time Equivalent hours does a given developer represent? A guesstimate: about 25 hrs/wk of coding and 30 hrs/wk of talking for social folks, maybe 30 hrs/wk of coding and 10 hrs/wk of talking for contractors; and 5-8 full days off a month (including weekends). Is there any list of developers and which slot each fit into? Why? What is the use of asking questions that are somewhat private (a co-worker's opinion as to who's social or not) and unactionable by you? These are actually rhetorical questions, so let me get to the point (below)... You are either joking or willfully missing the point due to what you probably view as previous provocations... The slots I was asking about were employee vs contractor. Because Michael Stone has estimated different FTE hours for each: 55 vs 40. What components are the given developers capable of working on? I don't understand this question. You've got folks who have particular areas of expertise. Or to put it the other way, developers who can work in certain areas but not others. If your Trac ticket classifies a ticket as belonging to a particular area, you can then project how many FTE's you've got on hand to work in that area. I realize that this being an open source project leaves a lot open ended. But if you collect the data in a way that you can get at it effectively, you can use historic data to verify your assumptions and track and make projections against non-employee/non-contractor developers as well. You could, if 1) it were feasible to collect; 2) its analysis was a tractable problem; and 3) it analysis had (significantly) greater benefit than cost. 1) is possible to collect in this case (who has worked on what) but not (I contend) in your other point (predicting future development speed/progress) You are expressing an opinion. Whereas I can share
Trac: release management
On Wed, Jun 4, 2008 at 3:55 PM, Michael Stone [EMAIL PROTECTED] wrote: If it pleases you, count the number and severity of bugs that have been untouched for longer than 3 months. Then ask yourself where #6454 compares fits in to the lists of 'can be addressed quickly' and 'needs to be addressed quickly'. It depends on what your definition of addressed means. Every ticket ought to be addressed as in responded to within a couple days or a week at the latest. #6454 has gone 4 months without any response or comment from the ticket's owner or anyone at OLPC/1cc. How many other tickets are out there like it? I'll take you up on your offer for a cloned copy of the Trac db. If the data is in there, I'll write you a query which will give all the non-closed tickets which have never been changed by the owner. On Wed, Jun 04, 2008 at 02:50:30PM -0400, Garrett Goebel wrote: Where is your list of priorities? http://wiki.laptop.org/go/Priorities-2008 How does that map to the list of open Trac tickets? It doesn't. See http://lists.laptop.org/pipermail/sugar/2008-May/006006.html http://lists.laptop.org/pipermail/sugar/2008-May/006007.html Nice general overview of priorities. There ought to be a way to generate it or something a bit more detailed from the Trac database. You'd probably need some way of designating a ticket as a meta priority, and then have it block on all the tickets required to meet that goal. Speaking of which stuffing multiple values into the 'Blocked By' column has a certain odor. There seems to be some overlap between the Trac fields for Milestone and Version. They seem to be being used for some combination of 'branch' and 'build'. Whereas where I think you are trying to go, would be to have a Release and Schedule. Where 'Release' would be one of 08.Autumn, 09.Spring, etc. and would signify that work was to be targeted as an update to the branch for that Release and all subsequent releases. and 'Schedule' would be the YY-MM you want it to land. Where do you track the severity/impact of a ticket? I.e. scope of who is effected Some people try to indicate this information with the 'priority' field on the ticket. In practice, I actually try to skim every change to Trac looking for important issues. Then we discuss them via status summary emails or meetings, like the one we're going to have in 10 minutes at 2:00 PM EST in #olpc-meeting on irc.freenode.org. Where do you track the difficulty? I.e., general estimate of time require to address a ticket We don't track it formally; only via discussion and status updates. Whatever you want to call it, you might find it useful to track the scope and complexity of the changes required to fix an issue. Priority doesn't get at that. It would allow you to collect historic data which could be used to project how much time tickets will take to be implemented and how many bug hours you'll get per change. I understand that the process needs to be as lightweight as possible so as not to get in the way of developers actually implementing things. But there's the balance to be had with actually being able to have historic data available to make possible an efficient use of those developers. How to you track defects back to the changes (ticket) which introduced them? We don't do so systematically. It is hard to do if you want to track back to a specific git changeset... or Trac ticket. But you could start to get a handle on it by adding 'Found In', 'Fixed In', and 'Tested In' relationships for tickets. How do you currently figure out when/where a defect was introduced and fixed? How many Full Time Equivalent hours does a given developer represent? A guesstimate: about 25 hrs/wk of coding and 30 hrs/wk of talking for social folks, maybe 30 hrs/wk of coding and 10 hrs/wk of talking for contractors; and 5-8 full days off a month (including weekends). Is there any list of developers and which slot each fit into? What components are the given developers capable of working on? I don't understand this question. You've got folks who have particular areas of expertise. Or to put it the other way, developers who can work in certain areas but not others. If your Trac ticket classifies a ticket as belonging to a particular area, you can then project how many FTE's you've got on hand to work in that area. I realize that this being an open source project leaves a lot open ended. But if you collect the data in a way that you can get at it effectively, you can use historic data to verify your assumptions and track and make projections against non-employee/non-contractor developers as well. How long does the assigned developer think the specific ticket will take to complete? How long did it take? The limiting factors seem to me to be: a) how long is the critical path of changes necessary to close the ticket? b) how overloaded is the required developers? c) how frequently are the required developers task-switching
Re: OLPC: Open Organized Transparent
What we've got here is a failure to communicate On Tue, May 27, 2008 at 7:38 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I'm sure I haven't said all the things you'd have liked me to say, but I've done my best to be open and honest here. Thank you for starting this discussion. Thank you for continuing it despite your priorities and time constraints. While much of what follows are direct responses to your email, please don't take it as directed personally. The original post was focused on what the OLPC could do to be more open, organized and transparent. I.e. to create a healthy community. As such the short comings I'm belaboring are with infrastructure, communication, and organization. Though in the end, it all comes down to individuals working together... or not. I'd much more interested in hearing a response to the issues I raised rather than potshots at the messenger... I hope you agree. Issues o how to address in the insider/outsider decisions made behind closed doors issue? o unbundling: hardware, os, drivers, and desktop metaphor o how to seed and grow the community o offer a reference solution embrace all solutions Well, since I'm apparently the one fingered as smart, holier than thou, and derisive, let me publicly apologize for being short-tempered at times. I do get frustrated when I see the same issues pop up over and over again: remember there are many many more of you out there than there are here at 1cc, and in order to be successful we at OLPC *must* allocate our time wisely. Sometimes that means I'm rather short and/or terse. I didn't intend to single you out. Your comments happened to be the easiest to find from an @laptop.org address. In catching up this morning, I noted at least 2 threads where someone was either calling for more professional behavior or a code of conduct. That said, you _are_ an OLPC employee. When I or someone outside the project is unprofessional... we're just lone volunteer assholes. Not to lecture... well yes, I am lecturing. But when you are short/terse it reflects badly on the project and the community atmosphere. Issues popping up again and again are a sign that issues, decisions, and their rational aren't documented well enough. Wiser time management would be to: o respond with a url to documentation (or write it then respond with a url) o ask if there is anything in the referenced documentation that needs to be clarified o ask where the person raising the question looked for their answers o update where the questioner looked first to reference the documentation You aren't bad on #1, but the others... A related issue is when people loudly insist that OLPC solve their personal problem *right now*. Again, we have tens of thousands of machines in the field now, and thousands more every day. You personally may care about, say, Java in your browser, but it is not a priority for OLPC, by which I mean the 3 people I sit next to. No, tell me how you really feel... Which is the OLPC you care about? You and the 3 people sitting next to you? Or the tens of thousands of machines in the field? Where do the children fit in? How about the 8 XO's I purchased. Do you care about them? Or the children who can't use them to run their web-based self-paced mathematics instruction? It reminds me about the parable of the tens of thousands of starfish washed up on the shore. One man stoops, picks one up and throws it in the water. The man next to him says, There are too many. It won't make a difference. The first replies, It made a difference to that one. Don't try to imply that #6454 is a personal problem or that I'm the only one out banging my head up against it. I didn't open it, though I did report my findings in it. FYI #6454 was opened 4 months ago, last updated by me 3 months ago, and never assigned or commented upon by a OLPC or 1cc employee. So please drop the dramatic characterization by implying that I was demanding it be fixed *right now*. Did you bother to read #6454? You certainly didn't update it. Good thing I've spent the last hour trawling through OLPC developer list emails to find out that I am not a priority. It is not part of the software included in our large scale deployments. Ah, but the OLPC has told the public java can be added on after the fact. And what you've told people isn't entirely true. Furthermore, it isn't clear that it ever was true. Your documentation on how to do it is wrong. And the trac ticket is being ignored. I'd like to make it true. By all means work on the problem, and we will certainly help you publicize the solution you come up with as much as we are able, but there are not resources to devote to every feature request. We have to prioritize. Ok. Where is your list of priorities? How does that map to the list of open Trac tickets? Are the milestones dates or features? Will it be the same next week? What is the order of milestones? Where do you track the severity/impact of a
Trac: reports and queries and schema... oh my!
On Wed, Jun 4, 2008 at 3:03 PM, Noah Kantrowitz [EMAIL PROTECTED] wrote: How do I create a report? http://dev.laptop.org/wiki/TracReports tells you about reports, but not how to create one... Unfortunately we cannot allow non-admins to create reports because they are unrestricted queries against the Trac database. Ok. I understand the security and performance concerns there. If I wanted to create a report, who should I contact? One of the Trac admins? Who are the Trac admins? Where is an up-to-date list of Trac admins kept? Is the underlying schema for the Trac database documented anywhere? And the modifications from the vanilla install? How do I view the query underlying a report? Look at the Other formats links at the bottom of the page. Thanks! Now I can have some hope of figuring out why the resultset isn't what I expected. How is it that #6454 is assigned, but doesn't show up under the owner's active tickets report? Which report do you mean? That ticket is open, but not in the accepted state. Some people like to use the open vs. accepted states to show what they are actively working on right now, others just ignore it and go right from open - closed. http://dev.laptop.org/report/4 http://dev.laptop.org/report/5 Where is this open but not accepted state designated? Status? Accepted isn't an option for filtering the Status column. Status doesn't appear to be displayed on the ticket details page. How do I tell if the state is open or accepted? The query for report 4 is: SELECT p.value AS __color__, owner AS __group__, id AS ticket, summary, component, milestone, t.type AS type, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter FROM ticket t, enum p WHERE status = 'assigned' AND p.name=t.priority AND p.type='priority' ORDER BY owner, p.value, t.type, time So I'm guessing the key here is status = 'assigned'. Will anyone volunteer to mentor me (hold my hand) on this? Should I contact the ticket's owner directly? How do you figure out the email address by owner name? For privacy reasons, you cannot get a users email address from their Trac username. If someone wants to create a table on the wiki somewhere mapping names to people, those that wish to be known can add themselves. If you leave a comment on a ticket, it will be emailed to the owner though. So what recourse do I have when I enter a ticket and nothing happens for 3-4 months? Who do we bump and how do be bump them to find out what is up with an apparently abandoned ticket? cheers, Garrett ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Trac: reports and queries and schema... oh my!
On Wed, Jun 4, 2008 at 3:03 PM, Noah Kantrowitz [EMAIL PROTECTED] wrote: How do I create a report? http://dev.laptop.org/wiki/TracReports tells you about reports, but not how to create one... Unfortunately we cannot allow non-admins to create reports because they are unrestricted queries against the Trac database. Ok. I understand the security and performance concerns there. If I wanted to create a report, who should I contact? One of the Trac admins? Who are the Trac admins? Where is an up-to-date list of Trac admins kept? Is the underlying schema for the Trac database documented anywhere? And the modifications from the vanilla install? How do I view the query underlying a report? Look at the Other formats links at the bottom of the page. Thanks! Now I can have some hope of figuring out why the resultset isn't what I expected. How is it that #6454 is assigned, but doesn't show up under the owner's active tickets report? Which report do you mean? That ticket is open, but not in the accepted state. Some people like to use the open vs. accepted states to show what they are actively working on right now, others just ignore it and go right from open - closed. http://dev.laptop.org/report/4 http://dev.laptop.org/report/5 Where is this open but not accepted state designated? Status? Accepted isn't an option for filtering the Status column. Status doesn't appear to be displayed on the ticket details page. How do I tell if the state is open or accepted? The query for report 4 is: SELECT p.value AS __color__, owner AS __group__, id AS ticket, summary, component, milestone, t.type AS type, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter FROM ticket t, enum p WHERE status = 'assigned' AND p.name=t.priority AND p.type='priority' ORDER BY owner, p.value, t.type, time So I'm guessing the key here is status = 'assigned'. Will anyone volunteer to mentor me (hold my hand) on this? Should I contact the ticket's owner directly? How do you figure out the email address by owner name? For privacy reasons, you cannot get a users email address from their Trac username. If someone wants to create a table on the wiki somewhere mapping names to people, those that wish to be known can add themselves. If you leave a comment on a ticket, it will be emailed to the owner though. So what recourse do I have when I enter a ticket and nothing happens for 3-4 months? Who do we bump and how do we bump them to find out what is up with an apparently abandoned ticket? cheers, Garrett ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC: Open Organized Transparent
I'm not the best person with words. But here goes anyway... Yes, the OLPC project is an open source project, but in practice the project itself suffers from being closed, disorganized, and opaque in its operations. We (if you're reading this, I mean you) need to put aside all this personal One True Way axe grinding, do a little individual introspection, and try to focus on the common factors which bring people together in this endeavor. We're all here with different personalities, ideals, expertise, and axes to grind. The one thing we all have in common is a desire to provide educational opportunity to children. OLPC is an Education Project. There is enough room at the table for each of us to bring a different set if ideals and ideas on the means of achieving it. The current problem, appears to be that the project isn't effectively organized and it isn't optimized to embrace the varying perspectives and develop a large community of open source developers. Many decisions are made behind closed doors. And decisions once made aren't very well communicated. It isn't just that the outside developer community doesn't feel like anyone is listening. There is a real sense that upper management is out of touch with its own employees. The Cambridge Lab staff ought to do a little self-examination. Because they would never guess how much to us outsiders they resemble their upper management. I can't tell you how often these smart mostly male MIT types turn a deaf ear or return a derisive holier than thou email to the outsiders and developer community they will ultimately be dependent upon growing in order to succeed. None of this is remotely surprising in a startup. And frankly, it wouldn't be all that surprising to encounter in a software development department of any organization. But it is suicide for an Open Source project. On Thu, May 15, 2008 at 8:57 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think the way to protect Sugar and to take a step further in the whole project is giving one step back: Sugar must be able to run on any Linux distro. I know that it is hard... but IF we are able to take this step back then Sugar (and many other things) will be in better competitive position. I think the project needs to take another step back. The education project is both a hardware and a software project. The best way to insure the success of the project is to divide the project into its constituent sub-projects and let each sink or swim based on their relative merit and the resources they can attract to achieve their goals. The OLPC needs to reorganize to embrace the There Is More Than One Way To Do It philosophical perspective which will allow us to collectively take advantage of the synergies which exists where our ideas intersect. Getting Sugar running on any Linux distribution isn't enough. 1) Unbundle the hardware and the software projects. We should allow the educational organizations footing the bill to define their own requirements. Whether that means an XO running something other than Sugar, Sugar running on something other than an XO, or even Sugar running on something other than Linux. Perfect is the enemy of good enough. Let us be willing to accept getting any combination of XO, Linux, and Sugar into the hands of children as an improvement over the status quo. 2) Seed the developer community The OLPC ought to give XO's away to the lead developers of every open source project on which the reference platform has an underlying dependency. And XO's should be made _easily_ available at cost to developers from other open source projects and developers of proprietary software, operating systems, and hardware devices. I think the OLPC's decision to sell XO's only in large quantities and only top down to educational institutions is wrong. I know the stated reason of discouraging theft from children. And the unstated reason of avoiding the additional cost of providing customer service and support. Both are short sighted and wrong. The economies of scale that could be achieved increasing sales might actually make the realization of a $100 laptop possible. Include the cost of customer support in the sale of individual XO's. Let it pay for the customer service infrastructure for servicing organizations in developing countries as well. The XO is designed for children. Most adults wouldn't use one if you gave it to them. The firmware with security enabled should provide a cost effective deterrent to theft. 3) There Is More Than One Way To Do It The Cambridge Labs should continue to coordinate the development, testing, and release of reference platforms which provide a stable base and showcase the various hardware and software innovations. The One True Way currently appears to be XO, Fedora Linux, Sugar, and Python. The one true way should change to a tried, tested, and supported reference platform. However, the driving mindset should be cross platform compatibility at all levels. This
Re: OLPC: Open Organized Transparent
On Fri, May 16, 2008 at 5:25 PM, Denver Gingerich [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 2:46 PM, Garrett Goebel [EMAIL PROTECTED] wrote: [...] The Cambridge Lab staff ought to do a little self-examination. Because they would never guess how much to us outsiders they resemble their upper management. I can't tell you how often these smart mostly male MIT types turn a deaf ear or return a derisive holier than thou email to the outsiders and developer community they will ultimately be dependent upon growing in order to succeed. From my experience, the people in the Cambridge Lab are more than happy to help us outsiders and discuss their plans openly. The devel, sugar, and many other mailing lists are open to everyone. They seem open to giving people accounts on their systems when it will help move the project forward. I personally don't see any resemblance to the upper management. It is more than a bit like the arguments people get into about how to fix the public schools system. The people in the front lines like teachers and the developers working on OLPC are with very few exceptions good people doing good things... with not nearly enough support or thanks. And it is very easy to offend these individuals when what you are trying to do is figure out why the system in which these individuals are working appears to be failing. Most of my original post related to organization and management. However, you're right that this comment was pointedly directed at the OLPC developers. I've never seen one of these holier than thou e-mails you mention. It certainly doesn't seem to be like any of the staff I've communicated with to do such a thing. Going back through the archives, I have to admit that as often as not the smack talk came from someone without a laptop.org email address. But here are some examples of offensive, dismissive, and unanswered emails: http://lists.laptop.org/pipermail/devel/2008-May/013770.html You're on crack, Bert [...] Didn't we go over this already? http://lists.laptop.org/pipermail/devel/2008-May/013745.html Dammit, why are we having the discussion again! [...] But feel free to disregard the problem, if it makes you feel better. http://lists.laptop.org/pipermail/devel/2008-April/013015.html Finding a 'sales' team is not the immediate problem to selling in the US. What is, then? [unanswered] http://dev.laptop.org/ticket/6465 Ticket opened 3 months ago... no developer comments I think any lack of communication on the mailing lists can be largely attributed to how busy the staff are. Not only are they working their tails off to move the project forward (ie. by writing software), but they are also participating in discussions about the state of OLPC and answering questions about things they can't control. I'm sure you're probably right. Understaffed. Underfunded. Lacking direct clear communication from management. Unreasonable expectations, shifting requirements, and schedules. ...Not altogether different than the fate of most developers in most organizations. Most developers however, aren't being asked to achieve such lofty goals. The XO is an amazing bit of hardware. The folks working in the Cambridge Labs and elsewhere are an amazing collection of folks and have done and are are doing excellent work. The first 80% of the functionality is implemented. But as they say, the last 20% takes 80% of the time. It makes a great prototype. But is it really ready for mass deployment? Can it be supported in the field? The XO and Sugar are innovative, but it isn't clear that its innovations will give it enough of a leg up against the competition in the commodity laptop market. Competition that has woken up, and can use its influence and muscle to reopen done deals. And it may be a perception born of short staffing, but the documentation on the wiki is scattered, incomplete or out of date. Tickets go unanswered. Short of subscribing to the developers list, there's no way to tell what builds and build streams are out there. Unless you somehow know to go look at Bert's wonderful build stream logs (http://dev.laptop.org/~bert/olpc3-pkgs.html). Useful web pages sit under developers personal directories... which seem to come, go, or be abandoned at a whim. For example Bert's build logs no longer work for joyride and faster. For people working on the project full time, it probably isn't too difficult to stay in the zone. The barrier to entry for weekend warriors and volunteers needs to be low enough that we don't have to understand how everything fits together to mess around in the corner we're interested in. Or have to read a mailing list daily to keep up with significant changes in expected behavior. Like having your activities after performing an olpc-update to update1 build 703. The OLPC developers may be amazing and brilliant, but apparently there aren't enough of them to go round. I'm convinced that the only possible path to sustained success
