Posts that are olpc-ish

NECC[-1] = Saturday

The open-source-and-education fun at NECC started even before I hit the conference. On the shuttle from the airport, sickness I sat in front of a bone marrow transplant delivery man and next to Randall Samstag, an environmental engineer from Seattle who (as it turns out) had some questions about We quickly got into a discussion about sanitation systems, designing waste processing plants for the developing world, and the difficulties of breaking into the field of appropriate technology and the difficulties of changing a large-scale entrenched system when customers want to throw money at the problem and be done with it rather than taking the time to get involved with the design needs of the community they’re serving. This sounded pretty familiar.

A lot of sanitation projects are large-scale government-backed operations, and getting the technology in place was harder than inventing it – he told the story of his friend, the inventor of a 3-chamber sequential flow gravity-fed wastewater treatment system designed for Venezuela that was a huge improvement over the prior “dump ‘er in the lagoon and the bacteria will break it down” method (which works, but you need a lot of lagoon space for a lot of people; this system was much smaller). It worked like a charm. Then the Cubans came. They wanted sanitation everywhere (a noble goal) but didn’t understand this newfangled 3-chamber system – they knew lagoons. So the new tech sat unused and the lagoons got dumped in and the harmful effluents in the water supply increased by an order of magnitude… and there was no way to share the information, the design, the knowledge of how to use it, so there wasn’t much anyone could do about it.

I brought up the idea of open design repositories such as Appropedia (where Chris Watkins has been doing work on sanitation), and how they serve as knowledge bases and watering holes for projects like IDDS as well as ways for potential future sanitation engineers to get involved without the high entry barrier (“must have experience to get experience”) that makes it tough for folks like Liz and Chris to break into the field. Randal was intrigued.

What does this have to do with open source and education? (more below the fold, for the sanity of Planet aggregator readers…)

Continue reading NECC[-1] = Saturday

I’m going to NECC!

I was originally going to wait for all my travel plans to finalize, this but there’s no reason why I shouldn’t holler out right now that I’ll be at  NECC this year. If you are also coming, let me know!

NECC is the National Educational Computing Conference, and it is – from what I’ve heard – the stuff of legend and the place to be for people interested in teaching and technology. I say this based on two things: (1) 100% of the people I know who’ve been to NECC have emailed/called/found me immediately afterwards and bellowed “YOU HAVE TO GO TO NECC!” and (2) when asked to describe what NECC was like, their first reponse is to drop their jaw into a massive grin and flail their arms around in wordless happiness before they’re able to start describing it in English.

So when I found out I was going down to DC, I quietly and calmly finished up some time-sensitive morning tasks and then RAN AROUND THE OFFICE BUILDING IN EXCITEMENT! Until it started to rain – at which point I went inside and sped another half-mile on a treadmill before I had expended enough adrenaline to sit down and be productive again. (Otherwise all my coworkers would be wondering why someone was whooping and hollering through the hallways.)

Needless to say, I’m looking forward to this. I’m looking through the program and starting to loosely map out my time there. It’s a given that I’ll want to check out “open source in education” stuff, but I also want to examine the basis of my kool-aid drinking on it, since to most of the world, this is not obvious. In fact, I’ve heard brilliant people whom I admire and respect tell me that open source and education is a terrible idea. They have good reasons. I don’t know what those reasons are yet.

I want to understand where that comes from – not to argue or fight back against it, but because there’s certainly a lot that we can learn from it and use to make our own work better. The realities and presures of working in a classroom, in a lab with creaky old equipment, with a massive district to oversee, within the government, with an overloaded IT staff, with tests and rules and regulations, with a host of kids with challenging needs, with things I can’t even imagine… and the solutions and mistakes and triumphs and opportunities that other people are already finding – what is this world? I have a lot to listen to and learn.

I’ll post more plans here when I have them, but in the meantime… who should I meet? What should I go to? Are there questions I should ask, topics I should seek out, things I should watch for? General conference-attending tips I should heed?

I plan on documenting everything I can, primarily through abusing my typing speed for live transcriptions (if you’d like me to transcribe your talk, or any particular talk, please let me know) and collecting short one-question interviews, for which I need a good question to ask. Maybe “What is your biggest learning goal for the upcoming school year, and what would help you get there?” – but that’s awkwardly phrased. Any ideas for a better one?

Radical transparency: guys, it doesn’t work retroactively.

