Criticism of the OLPC XO-1 concept

In John C. Dvorak's PC Magazine article "One Laptop per Child Doesn't Change the World", he writes:

Does anyone but me see the OLPC XO-1 as an insulting "let them eat cake" sort of message to the world's poor?

I like Dvorak and I often follow him on the TWiT podcast and CrankyGeeks on TiVo, but he polarizes issues in ways that sometimes aren't that useful, except for bringing attention to an issue. Hopefully the audience is paying enough attention to think for themselves, but that has proven repeatedly not to be the case.

In my view, if some service like "Mechanical Turk" pays living wages for these folks, then it was worth it. On average and over a lifetime, each of these students should be able to earn more than the cost/value of the computer.

Yes, the literacy rates and language barriers are an issue in making the computers useful at all. There would be, however, huge motivation to focus on literacy and additional languages, if some people are able to earn money with these machines.

So, Dvorak has given all of us XO enthusiasts a mission: enable students to make money using these machines by providing services like Mechanical Turk in the languages of the students and figure out how they can collect the resulting goods.

OK, I admit, this isn't a perfect idea. I've heard concerns that these laptops will be stolen if a market emerges for them and having them be a source of money would certainly make them valuable. This is also, to a degree, advocating some sort of child labor, which is a reality, despite the many objections we have in the developed world.

Better ideas?

Blogger Beta Ships OpenID

Google has added new login options to Blogger, including OpenID. This is an important additional baby step towards a web with a single sign-on that allows you to have better control of your identity information.

read more | digg story

N810 demo video from Nokia

Nothing too special about the web page, but the video gives lots of good angles and pictures of accessories. Sure would be nice if they used that GPS and a database to help find some WiFi hotspots. Too bad it doesn't have WiMax or EV-DO.

read more | digg story

Accessibility is the killer mashup/webos application

After watching Douglas Crockford (of Yahoo and JavaScript fame) plea for Google, Microsoft, and others to participate in a mashup summit and reading some of the feedback around the web, I realized the critical application use-case is still missing.

Someone in the Q&A brought up a good example of a mashup implemented today in an undesirable method due to security reasons: Facebook accessing your GMail/MSN/... contacts to request more members. Contact sharing between applications is an excellent use-case for mashups, but I don't see it as a driving application. Certainly it gets to the heart of Crockford's talk: security is an excellent application for the Google Gears WorkerPools. If you are like me, you'll still be left thinking about how everyday web consumers will be motivated to download Gears, instead of walking down the questionable path of simply giving applications like Facebook access to all of your potentially private information.

Mashups are the most interesting innovation in software development in decades. Unfortunately, the browser's security model did not anticipate this development, so mashups are not safe if there is any confidential information in the page. Since virtually every page has at least some confidential information in it, this is a big problem. Google Gears may lead to the solution.

Security is important and is critical to the growth of new mashup applications and I'll be happy if that alone brings us worker threads and off-line support, but I think the killer mashup is the one that makes all of this great data exposed through APIs and structured web pages and makes it accessible in new ways.

Mark, of diveintoaccessibility and diveintogreasemonkey fame, who I admire for his vision of accessibility wrote in his blog post "if wishes were iPhones":

I don’t understand this continuing obsession with buying things that you need to break before they do what you want.

And with this thought I am reminded that the killer mashup/webos application is the one that takes all of those immensely useful web services out there and makes them measurably usable. And by usable, I mean giving the user control.

Mobile 2.0 Conference

I'm thinking about trying to attend the Mobile 2.0 Conference on October 15th in San Francisco. Anyone have comments about this event? If there were a handful of people interested in chatting about how to enable creation of scalable web services generated from mobile/embedded devices, I'd make a point of going.

No server, no satisfaction

There's just no satisfaction for the casual home user who wants to collaborate with friends. Even when dealing with a problem that has been solved many times over, it is really difficult without a server of your own and a fair amount of programming. The problem I'm talking about is planning events on a group calendar.

