Spicy take: I always got the feeling OLPC was a FSF-adjacent scheme to embezzle UN money and put it into eye-in-the-sky perennial Linux desktop dreams. The machines felt overdesigned and Sugar dog slow on them. Things like Open Firmware on x86 or the mesh networking were masturbatory and served little purpose. Promises like the pen-on-trackpad or Sugar’s ease of live application modification were never met. There never was any sort of curriculum; HW was shipped with no plan.

I will admit that the screen on them is excellent though. Pixel Qi should have taken off.

What they should have done, IME, is acquire whatever cheap used high-end business laptop hardware was at the time, (fairly reliable, faster than the anemic Geode in XO-1, and cheap too) and design a curriculum with it so teachers have something to do with the machines, rather than be thrown overboard into it.

edit: Something else I did find interesting: The Mac OS X offer. That seems clearly to me, to be Jobs wanting to create iPad, using OLPC as its vehicle.

I have one of these sitting on a shelf in my closet, given to me several years ago by a friend who bought it during the “Give One Get One” program. I remember following this project but was a broke student at the time so I was interested in trying it out and seeing what they got right and where it went wrong.

As you detailed, there’s a lot of interesting ideas in this unit (with questionable motives for their inclusion in the design). There was too much groupthink around doing something new and cool, and using specific technologies that weren’t ready for prime time. This led the project away from it’s goal of actually shipping something successful to kids (at least out of the box). I remember when I first read that they were developing Sugar in Python and wondering why anybody would do that. Python at the time was super slow compared with how it is now and there were much better choices for developing a full desktop environment. In addition, the RedHat distro it was based on had too much bloat. These were not fast machines and every clock cycle counts.

When I was a kid in the 80’s, I could turn on my Commodore 64 and get a Ready prompt right away, and start typing Basic programs. Commercial games and programs loading from cartridge were fairly instant as well. I feel like the rugged industrial design of OLPC was the right direction and they totally missed the boat on software. The night I got the OLPC from my friend, I checked out, built, and flashed the latest version of the OLPC image. I cannot overstate how disappointed I was with how long Sugar took to boot up.

Honestly, I’m not even sure computers would’ve kept my interest as a kid had my Commodore taken that long to boot to be usable. Even programs loading from 5¼” floppy disk or cassette tape were faster. Sugar had a lot of neat functions, but the delay to get to a very slow desktop and then to switch to each task rendered the device useless as shipped. This was a project I wanted to believe in, but it really went off the rails.

I always got the feeling OLPC was a FSF-adjacent scheme
The FSF HATED OLPC once the microsoft deal was announced.

Open Firmware on x86
This was mainly because they had weird custom hardware, and were trying to be free/open.

mesh networking
Looked like it was going to work at first, but they were plagued by problems with the wifi daughter board not having a good or consistent interface. This was well well before there were devices like the ESP8266 or common WIFI-on-a-chip boards. I believe they ended up using the same wifi board as the first xbox wifi adapter.

Sugar’s ease of live application modification were never met
That was met by early 2009, implemented by Chris Ball I believe. View-source was a regularly used and well distributed feature. Perhaps you were only using the earlier G1G1 Sugar releases?

acquire whatever cheap used high-end business laptop hardware was at the time
Have you tried to reflash and rehabilitate a laptop? It takes a while. It takes much much longer if you don’t have exactly the same hardware. Unpacking and installing on arbitrary machines would have taken a lot longer than you think, and wouldn’t have worked in many of the enviroments the machines were shipped to.