In the middle of the discussion on opening up a discussion on the Philippines, surgeon I got a bit impatient with all the conversations about “the core team” (which I’d been invited to, whereupon I immediately asked “what does that mean?”).

Here’s the crux of it: are we the core team, period – or are we the core team so far? (If it’s the former, then I’d consider myself to not be on the “core team” yet, since I don’t understand the expectations that entails.) Arbitrarily delineating “insiders” and “outsiders” with no criteria as to how you progress from one to the other eventually becomes an artificial cap on community growth.

I then proceeded to state that, to put my money where my mouth was, I would forward all the conversations to the public mailing list if there were no objections within 4 days. Boy, did discussions ensue. Then, in a bit under two hours, we went from this:

While I think it’s a great idea to have an open meeting… I believe it is important for us (core members) to hold a closed meeting first…

To this:

Community growth and ownership has an inseparable link. It took this email thread, a quick chat… and kim chi, to see that our success really lies in our community. So lets go for this open meeting!

So today I kept my promise and forwarded all those conversations to the list, with context. (Yeah, it took a while; I think I’ve learned to do it faster for next time.) It was interesting, trying to strike the right balance between presenting a summary of existing ideas (which I’d only heard myself a few days prior) and leaving things open for suggestions, as well as how to tactfully nudge people in the start doing things! ask forgiveness, not permission! direction.

A number of us interested in open-source educational technology in the Philippines have decided to get together online to share the respective projects we’re working on and the roles we’re starting to find ourselves playing in the hopes that we’ll be able to find a better way to move forward together… So far, the discussion leading up to this meeting has been on private email, and the meeting was also supposed to be private. After some conversations, we realized that this was counterproductive to community-building, and that we should open both the meeting and the planning for it to anybody who is interested.

This was done with the understanding that since we’re all individual volunteers, people are free to do what they want to do – this means that you can work on what you’re interested in without having to ask permission, but you also shouldn’t expect your suggestions to be followed unless you pick up the work and do it yourself. This email thread is, in part, me following my own suggestion to open up the meeting…

This was one of the most awkward emails I’ve sent in a while. And the context-filling-in emails are still incomplete and choppy, because even with cleanup, threaded forwards are just messy. It remains to be seen whether this made any difference.

On the up side, I get to point to this thread and say “See? If we’d had this conversation on a public mailing list from the beginning, how much easier would life be right now?” And I think it was The Right Thing To Do. Because we fixed it now, we don’t have to go back and fix it later (for an even later value of later) when it would be even harder.

Cultural adjustments are the hardest kind to make – I’ve been incredibly impressed with how willing everyone involved was to discuss and try out new (and potentially unfamiliar) ideas. I mean, the culture in the Philippines is not generally… open-source-ish. But hey! We’re learning and adjusting – in both directions. Having grown up as a Chinese-Filipino in the US, I’m coming to understand, at a more-than-intellectual level, that getting open source into the Philippines means that the culture has to be an open-source one… but it also has to be a Filipino one.

I’m not yet sure how you get there. We’re all flying by feel. But I think we’ve gotten the radical transparency lesson down, at the very least. (And a shout-out to Planet Fedora – reading other people’s posts there over the last few weeks has given me a way better idea of how to explain this sort of thing to others. Thanks!)

Responses to objections on transparency

Since I learn by documenting, physiotherapist I’m starting to chronicle the things I’m learning about doing open-source community work here.

Over the past week (or two years, depending on how you count it), I’ve been talking with a group of people – many of them who I’ve known for some time – interested in bringing open-source educational technology to the Philippines. The OLPC and Sugar projects serve as convenient starting places for this. They know it’s going to be a volunteer effort. So far so good.

And then I was told that our next step was to hold a private meeting to discuss high-level strategies amongst ourselves. (Virtual nods all around.) Wait, stop. Hold on, I told them. Why?

The resulting discussion was fascinating; I’d forgotten how much I’d taken radical transparency for granted, and their questions made me stop and explain to them – and myself – why it was the way to go. Some of our more interesting discussion points are below – I’m curious what people think of the questions and my responses. (Would you have phrased things differently?)

