Open source education

Graham Glass wrote a blog entry this week that touched on two of my favorite themes: open source and education. In the middle of a project based on the red-hot Ruby on Rails platform, he took time out to explain how he found, and worked around, a Rails limitation. Digging down to the roots of the problem took six hours of investigation. Crafting the work-around took just six lines of code.

Glass is one of the more dynamic figures in the software world. At his first company, ObjectSpace, he created the Voyager object request broker. In his next venture, The Mind Electric, he created GLUE, a Web services toolkit, and GAIA, a services fabric. He became CTO of webMethods when it acquired The Mind Electric and then left to start yet another venture. This time he aims to bring much-needed software innovation to the world of education.

It says a lot for Ruby, the dynamic language that’s giving Perl and Python a run for their money, as well as for Rails, the application framework that made Ruby famous, that such a savvy software veteran would choose to bet his next business on these open source technologies. It says even more about the nature of the open source process, as well as the future of education, that he would not only propose an improvement to Ruby on Rails but also publish the analysis that led to his proposal.

Open source software development, to a degree unmatched by any other modern profession, offers apprentices the opportunity to watch journeymen and masters at work, to interact with them, and to learn how they think, work, succeed, and fail. Transparency and accountability govern not only the production of source code but also the companion processes of design, specification, testing, maintenance, and evaluation.

When I read that Glass had spent six hours researching his problem, I thought, “Graham’s human!” It always takes me a long time to learn my way around an unfamiliar code base, but I often imagine that superstar programmers just intuit things directly. Likewise, when he noted stylistic problems he saw in the Rails code, I thought, “The Rails guys are human, too!”

When I read that the outcome was six lines of code, I recalled the old saw about the tradesman whose customer gripes about being billed a one-hour minimum for fixing a problem in five minutes. “Yeah,” he retorts, “but it took me 20 years to learn how to fix it in five minutes.”

It’s typical of many professions to cultivate an aura of infallibility and monopoly control of information. Open source doesn’t work that way. There are prima donnas, to be sure, but the culture requires practitioners to show their cards, and it erodes information monopolies. Shared code is just the tip of the iceberg. Below the waterline, there’s a vast body of shared knowledge and tradition, grounded in what Tim O'Reilly calls an architecture of participation.

We’ve come to see open source as an economic innovation. Cooperative production of commodity infrastructure paves the way for competitive production of high-value products and services. Perhaps we’ll someday see open source as an educational innovation, too. Cooperative production of shared knowledge isn’t just a by-product. When apprentices, journeymen, and masters engage in a continuous cycle of learning and teaching, an old approach to education is made new again.