This OLPC project seems to be going pretty well. G1G1 2008 just finished, there are a number of successful pilots going on, and a number of larger-scale pilots will come online this spring and coming summer.
Still, there is a big gaping whole in the middle of our little education project. There just aren't enough activities. Mind you, we have some seriously awesome activities such as Etoys, Scratch, TamTam, and others. We have tremendous depth but very limited breadth.
By breadth, I mean interactive activities for language, history, geology, health, etc. In order to expand the range of activities, we need to recruit a lot more activity developers and make it dead-simple for them to contribute.
EToys can do a Lot
But Which Developers?
Let's think about who we want to recruit. We're talking about breadth here so we need experts on Nepali grammar, Pashto vocabulary, Philippine history, and Andean geography. The good news is that there are technically-oriented people out there that know these things and want to help.
We already have a hardcore team of dedicated hackers. We need them for the work that hackers excel at: building infrastructure, testing the limits of new systems. But now we need a different class of developer, those that are focused on the presentation, game play and not system internals.
Based on these characteristics, let's call these people designers. The good news is that there are lots of designers-particularly in developing countries-that want to contribute to OLPC. The bad news is that they don't know python. or GTK+. They may not even be familiar with linux. They do know HTML, CSS, Javascript, and Adobe Flash. Allow me to explain.
Due to rise of the Internet and related boom in outsourcing, the vast, vast majority of programmers in developing countries are web developers (according to my own grossly unscientific survey). The rise of the Internet has also led a lot of talented graphic designers in developing and developed countries to learn web technologies. I even
wager that CSS/HTML/Javascript will become the de facto GUI technologies in a few years time. PyGTK won't take over the world nor will VB.net.
The popular term for this triumvirate of technologies is AJAX, with the difference that AJAX applications typically require communication with a remote server. I propose using web technologies for completely offline activities. Adobe's Flash is basically a variant of AJAX that uses dialects of Javascript (Actionscript) and XML (MXML).
Very few programmers in the developed world get paid to write desktop linux apps. Still, open-source developers find learn and build pygtk, mono, and KDE apps in their free-time. Developers in the developing world are extremely enthusiastic about FOSS but not nearly as prolific in creating open-source software due to a phenomenon I
call the "FOSS-Nepal Paradox."
The FOSS Nepal community has won the award for best celebration of Software Freedom day for two years in a running. Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce.
Open-Source is Expensive
Open-source software voraciously consumes a resource even more valuable than hard cash, programmer time. Linus Torvalds could afford to spend some of the most productive years of his life working without immediate financial benefit. He could slack off in his classes without fear of unemployment upon graduation. I doubt his parents were counting on him to support them financially once he got a job.
Most talented Nepali programmers I know do not have those luxuries. They are under a lot of pressure to support their parents and extended families, financially and otherwise. So Nepalis, Bangladeshis, Peruanos, etc. certainly have the passion and ability to contribute to open-source but their free time is significantly more limited.
This doesn't mean that we should rely on developers from rich countries. We simply need to radically lower the amount of time required to create learning activities. I believe that many, many developers in the developing world can contribute 3-5 hours per week. To make those few hours productive we need to rework the default activity framework.
From what I can tell, the primary design goals of the default PyGTK activity
framework are as follows:
- Give the programmer maximum flexibility
- Fully exploit the XO's hardware features
- Mesh nicely with Sugar
These three goals are laudable and their hacker roots are obvious. The problem is that these goals maximize the technology's potential rather than programmer productivity. We need reach beyond the vi/emacs crowd (Note: I wrote this article using emacs) to thos folks that the masters of Photoshop, Adobe Illustrator, Eclipse, and GIMP.
I propose a new set of design goals:
- Allow activity designers to quickly build activities utilizing widely-used tools.
- Quickly reward effort with working behavior
- Mesh nicely with the Sugar UI
It's OK to be Opinionated
We need an opinionated activity framework that makes infrastructure choices for the designer so that she can focus presentation and gameplay. Some may recognize this as the principle of Convention Over Configuration, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly.
Establishing an "opinionated" activity framework will in no way limit the freedom of those hackers who want to go their own way. They can always build their own activities from whatever tools they choose. The whole point of a framework is to help people get started quickly but it doesn't constrain anyone.
This concludes part I. Here are some tantalizing morsels from Part II
of "How to Make Activity Designers Happy,"
- Where it's at: HTML, CSS, Javascript, and *gasp* Flash
- Nepal's Content Development Experience
- Aren't Kids going to create all learning activities so we don't have to?
Bryan Berry is the Technology Director of OLE Nepal and deadbeat co-editor of OLPCNews.com.
A lot of work has been put by the author into a very detailed, but ultimately useless plan.
Any education project created and guided by people who lack the knowledge and experience of professional educators ("professional" as in actually having a college degree in education - hacking is possible and harmless in programming, but not in education) is doomed to failure.
The OLPC Project has suffered a lot because it ignored the need for actual educators providing the knowledge and input necessary to give these laptops a chance of becoming a useful device for educational purposes. The author's idea is just more of the same wrong-headed approach: "let's throw more content at them; education will happen by osmosis".
Sorry, it doesn't work like that.
"Any education project created and guided by people who lack the knowledge and experience of professional educators ("professional" as in actually having a college degree in education - hacking is possible and harmless in programming, but not in education) is doomed to failure"
Possibly correct
However, conversely, professional educators have also failed to produce a single successful international project to provide universal use of ICT in education - almost every country is worried about the low level of ICT use in their education system.
Let's not get too high and mighty about success and failure.
"However, conversely, professional educators have also failed to produce a single successful international project to provide universal use of ICT in education - almost every country is worried about the low level of ICT use in their education system."
I have had the privilege of working with professional educators and ICT specialists. Both the ICT people and the educator's matched each other in utter ignorance on the other field. In the end, it worked out successfully.
What I did learn (again) was that nothing moved until the programmers were able to present an example (RAD) application. So the initiative seems to lie with the programmers.
Winter
Additionally, the proposal simply substitutes one programming environment for another (and the new one is less well supported by the XO's current software build). The basic problem is NOT that the programming LANGUAGE is hard to learn; it's that the programming ENVIRONMENT is un(der)-documented. Learning to code in Python isn't hard; learning to use the Activity class properly and make sensible API calls to the Sugar environment is.
"Open-source software voraciously consumes a resource even more valuable than hard cash, programmer time."
I think the author has it backwards, squared.
Open Source is the biggest time saver of all. Because you can exchange code with other projects. Proprietary projects always run against license problems and therefor they have to develop too much in house.
Linux could be collected because vast libraries of code code be incorporated. An example in point is the large collection of drivers.
Vi/emacs crowd? Where do you live?
Name an IDE and some open source is developed in it. Python is currently second only to VB as a scripting language for complex tasks. And VB is not an option. Writing the XO in C++ will not attract more developers. (Javascript is out of the question, and I would not advocate Perl for it).
If your point is that you want to move away from open source, say towards Flash, then the project dies immediately. Simply because for proprietary platforms you have to pay developers out of your own pocket. And if you are not Adobe or MS, you won't have the capital to pay for a new GUI on a closed platform.
Winter