There is a group of somewhat over 25 people near where I live that frequently gets together to play outdoor roller hockey. We play in a parking lot in one of the area parks or offices. We have a mailing list on Yahoo, but most people are just copied on a repeatedly used e-mail thread. On that thread, the subject line is typically changed to match the proposed day and time. Every week, we all bombard each other with e-mails to make sure that enough of us are coming out to play. This has actually worked fairly well, but there have been some significant exceptions.

Sometimes we don't meet our threshold of 6 players and additional e-mails go out to entice people to sign-up to play. Calls are made. Threats are discussed. People who previously agreed to go attend might decline since they don't want to risk trying to play hockey with only 3 people. Chaos ensues.

One of they guys who used to come out regularly created a really simple sign-up page on a website. The site accepted a name, e-mail address, and phone number to sign-up for a given game. The name is listed beside the entry for that game. The e-mail was used to send out the "game-on" or "need-more-players" notification a few hours before the prospective game. Phone numbers were included to speed up the communication.

The application worked quite well and was simple-minded. Entering the same sign-up information twice would result in being removed from the list. The phone number and e-mail information had to match, providing a tiny amount of security from folks simply removing everyone from the list. No verification of the entry was done, but you can imagine a simple verification code being provided via SMS to the mobile phone number if we ever started to have problems with that. Life was good.

He stopped playing and his site stopped working. We were back to using e-mail. A few folks reminisced about the good 'ol days when we had our own web server. I own the domain name, so I decided to bring back the sign-up sheet. Where should I host it?

I don't really like the idea of pointing people to my home computer, so that's not my first choice. I don't really like the idea of paying for a full-featured (LAMP and/or Ruby enabled, ie. scripting and a database) hosting service just for this hobby. This is just calendar data! Why should I need a web server to do something that Yahoo and Google provide for free?

Our mailing list is on Yahoo, so I looked first at their group calendar. It was a disastrously complex to use and didn't provide any of the custom features we had with the much simpler web app. Similar problems were had with Google's calendar and Evite. The most fundamental issue with all of these calendaring solutions: they required account creation and login to utilize.

I tried to see if I could do something with static hosting, but it seems even Amazon's simple queuing service doesn't seem to work without having a dynamic host. At this point I gave up, but I'll get back to this application yet.

Still don't get the whole WebOS thing?

I've gotten a bit smarter about explaining why there will be a sort of emerging web operating system to the people who inquire. For example, I've started calling it a "web services kit", instead of an operating system. Today's tech savvy minds can accept the idea of yet-another-SDK, whereas the idea of a web operating system is either tainted by the webtops or seen as inconceivable and unnecessary delusions to compete with Windows, Linux, or OSX.

What I haven't leveraged enough is the great summary of web service APIs provided by ProgrammableWeb. From their simple scorecard, you can get a quick overview of the categories of popular services and some of the key players. Ask yourself what sustainable advantage do any of these players have within their service space. Don't get fooled, it isn't an easy question. Keep in mind that standard service definitions are coming into existence for most of these services, such as XMPP for chatting and OpenID for identity. Take up the exercise to look across these service APIs, look for winners, and look for emerging standards.

Comfortable? Now, realize that it is only a matter of time before there are standards-based implementations of all of these services. Sure, it might take a while, but it'll happen.

If you are quick, you might be sighing and thinking to yourself, "what about the data?". I'm glad you asked, because that is really the point. These services are all about controlling access to data and looking for ways to monetize it. You might stumble over the idea that on-line office applications involve an incredibly complex pile-o-code, but then you'll remember that you already have 2-3 other viable choices of office applications to which you already had access. Over the long-term, it is all about the data.

Still don't feel like you're any closer to accepting the idea of a web operating system? That's okay, as long as you recognize the benefit of something that provides you with the capability to control and monetize access to data and some sort of well-understood integration layer back into your application. You'll come around when you start thinking about who you want to own your data.