[We can't have this discussion on the mailing list because] there are still people on the mailing list that have different ideas on where the organization is.

That’s really good to keep transparency on, actually. You get multiple points of view, and clarity on which ones you aren’t working with so you can go your separate ways and not wait on each other.

One of the reasons that the meeting wasn’t highly publicized is that it could grow too big.

Why is this a problem? Size shouldn’t be a problem; issues that ”appear” to be caused by size are the problems, and they’re solvable. In general, if more participation is a negative, there’s probably some other bottleneck we need to fix.

(Paraphrased:) Last time we tried to have an open meeting, we got a lot of off-topic questions on basic things we’ve answered a million times before.

Yeah, I can sympathize with that. The best solution I’ve found is to tightly define the meeting scope (“during this meeting, we are hammering out a mission statement” = by definition, we aren’t doing anything else) and ruthlessly defer things that are off-topic, but have one or two people offer to stick around after the meeting and take additional questions.

Another solution is to have meetings open to all, but only allow certain people to speak.

Also: make a FAQ.

The mailing lists have become a “catch-all” [and they're such a mess, we're going to split into separate blog sites for each topic].

I’d actually advise against this, from a community-building perspective. The olpc-ph list is still pretty low-traffic – it’s just that the traffic we get there is… well, lousy traffic. (My own posts are not exempt from this description.) There aren’t a lot of good email discussions there.

But people are there. So instead of starting separate blogs (or even separate mailing lists), we should start good conversations in the spaces we already have. When the good conversations are clearly bursting the mailing list’s attention capacity at the seams, or when they’re clearly being hurt by all the lousy conversations, *then* we start new things – generally, you want to tighten groups before you split them.

We need to work on our capacity (or volunteer model) to handle inquiries and cultivate our member base [before we open participation up to people outside this small group].

All the more reason to publicly discuss how we’re going to handle incoming volunteers/requests so that the folks who may be volunteering/requesting things from us have a chance to participate.

Mind you, I don’t expect many (if any) other people to join in – I think that if we’re lucky, maybe we’ll get 5 observers, 2 of whom might talk at some point. But we should give them the option! And publish full logs afterwards for the people who couldn’t come – we must default to transparency if we want other people to step up and take their own initiatives on this, because that is what is going to give us that capacity to handle inquiries and cultivate our member base. (I mean, I sure don’t want to handle all those inquiries and do all that cultivation on my own…)

An open meeting is our first full-step forward. If that’s how we want to do this entire thing, that’s how we should operate from day 1.

Communications of the ACM: OLPC analysis

Via Steve Jacobs: The Communications of the ACM has an analysis of what happened to OLPC. It has a lot of generalized statements – I’d like to have seen it backed up by more specific stories – but it is a good summary, generic as far as I can understand it.

Information technologies are not standalone innovations but… socially embedded systems, view the use of which cannot be isolated from the social and cultural environment or from local norms of practice… The fact that OLPC was much stronger in developing innovative technology than in understanding how to diffuse it may reflect the engineering orientation of the organization and its lack of understanding of the needs or interests of the nontechnical people who will ultimately buy and use the innovation.

I’d also like to see a similar thing written on Sugar Labs (now that it’s nearing its one-year anniversary) by someone with an MBA-like mentality who can step back and see more of an operational picture rather than just technology or education alone (though “learning” has to be the metric of success, order somehow).

As an aside to the students and alumni of my alma mater: I’m deeply thankful for the education I got at Olin. It didn’t necessarily teach me everything about how to make innovative technologies or how to diffuse them (what academic program can?) but it did teach me that I needed to learn both, and gave me the tools to do so. I feel like I can absorb a lot more learning from experiences like working on OLPC because of the things my undergrad years gave me to reflect on. Working on these kinds of things definitely showed me why our profs tried to teach us the way they did.

Finally, I do agree with this comment from Julian Bass:

The OLPC appears to prioritise a technocratic solution to what is essentially a social problem. Large scale educational change requires a social movement.

…and I suppose that’s why I’ve moved into community work over the past few years, though I didn’t realize that was what I was doing for quite some time. Sometimes you need to do technology work because the tools that people need to change things don’t exist. Sometimes you need to do policy work because they’re not legally allowed to. Sometimes you need to do journalism and marketing because they don’t know about it. Sometimes you need to do education work so they can teach themselves to understand. Sometimes you need to move between them all (and more), busting bottlenecks in whatever disciplines they come up in.

It’s interesting to watch people and organizations adapt to better save the world.

The Boston deployments need some help.

(The shortness of this post brought to you by RSI.)

The Boston deployments need some help. Here is what we have been up to lately. (Should I also post those updates on this blog?)

Boston deployments updates

Most of my life (and RSI-rationed typing time) this week was spent on

Not just CFS – visited 2 SoaS pilot sites with Caroline and have some tickets to file when I can type again tomorrow…

In other news, my immune system has declared war on spring (yay allergies) and I have my first jazz jam session in 14 hours. Jason Rock also made my day with a first mockup of multiply – see the feedback that he’s gotten, starting here with Frederick.

Hands in pain, typed too much writing all the CFS updates… need replacement for next week’s notes. Bedtime.

You teach… should I? Where?

The title of this post is the subject of an email I got from Colin, diagnosis an Olin College student and the organizer of Gurufest. He explained that he’d seen people in the OLPC and SL communities writing about their ongoing discovery processes and asking if he should do the same. If so, information pills what would be the best way to document what he’s learning about open-source community event organization? This was most of my email reply, cialis sale with hyperlinks added in.

You don’t know how happy it’s making me to hear you ask these questions. Yes, please do write them up! It’s useful to others, to your future self trying to do the same thing and demonstrating your mad skillz to potential donors/employers, and saves you time whenever someone asks “how can I do that too?” and you can send them a link. Where to put it? Here’s my usual strategy.

Post it in one place.

For me, this is usually either… (1) my blog, with appropriate tags turned on – are you on Planet Laptop or Planet Sugar Labs? If not, you should be; look for the link on the side that says “email the planetmaster” and send them a message with the URL of your blog feed. I can help with this if you need it.

(2) is a wiki page in mainspace. Mainspace is better than your userpage because it’s more findable. Think search terms and links and make sure your page is wikilinked to by other related pages. The [[Gurufest]] page, for instance, could link to [[How to run a Gurufest]], which would be a fine title.

Point everything else to that place.

Make sure everyone and everything else knows about and links to it. I already covered other wikipages. Also think about redirects. For instance, [[How to run a gurufest]] and other capitalization variants as well as [[Running a gurufest]], [[Gurufest howto]], and other phrase variants. You tend to reach diminishing returns on this pretty fast, and honestly, I’ll usually make 0-1 redirects each time I make a page, but it can be useful especially if a redirect gets used a lot. See the [[Jams]] / [[Jam]] redirect, for instance, or where [[Olin]] and [[IMSA]] redirect to and are linked from (what links to [[IMSA]] vs the original page, and what links to [[Olin]] vs the original page – note that you get the “what links here” from your redirects, too).

More important are mailing lists. Send the link to any lists you think would be interested with a short summary and a call to look, like “I thought others might be interested so I wrote up this…” and a “contact me if you have any questions” bit and a “please forward.”

If it’s a blogpost, link to it on your userpage. If it was a wikipage, blog it and link to it on your userpage.

And then don’t forget the power of pinging individuals. Email particular people you’d like to take a look at something and tell them why, and ask if they can edit/make comments/give feedback. Ditto for friends you find on IRC. It’s always neat to be able to see what your friends are working on.

Probably a longer answer than you wanted, but this is what’s worked for me – I’d love to hear tweaks if you have any ideas.

Any more tips/thoughts for Colin?

Working on the Boston pilots

Things I’m working on for the CFS pilot right now, there deliberately kept rough and unedited. Deployment work is messy behind the scenes, and sometimes you don’t have time to make stuff all professional and shiny-looking for the public eye – this sort of to-do list publishing would probably mortify a number of other organizers, but this is the sort of list I really work from

  • Get the tech teams in Boston to have interfaces that the loop team can work with and plan around, by way of nudging the loop team to have interfaces with external volunteer groups.
  • Make and maintain a tech status page up on the wiki where the questions “what’s happened so far? what’s happening now? how can I help with what should happen in the future?” can be answered at any point in time.
  • Support Yifan in her team’s efforts to get an XS up and running and the teachers trained on how to use it.
  • Ditto Sandra for the curriculum support and integration team (“curriculum team” for short).
  • Ditto Elsa and Colin for Sugar testing sprints.
  • There must be other teams in the Boston area who want to help with things… where are they now?
  • Schedule interview sessions with the teams working on the pilot, likely late this month after the XOs are deployed. I’m determined to have a behind-the-scenes “here’s how to reproduce what we did with this deployment setup” guide. My ethnographic and journalistic tendencies demand it. (Also my apparent love of pedagogic documentation.)
  • Stay on top of things and keep reminding people
  • Stay on top of things and keep reminding people
  • Stay on top of things and keep reminding people
  • Do all of the above extremely part time, largely remotely, with no actual authority, and with no income. (I consider myself to be paid in “learning stuff and doing interesting things.”)

In my craze to get things done and clarified and documented (while not being crazed and actually relaxing and cooking really good food and geeking out with music) I’ve largely dropped offline. My IRC hours have plummeted, and I’ve discovered that I’m functional without them – but that I miss them. They’re like hanging out with friends in the living room after a long day, which is nice since I increasingly come home to an empty apartment (and then jog in my coat until my room heats up, after which point I stay in my room as the “has habitable temperature” location of the domicile). So now I’m productive in a way, but out of touch with the rest of the community – so many things to balance.

As a side note, I constantly wonder why I’m learning about project management; a few years ago, when I was still in engineering school, I would have told you that the last thing I wanted to become was a manager – what you need is hackers who can get stuff done. Turns out that sometimes you need more than hacking to get stuff done… so now I’m adding another perspective to my toolset. It doesn’t excuse you from non-meta work, though; I’m still bushwhacking wiki pages, hammering at builds, proofreading volunteering invitations.

When you can’t tell people what to do, you make it really easy and appealing for them to do the stuff you want them to do. (And if it’s really easy and appealing, at that point you might as well also help them do it.)

Deployment tech teams need ticket trackers too

We’ve got a problem and would like a less hackish way to fix it. Help!


We’re a coalition of teams in Boston dedicated to various aspects of local deployment tech support. Right now, page nearly all the people involved are students at Olin College, ophthalmologist there’s a lot of overlap between the memberships of teams, prostate and we only have one active deployment at the Cambridge Friends School which, in this case, is coordinated by a Harvard-based loop team called One For All; the loop team serves as the contact point between the school and all these independent teams of volunteers.

But we digress. We’ve got a lot of things To Work On, and they’re floating around in a Nebulously Undefined Cloud that occasionally emits noises that sound a lot like “we have stuff to do, but we’re not really sure what stuff needs to be worked on now.” Most of our volunteers are busy students or working people who don’t have the bandwidth to constantly keep up on what’s going on. Every time they cleared a block of time (intermittently available, not-necessarily-at-regular-planned-intervals) to volunteer, they had to go through a huge overhead of asking around and finding out what needed to be worked on, where to get the resources to do it, who they had to give what to by when, how they would know when they were done…

If only there was a way they could, at any given moment, look at an open list of well-defined to-do items with deadlines, explanations of the milestones they’re working towards, and all of the resources and contact information someone would need to pick up the job and do it…

Our current hack:

A few of us got fed up with this one afternoon, sat down and made a wiki status page with some tasks, and started driving a schedule of more regular check-ins (schedule still stabilizing, but getting there).

There are obvious scaleability problems with this. Beyond this pilot, beyond these short-term deadlines, we have no way to track our to-do list without going insane. Even now, managing the page by editing it is a pain. Watchlisting the entire page for email updates (so we won’t forget) sends us a message any time any task is changed, not just the ones we care about.

Is there a better way?

This sounds like a job for a ticket tracker. We set up a temporary Trac instance on Colin’s shared server account and are moving towards that for our second temporary solution – I say “temporary” because it’s a pain in the neck to set up and maintain, and takes time away from what we want to focus on (serving the technical needs of local deployments).

What we’d really like is to have a ticketing instance hosted elsewhere, administered by Someone Else. We don’t really care who. We don’t even really care what platform it is (RT, bugzilla, Trac… whatever), as long as it’s for deployment tickets rather than code bug-tracking. We’ll have tickets like “install the Maze Activity on all of Mrs. Johnson’s class’s laptops” – not a bug but a to-do item- as opposed to “Maze feature such-and-such is broken, please fix” (which we’ll file upstream in the appropriate development bugtracker if we find it). Deployment tickets, not development tickets.

This would make a great community-group service for Sugar Labs, olpcfriends, or a similar group to offer for deployment groups – a set of conditions (who’s eligible, what maintenance you must provide, what terms of usage you have to agree to) for getting Trac hosting with certain features and services provided, and a handy subdomain ( for access. This shouldn’t seem like such a strange idea; Sugar Labs already does it for code hosting.

O Metabrain, what can we do?