I thought this was a great point from last week's discussion that deserved a shout-out:

"Remember however that some (high level scripting) software will effectively become learning materials - any code the students are asked to edit - and should be treated as learning materials." --Joe

One of my personal favorite things about the XO being open-source is that the entire machine, turns into a 3.2lb green box full of learning materials. The increasingly blurring line between Activities and Content Bundles (regarding how they're treated in software) is a good example of this.

Now, about bounties, and solving the problem of how to get people to do things that aren't glamorous (such as "make gforge work")...

Listening in on Doc Searls in the #berkman backchannel last week made me think again about why bounties have not been historically useful with OSS development. Doc brought up that a lot of open-source work is done by geeks scratching their own itches, and that bribing somebody to scratch an itch they don't have doesn't really work.

But that's the point of bounties. They are supposed to move the itch. Now the itch you have to scratch is not "I want to fix this for myself," but "I don't have that reward, I'd like to have it." Rewards can be financial, status recognition, or some good thing happening to someone else you care about ("I fixed this problem for my friend/a child in a 3rd world country.")

But that doesn't seem to be happening - I come across bounty site after bounty site for OSS with no recent activity. Maybe there is one I'm missing that's prolific and alive, but there doesn't seem to be a dedicated bounty site that gets good results across multiple OSS projects - most work on a project, bounty or not, seems to be done by hackers already within their communities...

...and this, I think, is what the bounty sites are missing.

One emotion often associated with OSS communities is their sense of independence and grassroots-driven-ness; the sense that they built their own identity and are centralized in their own (online) location. So I can see a centralized bounty system falling flat with NIH syndrome, unless it's offered as something each project can incorporate/control inside their own systems. (Can you imagine Trac existing only as a "we'll host it for you" service, rather than having projects install, manage, and configure their own installations and write plugins for them? Scratch your own itch mentality is there.)

I talked about emotion earlier. Emotion is important.

If bounty sites fail because they don't have bugs that hackers want to fix, because it's not an itch they want to scratch, we have to think about what makes people think bugs are important for them to fix. Debasis Pradhan has a good answer: it's emotion. You spot a bug by the emotional reaction you have to it. Frustration. Surprise. Rage against the machine.

So maybe one issue with bounty sites is that they treat OSS development as a purely economic activity without emotions as a motivational driver in that market.

All right. So what might be good requirements for a solution to the set of problems bounty sites are trying to solve?

  1. It must create emotional attachments between hackers and the bugs you want them to fix. Make it really their itch to scratch; don't pay them to scratch an itch they don't feel. ("Why would I scratch my behind for no apparent reason? I don't care if you're going to pay me for it. That's absurd.")
  2. It must consider community identity, and work on building the identities of the communities it serves, rather than creating its own centralized brand.

What else? And then - of course - the question: "How does this apply to OLPC?"